From dholmes at openjdk.java.net Thu Oct 1 01:22:16 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 1 Oct 2020 01:22:16 GMT Subject: RFR: 8253429: Error reporting should report correct state of terminated/aborted threads [v2] In-Reply-To: References: <5n1FG7ZdpZblWlv7-4An1W-mUTFhw3ugf2b85X-ALeQ=.e8a38616-ca96-4d4e-83e8-a886bafa9f92@github.com> Message-ID: On Wed, 30 Sep 2020 20:17:46 GMT, Zhengyu Gu wrote: >> For some non-JavaThread, their object instances can outlast threads' lifespan. For example, we still can query/report >> thread's state after thread terminated. >> But the query/report currently returns wrong state. E.g. a terminated thread appears to be alive and seemly has valid >> thread stack, etc. >> This patch sets non-JavaThread's state to ZOMBIE just before it terminates, so that we can distinguish terminated >> thread from live thread. >> Also, thread should not report its SMR info, if it has terminated or it never started (thread->osthread() == NULL). >> >> Note: Java thread does not have such issue, its thread object is deleted before thread terminates. > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Update This version looks good to me. Thanks for the updates. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/341 From vromero at openjdk.java.net Thu Oct 1 01:31:04 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 1 Oct 2020 01:31:04 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v9] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: <0aKjS2ruCGPqJsSjll3RsknZpCuGsAkrQaANwVqPTMs=.b9628de2-6f3e-41d0-9c59-6b85dd6d71f5@github.com> > Co-authored-by: Vicente Romero > Co-authored-by: Harold Seigel > Co-authored-by: Jonathan Gibbons > Co-authored-by: Brian Goetz > Co-authored-by: Maurizio Cimadamore > Co-authored-by: Joe Darcy > Co-authored-by: Chris Hegarty > Co-authored-by: Jan Lahoda Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: remove unnecessary jtreg tags from tests, remove othervm etc when applicable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/76e3d278..7501148d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=07-08 Stats: 102 lines in 54 files changed: 33 ins; 19 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Thu Oct 1 01:33:58 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Thu, 1 Oct 2020 01:33:58 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v3] In-Reply-To: References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Wed, 30 Sep 2020 08:54:14 GMT, Chris Hegarty wrote: >> test/langtools/tools/javac/records/LocalStaticDeclarations.java line 33: >> >>> 31: * jdk.compiler/com.sun.tools.javac.util >>> 32: * @build combo.ComboTestHelper >>> 33: * @compile LocalStaticDeclarations.java >> >> This, and other, explicit at compile tags could be elided, no? The test source file will be implicitly compiled by the >> at run tag. I believe that the explicit at compile tag was added original so that the enable preview and source version >> options could be passed to javac - neither of which are needed any more. > > Does this test need an @run tag rather than an @compile tag ? ( the @run with implicitly compile the source file, > before running it ) @ChrisHegarty I have created commit [7501148](https://github.com/openjdk/jdk/pull/290/commits/7501148dd4c21847699a84d6dc5ef100d993b78d) to address this issue, thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From dholmes at openjdk.java.net Thu Oct 1 01:40:24 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 1 Oct 2020 01:40:24 GMT Subject: RFR: 8253843: AArch64: Use ishst for storestore barrier In-Reply-To: References: <4bvHnsfvpM8MDmGCQgOkn2ovdeeGLJO5Vh8tYR9p2mc=.4563c186-e164-4295-a49b-06ce715fef72@github.com> Message-ID: On Wed, 30 Sep 2020 11:31:26 GMT, Alan Hayward wrote: >> There doesn't seem to be an AArch64-port label. Is there any way to get AArch64 patches posted to the AArch64-port-dev >> mailing list? > > I'm also getting CI failures unrelated to this patch, due to disks being full: > https://github.com/a74nh/jdk/actions/runs/280072223 PRs for mainline should be reviewed on mainline mailing lists. The xxx-port mailing lists are supposed to be used for changes applied to port specific repositories, hence the is no label mapping for them here. You can of course reply directly to the PR email and add the additional mailing list. ------------- PR: https://git.openjdk.java.net/jdk/pull/427 From stuefe at openjdk.java.net Thu Oct 1 03:53:21 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 1 Oct 2020 03:53:21 GMT Subject: RFR: 8253429: Error reporting should report correct state of terminated/aborted threads [v2] In-Reply-To: References: <5n1FG7ZdpZblWlv7-4An1W-mUTFhw3ugf2b85X-ALeQ=.e8a38616-ca96-4d4e-83e8-a886bafa9f92@github.com> Message-ID: On Wed, 30 Sep 2020 20:17:46 GMT, Zhengyu Gu wrote: >> For some non-JavaThread, their object instances can outlast threads' lifespan. For example, we still can query/report >> thread's state after thread terminated. >> But the query/report currently returns wrong state. E.g. a terminated thread appears to be alive and seemly has valid >> thread stack, etc. >> This patch sets non-JavaThread's state to ZOMBIE just before it terminates, so that we can distinguish terminated >> thread from live thread. >> Also, thread should not report its SMR info, if it has terminated or it never started (thread->osthread() == NULL). >> >> Note: Java thread does not have such issue, its thread object is deleted before thread terminates. > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Update LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/341 From mdoerr at openjdk.java.net Thu Oct 1 08:47:32 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 1 Oct 2020 08:47:32 GMT Subject: RFR: 8253824: Revert JDK-8253089 since VS warning C4307 has been disabled In-Reply-To: References: Message-ID: <8-JlCnglDJsCsJuAICPsi1KQWzo7w6fu0JFx29gltMk=.48dbc99e-4c75-4d5e-944c-7886842680ed@github.com> On Wed, 30 Sep 2020 08:09:39 GMT, Aleksey Shipilev wrote: > This reverts commit 3f455f09dc738b7c76210c1080df2aaa8e19a19d. > > Testing: > - [x] Linux x86_64 {fastdebug,release,slowdebug} builds > - [x] Windows MSVC 2017 build (tested by Martin Doerr) Looks good and builds with VS2017. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/426 From shade at openjdk.java.net Thu Oct 1 08:47:32 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 1 Oct 2020 08:47:32 GMT Subject: RFR: 8253824: Revert JDK-8253089 since VS warning C4307 has been disabled In-Reply-To: <8-JlCnglDJsCsJuAICPsi1KQWzo7w6fu0JFx29gltMk=.48dbc99e-4c75-4d5e-944c-7886842680ed@github.com> References: <8-JlCnglDJsCsJuAICPsi1KQWzo7w6fu0JFx29gltMk=.48dbc99e-4c75-4d5e-944c-7886842680ed@github.com> Message-ID: <3AsYJPnxtp87FKUtoc8AmQAa8c4x6LB9xOk3Ucnt_cA=.20888dbc-4166-4844-b5d7-3cf899cc0288@github.com> On Thu, 1 Oct 2020 08:42:54 GMT, Martin Doerr wrote: >> This reverts commit 3f455f09dc738b7c76210c1080df2aaa8e19a19d. >> >> Testing: >> - [x] Linux x86_64 {fastdebug,release,slowdebug} builds >> - [x] Windows MSVC 2017 build (tested by Martin Doerr) > > Looks good and builds with VS2017. Thanks for testing, @TheRealMDoerr! @iklam, want to take a look? ------------- PR: https://git.openjdk.java.net/jdk/pull/426 From aph at redhat.com Thu Oct 1 08:53:30 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 1 Oct 2020 09:53:30 +0100 Subject: RFR: 8253843: AArch64: Use ishst for storestore barrier In-Reply-To: <4bvHnsfvpM8MDmGCQgOkn2ovdeeGLJO5Vh8tYR9p2mc=.4563c186-e164-4295-a49b-06ce715fef72@github.com> References: <4bvHnsfvpM8MDmGCQgOkn2ovdeeGLJO5Vh8tYR9p2mc=.4563c186-e164-4295-a49b-06ce715fef72@github.com> Message-ID: On 30/09/2020 17:29, Alan Hayward wrote: > AArch64 orderAccess uses gcc built in atomic functions, which expand > inline to DMB barrier instructions. Specifically, they call the following: > > FULL_MEM_BARRIER -> DMB ISH > READ_MEM_BARRIER -> DMB ISHLD > WRITE_MEM_BARRIER -> DMB ISH > > However, storestore should be optimised to use ISHST. > > In addition, __sync_synchronize is marked as legacy. See: > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html > > In order for the code to match, To match what? > I switched everything to call dmbs directly. We are now able to use modern C++, which means that we can use real C++ atomic operations. Going back to inline asms would be a regression. The trouble with using asms for this is that the compiler does not know what is going on inside an asm. If you use an asm with a memory clobber for a StoreStore barrier, the compiler has to treat the asm as a full memory barrier, so it cannot move any loads and stores across the StoreStore. So, paradoxically, you might be making things worse. > Also, add AArch64 to the orderAccess documentation table. Please don't. it's more complicated than that, and it's not necessary. -- 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 shade at openjdk.java.net Thu Oct 1 09:13:26 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 1 Oct 2020 09:13:26 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v5] In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 09:37:41 GMT, Severin Gehwolf wrote: >> Account for interface files for swap and memory being reported independently. >> The cgroup v1-like value is now reported by adding the memory.max value to >> the memory.swap.max value. >> >> Testing: Container tests on Linux x86_64 on cgroups v2 with crun 0.15 > > Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From sgehwolf at openjdk.java.net Thu Oct 1 09:28:35 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 1 Oct 2020 09:28:35 GMT Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported incorrectly [v5] In-Reply-To: References: Message-ID: <1Mxt3m-eu_X4vjWZ2Q4lZtaFhQDd7_J5oOaHsC6bZlM=.9c61625f-e263-4b6f-b95b-4a9775c20cee@github.com> On Thu, 1 Oct 2020 09:11:05 GMT, Aleksey Shipilev wrote: >> Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. The pull request contains one new >> commit since the last revision: >> 8253727: [cgroups v2] Memory and swap limits reported incorrectly > > Marked as reviewed by shade (Reviewer). Thanks for the review, @shipilev! ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From stuefe at openjdk.java.net Thu Oct 1 09:29:35 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 1 Oct 2020 09:29:35 GMT Subject: RFR: 8253889: Remove ExecMem constant Message-ID: Hi, may I have reviews please for this trivial cleanup. ExecMem is defined in os.hpp as: // Executable parameter flag for os::commit_memory() and // os::commit_memory_or_exit(). const bool ExecMem = true; and only ever used as "!ExecMem" parameter value to the "executable" argument in calls to os::commit_memory(). Maybe it did something in the past. Now it just seems to be a complicated way to say "false". ------------- Commit messages: - initial commit Changes: https://git.openjdk.java.net/jdk/pull/454/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=454&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253889 Stats: 26 lines in 13 files changed: 0 ins; 4 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/454.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/454/head:pull/454 PR: https://git.openjdk.java.net/jdk/pull/454 From sgehwolf at openjdk.java.net Thu Oct 1 09:32:00 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 1 Oct 2020 09:32:00 GMT Subject: Integrated: 8253727: [cgroups v2] Memory and swap limits reported incorrectly In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 17:22:21 GMT, Severin Gehwolf wrote: > Account for interface files for swap and memory being reported independently. > The cgroup v1-like value is now reported by adding the memory.max value to > the memory.swap.max value. > > Testing: Container tests on Linux x86_64 on cgroups v2 with crun 0.15 This pull request has now been integrated. Changeset: 3e96721c Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/3e96721c Stats: 47 lines in 3 files changed: 42 ins; 0 del; 5 mod 8253727: [cgroups v2] Memory and swap limits reported incorrectly Account for interface files for swap and memory being reported independently. The cgroup v1-like value is now reported by adding the memory.max value to the memory.swap.max value, and memory.current and memory.swap.current respectively. Reviewed-by: bobv, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/384 From chegar at openjdk.java.net Thu Oct 1 09:32:03 2020 From: chegar at openjdk.java.net (Chris Hegarty) Date: Thu, 1 Oct 2020 09:32:03 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v9] In-Reply-To: <0aKjS2ruCGPqJsSjll3RsknZpCuGsAkrQaANwVqPTMs=.b9628de2-6f3e-41d0-9c59-6b85dd6d71f5@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> <0aKjS2ruCGPqJsSjll3RsknZpCuGsAkrQaANwVqPTMs=.b9628de2-6f3e-41d0-9c59-6b85dd6d71f5@github.com> Message-ID: On Thu, 1 Oct 2020 01:31:04 GMT, Vicente Romero wrote: >> Co-authored-by: Vicente Romero >> Co-authored-by: Harold Seigel >> Co-authored-by: Jonathan Gibbons >> Co-authored-by: Brian Goetz >> Co-authored-by: Maurizio Cimadamore >> Co-authored-by: Joe Darcy >> Co-authored-by: Chris Hegarty >> Co-authored-by: Jan Lahoda > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > remove unnecessary jtreg tags from tests, remove othervm etc when applicable Marked as reviewed by chegar (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From shade at openjdk.java.net Thu Oct 1 09:38:38 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 1 Oct 2020 09:38:38 GMT Subject: RFR: 8253889: Remove ExecMem constant In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 09:22:53 GMT, Thomas Stuefe wrote: > Maybe it did something in the past. Now it just seems to be a complicated way to say "false". I think that's a Hotspot style. There are few other places where "symbolic values" for boolean parameters are used. For example, `CodeBlobToOopClosure::FixRelocations`. `grep 'static const bool'` identify a few more. I personally find it a tad more readable. So, it is not as useless... ------------- PR: https://git.openjdk.java.net/jdk/pull/454 From zgu at openjdk.java.net Thu Oct 1 12:01:19 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 1 Oct 2020 12:01:19 GMT Subject: Integrated: 8253429: Error reporting should report correct state of terminated/aborted threads In-Reply-To: <5n1FG7ZdpZblWlv7-4An1W-mUTFhw3ugf2b85X-ALeQ=.e8a38616-ca96-4d4e-83e8-a886bafa9f92@github.com> References: <5n1FG7ZdpZblWlv7-4An1W-mUTFhw3ugf2b85X-ALeQ=.e8a38616-ca96-4d4e-83e8-a886bafa9f92@github.com> Message-ID: On Thu, 24 Sep 2020 18:14:10 GMT, Zhengyu Gu wrote: > For some non-JavaThread, their object instances can outlast threads' lifespan. For example, we still can query/report > thread's state after thread terminated. > But the query/report currently returns wrong state. E.g. a terminated thread appears to be alive and seemly has valid > thread stack, etc. > This patch sets non-JavaThread's state to ZOMBIE just before it terminates, so that we can distinguish terminated > thread from live thread. > Also, thread should not report its SMR info, if it has terminated or it never started (thread->osthread() == NULL). > > Note: Java thread does not have such issue, its thread object is deleted before thread terminates. This pull request has now been integrated. Changeset: dd36d8c6 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/dd36d8c6 Stats: 13 lines in 1 file changed: 7 ins; 1 del; 5 mod 8253429: Error reporting should report correct state of terminated/aborted threads Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/341 From iklam at openjdk.java.net Thu Oct 1 15:42:04 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Oct 2020 15:42:04 GMT Subject: RFR: 8253824: Revert JDK-8253089 since VS warning C4307 has been disabled In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 08:09:39 GMT, Aleksey Shipilev wrote: > This reverts commit 3f455f09dc738b7c76210c1080df2aaa8e19a19d. > > Testing: > - [x] Linux x86_64 {fastdebug,release,slowdebug} builds > - [x] Windows MSVC 2017 build (tested by Martin Doerr) Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/426 From shade at openjdk.java.net Thu Oct 1 16:11:06 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 1 Oct 2020 16:11:06 GMT Subject: Integrated: 8253824: Revert JDK-8253089 since VS warning C4307 has been disabled In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 08:09:39 GMT, Aleksey Shipilev wrote: > This reverts commit 3f455f09dc738b7c76210c1080df2aaa8e19a19d. > > Testing: > - [x] Linux x86_64 {fastdebug,release,slowdebug} builds > - [x] Windows MSVC 2017 build (tested by Martin Doerr) This pull request has now been integrated. Changeset: 60ec2a53 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/60ec2a53 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod 8253824: Revert JDK-8253089 since VS warning C4307 has been disabled Reviewed-by: mdoerr, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/426 From rehn at openjdk.java.net Thu Oct 1 17:10:13 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 1 Oct 2020 17:10:13 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts Message-ID: The issue is that this test doesn't consider Handshake All operation. Depending if/when such operation is scheduled it can lockup the VM thread. And the safepoint that should timeout never happens. See issue for more information. So I changed the test to "try timeout" the safepoint, but if there was no safepoint (blocked by a handshake all), we retry. We sleep unsafe much longer than the interval SafepointALot generates operations, which 'guarantees' we will timeout if there is no handshake all. (some extreme case of kernel scheduling causing a very long context switch could also make us not timeout) Passes t1, t3, and repeat runs of the test. ------------- Commit messages: - Fixed test Changes: https://git.openjdk.java.net/jdk/pull/465/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=465&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253794 Stats: 53 lines in 3 files changed: 16 ins; 26 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/465/head:pull/465 PR: https://git.openjdk.java.net/jdk/pull/465 From gziemski at openjdk.java.net Thu Oct 1 18:13:17 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 1 Oct 2020 18:13:17 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms [v6] In-Reply-To: References: Message-ID: > hi all, > > Please review this change that refactors common POSIX code into a separate > file. > > Currently there appears to be quite a bit of duplicated code among POSIX > platforms, which makes it difficult to apply single fix to the signal code. > With this fix, we will only need to touch single file for common POSIX > code fixes from now on. > > ---------------------------------------------------------------------------- > The APIs which moved from os/bsd/os_bsd.cpp to to os/posix/PosixSignals.cpp: > > //////////////////////////////////////////////////////////////////////////////// > // signal support > void os::Bsd::signal_sets_init() > sigset_t* os::Bsd::unblocked_signals() > sigset_t* os::Bsd::vm_signals() > void os::Bsd::hotspot_sigmask(Thread* thread) > //////////////////////////////////////////////////////////////////////////////// > // sun.misc.Signal support > static void UserHandler(int sig, void *siginfo, void *context) > void* os::user_handler() > void* os::signal(int signal_number, void* handler) > void os::signal_raise(int signal_number) > int os::sigexitnum_pd() > static void jdk_misc_signal_init() > void os::signal_notify(int sig) > static int check_pending_signals() > int os::signal_wait() > //////////////////////////////////////////////////////////////////////////////// > // suspend/resume support > static void resume_clear_context(OSThread *osthread) > static void suspend_save_context(OSThread *osthread, siginfo_t* siginfo, ucontext_t* context) > static void SR_handler(int sig, siginfo_t* siginfo, ucontext_t* context) > static int SR_initialize() > static int sr_notify(OSThread* osthread) > static bool do_suspend(OSThread* osthread) > static void do_resume(OSThread* osthread) > /////////////////////////////////////////////////////////////////////////////////// > // signal handling (except suspend/resume) > static void signalHandler(int sig, siginfo_t* info, void* uc) > struct sigaction* os::Bsd::get_chained_signal_action(int sig) > static bool call_chained_handler(struct sigaction *actp, int sig, > siginfo_t *siginfo, void *context) > bool os::Bsd::chained_handler(int sig, siginfo_t* siginfo, void* context) > int os::Bsd::get_our_sigflags(int sig) > void os::Bsd::set_our_sigflags(int sig, int flags) > void os::Bsd::set_signal_handler(int sig, bool set_installed) > void os::Bsd::install_signal_handlers() > static const char* get_signal_handler_name(address handler, > char* buf, int buflen) > static void print_signal_handler(outputStream* st, int sig, > char* buf, size_t buflen) > void os::run_periodic_checks() > void os::Bsd::check_signal_handler(int sig) > > ----------------------------------------------------------------------------- > The APIs which moved from os/posix/os_posix.cpp to os/posix/PosixSignals.cpp: > > const char* os::Posix::get_signal_name(int sig, char* out, size_t outlen) > int os::Posix::get_signal_number(const char* signal_name) > int os::get_signal_number(const char* signal_name) > bool os::Posix::is_valid_signal(int sig) > bool os::Posix::is_sig_ignored(int sig) > const char* os::exception_name(int sig, char* buf, size_t size) > const char* os::Posix::describe_signal_set_short(const sigset_t* set, char* buffer, size_t buf_size) > void os::Posix::print_signal_set_short(outputStream* st, const sigset_t* set) > const char* os::Posix::describe_sa_flags(int flags, char* buffer, size_t size) > oid os::Posix::print_sa_flags(outputStream* st, int flags) > static bool get_signal_code_description(const siginfo_t* si, enum_sigcode_desc_t* out) > void os::print_siginfo(outputStream* os, const void* si0) > bool os::signal_thread(Thread* thread, int sig, const char* reason) > int os::Posix::unblock_thread_signal_mask(const sigset_t *set) > address os::Posix::ucontext_get_pc(const ucontext_t* ctx) > void os::Posix::ucontext_set_pc(ucontext_t* ctx, address pc) > struct sigaction* os::Posix::get_preinstalled_handler(int sig) > void os::Posix::save_preinstalled_handler(int sig, struct sigaction& oldAct) > > > -------------------------------------------------------- > -------------------------------------------------------- > > DETAILS: > > -------------------------------------------------------- > Public APIs which are now internal static PosixSignals:: > > sigset_t* os::Bsd::vm_signals() > struct sigaction* os::Bsd::get_chained_signal_action(int sig) > int os::Bsd::get_our_sigflags(int sig) > void os::Bsd::set_our_sigflags(int sig, int flags) > void os::Bsd::set_signal_handler(int sig, bool set_installed) > void os::Bsd::check_signal_handler(int sig) > const char* os::Posix::get_signal_name(int sig, char* out, size_t outlen) > bool os::Posix::is_valid_signal(int sig) > const char* os::Posix::describe_signal_set_short(const sigset_t* set, char* buffer, size_t buf_size) > void os::Posix::print_signal_set_short(outputStream* st, const sigset_t* set) > const char* os::Posix::describe_sa_flags(int flags, char* buffer, size_t size) > oid os::Posix::print_sa_flags(outputStream* st, int flags) > static bool get_signal_code_description(const siginfo_t* si, enum_sigcode_desc_t* out) > void os::Posix::save_preinstalled_handler(int sig, struct sigaction& oldAct) > > ------------------------------------------------ > Public APIs which moved to public PosixSignals:: > > void os::Bsd::signal_sets_init() > void os::Bsd::hotspot_sigmask(Thread* thread) > bool os::Bsd::chained_handler(int sig, siginfo_t* siginfo, void* context) > void os::Bsd::install_signal_handlers() > bool os::Posix::is_sig_ignored(int sig) > int os::Posix::unblock_thread_signal_mask(const sigset_t *set) > address os::Posix::ucontext_get_pc(const ucontext_t* ctx) > void os::Posix::ucontext_set_pc(ucontext_t* ctx, address pc) > > ---------------------------------------------------- > Internal APIs which are now public in PosixSignals:: > > static void jdk_misc_signal_init() > static int SR_initialize() > static bool do_suspend(OSThread* osthread) > static void do_resume(OSThread* osthread) > static void print_signal_handler(outputStream* st, int sig, char* buf, size_t buflen) > > -------------------------- > New APIs in PosixSignals:: > > static bool are_signal_handlers_installed(); Gerard Ziemski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - fix merge - Revert "Add AIX specific SA code" This reverts commit cc13700d7d3f15927e22d92d9f5ec9a0739ef9a1. - Add AIX specific SA code - Remove leftover AIX signal code - removed white spaces - Refactored common POSIX signal code into seperate file - Address David's review issues - Revert "Add AIX specific SA code" This reverts commit cc13700d7d3f15927e22d92d9f5ec9a0739ef9a1. - Add AIX specific SA code - Remove leftover AIX signal code - ... and 2 more: https://git.openjdk.java.net/jdk/compare/60ec2a53...4f5d4cd4 ------------- Changes: https://git.openjdk.java.net/jdk/pull/157/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=157&range=05 Stats: 5379 lines in 21 files changed: 1743 ins; 3529 del; 107 mod Patch: https://git.openjdk.java.net/jdk/pull/157.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/157/head:pull/157 PR: https://git.openjdk.java.net/jdk/pull/157 From gziemski at openjdk.java.net Thu Oct 1 18:17:06 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 1 Oct 2020 18:17:06 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms [v5] In-Reply-To: References: <0_pPVrBJAGbaVyHMnVhS2E0ByTkolg4tKpUH4N8fplg=.eb0fa0d9-44f8-4c63-8322-bd2320d3000a@github.com> <_RJ0u-P40RQfJNTWyHNYS3uh4TCeHY8ljaS5CLGgnFY=.3bbd9ea2-0d27-4562-a1bb-f0eadb374c50@github.com> Message-ID: On Wed, 30 Sep 2020 23:24:25 GMT, David Holmes wrote: >> Sorry for taking so long, but this is my 1st github pr and I did not liked the merge issues that David discovered and >> tried to redo the merge, but I keep getting it wrong. >> I just forced pushed update removing the BIG merge and I keep working on it, hopefully without introducing another huge >> merge. If anyone has tips on how to apply local changes (i.e. rebase/stash?) without having to merge, please let me >> know. Once I figure this out, I will re-implement the few, non-merge, issues that David discovered and this will be >> ready for integration. > > @gerard-ziemski Please do not force-push any commits in an open PR as it breaks the commit history and the chain of > review comments. I will not be able to see the merge issues actually fixed as a diff from the previous commit. > merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your > intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of > this pull request to `Merge :` where `` is the name of another project in the [OpenJDK > organization](https://github.com/openjdk) (for example `Merge jdk:master`). Can anyone explain what this means and whether it's OK to go ahead with this pr, or should I close this one (since I made quite a mess of it) and start a new one? ------------- PR: https://git.openjdk.java.net/jdk/pull/157 From martin.doerr at sap.com Thu Oct 1 18:52:06 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 1 Oct 2020 18:52:06 +0000 Subject: guarantee(object->mark() == markWord::INFLATING()) failed: invariant Message-ID: Hi, we have seen a crash when running Spec JVM 2008 on a Power9 machine. It occurred only once so I can't tell if it is a PPC64 specific or weak memory model specific issue. Locking code has worked very solid for many years on this platform. # Internal Error (synchronizer.cpp:1953), pid=18455, tid=19363 # guarantee(object->mark() == markWord::INFLATING()) failed: invariant V [libjvm.so+0xe463cc] ObjectSynchronizer::inflate(Thread*, oopDesc*, ObjectSynchronizer::InflateCause)+0x76c V [libjvm.so+0xe467ac] ObjectSynchronizer::exit(oopDesc*, BasicLock*, Thread*)+0x4c V [libjvm.so+0xda18a0] SharedRuntime::complete_monitor_unlocking_C(oopDesc*, BasicLock*, JavaThread*)+0xc0 J 5765 c2 sun.nio.cs.StreamEncoder.flushBuffer()V java.base at 16.0.0.1-internal (42 bytes) @ 0x00007fff95e1d84c [0x00007fff95e1d400+0x000000000000044c] J 6249 c2 java.io.PrintStream.println(Ljava/lang/String;)V java.base at 16.0.0.1-internal (44 bytes) @ 0x00007fff95f1f1a0 [0x00007fff95f1ea80+0x0000000000000720] J 6534 c1 spec.benchmarks.crypto.aes.Main.runEncryptDecrypt(Ljavax/crypto/SecretKey;Ljava/lang/String;Ljava/lang/String;)V (93 bytes) @ 0x00007fff8e575794 [0x00007fff8e574e00+0x0000000000000994] j spec.benchmarks.crypto.aes.Main.harnessMain()V+69 ... object->_mark points to a stack lock: 0x00007ffe67dfdbc8 is pointing into the stack for thread: 0x00007ffeec10d5e0 content of stack slot 0x7ffe67dfdbc8: 0x0000000000000009 which belongs to the crashing thread: Current thread (0x00007ffeec10d5e0): JavaThread "BenchmarkThread crypto.aes 5" [_thread_in_Java, id=19363, stack(0x00007ffe67c00000,0x00007ffe67e00000)] I wonder how this can happen. Can it be related to asynchronous lock deflation? Any ideas are welcome. Best regards, Martin From pchilanomate at openjdk.java.net Thu Oct 1 19:01:05 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 1 Oct 2020 19:01:05 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 14:35:45 GMT, Robbin Ehn wrote: > The issue is that this test doesn't consider Handshake All operation. > Depending if/when such operation is scheduled it can lockup the VM thread. > And the safepoint that should timeout never happens. > See issue for more information. > > So I changed the test to "try timeout" the safepoint, but if there was no safepoint (blocked by a handshake all), we > retry. We sleep unsafe much longer than the interval SafepointALot generates operations, which 'guarantees' we will > timeout if there is no handshake all. (some extreme case of kernel scheduling causing a very long context switch could > also make us not timeout) Passes t1, t3, and repeat runs of the test. LGTM ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk/pull/465 From gziemski at openjdk.java.net Thu Oct 1 19:18:22 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 1 Oct 2020 19:18:22 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms [v7] In-Reply-To: References: Message-ID: <1BH4FH5_sthoZOvLa3nQZTVjlP0CFI2JNu-0RI9zzXI=.01b48623-9d7d-437a-b400-c66cf114c42f@github.com> > hi all, > > Please review this change that refactors common POSIX code into a separate > file. > > Currently there appears to be quite a bit of duplicated code among POSIX > platforms, which makes it difficult to apply single fix to the signal code. > With this fix, we will only need to touch single file for common POSIX > code fixes from now on. > > ---------------------------------------------------------------------------- > The APIs which moved from os/bsd/os_bsd.cpp to to os/posix/PosixSignals.cpp: > > //////////////////////////////////////////////////////////////////////////////// > // signal support > void os::Bsd::signal_sets_init() > sigset_t* os::Bsd::unblocked_signals() > sigset_t* os::Bsd::vm_signals() > void os::Bsd::hotspot_sigmask(Thread* thread) > //////////////////////////////////////////////////////////////////////////////// > // sun.misc.Signal support > static void UserHandler(int sig, void *siginfo, void *context) > void* os::user_handler() > void* os::signal(int signal_number, void* handler) > void os::signal_raise(int signal_number) > int os::sigexitnum_pd() > static void jdk_misc_signal_init() > void os::signal_notify(int sig) > static int check_pending_signals() > int os::signal_wait() > //////////////////////////////////////////////////////////////////////////////// > // suspend/resume support > static void resume_clear_context(OSThread *osthread) > static void suspend_save_context(OSThread *osthread, siginfo_t* siginfo, ucontext_t* context) > static void SR_handler(int sig, siginfo_t* siginfo, ucontext_t* context) > static int SR_initialize() > static int sr_notify(OSThread* osthread) > static bool do_suspend(OSThread* osthread) > static void do_resume(OSThread* osthread) > /////////////////////////////////////////////////////////////////////////////////// > // signal handling (except suspend/resume) > static void signalHandler(int sig, siginfo_t* info, void* uc) > struct sigaction* os::Bsd::get_chained_signal_action(int sig) > static bool call_chained_handler(struct sigaction *actp, int sig, > siginfo_t *siginfo, void *context) > bool os::Bsd::chained_handler(int sig, siginfo_t* siginfo, void* context) > int os::Bsd::get_our_sigflags(int sig) > void os::Bsd::set_our_sigflags(int sig, int flags) > void os::Bsd::set_signal_handler(int sig, bool set_installed) > void os::Bsd::install_signal_handlers() > static const char* get_signal_handler_name(address handler, > char* buf, int buflen) > static void print_signal_handler(outputStream* st, int sig, > char* buf, size_t buflen) > void os::run_periodic_checks() > void os::Bsd::check_signal_handler(int sig) > > ----------------------------------------------------------------------------- > The APIs which moved from os/posix/os_posix.cpp to os/posix/PosixSignals.cpp: > > const char* os::Posix::get_signal_name(int sig, char* out, size_t outlen) > int os::Posix::get_signal_number(const char* signal_name) > int os::get_signal_number(const char* signal_name) > bool os::Posix::is_valid_signal(int sig) > bool os::Posix::is_sig_ignored(int sig) > const char* os::exception_name(int sig, char* buf, size_t size) > const char* os::Posix::describe_signal_set_short(const sigset_t* set, char* buffer, size_t buf_size) > void os::Posix::print_signal_set_short(outputStream* st, const sigset_t* set) > const char* os::Posix::describe_sa_flags(int flags, char* buffer, size_t size) > oid os::Posix::print_sa_flags(outputStream* st, int flags) > static bool get_signal_code_description(const siginfo_t* si, enum_sigcode_desc_t* out) > void os::print_siginfo(outputStream* os, const void* si0) > bool os::signal_thread(Thread* thread, int sig, const char* reason) > int os::Posix::unblock_thread_signal_mask(const sigset_t *set) > address os::Posix::ucontext_get_pc(const ucontext_t* ctx) > void os::Posix::ucontext_set_pc(ucontext_t* ctx, address pc) > struct sigaction* os::Posix::get_preinstalled_handler(int sig) > void os::Posix::save_preinstalled_handler(int sig, struct sigaction& oldAct) > > > -------------------------------------------------------- > -------------------------------------------------------- > > DETAILS: > > -------------------------------------------------------- > Public APIs which are now internal static PosixSignals:: > > sigset_t* os::Bsd::vm_signals() > struct sigaction* os::Bsd::get_chained_signal_action(int sig) > int os::Bsd::get_our_sigflags(int sig) > void os::Bsd::set_our_sigflags(int sig, int flags) > void os::Bsd::set_signal_handler(int sig, bool set_installed) > void os::Bsd::check_signal_handler(int sig) > const char* os::Posix::get_signal_name(int sig, char* out, size_t outlen) > bool os::Posix::is_valid_signal(int sig) > const char* os::Posix::describe_signal_set_short(const sigset_t* set, char* buffer, size_t buf_size) > void os::Posix::print_signal_set_short(outputStream* st, const sigset_t* set) > const char* os::Posix::describe_sa_flags(int flags, char* buffer, size_t size) > oid os::Posix::print_sa_flags(outputStream* st, int flags) > static bool get_signal_code_description(const siginfo_t* si, enum_sigcode_desc_t* out) > void os::Posix::save_preinstalled_handler(int sig, struct sigaction& oldAct) > > ------------------------------------------------ > Public APIs which moved to public PosixSignals:: > > void os::Bsd::signal_sets_init() > void os::Bsd::hotspot_sigmask(Thread* thread) > bool os::Bsd::chained_handler(int sig, siginfo_t* siginfo, void* context) > void os::Bsd::install_signal_handlers() > bool os::Posix::is_sig_ignored(int sig) > int os::Posix::unblock_thread_signal_mask(const sigset_t *set) > address os::Posix::ucontext_get_pc(const ucontext_t* ctx) > void os::Posix::ucontext_set_pc(ucontext_t* ctx, address pc) > > ---------------------------------------------------- > Internal APIs which are now public in PosixSignals:: > > static void jdk_misc_signal_init() > static int SR_initialize() > static bool do_suspend(OSThread* osthread) > static void do_resume(OSThread* osthread) > static void print_signal_handler(outputStream* st, int sig, char* buf, size_t buflen) > > -------------------------- > New APIs in PosixSignals:: > > static bool are_signal_handlers_installed(); Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: Fix mispelled BSD macro name in define ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/157/files - new: https://git.openjdk.java.net/jdk/pull/157/files/4f5d4cd4..b50d7229 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=157&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=157&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/157.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/157/head:pull/157 PR: https://git.openjdk.java.net/jdk/pull/157 From dcubed at openjdk.java.net Thu Oct 1 20:14:05 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 1 Oct 2020 20:14:05 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 14:35:45 GMT, Robbin Ehn wrote: > The issue is that this test doesn't consider Handshake All operation. > Depending if/when such operation is scheduled it can lockup the VM thread. > And the safepoint that should timeout never happens. > See issue for more information. > > So I changed the test to "try timeout" the safepoint, but if there was no safepoint (blocked by a handshake all), we > retry. We sleep unsafe much longer than the interval SafepointALot generates operations, which 'guarantees' we will > timeout if there is no handshake all. (some extreme case of kernel scheduling causing a very long context switch could > also make us not timeout) Passes t1, t3, and repeat runs of the test. Changes requested by dcubed (Reviewer). test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 71: > 69: ProcessBuilder pb = ProcessTools.createJavaProcessBuilder( > 70: "-XX:+UnlockDiagnosticVMOptions", > 71: "-XX:-UseBiasedLocking", I think "-XX:-UseBiasedLocking" is specified to make sure that Biased Locking is disabled even in test tasks where it is enabled by task specific flags. test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 66: > 64: "-Xms64m", > 65: "TestAbortVMOnSafepointTimeout", > 66: "" + unsafe_wait Cheap conversion from int to String? test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 42: > 40: public static void main(String[] args) throws Exception { > 41: if (args.length > 0) { > 42: Integer waitTime = Integer.parseInt(args[0]); What is this going to do if no argument is passed? Looks like it's going to throw NumberFormatException... Update: I missed the `if (args.length > 0)` above... test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 35: > 33: * @build TestAbortVMOnSafepointTimeout > 34: * @run driver ClassFileInstaller sun.hotspot.WhiteBox > 35: * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI > TestAbortVMOnSafepointTimeout L42 below parses args[0], but you're not passing a parameter here... Update: Ahhh... this just launches the test and the test launches another VM... got it. test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 49: > 47: System.out.println("This message would occur after some time."); > 48: } else { > 49: testWith(50, 1, 999); Please consider: `testWith(50 /* sfpt_interval */, 1 /* timeout_delay */, 999 /* unsafe_wait */);` test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 30: > 28: /* > 29: * @test TestAbortVMOnSafepointTimeout > 30: * @summary Check if VM can kill thread which doesn't reach safepoint. Not your bug, but this summary is wrong. Perhaps: `@summary Check if VM aborts when a thread doesn't reach safepoint.` src/hotspot/share/prims/whitebox.cpp line 2294: > 2292: > 2293: WB_ENTRY(jboolean, WB_WaitUnsafe(JNIEnv* env, jobject wb, jint time)) > 2294: SafepointStateTracker tracker = SafepointSynchronize::safepoint_state_tracker(); I had to go back and reread the `SafepointStateTracker` code... Because this JavaThread is executing and not at a safepoint, the call to `SafepointSynchronize::safepoint_state_tracker()` will save state as not-at-a-safepoint (with some safepoint_id value). src/hotspot/share/prims/whitebox.cpp line 2296: > 2294: SafepointStateTracker tracker = SafepointSynchronize::safepoint_state_tracker(); > 2295: os::naked_short_sleep(time); > 2296: return tracker.safepoint_state_changed(); Ahhh... returns true when we've had a state change or when the safepoint ID has changed, but... how can the system change the `SafepointSynchronize::is_at_safepoint()` return value or the safepoint_id value while we're sleeping? The system shouldn't be able to go to a safepoint or change safepoint_id values while this calling thread is not safepoint safe. I would think that this function would always return false, but maybe I'm missing something here. test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 47: > 45: System.out.println("Waiting for safepoint"); > 46: } > 47: System.out.println("This message would occur after some time."); Maybe I'm missing something, but I don't see how `wb.waitUnsafe(waitTime)` is ever going to return anything but false so this message should never be printed. test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 79: > 77: } > 78: } > 79: output.shouldNotHaveExitValue(0); Looks like the test doesn't require that this mesg get printed: `System.out.println("This message would occur after some time.");` And it is set up to detect that the SafepointTimeout happened which is what we want the test to verify at the core. ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From dcubed at openjdk.java.net Thu Oct 1 20:14:06 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 1 Oct 2020 20:14:06 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 19:40:04 GMT, Daniel D. Daugherty wrote: >> The issue is that this test doesn't consider Handshake All operation. >> Depending if/when such operation is scheduled it can lockup the VM thread. >> And the safepoint that should timeout never happens. >> See issue for more information. >> >> So I changed the test to "try timeout" the safepoint, but if there was no safepoint (blocked by a handshake all), we >> retry. We sleep unsafe much longer than the interval SafepointALot generates operations, which 'guarantees' we will >> timeout if there is no handshake all. (some extreme case of kernel scheduling causing a very long context switch could >> also make us not timeout) Passes t1, t3, and repeat runs of the test. > > test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 49: > >> 47: System.out.println("This message would occur after some time."); >> 48: } else { >> 49: testWith(50, 1, 999); > > Please consider: > > `testWith(50 /* sfpt_interval */, 1 /* timeout_delay */, 999 /* unsafe_wait */);` Also, I think the test would be more clear if this testWith() part was in a `if (args.length == 0)` block at the top and the else part was the rest of the test. After all, code flow wise, you execute the `(args.length == 0)` case first and then come back for the case with the unsafe_wait value. ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From iklam at openjdk.java.net Thu Oct 1 20:15:08 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Oct 2020 20:15:08 GMT Subject: RFR: 8253909: Implement detailed map file for CDS Message-ID: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> For analyzing the contents of a CDS archive, we need a "map file" that describes the archive in different levels of detail. This can be done using unified logging. E.g., java -Xshare:dump -Xlog:cds+map=trace:file=cds.map:none:filesize=0 For example, we can use the map file for troubleshooting [JDK-8253495](https://bugs.openjdk.java.net/browse/JDK-8253495) (runtime/cds/DeterministicDump.java broken). We can diff two different cds.map files to see where the non-deterministic contents come from. See attachments in [JDK-8253909](https://bugs.openjdk.java.net/browse/JDK-8253909) for example map files at the info/debug/trace levels. ------------- Commit messages: - 8253909: Implement detailed map file for CDS Changes: https://git.openjdk.java.net/jdk/pull/474/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=474&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253909 Stats: 305 lines in 8 files changed: 265 ins; 9 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/474/head:pull/474 PR: https://git.openjdk.java.net/jdk/pull/474 From daniel.daugherty at oracle.com Thu Oct 1 20:28:43 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 1 Oct 2020 16:28:43 -0400 Subject: guarantee(object->mark() == markWord::INFLATING()) failed: invariant In-Reply-To: References: Message-ID: Hi Martin, It's best to file a new bug and make it clear that the sighting is on PPC. I have not seen this failure mode in my own stress testing nor have I seen it in Mach5... Dan On 10/1/20 2:52 PM, Doerr, Martin wrote: > Hi, > > we have seen a crash when running Spec JVM 2008 on a Power9 machine. > It occurred only once so I can't tell if it is a PPC64 specific or weak memory model specific issue. > Locking code has worked very solid for many years on this platform. > > # Internal Error (synchronizer.cpp:1953), pid=18455, tid=19363 > # guarantee(object->mark() == markWord::INFLATING()) failed: invariant > > V [libjvm.so+0xe463cc] ObjectSynchronizer::inflate(Thread*, oopDesc*, ObjectSynchronizer::InflateCause)+0x76c > V [libjvm.so+0xe467ac] ObjectSynchronizer::exit(oopDesc*, BasicLock*, Thread*)+0x4c > V [libjvm.so+0xda18a0] SharedRuntime::complete_monitor_unlocking_C(oopDesc*, BasicLock*, JavaThread*)+0xc0 > J 5765 c2 sun.nio.cs.StreamEncoder.flushBuffer()V java.base at 16.0.0.1-internal (42 bytes) @ 0x00007fff95e1d84c [0x00007fff95e1d400+0x000000000000044c] > J 6249 c2 java.io.PrintStream.println(Ljava/lang/String;)V java.base at 16.0.0.1-internal (44 bytes) @ 0x00007fff95f1f1a0 [0x00007fff95f1ea80+0x0000000000000720] > J 6534 c1 spec.benchmarks.crypto.aes.Main.runEncryptDecrypt(Ljavax/crypto/SecretKey;Ljava/lang/String;Ljava/lang/String;)V (93 bytes) @ 0x00007fff8e575794 [0x00007fff8e574e00+0x0000000000000994] > j spec.benchmarks.crypto.aes.Main.harnessMain()V+69 > ... > > object->_mark points to a stack lock: > 0x00007ffe67dfdbc8 is pointing into the stack for thread: 0x00007ffeec10d5e0 > content of stack slot 0x7ffe67dfdbc8: 0x0000000000000009 > which belongs to the crashing thread: > Current thread (0x00007ffeec10d5e0): JavaThread "BenchmarkThread crypto.aes 5" [_thread_in_Java, id=19363, stack(0x00007ffe67c00000,0x00007ffe67e00000)] > > I wonder how this can happen. Can it be related to asynchronous lock deflation? > Any ideas are welcome. > > Best regards, > Martin > From iignatyev at openjdk.java.net Thu Oct 1 21:49:09 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 1 Oct 2020 21:49:09 GMT Subject: RFR: 8253913: unify gtest test names Message-ID: Hi all, could you please review this small and trivial patch that unifies the names of hotspot gtests? in some cases, "_test" is added to gtest names, in others it isn't. given some tests specify "test" in their names, so we get "test_test" like in `UninitializedDoubleElementWorkerDataArrayTest.sum_test_test_vm`. the patch removes `_test` from the suffixes added by `TEST*` macros. testing: ? `make test TEST=gtest` on macosx-x64 ? `test/hotspot/jtreg/gtest/` on {linux,windows,macosx}-x64 ------------- Commit messages: - 8253913: unify gtest test names Changes: https://git.openjdk.java.net/jdk/pull/475/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=475&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253913 Stats: 11 lines in 2 files changed: 4 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/475.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/475/head:pull/475 PR: https://git.openjdk.java.net/jdk/pull/475 From iignatyev at openjdk.java.net Thu Oct 1 22:16:16 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 1 Oct 2020 22:16:16 GMT Subject: RFR: 8253913: unify gtest test names [v2] In-Reply-To: References: Message-ID: > Hi all, > > could you please review this small and trivial patch that unifies the names of hotspot gtests? in some cases, "_test" > is added to gtest names, in others it isn't. given some tests specify "test" in their names, so we get "test_test" like > in `UninitializedDoubleElementWorkerDataArrayTest.sum_test_test_vm`. the patch removes `_test` from the suffixes added > by `TEST*` macros. testing: ? `make test TEST=gtest` on macosx-x64 > ? `test/hotspot/jtreg/gtest/` on {linux,windows,macosx}-x64 Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: adjust test class names in LogStream's friends ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/475/files - new: https://git.openjdk.java.net/jdk/pull/475/files/d0a45837..5d7e7f50 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=475&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=475&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/475.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/475/head:pull/475 PR: https://git.openjdk.java.net/jdk/pull/475 From ccheung at openjdk.java.net Thu Oct 1 22:46:11 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 1 Oct 2020 22:46:11 GMT Subject: RFR: 8224509: Incorrect alignment in CDS related allocation code on 32-bit platforms Message-ID: CDS aligns pointers and sizes to BytesPerWord. On 64-bit, BytesPerWord = 8. On 32-bit, BytesPerWord = 4. To make the alignment consistent between 64- and 32-bit platforms, this patch changes the alignment value to 8. Testing: tiers 1 - 4 built linux-x86-debug. ------------- Commit messages: - 8224509 (initial commit) Changes: https://git.openjdk.java.net/jdk/pull/476/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=476&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8224509 Stats: 12 lines in 5 files changed: 3 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/476.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/476/head:pull/476 PR: https://git.openjdk.java.net/jdk/pull/476 From iklam at openjdk.java.net Thu Oct 1 23:00:13 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Oct 2020 23:00:13 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v8] In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 13:17:27 GMT, Thomas Stuefe wrote: >> Hi all, >> >> this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the >> delay, had vacation then the entrance of Skara delayed things a bit. >> For the delta diff please see [3]. >> >> This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all >> feedback individually in this PR body, but I incorporated almost all into the new revision. >> What changed since the last version: >> >> - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the >> group consent. >> >> - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for >> overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth >> class loader which made it rather pointless. Now I run it always. >> >> - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. >> >> - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) >> >> Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. >> >> - In ChunkManager::purge() I improved the comments after discussions with Leo. >> >> - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due >> to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run >> every time. >> >> - Fixed indentation issues as Leo requested >> >> - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested >> >> - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes >> and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more >> flexible since it allows us to have list with purge-able and non-purge-able nodes. >> >> - and various smaller fixes, mainly on request of Leo. >> >> @lkorinth: >> >>> VirtualSpaceNode.hpp >>> >>>102 // Start pointer of the area. >>>103 MetaWord* const _base; >>> >>>How does this differ from _rs._base? Really needed? >>> >>>105 // Size, in words, of the whole node >>>106 const size_t _word_size; >>> >>>Can we not calculate this from _rs.size()? >> >> You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it >> is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly >> improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at >> some point and make those members const - as they should be - then I would rewrite this as you suggest. >> Thanks, again, for all your review work! >> >> ------ >> >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html >> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html >> [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d > > Thomas Stuefe 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 jep387 > - Remove accidentally added file > - Merge branch 'jep387' of github.com:tstuefe/jdk into jep387 > - Create submit.yml > - Review feedback Ioi > - cds MaxMetaspaceSize test does not need MaxMetaspaceSize increase > - Make MetaspaceGuardAllocations a diagnostic flag (2) > - Make MetaspaceGuardAllocations a diagnostic flag > - Style fixes > - Remove empty lines from include sections > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/f80a6066...f5cf615b LGTM src/hotspot/share/memory/metaspace.hpp line 179: > 177: class ClassLoaderMetaspace : public CHeapObj { > 178: > 179: // A reference to an outside lock, held by the CLD. Should this be moved to classLoaderMetaspace.hpp (now that you have created a new file classLoaderMetaspace.cpp). src/hotspot/share/memory/metaspace/metaspaceSettings.hpp line 67: > 65: > 66: // If true, we handle deallocated blocks (default). > 67: DEBUG_ONLY(static bool _handle_deallocations;) I think "handle deallocated blocks" is a bit unclear. How about "If false, no blocks are ever freed and left-over space in chunks are not salvaged.". src/hotspot/share/memory/metaspace/metaspaceArena.cpp line 99: > 97: requested_word_size, chunklevel::MAX_CHUNK_WORD_SIZE); > 98: > 99: const int growth_step = _chunks.count(); growth_step is unused. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/336 From dholmes at openjdk.java.net Fri Oct 2 03:52:07 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 2 Oct 2020 03:52:07 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms [v5] In-Reply-To: References: <0_pPVrBJAGbaVyHMnVhS2E0ByTkolg4tKpUH4N8fplg=.eb0fa0d9-44f8-4c63-8322-bd2320d3000a@github.com> <_RJ0u-P40RQfJNTWyHNYS3uh4TCeHY8ljaS5CLGgnFY=.3bbd9ea2-0d27-4562-a1bb-f0eadb374c50@github.com> Message-ID: On Thu, 1 Oct 2020 18:14:24 GMT, Gerard Ziemski wrote: >> @gerard-ziemski Please do not force-push any commits in an open PR as it breaks the commit history and the chain of >> review comments. I will not be able to see the merge issues actually fixed as a diff from the previous commit. > >> merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your >> intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of >> this pull request to `Merge :` where `` is the name of another project in the [OpenJDK >> organization](https://github.com/openjdk) (for example `Merge jdk:master`). > > Can anyone explain what this means and whether it's OK to go ahead with this pr, or should I close this one (since I > made quite a mess of it) and start a new one? Hi Gerard, I'm afraid something is still very wrong here. I see you fixing the original merge issues in: b33d292e96a559b8a3a998641411f61bf087738f (Address David's review issues ) but then the "Fix Merge" commit 4f5d4cd49436b64dc3770e4ba1f811a76b5a09e7 applied after that seems to have reversed them again! I think it might be necessary to close this PR and create a new one. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/157 From dholmes at openjdk.java.net Fri Oct 2 04:27:04 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 2 Oct 2020 04:27:04 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 20:11:46 GMT, Daniel D. Daugherty wrote: >> The issue is that this test doesn't consider Handshake All operation. >> Depending if/when such operation is scheduled it can lockup the VM thread. >> And the safepoint that should timeout never happens. >> See issue for more information. >> >> So I changed the test to "try timeout" the safepoint, but if there was no safepoint (blocked by a handshake all), we >> retry. We sleep unsafe much longer than the interval SafepointALot generates operations, which 'guarantees' we will >> timeout if there is no handshake all. (some extreme case of kernel scheduling causing a very long context switch could >> also make us not timeout) Passes t1, t3, and repeat runs of the test. > > Changes requested by dcubed (Reviewer). Hi Robbin, So.... The old test used an "uncounted loop" (based on internal JIT knowledge) to create looping code with no safepoint polls so that it remains safepoint-unsafe (and Patricio had to tweak the test conditions to avoid unexpected safepoints). The new code has a WhiteBox entry that uses an internal naked_sleep which keeps the thread _thread_in_VM IIUC, which is not safepoint-safe, but also potentially different to being _thread_in_Java. But lets just accept the net effect is the same - the thread will prevent a safepoint from being reached until the sleep time has elapsed. If that time is > (GuaranteedSafepointInterval + SafepointTimeoutDelay) then we should see a safepoint timeout and the VM abort. Okay ... so how does that solve the problem the test currently experiences with handshakes ... if we are at a handshake the handshake can't proceed until the sleep time expires, but then when we transition back to Java the thread will see the handshake and so the handshake will proceed. As long as the WB function returns false we will repeat the process, eventually when the expected safepoint is requested we should again trigger the safepoint timeout and abort. But like Dan I'm unclear how the WB function can ever return true as the safepoint state can't change whilst the thread is in the naked sleep. ?? Aside: rather than using "args.length > 0" to discriminate between the original and subsequent executions of the test class, it can be clearer (IMO) to add a static nested class which has the main method that performs the actual test, and you invoke that via ProcessTools. That all said, for the record, we really should have a handshake timeout mechanism the same as we have the safepoint timeout mechanism. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From thomas.stuefe at gmail.com Fri Oct 2 04:44:50 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 2 Oct 2020 06:44:50 +0200 Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms [v5] In-Reply-To: References: <0_pPVrBJAGbaVyHMnVhS2E0ByTkolg4tKpUH4N8fplg=.eb0fa0d9-44f8-4c63-8322-bd2320d3000a@github.com> <_RJ0u-P40RQfJNTWyHNYS3uh4TCeHY8ljaS5CLGgnFY=.3bbd9ea2-0d27-4562-a1bb-f0eadb374c50@github.com> Message-ID: > > > Can anyone explain what this means and whether it's OK to go ahead with > this pr, or should I close this one (since I > > made quite a mess of it) and start a new one? > > Hi Gerard, > > I'm afraid something is still very wrong here. I see you fixing the > original merge issues in: > > b33d292e96a559b8a3a998641411f61bf087738f (Address David's review issues ) > > but then the "Fix Merge" commit > > 4f5d4cd49436b64dc3770e4ba1f811a76b5a09e7 > > applied after that seems to have reversed them again! > > I think it might be necessary to close this PR and create a new one. > > I agree. Also, then you get the new Activity-based builds and tier0 tests for free since that submit.yml file is now checked in head :) Cheers, Thomas Thanks. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/157 > From iklam at openjdk.java.net Fri Oct 2 04:56:04 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 2 Oct 2020 04:56:04 GMT Subject: RFR: 8224509: Incorrect alignment in CDS related allocation code on 32-bit platforms In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 22:40:46 GMT, Calvin Cheung wrote: > CDS aligns pointers and sizes to BytesPerWord. On 64-bit, BytesPerWord = 8. On 32-bit, BytesPerWord = 4. > > To make the alignment consistent between 64- and 32-bit platforms, this patch changes the alignment value to 8. > > Testing: tiers 1 - 4 > built linux-x86-debug. Marked as reviewed by iklam (Reviewer). src/hotspot/share/memory/archiveUtils.hpp line 33: > 31: #include "utilities/bitMap.hpp" > 32: > 33: #define SharedSpaceObjectAlignment 8 I think we can use a `const int` instead of `#define`. Also, some comments will be helpful. Maybe: // Metaspace::allocate() requires that all blocks must be aligned with KlassAlignmentInBytes. // We enforce the same alignment rule in blocks allocated from the shared space. const int SharedSpaceObjectAlignment = KlassAlignmentInBytes; ------------- PR: https://git.openjdk.java.net/jdk/pull/476 From stuefe at openjdk.java.net Fri Oct 2 05:15:05 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 2 Oct 2020 05:15:05 GMT Subject: RFR: 8224509: Incorrect alignment in CDS related allocation code on 32-bit platforms In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 22:40:46 GMT, Calvin Cheung wrote: > CDS aligns pointers and sizes to BytesPerWord. On 64-bit, BytesPerWord = 8. On 32-bit, BytesPerWord = 4. > > To make the alignment consistent between 64- and 32-bit platforms, this patch changes the alignment value to 8. > > Testing: tiers 1 - 4 > built linux-x86-debug. Just a drive by comment. Otherwise looks good to my non-CDS-eyes. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/476 From stuefe at openjdk.java.net Fri Oct 2 05:15:09 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 2 Oct 2020 05:15:09 GMT Subject: RFR: 8224509: Incorrect alignment in CDS related allocation code on 32-bit platforms In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 04:53:21 GMT, Ioi Lam wrote: >> CDS aligns pointers and sizes to BytesPerWord. On 64-bit, BytesPerWord = 8. On 32-bit, BytesPerWord = 4. >> >> To make the alignment consistent between 64- and 32-bit platforms, this patch changes the alignment value to 8. >> >> Testing: tiers 1 - 4 >> built linux-x86-debug. > > src/hotspot/share/memory/archiveUtils.hpp line 33: > >> 31: #include "utilities/bitMap.hpp" >> 32: >> 33: #define SharedSpaceObjectAlignment 8 > > I think we can use a `const int` instead of `#define`. Also, some comments will be helpful. Maybe: > > // Metaspace::allocate() requires that all blocks must be aligned with KlassAlignmentInBytes. > // We enforce the same alignment rule in blocks allocated from the shared space. > const int SharedSpaceObjectAlignment = KlassAlignmentInBytes; +1 to making the dependency on KlassAlignment explicit. Please do not hide any dependencies on Klass alignment behind literals (I am currently experimenting with increasing class space allocation alignment to increase the range of zero-based Klass* encoding) ------------- PR: https://git.openjdk.java.net/jdk/pull/476 From stefank at openjdk.java.net Fri Oct 2 06:25:05 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 2 Oct 2020 06:25:05 GMT Subject: RFR: 8253913: unify gtest test names [v2] In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 22:16:16 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this small and trivial patch that unifies the names of hotspot gtests? in some cases, "_test" >> is added to gtest names, in others it isn't. given some tests specify "test" in their names, so we get "test_test" like >> in `UninitializedDoubleElementWorkerDataArrayTest.sum_test_test_vm`. the patch removes `_test` from the suffixes added >> by `TEST*` macros. testing: ? `make test TEST=gtest` on macosx-x64 >> ? `test/hotspot/jtreg/gtest/` on {linux,windows,macosx}-x64 > > Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: > > adjust test class names in LogStream's friends Looks good. I think it's great that you clean this up. I started doing something similar myself, but never got around to create an RFE for it. IIRC, when I looked at it there were more inconsistencies with the names, but maybe they are gone now. ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/475 From stuefe at openjdk.java.net Fri Oct 2 06:26:06 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 2 Oct 2020 06:26:06 GMT Subject: RFR: 8253909: Implement detailed map file for CDS In-Reply-To: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> References: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> Message-ID: On Thu, 1 Oct 2020 20:06:32 GMT, Ioi Lam wrote: > For analyzing the contents of a CDS archive, we need a "map file" that describes the archive in different levels of > detail. This can be done using unified logging. E.g., > java -Xshare:dump -Xlog:cds+map=trace:file=cds.map:none:filesize=0 > > For example, we can use the map file for troubleshooting [JDK-8253495](https://bugs.openjdk.java.net/browse/JDK-8253495) > (runtime/cds/DeterministicDump.java broken). We can diff two different cds.map files to see where the non-deterministic > contents come from. > See attachments in [JDK-8253909](https://bugs.openjdk.java.net/browse/JDK-8253909) for example map files at the > info/debug/trace levels. Not a full review, just some drive-by comments. src/hotspot/share/memory/archiveBuilder.cpp line 723: > 721: // Dump all the data [base...top). Pretend that the base address > 722: // will be mapped to runtime_base at run-time. > 723: static void write_data(address base, address top, address runtime_base) { Consider printing the data with os::print_hex_dump() instead. Would slim down this coding. src/hotspot/share/memory/archiveBuilder.cpp line 769: > 767: log_info(cds, map)("Log level = info"); > 768: log_info(cds, map)("Run with -Xlog:cds+map=debug for more detailed information"); > 769: log_info(cds, map)("Run with -Xlog:cds+map=trace for even more detailed information"); Matter of taste, but I do not think usage information belongs into a log. src/hotspot/share/memory/archiveBuilder.cpp line 759: > 757: GrowableArray *closed_heap_regions, > 758: GrowableArray *open_heap_regions, > 759: char* bitmap, size_t bitmap_size_in_bytes) { Consider, instead of directly writing to UL, writing to an outputStream*. That would make the code more versatile and reusable. You can then use LogStream to print to UL with the same result. src/hotspot/share/memory/archiveBuilder.cpp line 609: > 607: // picked by the OS. At runtime, we try to map at a fixed location (SharedBaseAddress). For > 608: // consistency, we log everything using runtime addresses. > 609: class ArchiveBuilder::CDSMapLogger { AllStatic? src/hotspot/share/memory/archiveBuilder.cpp line 775: > 773: address header_end = header + mapinfo->header()->header_size(); > 774: write_region("header", header, header_end, 0); > 775: write_data(header, header_end, 0); Consider writing out the header members human-readable, that would be more useful than a hexdump. I'd also print them already at Info level, since often the header info is the only thing interesting. src/hotspot/share/memory/filemap.hpp line 461: > 459: void write_region(int region, char* base, size_t size, > 460: bool read_only, bool allow_exec); > 461: char* write_bitmap_region(const CHeapBitMap* ptrmap, Can you add a comment here and in MetaspaceShared::write_core_archive_regions() that the returned bitmap is c-heap allocated and needs to be freed? ------------- PR: https://git.openjdk.java.net/jdk/pull/474 From stuefe at openjdk.java.net Fri Oct 2 06:39:26 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 2 Oct 2020 06:39:26 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: > Hi all, > > this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the > delay, had vacation then the entrance of Skara delayed things a bit. > For the delta diff please see [3]. > > This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all > feedback individually in this PR body, but I incorporated almost all into the new revision. > What changed since the last version: > > - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the > group consent. > > - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for > overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth > class loader which made it rather pointless. Now I run it always. > > - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. > > - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) > > Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. > > - In ChunkManager::purge() I improved the comments after discussions with Leo. > > - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due > to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run > every time. > > - Fixed indentation issues as Leo requested > > - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested > > - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes > and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more > flexible since it allows us to have list with purge-able and non-purge-able nodes. > > - and various smaller fixes, mainly on request of Leo. > > @lkorinth: > >> VirtualSpaceNode.hpp >> >>102 // Start pointer of the area. >>103 MetaWord* const _base; >> >>How does this differ from _rs._base? Really needed? >> >>105 // Size, in words, of the whole node >>106 const size_t _word_size; >> >>Can we not calculate this from _rs.size()? > > You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it > is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly > improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at > some point and make those members const - as they should be - then I would rewrite this as you suggest. > Thanks, again, for all your review work! > > ------ > > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html > [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: - Misc. Review feedback - Move ClassLoaderMetaspace to own include and correct includes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/336/files - new: https://git.openjdk.java.net/jdk/pull/336/files/f5cf615b..ece884f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=07-08 Stats: 212 lines in 17 files changed: 127 ins; 79 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/336/head:pull/336 PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Fri Oct 2 06:39:26 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 2 Oct 2020 06:39:26 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v8] In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 22:57:23 GMT, Ioi Lam wrote: > LGTM Thanks Ioi! I moved CLMS to an own header as you suggested. I decided to put them outside the metaspace namespace and the metaspace subdirectory since they belong to the external interface (strictly speaking they are the glue between CLD and metaspace). Also keeps changes to outside code small. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From rehn at openjdk.java.net Fri Oct 2 07:18:08 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 2 Oct 2020 07:18:08 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts In-Reply-To: References: Message-ID: <9CQIDFYeLLRibIAwy6T_XgWPoB4STYNycFra37XBvGw=.34931f06-646a-4b93-be55-594bfdea6931@github.com> On Thu, 1 Oct 2020 19:49:20 GMT, Daniel D. Daugherty wrote: >> The issue is that this test doesn't consider Handshake All operation. >> Depending if/when such operation is scheduled it can lockup the VM thread. >> And the safepoint that should timeout never happens. >> See issue for more information. >> >> So I changed the test to "try timeout" the safepoint, but if there was no safepoint (blocked by a handshake all), we >> retry. We sleep unsafe much longer than the interval SafepointALot generates operations, which 'guarantees' we will >> timeout if there is no handshake all. (some extreme case of kernel scheduling causing a very long context switch could >> also make us not timeout) Passes t1, t3, and repeat runs of the test. > > src/hotspot/share/prims/whitebox.cpp line 2294: > >> 2292: >> 2293: WB_ENTRY(jboolean, WB_WaitUnsafe(JNIEnv* env, jobject wb, jint time)) >> 2294: SafepointStateTracker tracker = SafepointSynchronize::safepoint_state_tracker(); > > I had to go back and reread the `SafepointStateTracker` code... > Because this JavaThread is executing and not at a safepoint, the call > to `SafepointSynchronize::safepoint_state_tracker()` will save state > as not-at-a-safepoint (with some safepoint_id value). Yes. We can never return true from this function, e.g. a safepoint happened when unsafe, if we don't have a bug. > src/hotspot/share/prims/whitebox.cpp line 2296: > >> 2294: SafepointStateTracker tracker = SafepointSynchronize::safepoint_state_tracker(); >> 2295: os::naked_short_sleep(time); >> 2296: return tracker.safepoint_state_changed(); > > Ahhh... returns true when we've had a state change or when the > safepoint ID has changed, but... how can the system change the > `SafepointSynchronize::is_at_safepoint()` return value or the > safepoint_id value while we're sleeping? The system shouldn't > be able to go to a safepoint or change safepoint_id values while > this calling thread is not safepoint safe. > > I would think that this function would always return false, but maybe > I'm missing something here. Yes it is like saying return false when everything is working. So yes it may not be so useful. > test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 30: > >> 28: /* >> 29: * @test TestAbortVMOnSafepointTimeout >> 30: * @summary Check if VM can kill thread which doesn't reach safepoint. > > Not your bug, but this summary is wrong. Perhaps: > `@summary Check if VM aborts when a thread doesn't reach safepoint.` The timeout shots a SIGILL on the 'slow' thread, it does not abort (it do abort if it can't send the signal). Test also checks that the log says we have done this. > test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 47: > >> 45: System.out.println("Waiting for safepoint"); >> 46: } >> 47: System.out.println("This message would occur after some time."); > > Maybe I'm missing something, but I don't see how `wb.waitUnsafe(waitTime)` is > ever going to return anything but false so this message should never be printed. It's not a new line. The line was there if the VM fails timeout, so it was never printed assuming a working VM. And now it still not printed assuming a working VM. > test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 71: > >> 69: ProcessBuilder pb = ProcessTools.createJavaProcessBuilder( >> 70: "-XX:+UnlockDiagnosticVMOptions", >> 71: "-XX:-UseBiasedLocking", > > I think "-XX:-UseBiasedLocking" is specified to make sure > that Biased Locking is disabled even in test tasks where it > is enabled by task specific flags. Yes. But now this test is fine with using biased locking. > test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 66: > >> 64: "-Xms64m", >> 65: "TestAbortVMOnSafepointTimeout", >> 66: "" + unsafe_wait > > Cheap conversion from int to String? I followed the other ones: "-XX:SafepointTimeoutDelay=" + timeout_delay In this case we have no name for the 'option', it thus becomes: "" + unsafe_wait > test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 79: > >> 77: } >> 78: } >> 79: output.shouldNotHaveExitValue(0); > > Looks like the test doesn't require that this mesg get printed: > `System.out.println("This message would occur after some time.");` > > And it is set up to detect that the SafepointTimeout happened > which is what we want the test to verify at the core. The line "This message would occur after some time." should never be print if VM is working. If the VM fails for some reason and the timeout is not performed, line: "Timed out while spinning to reach a safepoint." is never printed and the OutputAnalyzer fails the test. If we did timeout and it was printed we know that we didn't print the other message, since the only thread that can timeout is the one printing that message. The second part verifies that the SIGILL was delivered. ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From rehn at openjdk.java.net Fri Oct 2 07:18:04 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 2 Oct 2020 07:18:04 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 04:24:44 GMT, David Holmes wrote: > Hi Robbin, > Hi David, > So.... The old test used an "uncounted loop" (based on internal JIT knowledge) to create looping code with no safepoint > polls so that it remains safepoint-unsafe (and Patricio had to tweak the test conditions to avoid unexpected > safepoints). The new code has a WhiteBox entry that uses an internal naked_sleep which keeps the thread _thread_in_VM > IIUC, which is not safepoint-safe, but also potentially different to being _thread_in_Java. But lets just accept the > net effect is the same - the thread will prevent a safepoint from being reached until the sleep time has elapsed. If > that time is > (GuaranteedSafepointInterval + SafepointTimeoutDelay) then we should see a safepoint timeout and the VM > abort. Okay ... so how does that solve the problem the test currently experiences with handshakes ... if we are at a > handshake the handshake can't proceed until the sleep time expires, but then when we transition back to Java the thread > will see the handshake and so the handshake will proceed. As long as the WB function returns false we will repeat the > process, eventually when the expected safepoint is requested we should again trigger the safepoint timeout and abort. > But like Dan I'm unclear how the WB function can ever return true as the safepoint state can't change whilst the thread > is in the naked sleep. ?? It can't return true if the VM is working. So yes the safepoint tracker maybe overkill. > > Aside: rather than using "args.length > 0" to discriminate between the original and subsequent executions of the test > class, it can be clearer (IMO) to add a static nested class which has the main method that performs the actual test, > and you invoke that via ProcessTools. I didn't change any of that. > That all said, for the record, we really should have a handshake timeout mechanism the same as we have the safepoint > timeout mechanism. We have a timeout mechanism but default off HandshakeTimeout. But it doesn't fire SIGILL to troubled thread as safepoint does. Thanks, Robbin > > Thanks, > David ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From rehn at openjdk.java.net Fri Oct 2 07:18:08 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 2 Oct 2020 07:18:08 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 20:11:12 GMT, Daniel D. Daugherty wrote: >> test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 49: >> >>> 47: System.out.println("This message would occur after some time."); >>> 48: } else { >>> 49: testWith(50, 1, 999); >> >> Please consider: >> >> `testWith(50 /* sfpt_interval */, 1 /* timeout_delay */, 999 /* unsafe_wait */);` > > Also, I think the test would be more clear if this testWith() part > was in a `if (args.length == 0)` block at the top and the else > part was the rest of the test. After all, code flow wise, you > execute the `(args.length == 0)` case first and then come > back for the case with the unsafe_wait value. I only removed the return in favor of the else, the rest is the same as before. ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From github.com+4146708+a74nh at openjdk.java.net Fri Oct 2 08:59:38 2020 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Fri, 2 Oct 2020 08:59:38 GMT Subject: RFR: 8253843: AArch64: Use ishst for storestore barrier In-Reply-To: References: <4bvHnsfvpM8MDmGCQgOkn2ovdeeGLJO5Vh8tYR9p2mc=.4563c186-e164-4295-a49b-06ce715fef72@github.com> Message-ID: On Thu, 1 Oct 2020 01:38:03 GMT, David Holmes wrote: >> I'm also getting CI failures unrelated to this patch, due to disks being full: >> https://github.com/a74nh/jdk/actions/runs/280072223 > > PRs for mainline should be reviewed on mainline mailing lists. The xxx-port mailing lists are supposed to be used for > changes applied to port specific repositories, hence the is no label mapping for them here. You can of course reply > directly to the PR email and add the additional mailing list. > _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on > [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_ > On 30/09/2020 17:29, Alan Hayward wrote: > > > AArch64 orderAccess uses gcc built in atomic functions, which expand > > inline to DMB barrier instructions. Specifically, they call the following: > > FULL_MEM_BARRIER -> DMB ISH > > READ_MEM_BARRIER -> DMB ISHLD > > WRITE_MEM_BARRIER -> DMB ISH > > However, storestore should be optimised to use ISHST. > > In addition, __sync_synchronize is marked as legacy. See: > > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html > > In order for the code to match, > > To match what? Original version of my patch just switched storestore to call asm dmb ishst But then it looks very odd that one function in the file is using asm and the rest of the file is using the C++ functions. > > > I switched everything to call dmbs directly. > > We are now able to use modern C++, which means that we can use real > C++ atomic operations. Going back to inline asms would be a > regression. > > The trouble with using asms for this is that the compiler does not > know what is going on inside an asm. If you use an asm with a memory > clobber for a StoreStore barrier, the compiler has to treat the asm as > a full memory barrier, so it cannot move any loads and stores across > the StoreStore. So, paradoxically, you might be making things worse. > Ok, I agree with that. (maybe a comment in the code would be useful here) At the risk of asking something that's probably been asked before ....Why then do we have inline asm for other targets? Wouldn't it be better to have a common (or OS?) level file for these functions? Also, it looks like using the C++ atomic functions there seems to be no way to generate a dmb ishst. > > Also, add AArch64 to the orderAccess documentation table. > > Please don't. it's more complicated than that, and it's not necessary. > Happy to drop that. But, if it is more complicated than that, then is it wrong for other architectures too? Should that whole table be removed? ------------- PR: https://git.openjdk.java.net/jdk/pull/427 From rehn at openjdk.java.net Fri Oct 2 09:00:54 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 2 Oct 2020 09:00:54 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: References: Message-ID: > The issue is that this test doesn't consider Handshake All operation. > Depending if/when such operation is scheduled it can lockup the VM thread. > And the safepoint that should timeout never happens. > See issue for more information. > > So I changed the test to "try timeout" the safepoint, but if there was no safepoint (blocked by a handshake all), we > retry. We sleep unsafe much longer than the interval SafepointALot generates operations, which 'guarantees' we will > timeout if there is no handshake all. (some extreme case of kernel scheduling causing a very long context switch could > also make us not timeout) Passes t1, t3, and repeat runs of the test. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Update with input from reviews ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/465/files - new: https://git.openjdk.java.net/jdk/pull/465/files/13b40338..90fb3106 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=465&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=465&range=00-01 Stats: 34 lines in 3 files changed: 12 ins; 15 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/465/head:pull/465 PR: https://git.openjdk.java.net/jdk/pull/465 From martin.doerr at sap.com Fri Oct 2 10:12:24 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 2 Oct 2020 10:12:24 +0000 Subject: guarantee(object->mark() == markWord::INFLATING()) failed: invariant In-Reply-To: References: Message-ID: Hi Dan, I just filed https://bugs.openjdk.java.net/browse/JDK-8253927 I'll also look into the code, but this looks like a difficult problem. Best regards, Martin > -----Original Message----- > From: Daniel D. Daugherty > Sent: Donnerstag, 1. Oktober 2020 22:29 > To: Doerr, Martin ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: guarantee(object->mark() == markWord::INFLATING()) failed: > invariant > > Hi Martin, > > It's best to file a new bug and make it clear that the sighting is on > PPC. I have not seen this failure mode in my own stress testing nor > have I seen it in Mach5... > > Dan > > > On 10/1/20 2:52 PM, Doerr, Martin wrote: > > Hi, > > > > we have seen a crash when running Spec JVM 2008 on a Power9 machine. > > It occurred only once so I can't tell if it is a PPC64 specific or weak memory > model specific issue. > > Locking code has worked very solid for many years on this platform. > > > > # Internal Error (synchronizer.cpp:1953), pid=18455, tid=19363 > > # guarantee(object->mark() == markWord::INFLATING()) failed: invariant > > > > V [libjvm.so+0xe463cc] ObjectSynchronizer::inflate(Thread*, oopDesc*, > ObjectSynchronizer::InflateCause)+0x76c > > V [libjvm.so+0xe467ac] ObjectSynchronizer::exit(oopDesc*, BasicLock*, > Thread*)+0x4c > > V [libjvm.so+0xda18a0] > SharedRuntime::complete_monitor_unlocking_C(oopDesc*, BasicLock*, > JavaThread*)+0xc0 > > J 5765 c2 sun.nio.cs.StreamEncoder.flushBuffer()V java.base at 16.0.0.1- > internal (42 bytes) @ 0x00007fff95e1d84c > [0x00007fff95e1d400+0x000000000000044c] > > J 6249 c2 java.io.PrintStream.println(Ljava/lang/String;)V > java.base at 16.0.0.1-internal (44 bytes) @ 0x00007fff95f1f1a0 > [0x00007fff95f1ea80+0x0000000000000720] > > J 6534 c1 > spec.benchmarks.crypto.aes.Main.runEncryptDecrypt(Ljavax/crypto/SecretK > ey;Ljava/lang/String;Ljava/lang/String;)V (93 bytes) @ 0x00007fff8e575794 > [0x00007fff8e574e00+0x0000000000000994] > > j spec.benchmarks.crypto.aes.Main.harnessMain()V+69 > > ... > > > > object->_mark points to a stack lock: > > 0x00007ffe67dfdbc8 is pointing into the stack for thread: > 0x00007ffeec10d5e0 > > content of stack slot 0x7ffe67dfdbc8: 0x0000000000000009 > > which belongs to the crashing thread: > > Current thread (0x00007ffeec10d5e0): JavaThread "BenchmarkThread > crypto.aes 5" [_thread_in_Java, id=19363, > stack(0x00007ffe67c00000,0x00007ffe67e00000)] > > > > I wonder how this can happen. Can it be related to asynchronous lock > deflation? > > Any ideas are welcome. > > > > Best regards, > > Martin > > From sjohanss at openjdk.java.net Fri Oct 2 10:18:42 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 2 Oct 2020 10:18:42 GMT Subject: RFR: 8253926: Use extra_size correctly in anon_mmap_aligned Message-ID: A recent cleanup ([8253638: Cleanup os::reserve_memory and remove MAP_FIXED](https://github.com/openjdk/jdk/pull/357/)) got a size mixed up in `anon_mmap_aligned()`. Instead of passing down the calculated `extra_size` to `anon_mmap()` it uses the original size `bytes`. This resulted in an early crash when using large pages and with this fix the crash goes away. ------------- Commit messages: - 8253926: Use extra_size correctly in anon_mmap_aligned Changes: https://git.openjdk.java.net/jdk/pull/479/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=479&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253926 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/479.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/479/head:pull/479 PR: https://git.openjdk.java.net/jdk/pull/479 From shade at openjdk.java.net Fri Oct 2 10:25:37 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 2 Oct 2020 10:25:37 GMT Subject: RFR: 8253926: Use extra_size correctly in anon_mmap_aligned In-Reply-To: References: Message-ID: <8y6-slKq9miN7GkGXftijelPThZVbTfxk_JGGhbNoDg=.3386a289-6129-482b-819a-6a8313228ce2@github.com> On Fri, 2 Oct 2020 10:00:27 GMT, Stefan Johansson wrote: > A recent cleanup ([8253638: Cleanup os::reserve_memory and remove MAP_FIXED](https://github.com/openjdk/jdk/pull/357/)) > got a size mixed up in `anon_mmap_aligned()`. Instead of passing down the calculated `extra_size` to `anon_mmap()` it > uses the original size `bytes`. This resulted in an early crash when using large pages and with this fix the crash > goes away. Looks fine. I read the original changeset, and there seem to be no other instances of this error. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/479 From kbarrett at openjdk.java.net Fri Oct 2 10:45:39 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 2 Oct 2020 10:45:39 GMT Subject: RFR: 8253926: Use extra_size correctly in anon_mmap_aligned In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 10:00:27 GMT, Stefan Johansson wrote: > A recent cleanup ([8253638: Cleanup os::reserve_memory and remove MAP_FIXED](https://github.com/openjdk/jdk/pull/357/)) > got a size mixed up in `anon_mmap_aligned()`. Instead of passing down the calculated `extra_size` to `anon_mmap()` it > uses the original size `bytes`. This resulted in an early crash when using large pages and with this fix the crash > goes away. Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/479 From tschatzl at openjdk.java.net Fri Oct 2 11:06:37 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 2 Oct 2020 11:06:37 GMT Subject: RFR: 8253926: Use extra_size correctly in anon_mmap_aligned In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 10:00:27 GMT, Stefan Johansson wrote: > A recent cleanup ([8253638: Cleanup os::reserve_memory and remove MAP_FIXED](https://github.com/openjdk/jdk/pull/357/)) > got a size mixed up in `anon_mmap_aligned()`. Instead of passing down the calculated `extra_size` to `anon_mmap()` it > uses the original size `bytes`. This resulted in an early crash when using large pages and with this fix the crash > goes away. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/479 From sjohanss at openjdk.java.net Fri Oct 2 11:06:38 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 2 Oct 2020 11:06:38 GMT Subject: RFR: 8253926: Use extra_size correctly in anon_mmap_aligned In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 10:42:50 GMT, Kim Barrett wrote: >> A recent cleanup ([8253638: Cleanup os::reserve_memory and remove MAP_FIXED](https://github.com/openjdk/jdk/pull/357/)) >> got a size mixed up in `anon_mmap_aligned()`. Instead of passing down the calculated `extra_size` to `anon_mmap()` it >> uses the original size `bytes`. This resulted in an early crash when using large pages and with this fix the crash >> goes away. > > Marked as reviewed by kbarrett (Reviewer). Thanks @shipilev and @kimbarrett for reviewing. ------------- PR: https://git.openjdk.java.net/jdk/pull/479 From stefank at openjdk.java.net Fri Oct 2 11:35:37 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 2 Oct 2020 11:35:37 GMT Subject: RFR: 8253926: Use extra_size correctly in anon_mmap_aligned In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 10:00:27 GMT, Stefan Johansson wrote: > A recent cleanup ([8253638: Cleanup os::reserve_memory and remove MAP_FIXED](https://github.com/openjdk/jdk/pull/357/)) > got a size mixed up in `anon_mmap_aligned()`. Instead of passing down the calculated `extra_size` to `anon_mmap()` it > uses the original size `bytes`. This resulted in an early crash when using large pages and with this fix the crash > goes away. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/479 From sjohanss at openjdk.java.net Fri Oct 2 11:48:43 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 2 Oct 2020 11:48:43 GMT Subject: RFR: 8253926: Use extra_size correctly in anon_mmap_aligned In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 11:32:27 GMT, Stefan Karlsson wrote: >> A recent cleanup ([8253638: Cleanup os::reserve_memory and remove MAP_FIXED](https://github.com/openjdk/jdk/pull/357/)) >> got a size mixed up in `anon_mmap_aligned()`. Instead of passing down the calculated `extra_size` to `anon_mmap()` it >> uses the original size `bytes`. This resulted in an early crash when using large pages and with this fix the crash >> goes away. > > Marked as reviewed by stefank (Reviewer). Thanks @tschatzl and @stefank, I will integrate this now. ------------- PR: https://git.openjdk.java.net/jdk/pull/479 From sjohanss at openjdk.java.net Fri Oct 2 11:48:44 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 2 Oct 2020 11:48:44 GMT Subject: Integrated: 8253926: Use extra_size correctly in anon_mmap_aligned In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 10:00:27 GMT, Stefan Johansson wrote: > A recent cleanup ([8253638: Cleanup os::reserve_memory and remove MAP_FIXED](https://github.com/openjdk/jdk/pull/357/)) > got a size mixed up in `anon_mmap_aligned()`. Instead of passing down the calculated `extra_size` to `anon_mmap()` it > uses the original size `bytes`. This resulted in an early crash when using large pages and with this fix the crash > goes away. This pull request has now been integrated. Changeset: f686a380 Author: Stefan Johansson URL: https://git.openjdk.java.net/jdk/commit/f686a380 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8253926: Use extra_size correctly in anon_mmap_aligned Reviewed-by: shade, kbarrett, tschatzl, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/479 From lkorinth at openjdk.java.net Fri Oct 2 11:53:42 2020 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 2 Oct 2020 11:53:42 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 06:39:26 GMT, Thomas Stuefe wrote: >> Hi all, >> >> this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the >> delay, had vacation then the entrance of Skara delayed things a bit. >> For the delta diff please see [3]. >> >> This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all >> feedback individually in this PR body, but I incorporated almost all into the new revision. >> What changed since the last version: >> >> - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the >> group consent. >> >> - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for >> overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth >> class loader which made it rather pointless. Now I run it always. >> >> - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. >> >> - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) >> >> Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. >> >> - In ChunkManager::purge() I improved the comments after discussions with Leo. >> >> - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due >> to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run >> every time. >> >> - Fixed indentation issues as Leo requested >> >> - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested >> >> - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes >> and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more >> flexible since it allows us to have list with purge-able and non-purge-able nodes. >> >> - and various smaller fixes, mainly on request of Leo. >> >> @lkorinth: >> >>> VirtualSpaceNode.hpp >>> >>>102 // Start pointer of the area. >>>103 MetaWord* const _base; >>> >>>How does this differ from _rs._base? Really needed? >>> >>>105 // Size, in words, of the whole node >>>106 const size_t _word_size; >>> >>>Can we not calculate this from _rs.size()? >> >> You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it >> is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly >> improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at >> some point and make those members const - as they should be - then I would rewrite this as you suggest. >> Thanks, again, for all your review work! >> >> ------ >> >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html >> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html >> [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - Misc. Review feedback > - Move ClassLoaderMetaspace to own include and correct includes Let us ship this. Thanks for all your great work, great presentations and for doing all the tedious fixes. ------------- Marked as reviewed by lkorinth (Committer). PR: https://git.openjdk.java.net/jdk/pull/336 From rehn at openjdk.java.net Fri Oct 2 12:10:40 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 2 Oct 2020 12:10:40 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 18:58:03 GMT, Patricio Chilano Mateo wrote: > LGTM Thanks! There is an update, please consider. ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From iignatyev at openjdk.java.net Fri Oct 2 13:50:47 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 2 Oct 2020 13:50:47 GMT Subject: Integrated: 8253913: unify gtest test names In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 21:42:10 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small and trivial patch that unifies the names of hotspot gtests? in some cases, "_test" > is added to gtest names, in others it isn't. given some tests specify "test" in their names, so we get "test_test" like > in `UninitializedDoubleElementWorkerDataArrayTest.sum_test_test_vm`. the patch removes `_test` from the suffixes added > by `TEST*` macros. testing: ? `make test TEST=gtest` on macosx-x64 > ? `test/hotspot/jtreg/gtest/` on {linux,windows,macosx}-x64 This pull request has now been integrated. Changeset: 406db1c2 Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/406db1c2 Stats: 14 lines in 3 files changed: 5 ins; 0 del; 9 mod 8253913: unify gtest test names Reviewed-by: stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/475 From iignatyev at openjdk.java.net Fri Oct 2 13:50:44 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 2 Oct 2020 13:50:44 GMT Subject: RFR: 8253913: unify gtest test names [v2] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 06:22:29 GMT, Stefan Karlsson wrote: >> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust test class names in LogStream's friends > > Looks good. I think it's great that you clean this up. I started doing something similar myself, but never got around > to create an RFE for it. IIRC, when I looked at it there were more inconsistencies with the names, but maybe they are > gone now. @stefank, thank you for your review. please let me know if you notice any other inconsistencies after the patch ------------- PR: https://git.openjdk.java.net/jdk/pull/475 From aph at redhat.com Fri Oct 2 14:24:54 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 2 Oct 2020 15:24:54 +0100 Subject: RFR: 8253843: AArch64: Use ishst for storestore barrier In-Reply-To: References: <4bvHnsfvpM8MDmGCQgOkn2ovdeeGLJO5Vh8tYR9p2mc=.4563c186-e164-4295-a49b-06ce715fef72@github.com> Message-ID: <8434c1ca-7b67-8ec3-265c-7e4e40ce3e2e@redhat.com> On 02/10/2020 09:59, Alan Hayward wrote: > >> >> The trouble with using asms for this is that the compiler does not >> know what is going on inside an asm. If you use an asm with a memory >> clobber for a StoreStore barrier, the compiler has to treat the asm as >> a full memory barrier, so it cannot move any loads and stores across >> the StoreStore. So, paradoxically, you might be making things worse. >> > > Ok, I agree with that. (maybe a comment in the code would be useful here) > > At the risk of asking something that's probably been asked before ....Why > then do we have inline asm for other targets? Wouldn't it be better to > have a common (or OS?) level file for these functions? There's history here. A lot of history. Back in the day, there was very poor support for multi-threaded programs in C++; there was even a famous paper "Threads cannot be implemented as a Library" by Hans Boehm. At that time, compiler authors had to invent nonstandard ways to support memory fences, and in the very early days (when Java was written) there was nothing but asms. Fast forward to recent times, and there was a rewrite of HotSpot's support for atomic memory ops. At that point the issue of using compiler builtins rather than asms came up. The objection to builtins was I agree that on x86, there isn't a whole lot of other things the compiler could do with the intrinsics than what we want it to do due to the relatively strong memory model of the machine. So this might be a possible simplification on x86 gcc/clang targets (but still not all x86 targets). As for PPC and ARMv7 though, that is not true any longer. For example, our conservative memory model is more conservative than seq_cst semantics. E.g. it also has "leading sync" semantics always guaranteed, which is exploited in our code base and would be broken if translated simply as seq_cst. Also, since the fencing from the C++ compiler must be compliant with what our code generation does, they could end up being incompatible due to choice of different fencing conventions. Intrinsic provided operations may or may not have leading sync semantics. We can hope for it, but we should never rely on it. https://mail.openjdk.java.net/pipermail/hotspot-dev/2017-September/028238.html I didn't agree with this reasoning for AArch64 because it's a new architecture and the mappings from the ISA to the C++ standard intrinsics are well defined, if somewhat informally. Using builtins turned out to have been a good decision for AArch64. When Neoverse N1 came out with a poorly-performing implementation of ldx/stx but fast LSE compaure-and-swap instructions GCC knew how to do the right thing, so we didn't need to change anything. > Also, it looks like using the C++ atomic functions there seems to be > no way to generate a dmb ishst. Seems like it, probably because its semantics in high-level-language terms are horrid. There's another gem from Hans Boehm: https://www.hboehm.info/c++mm/no_write_fences.html It's something of a shame that AArch64 can't give us a release fence instruction. > Happy to drop that. But, if it is more complicated than that, then > is it wrong for other architectures too? Should that whole table be > removed? I have no idea. I think it makes more sense to look at the code. -- 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 daniel.daugherty at oracle.com Fri Oct 2 15:19:18 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 2 Oct 2020 11:19:18 -0400 Subject: guarantee(object->mark() == markWord::INFLATING()) failed: invariant In-Reply-To: References: Message-ID: <498a6e46-11f6-625c-9956-edf59b08a1d9@oracle.com> Thanks for filing the bug! Dan On 10/2/20 6:12 AM, Doerr, Martin wrote: > Hi Dan, > > I just filed > https://bugs.openjdk.java.net/browse/JDK-8253927 > > I'll also look into the code, but this looks like a difficult problem. > > Best regards, > Martin > > >> -----Original Message----- >> From: Daniel D. Daugherty >> Sent: Donnerstag, 1. Oktober 2020 22:29 >> To: Doerr, Martin ; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: guarantee(object->mark() == markWord::INFLATING()) failed: >> invariant >> >> Hi Martin, >> >> It's best to file a new bug and make it clear that the sighting is on >> PPC. I have not seen this failure mode in my own stress testing nor >> have I seen it in Mach5... >> >> Dan >> >> >> On 10/1/20 2:52 PM, Doerr, Martin wrote: >>> Hi, >>> >>> we have seen a crash when running Spec JVM 2008 on a Power9 machine. >>> It occurred only once so I can't tell if it is a PPC64 specific or weak memory >> model specific issue. >>> Locking code has worked very solid for many years on this platform. >>> >>> # Internal Error (synchronizer.cpp:1953), pid=18455, tid=19363 >>> # guarantee(object->mark() == markWord::INFLATING()) failed: invariant >>> >>> V [libjvm.so+0xe463cc] ObjectSynchronizer::inflate(Thread*, oopDesc*, >> ObjectSynchronizer::InflateCause)+0x76c >>> V [libjvm.so+0xe467ac] ObjectSynchronizer::exit(oopDesc*, BasicLock*, >> Thread*)+0x4c >>> V [libjvm.so+0xda18a0] >> SharedRuntime::complete_monitor_unlocking_C(oopDesc*, BasicLock*, >> JavaThread*)+0xc0 >>> J 5765 c2 sun.nio.cs.StreamEncoder.flushBuffer()V java.base at 16.0.0.1- >> internal (42 bytes) @ 0x00007fff95e1d84c >> [0x00007fff95e1d400+0x000000000000044c] >>> J 6249 c2 java.io.PrintStream.println(Ljava/lang/String;)V >> java.base at 16.0.0.1-internal (44 bytes) @ 0x00007fff95f1f1a0 >> [0x00007fff95f1ea80+0x0000000000000720] >>> J 6534 c1 >> spec.benchmarks.crypto.aes.Main.runEncryptDecrypt(Ljavax/crypto/SecretK >> ey;Ljava/lang/String;Ljava/lang/String;)V (93 bytes) @ 0x00007fff8e575794 >> [0x00007fff8e574e00+0x0000000000000994] >>> j spec.benchmarks.crypto.aes.Main.harnessMain()V+69 >>> ... >>> >>> object->_mark points to a stack lock: >>> 0x00007ffe67dfdbc8 is pointing into the stack for thread: >> 0x00007ffeec10d5e0 >>> content of stack slot 0x7ffe67dfdbc8: 0x0000000000000009 >>> which belongs to the crashing thread: >>> Current thread (0x00007ffeec10d5e0): JavaThread "BenchmarkThread >> crypto.aes 5" [_thread_in_Java, id=19363, >> stack(0x00007ffe67c00000,0x00007ffe67e00000)] >>> I wonder how this can happen. Can it be related to asynchronous lock >> deflation? >>> Any ideas are welcome. >>> >>> Best regards, >>> Martin >>> From ccheung at openjdk.java.net Fri Oct 2 16:20:00 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 2 Oct 2020 16:20:00 GMT Subject: RFR: 8224509: Incorrect alignment in CDS related allocation code on 32-bit platforms [v2] In-Reply-To: References: Message-ID: > CDS aligns pointers and sizes to BytesPerWord. On 64-bit, BytesPerWord = 8. On 32-bit, BytesPerWord = 4. > > To make the alignment consistent between 64- and 32-bit platforms, this patch changes the alignment value to 8. > > Testing: tiers 1 - 4 > built linux-x86-debug. 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 three additional commits since the last revision: - Merge branch 'master' of github.com:calvinccheung/jdk into 8224509 - set SharedSpaceObjectAlignment to KlassAlignmentInBytes - 8224509 (initial commit) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/476/files - new: https://git.openjdk.java.net/jdk/pull/476/files/d17d328f..04b7a777 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=476&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=476&range=00-01 Stats: 18819 lines in 2008 files changed: 6755 ins; 4065 del; 7999 mod Patch: https://git.openjdk.java.net/jdk/pull/476.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/476/head:pull/476 PR: https://git.openjdk.java.net/jdk/pull/476 From ccheung at openjdk.java.net Fri Oct 2 16:25:45 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 2 Oct 2020 16:25:45 GMT Subject: RFR: 8224509: Incorrect alignment in CDS related allocation code on 32-bit platforms [v2] In-Reply-To: References: Message-ID: <_Av5wMHmeT4BEMU6M8IowRRni2LmhHOI7WCiK0yqDaA=.cc14bf75-e3bd-4aa3-98b2-4742f6e4aa49@github.com> On Fri, 2 Oct 2020 05:03:45 GMT, Thomas Stuefe wrote: >> src/hotspot/share/memory/archiveUtils.hpp line 33: >> >>> 31: #include "utilities/bitMap.hpp" >>> 32: >>> 33: #define SharedSpaceObjectAlignment 8 >> >> I think we can use a `const int` instead of `#define`. Also, some comments will be helpful. Maybe: >> >> // Metaspace::allocate() requires that all blocks must be aligned with KlassAlignmentInBytes. >> // We enforce the same alignment rule in blocks allocated from the shared space. >> const int SharedSpaceObjectAlignment = KlassAlignmentInBytes; > > +1 to making the dependency on KlassAlignment explicit. Please do not hide any dependencies on Klass alignment behind > literals (I am currently experimenting with increasing class space allocation alignment to increase the range of > zero-based Klass* encoding) Thanks @iklam and @tstuefe for the review. I've made the change in webrev 01. ------------- PR: https://git.openjdk.java.net/jdk/pull/476 From ccheung at openjdk.java.net Fri Oct 2 16:30:01 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 2 Oct 2020 16:30:01 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v3] In-Reply-To: References: Message-ID: > Following up on archiving lambda proxy classes in dynamic CDS archive > ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of > lambda proxy classes in static CDS archive. > When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved > during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will > be of the following format: > `@lambda-proxy: ` > > e.g. > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` > > When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above > `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool > indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool > entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index > and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. > During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not > found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> > IsCDSDumpingEnabled) is involved in the core-libs code.) > Testing: tiers 1,2,3,4. > > Performance results (javac on HelloWorld on linux-x64): > Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " > 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- > 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- > 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- > 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- > 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- > 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- > 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- > 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- > 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- > 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- > ============================================================ > 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- > instr delta = -161497801 -7.2542% > time delta = -24.722 ms -6.5951% 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 five additional commits since the last revision: - Merge branch 'master' into 8247666 - exclude archived lambda proxy classes in the classlist - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi - fix extraneous whitespace - 8247666 (initial commit) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/364/files - new: https://git.openjdk.java.net/jdk/pull/364/files/d66667d4..c82b39f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=01-02 Stats: 18818 lines in 2008 files changed: 6756 ins; 4063 del; 7999 mod Patch: https://git.openjdk.java.net/jdk/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364 PR: https://git.openjdk.java.net/jdk/pull/364 From sgehwolf at openjdk.java.net Fri Oct 2 16:41:49 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 2 Oct 2020 16:41:49 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) Message-ID: An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the affected system, `/proc/self/mountinfo` contains a line such as this one: 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd Note that `/proc/cgroups` looks like this: #subsys_name hierarchy num_cgroups enabled cpuset 0 1 1 cpu 0 1 1 cpuacct 0 1 1 blkio 0 1 1 memory 0 1 1 devices 0 1 1 freezer 0 1 1 net_cls 0 1 1 perf_event 0 1 1 net_prio 0 1 1 hugetlb 0 1 1 pids 0 1 1 This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and look for `cgroup` FS-type lines which aren't also mounted purely for systemd. **Testing** - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) - [x] Added regression test which fails prior the patch and passes after - [ ] Submit testing (still running) ------------- Commit messages: - 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) Changes: https://git.openjdk.java.net/jdk/pull/485/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245543 Stats: 89 lines in 4 files changed: 83 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Fri Oct 2 16:41:49 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 2 Oct 2020 16:41:49 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 16:34:49 GMT, Severin Gehwolf wrote: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and > look for `cgroup` FS-type lines which aren't also mounted purely for systemd. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [ ] Submit testing (still running) @bulasevich Do you want to give this a spin? ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From gziemski at openjdk.java.net Fri Oct 2 17:05:56 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 2 Oct 2020 17:05:56 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms [v8] In-Reply-To: References: Message-ID: > hi all, > > Please review this change that refactors common POSIX code into a separate > file. > > Currently there appears to be quite a bit of duplicated code among POSIX > platforms, which makes it difficult to apply single fix to the signal code. > With this fix, we will only need to touch single file for common POSIX > code fixes from now on. > > ---------------------------------------------------------------------------- > The APIs which moved from os/bsd/os_bsd.cpp to to os/posix/PosixSignals.cpp: > > //////////////////////////////////////////////////////////////////////////////// > // signal support > void os::Bsd::signal_sets_init() > sigset_t* os::Bsd::unblocked_signals() > sigset_t* os::Bsd::vm_signals() > void os::Bsd::hotspot_sigmask(Thread* thread) > //////////////////////////////////////////////////////////////////////////////// > // sun.misc.Signal support > static void UserHandler(int sig, void *siginfo, void *context) > void* os::user_handler() > void* os::signal(int signal_number, void* handler) > void os::signal_raise(int signal_number) > int os::sigexitnum_pd() > static void jdk_misc_signal_init() > void os::signal_notify(int sig) > static int check_pending_signals() > int os::signal_wait() > //////////////////////////////////////////////////////////////////////////////// > // suspend/resume support > static void resume_clear_context(OSThread *osthread) > static void suspend_save_context(OSThread *osthread, siginfo_t* siginfo, ucontext_t* context) > static void SR_handler(int sig, siginfo_t* siginfo, ucontext_t* context) > static int SR_initialize() > static int sr_notify(OSThread* osthread) > static bool do_suspend(OSThread* osthread) > static void do_resume(OSThread* osthread) > /////////////////////////////////////////////////////////////////////////////////// > // signal handling (except suspend/resume) > static void signalHandler(int sig, siginfo_t* info, void* uc) > struct sigaction* os::Bsd::get_chained_signal_action(int sig) > static bool call_chained_handler(struct sigaction *actp, int sig, > siginfo_t *siginfo, void *context) > bool os::Bsd::chained_handler(int sig, siginfo_t* siginfo, void* context) > int os::Bsd::get_our_sigflags(int sig) > void os::Bsd::set_our_sigflags(int sig, int flags) > void os::Bsd::set_signal_handler(int sig, bool set_installed) > void os::Bsd::install_signal_handlers() > static const char* get_signal_handler_name(address handler, > char* buf, int buflen) > static void print_signal_handler(outputStream* st, int sig, > char* buf, size_t buflen) > void os::run_periodic_checks() > void os::Bsd::check_signal_handler(int sig) > > ----------------------------------------------------------------------------- > The APIs which moved from os/posix/os_posix.cpp to os/posix/PosixSignals.cpp: > > const char* os::Posix::get_signal_name(int sig, char* out, size_t outlen) > int os::Posix::get_signal_number(const char* signal_name) > int os::get_signal_number(const char* signal_name) > bool os::Posix::is_valid_signal(int sig) > bool os::Posix::is_sig_ignored(int sig) > const char* os::exception_name(int sig, char* buf, size_t size) > const char* os::Posix::describe_signal_set_short(const sigset_t* set, char* buffer, size_t buf_size) > void os::Posix::print_signal_set_short(outputStream* st, const sigset_t* set) > const char* os::Posix::describe_sa_flags(int flags, char* buffer, size_t size) > oid os::Posix::print_sa_flags(outputStream* st, int flags) > static bool get_signal_code_description(const siginfo_t* si, enum_sigcode_desc_t* out) > void os::print_siginfo(outputStream* os, const void* si0) > bool os::signal_thread(Thread* thread, int sig, const char* reason) > int os::Posix::unblock_thread_signal_mask(const sigset_t *set) > address os::Posix::ucontext_get_pc(const ucontext_t* ctx) > void os::Posix::ucontext_set_pc(ucontext_t* ctx, address pc) > struct sigaction* os::Posix::get_preinstalled_handler(int sig) > void os::Posix::save_preinstalled_handler(int sig, struct sigaction& oldAct) > > > -------------------------------------------------------- > -------------------------------------------------------- > > DETAILS: > > -------------------------------------------------------- > Public APIs which are now internal static PosixSignals:: > > sigset_t* os::Bsd::vm_signals() > struct sigaction* os::Bsd::get_chained_signal_action(int sig) > int os::Bsd::get_our_sigflags(int sig) > void os::Bsd::set_our_sigflags(int sig, int flags) > void os::Bsd::set_signal_handler(int sig, bool set_installed) > void os::Bsd::check_signal_handler(int sig) > const char* os::Posix::get_signal_name(int sig, char* out, size_t outlen) > bool os::Posix::is_valid_signal(int sig) > const char* os::Posix::describe_signal_set_short(const sigset_t* set, char* buffer, size_t buf_size) > void os::Posix::print_signal_set_short(outputStream* st, const sigset_t* set) > const char* os::Posix::describe_sa_flags(int flags, char* buffer, size_t size) > oid os::Posix::print_sa_flags(outputStream* st, int flags) > static bool get_signal_code_description(const siginfo_t* si, enum_sigcode_desc_t* out) > void os::Posix::save_preinstalled_handler(int sig, struct sigaction& oldAct) > > ------------------------------------------------ > Public APIs which moved to public PosixSignals:: > > void os::Bsd::signal_sets_init() > void os::Bsd::hotspot_sigmask(Thread* thread) > bool os::Bsd::chained_handler(int sig, siginfo_t* siginfo, void* context) > void os::Bsd::install_signal_handlers() > bool os::Posix::is_sig_ignored(int sig) > int os::Posix::unblock_thread_signal_mask(const sigset_t *set) > address os::Posix::ucontext_get_pc(const ucontext_t* ctx) > void os::Posix::ucontext_set_pc(ucontext_t* ctx, address pc) > > ---------------------------------------------------- > Internal APIs which are now public in PosixSignals:: > > static void jdk_misc_signal_init() > static int SR_initialize() > static bool do_suspend(OSThread* osthread) > static void do_resume(OSThread* osthread) > static void print_signal_handler(outputStream* st, int sig, char* buf, size_t buflen) > > -------------------------- > New APIs in PosixSignals:: > > static bool are_signal_handlers_installed(); Gerard Ziemski 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: Address David's review issues ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/157/files - new: https://git.openjdk.java.net/jdk/pull/157/files/b50d7229..06b104d0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=157&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=157&range=06-07 Stats: 18 lines in 11 files changed: 0 ins; 4 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/157.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/157/head:pull/157 PR: https://git.openjdk.java.net/jdk/pull/157 From gziemski at openjdk.java.net Fri Oct 2 17:05:56 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 2 Oct 2020 17:05:56 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms [v5] In-Reply-To: References: <0_pPVrBJAGbaVyHMnVhS2E0ByTkolg4tKpUH4N8fplg=.eb0fa0d9-44f8-4c63-8322-bd2320d3000a@github.com> <_RJ0u-P40RQfJNTWyHNYS3uh4TCeHY8ljaS5CLGgnFY=.3bbd9ea2-0d27-4562-a1bb-f0eadb374c50@github.com> Message-ID: On Fri, 2 Oct 2020 03:49:44 GMT, David Holmes wrote: >>> merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your >>> intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of >>> this pull request to `Merge :` where `` is the name of another project in the [OpenJDK >>> organization](https://github.com/openjdk) (for example `Merge jdk:master`). >> >> Can anyone explain what this means and whether it's OK to go ahead with this pr, or should I close this one (since I >> made quite a mess of it) and start a new one? > > Hi Gerard, > > I'm afraid something is still very wrong here. I see you fixing the original merge issues in: > > b33d292e96a559b8a3a998641411f61bf087738f (Address David's review issues ) > > but then the "Fix Merge" commit > > 4f5d4cd49436b64dc3770e4ba1f811a76b5a09e7 > > applied after that seems to have reversed them again! > > I think it might be necessary to close this PR and create a new one. > > Thanks. I'm considering this pr to be "lost cause", so I just "force pushed" to a known good state, wiping out the bad merge that backed out my fixes based on David's comments, so that I have a snapshot of what I want to become the basis of new pr. Just thought I would explain what I'm trying to do before anyone points out to me that I should not be using "push --force". ------------- PR: https://git.openjdk.java.net/jdk/pull/157 From iklam at openjdk.java.net Fri Oct 2 22:46:41 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 2 Oct 2020 22:46:41 GMT Subject: RFR: 8224509: Incorrect alignment in CDS related allocation code on 32-bit platforms [v2] In-Reply-To: References: Message-ID: <4iiUT-v2gkVsju9OupdB9ExubZ2viPRzsd6LJaF4Dwg=.97b7b34b-c84a-4be0-bf3c-de9f27dc9d87@github.com> On Fri, 2 Oct 2020 16:20:00 GMT, Calvin Cheung wrote: >> CDS aligns pointers and sizes to BytesPerWord. On 64-bit, BytesPerWord = 8. On 32-bit, BytesPerWord = 4. >> >> To make the alignment consistent between 64- and 32-bit platforms, this patch changes the alignment value to 8. >> >> Testing: tiers 1 - 4 >> built linux-x86-debug. > > 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 three additional commits since > the last revision: > - Merge branch 'master' of github.com:calvinccheung/jdk into 8224509 > - set SharedSpaceObjectAlignment to KlassAlignmentInBytes > - 8224509 (initial commit) Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/476 From mchung at openjdk.java.net Fri Oct 2 22:50:44 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 2 Oct 2020 22:50:44 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v3] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 16:30:01 GMT, Calvin Cheung wrote: >> Following up on archiving lambda proxy classes in dynamic CDS archive >> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of >> lambda proxy classes in static CDS archive. >> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved >> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will >> be of the following format: >> `@lambda-proxy: ` >> >> e.g. >> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` >> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` >> >> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above >> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool >> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool >> entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index >> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. >> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not >> found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> >> IsCDSDumpingEnabled) is involved in the core-libs code.) >> Testing: tiers 1,2,3,4. >> >> Performance results (javac on HelloWorld on linux-x64): >> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " >> 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- >> 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- >> 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- >> 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- >> 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- >> 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- >> 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- >> 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- >> 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- >> 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- >> ============================================================ >> 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- >> instr delta = -161497801 -7.2542% >> time delta = -24.722 ms -6.5951% > > 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 five additional commits since > the last revision: > - Merge branch 'master' into 8247666 > - exclude archived lambda proxy classes in the classlist > - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi > - fix extraneous whitespace > - 8247666 (initial commit) > @lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233 @lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355 It seems very fragile to require listing the CP index to `invokedynamic` entries of a class file. Have you considered a simpler usage model without CP indices and default to all `invokedynamic` to `LambdaMetaFactory`? src/java.base/share/classes/jdk/internal/misc/CDS.java line 56: > 54: * Check if CDS dumping is enabled via the DynamicDumpSharedSpaces or the DumpSharedSpaces flag. > 55: */ > 56: public static native boolean isCDSDumpingEnabled(); I suggest to rename `CDS::isCDSDumpingEnabled` to `CDS:isDumpingEnabled` as this method is a static method in `CDS` case and the word `CDS` in the method name is just noise. JVM entry point `JVM_IsCDSDumpingEnabled` is good. src/hotspot/share/prims/jvm.cpp line 3834: > 3832: > 3833: JVM_ENTRY(jboolean, JVM_IsCDSDumpingEnabled(JNIEnv* env)) > 3834: JVMWrapper("JVM_IsCDSDumpingEnable"); typo: missing `d` s/Enable/Enabled/ ------------- PR: https://git.openjdk.java.net/jdk/pull/364 From zgu at openjdk.java.net Fri Oct 2 23:12:38 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 2 Oct 2020 23:12:38 GMT Subject: RFR: 8253948: Memory leak in ImageFileReader In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 20:47:16 GMT, Zhengyu Gu wrote: > ImageFileReader allocates ImageModuleData in ImageFileReader::open(), but never free. > > Also renamed module_data to _module_data to be consistent with other member variables. > > Test: > - [x] tier1 on Linux x86_64 ImageFileReader is also used in hotspot runtime ------------- PR: https://git.openjdk.java.net/jdk/pull/490 From zgu at openjdk.java.net Sat Oct 3 00:12:42 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Sat, 3 Oct 2020 00:12:42 GMT Subject: RFR: 8253960: Memory leak in Java_java_lang_ClassLoader_defineClass0() Message-ID: The memory leak is quite obvious. Early return results 'body' not been released. ------------- Commit messages: - 8253960: Memory leak in Java_java_lang_ClassLoader_defineClass0() Changes: https://git.openjdk.java.net/jdk/pull/492/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=492&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253960 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/492.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/492/head:pull/492 PR: https://git.openjdk.java.net/jdk/pull/492 From mchung at openjdk.java.net Sat Oct 3 02:02:37 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Sat, 3 Oct 2020 02:02:37 GMT Subject: RFR: 8253960: Memory leak in Java_java_lang_ClassLoader_defineClass0() In-Reply-To: References: Message-ID: On Sat, 3 Oct 2020 00:05:40 GMT, Zhengyu Gu wrote: > The memory leak is quite obvious. Early return results 'body' not been released. > > Test: > > - [x] tier1 on Linux x86_64 Thanks for catching this. Looks good. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/492 From stuefe at openjdk.java.net Sat Oct 3 05:27:37 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 3 Oct 2020 05:27:37 GMT Subject: RFR: 8253960: Memory leak in Java_java_lang_ClassLoader_defineClass0() In-Reply-To: References: Message-ID: On Sat, 3 Oct 2020 00:05:40 GMT, Zhengyu Gu wrote: > The memory leak is quite obvious. Early return results 'body' not been released. > > Test: > > - [x] tier1 on Linux x86_64 Look good! ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/492 From stuefe at openjdk.java.net Sat Oct 3 05:33:39 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 3 Oct 2020 05:33:39 GMT Subject: RFR: 8253889: Remove ExecMem constant In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 09:36:00 GMT, Aleksey Shipilev wrote: > > Maybe it did something in the past. Now it just seems to be a complicated way to say "false". > > I think that's a Hotspot style. There are few other places where "symbolic values" for boolean parameters are used. For > example, `CodeBlobToOopClosure::FixRelocations`. `grep 'static const bool'` identify a few more. I personally find it a > tad more readable. So, it is not as useless... Well in that case it is applied very inconsistently since most call sites just use false. Lets see if anyone else has an opinion on this. ------------- PR: https://git.openjdk.java.net/jdk/pull/454 From alanb at openjdk.java.net Sat Oct 3 06:10:36 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 3 Oct 2020 06:10:36 GMT Subject: RFR: 8253960: Memory leak in Java_java_lang_ClassLoader_defineClass0() In-Reply-To: References: Message-ID: On Sat, 3 Oct 2020 00:05:40 GMT, Zhengyu Gu wrote: > The memory leak is quite obvious. Early return results 'body' not been released. > > Test: > > - [x] tier1 on Linux x86_64 Should this be renamed to "Memory leak in Lookup.defineClass"? I don't think it impacts anything extending or using the ClassLoader. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/492 From stuefe at openjdk.java.net Sat Oct 3 09:48:39 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 3 Oct 2020 09:48:39 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 11:50:50 GMT, Leo Korinth wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - Misc. Review feedback >> - Move ClassLoaderMetaspace to own include and correct includes > > Let us ship this. Thanks for all your great work, great presentations and for doing all the tedious fixes. > Let us ship this. Thanks for all your great work, great presentations and for doing all the tedious fixes. > > /Leo Great, thank you too for your thorough review work! ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From jiefu at openjdk.java.net Sat Oct 3 13:34:43 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 3 Oct 2020 13:34:43 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) Message-ID: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> __sync_val_compare_and_swap shouldn't call with narrowOop* for clang after JDK-8247912. Before passing type T to __sync_val_compare_and_swap, the fix converts T to uint32_t* if sizeof(T) == 4. Testing: - Zero VM build on Linux and MacOS with clang - Zero VM build on Linux with gcc ------------- Commit messages: - 8253970 Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) Changes: https://git.openjdk.java.net/jdk/pull/496/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=496&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253970 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/496.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/496/head:pull/496 PR: https://git.openjdk.java.net/jdk/pull/496 From kbarrett at openjdk.java.net Sat Oct 3 16:08:36 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 3 Oct 2020 16:08:36 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) In-Reply-To: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> Message-ID: <4aGn4WWgiS5YyPD2c6E6oqZh_QYicXwlAhVPYbHCK8s=.be75166e-2965-4655-8f85-6871959fbea8@github.com> On Sat, 3 Oct 2020 13:29:03 GMT, Jie Fu wrote: > __sync_val_compare_and_swap shouldn't call with narrowOop* for clang after JDK-8247912. > Before passing type T to __sync_val_compare_and_swap, the fix converts T to uint32_t* if sizeof(T) == 4. > > Testing: > - Zero VM build on Linux and MacOS with clang > - Zero VM build on Linux with gcc No, don't make this change. Something else is going wrong here. The Platform layer shouldn't be called with enum types; the higher level platform-independent layer should have canonicalized such to the associated underlying integral types. ------------- PR: https://git.openjdk.java.net/jdk/pull/496 From alanb at openjdk.java.net Sat Oct 3 16:20:37 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 3 Oct 2020 16:20:37 GMT Subject: RFR: 8253948: Memory leak in ImageFileReader In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 20:47:16 GMT, Zhengyu Gu wrote: > ImageFileReader allocates ImageModuleData in ImageFileReader::open(), but never free. > > Also renamed module_data to _module_data to be consistent with other member variables. > > Test: > - [x] tier1 on Linux x86_64 The jimage file is opened at startup and should never be closed. However the jrtfs provider (used by IDEs and other tools to access the resources in a target run-time image) may run into it so good to get it fixed. Can you fix the formatting to use 4-space indentation consistently? ------------- PR: https://git.openjdk.java.net/jdk/pull/490 From kbarrett at openjdk.java.net Sat Oct 3 16:23:37 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 3 Oct 2020 16:23:37 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) In-Reply-To: <4aGn4WWgiS5YyPD2c6E6oqZh_QYicXwlAhVPYbHCK8s=.be75166e-2965-4655-8f85-6871959fbea8@github.com> References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> <4aGn4WWgiS5YyPD2c6E6oqZh_QYicXwlAhVPYbHCK8s=.be75166e-2965-4655-8f85-6871959fbea8@github.com> Message-ID: On Sat, 3 Oct 2020 16:05:57 GMT, Kim Barrett wrote: >> __sync_val_compare_and_swap shouldn't call with narrowOop* for clang after JDK-8247912. >> Before passing type T to __sync_val_compare_and_swap, the fix converts T to uint32_t* if sizeof(T) == 4. >> >> Testing: >> - Zero VM build on Linux and MacOS with clang >> - Zero VM build on Linux with gcc > > No, don't make this change. Something else is going wrong here. The Platform layer shouldn't be called with enum > types; the higher level platform-independent layer should have canonicalized such to the associated underlying integral > types. Apparently I misremembered. The platform-independent layer isn't doing that canonicalization of enum types to associated integral types. But I think it should be in some places. ------------- PR: https://git.openjdk.java.net/jdk/pull/496 From gziemski at openjdk.java.net Sat Oct 3 16:56:40 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Sat, 3 Oct 2020 16:56:40 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms [v5] In-Reply-To: References: <0_pPVrBJAGbaVyHMnVhS2E0ByTkolg4tKpUH4N8fplg=.eb0fa0d9-44f8-4c63-8322-bd2320d3000a@github.com> <_RJ0u-P40RQfJNTWyHNYS3uh4TCeHY8ljaS5CLGgnFY=.3bbd9ea2-0d27-4562-a1bb-f0eadb374c50@github.com> Message-ID: <_yPTL1tdDgTG8RcYs9U_iB5WlnUr9P9LrUP_HS8fRoI=.146ea025-92ad-4e82-8ab9-c829ae00b5ef@github.com> On Fri, 2 Oct 2020 16:23:14 GMT, Gerard Ziemski wrote: >> Hi Gerard, >> >> I'm afraid something is still very wrong here. I see you fixing the original merge issues in: >> >> b33d292e96a559b8a3a998641411f61bf087738f (Address David's review issues ) >> >> but then the "Fix Merge" commit >> >> 4f5d4cd49436b64dc3770e4ba1f811a76b5a09e7 >> >> applied after that seems to have reversed them again! >> >> I think it might be necessary to close this PR and create a new one. >> >> Thanks. > > I'm considering this pr to be "lost cause", so I just "force pushed" to a known good state, wiping out the bad merge > that backed out my fixes based on David's comments, so that I have a snapshot of what I want to become the basis of new > pr. Just thought I would explain what I'm trying to do before anyone points out to me that I should not be using > "push --force". > _Mailing list message from [Thomas St??fe](mailto:thomas.stuefe at gmail.com) on > [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_ > > > Can anyone explain what this means and whether it's OK to go ahead with > > > this pr, or should I close this one (since I > > > made quite a mess of it) and start a new one? > > > > > > Hi Gerard, > > I'm afraid something is still very wrong here. I see you fixing the > > original merge issues in: > > [b33d292](https://github.com/openjdk/jdk/commit/b33d292e96a559b8a3a998641411f61bf087738f) (Address David's review > > issues ) but then the "Fix Merge" commit > > [4f5d4cd](https://github.com/openjdk/jdk/commit/4f5d4cd49436b64dc3770e4ba1f811a76b5a09e7) > > applied after that seems to have reversed them again! > > I think it might be necessary to close this PR and create a new one. > > I agree. Also, then you get the new Activity-based builds and tier0 tests > for free since that submit.yml file is now checked in head :) > > Cheers, Thomas > > Thanks. I think I recovered this pr to the point where we could continue with reviews (all changes are in and it passes Mach5 hs-tier1,2,3,4,5 testing), but I do like the idea of Activity-based builds and tier0 tests with new pr, so I'm going to close this one, and open a new one shortly... Thank you Thomas and David for assuring me that the huge merges eventually get resolved and disappear automatically -that was the reason I started tweaking this pr and why I got it messed up. ------------- PR: https://git.openjdk.java.net/jdk/pull/157 From gziemski at openjdk.java.net Sat Oct 3 16:56:40 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Sat, 3 Oct 2020 16:56:40 GMT Subject: Withdrawn: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 20:59:57 GMT, Gerard Ziemski wrote: > hi all, > > Please review this change that refactors common POSIX code into a separate > file. > > Currently there appears to be quite a bit of duplicated code among POSIX > platforms, which makes it difficult to apply single fix to the signal code. > With this fix, we will only need to touch single file for common POSIX > code fixes from now on. > > ---------------------------------------------------------------------------- > The APIs which moved from os/bsd/os_bsd.cpp to to os/posix/PosixSignals.cpp: > > //////////////////////////////////////////////////////////////////////////////// > // signal support > void os::Bsd::signal_sets_init() > sigset_t* os::Bsd::unblocked_signals() > sigset_t* os::Bsd::vm_signals() > void os::Bsd::hotspot_sigmask(Thread* thread) > //////////////////////////////////////////////////////////////////////////////// > // sun.misc.Signal support > static void UserHandler(int sig, void *siginfo, void *context) > void* os::user_handler() > void* os::signal(int signal_number, void* handler) > void os::signal_raise(int signal_number) > int os::sigexitnum_pd() > static void jdk_misc_signal_init() > void os::signal_notify(int sig) > static int check_pending_signals() > int os::signal_wait() > //////////////////////////////////////////////////////////////////////////////// > // suspend/resume support > static void resume_clear_context(OSThread *osthread) > static void suspend_save_context(OSThread *osthread, siginfo_t* siginfo, ucontext_t* context) > static void SR_handler(int sig, siginfo_t* siginfo, ucontext_t* context) > static int SR_initialize() > static int sr_notify(OSThread* osthread) > static bool do_suspend(OSThread* osthread) > static void do_resume(OSThread* osthread) > /////////////////////////////////////////////////////////////////////////////////// > // signal handling (except suspend/resume) > static void signalHandler(int sig, siginfo_t* info, void* uc) > struct sigaction* os::Bsd::get_chained_signal_action(int sig) > static bool call_chained_handler(struct sigaction *actp, int sig, > siginfo_t *siginfo, void *context) > bool os::Bsd::chained_handler(int sig, siginfo_t* siginfo, void* context) > int os::Bsd::get_our_sigflags(int sig) > void os::Bsd::set_our_sigflags(int sig, int flags) > void os::Bsd::set_signal_handler(int sig, bool set_installed) > void os::Bsd::install_signal_handlers() > static const char* get_signal_handler_name(address handler, > char* buf, int buflen) > static void print_signal_handler(outputStream* st, int sig, > char* buf, size_t buflen) > void os::run_periodic_checks() > void os::Bsd::check_signal_handler(int sig) > > ----------------------------------------------------------------------------- > The APIs which moved from os/posix/os_posix.cpp to os/posix/PosixSignals.cpp: > > const char* os::Posix::get_signal_name(int sig, char* out, size_t outlen) > int os::Posix::get_signal_number(const char* signal_name) > int os::get_signal_number(const char* signal_name) > bool os::Posix::is_valid_signal(int sig) > bool os::Posix::is_sig_ignored(int sig) > const char* os::exception_name(int sig, char* buf, size_t size) > const char* os::Posix::describe_signal_set_short(const sigset_t* set, char* buffer, size_t buf_size) > void os::Posix::print_signal_set_short(outputStream* st, const sigset_t* set) > const char* os::Posix::describe_sa_flags(int flags, char* buffer, size_t size) > oid os::Posix::print_sa_flags(outputStream* st, int flags) > static bool get_signal_code_description(const siginfo_t* si, enum_sigcode_desc_t* out) > void os::print_siginfo(outputStream* os, const void* si0) > bool os::signal_thread(Thread* thread, int sig, const char* reason) > int os::Posix::unblock_thread_signal_mask(const sigset_t *set) > address os::Posix::ucontext_get_pc(const ucontext_t* ctx) > void os::Posix::ucontext_set_pc(ucontext_t* ctx, address pc) > struct sigaction* os::Posix::get_preinstalled_handler(int sig) > void os::Posix::save_preinstalled_handler(int sig, struct sigaction& oldAct) > > > -------------------------------------------------------- > -------------------------------------------------------- > > DETAILS: > > -------------------------------------------------------- > Public APIs which are now internal static PosixSignals:: > > sigset_t* os::Bsd::vm_signals() > struct sigaction* os::Bsd::get_chained_signal_action(int sig) > int os::Bsd::get_our_sigflags(int sig) > void os::Bsd::set_our_sigflags(int sig, int flags) > void os::Bsd::set_signal_handler(int sig, bool set_installed) > void os::Bsd::check_signal_handler(int sig) > const char* os::Posix::get_signal_name(int sig, char* out, size_t outlen) > bool os::Posix::is_valid_signal(int sig) > const char* os::Posix::describe_signal_set_short(const sigset_t* set, char* buffer, size_t buf_size) > void os::Posix::print_signal_set_short(outputStream* st, const sigset_t* set) > const char* os::Posix::describe_sa_flags(int flags, char* buffer, size_t size) > oid os::Posix::print_sa_flags(outputStream* st, int flags) > static bool get_signal_code_description(const siginfo_t* si, enum_sigcode_desc_t* out) > void os::Posix::save_preinstalled_handler(int sig, struct sigaction& oldAct) > > ------------------------------------------------ > Public APIs which moved to public PosixSignals:: > > void os::Bsd::signal_sets_init() > void os::Bsd::hotspot_sigmask(Thread* thread) > bool os::Bsd::chained_handler(int sig, siginfo_t* siginfo, void* context) > void os::Bsd::install_signal_handlers() > bool os::Posix::is_sig_ignored(int sig) > int os::Posix::unblock_thread_signal_mask(const sigset_t *set) > address os::Posix::ucontext_get_pc(const ucontext_t* ctx) > void os::Posix::ucontext_set_pc(ucontext_t* ctx, address pc) > > ---------------------------------------------------- > Internal APIs which are now public in PosixSignals:: > > static void jdk_misc_signal_init() > static int SR_initialize() > static bool do_suspend(OSThread* osthread) > static void do_resume(OSThread* osthread) > static void print_signal_handler(outputStream* st, int sig, char* buf, size_t buflen) > > -------------------------- > New APIs in PosixSignals:: > > static bool are_signal_handlers_installed(); This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/157 From gziemski at openjdk.java.net Sat Oct 3 17:16:40 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Sat, 3 Oct 2020 17:16:40 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms [v5] In-Reply-To: <_yPTL1tdDgTG8RcYs9U_iB5WlnUr9P9LrUP_HS8fRoI=.146ea025-92ad-4e82-8ab9-c829ae00b5ef@github.com> References: <0_pPVrBJAGbaVyHMnVhS2E0ByTkolg4tKpUH4N8fplg=.eb0fa0d9-44f8-4c63-8322-bd2320d3000a@github.com> <_RJ0u-P40RQfJNTWyHNYS3uh4TCeHY8ljaS5CLGgnFY=.3bbd9ea2-0d27-4562-a1bb-f0eadb374c50@github.com> <_yPTL1tdDgTG8RcYs9U_iB5WlnUr9P9LrUP_HS8fRoI=.146ea025-92ad-4e82-8ab9-c829ae00b5ef@github.com> Message-ID: On Sat, 3 Oct 2020 16:53:38 GMT, Gerard Ziemski wrote: >> I'm considering this pr to be "lost cause", so I just "force pushed" to a known good state, wiping out the bad merge >> that backed out my fixes based on David's comments, so that I have a snapshot of what I want to become the basis of new >> pr. Just thought I would explain what I'm trying to do before anyone points out to me that I should not be using >> "push --force". > >> _Mailing list message from [Thomas St??fe](mailto:thomas.stuefe at gmail.com) on >> [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_ >> > > Can anyone explain what this means and whether it's OK to go ahead with >> > > this pr, or should I close this one (since I >> > > made quite a mess of it) and start a new one? >> > >> > >> > Hi Gerard, >> > I'm afraid something is still very wrong here. I see you fixing the >> > original merge issues in: >> > [b33d292](https://github.com/openjdk/jdk/commit/b33d292e96a559b8a3a998641411f61bf087738f) (Address David's review >> > issues ) but then the "Fix Merge" commit >> > [4f5d4cd](https://github.com/openjdk/jdk/commit/4f5d4cd49436b64dc3770e4ba1f811a76b5a09e7) >> > applied after that seems to have reversed them again! >> > I think it might be necessary to close this PR and create a new one. >> >> I agree. Also, then you get the new Activity-based builds and tier0 tests >> for free since that submit.yml file is now checked in head :) >> >> Cheers, Thomas >> >> Thanks. > > I think I recovered this pr to the point where we could continue with reviews (all changes are in and it passes Mach5 > hs-tier1,2,3,4,5 testing), but I do like the idea of Activity-based builds and tier0 tests with new pr, so I'm going to > close this one, and open a new one shortly... Thank you Thomas and David for assuring me that the huge merges > eventually get resolved and disappear automatically -that was the reason I started tweaking this pr and why I got it > messed up. The new pr for this issue is https://github.com/openjdk/jdk/pull/497 ------------- PR: https://git.openjdk.java.net/jdk/pull/157 From stuefe at openjdk.java.net Sat Oct 3 19:12:43 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 3 Oct 2020 19:12:43 GMT Subject: RFR: 8224509: Incorrect alignment in CDS related allocation code on 32-bit platforms [v2] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 16:20:00 GMT, Calvin Cheung wrote: >> CDS aligns pointers and sizes to BytesPerWord. On 64-bit, BytesPerWord = 8. On 32-bit, BytesPerWord = 4. >> >> To make the alignment consistent between 64- and 32-bit platforms, this patch changes the alignment value to 8. >> >> Testing: tiers 1 - 4 >> built linux-x86-debug. > > 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 three additional commits since > the last revision: > - Merge branch 'master' of github.com:calvinccheung/jdk into 8224509 > - set SharedSpaceObjectAlignment to KlassAlignmentInBytes > - 8224509 (initial commit) Marked as reviewed by stuefe (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/476 From jiefu at openjdk.java.net Sun Oct 4 00:14:37 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Sun, 4 Oct 2020 00:14:37 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) In-Reply-To: References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> <4aGn4WWgiS5YyPD2c6E6oqZh_QYicXwlAhVPYbHCK8s=.be75166e-2965-4655-8f85-6871959fbea8@github.com> Message-ID: On Sat, 3 Oct 2020 16:20:35 GMT, Kim Barrett wrote: >> No, don't make this change. Something else is going wrong here. The Platform layer shouldn't be called with enum >> types; the higher level platform-independent layer should have canonicalized such to the associated underlying integral >> types. > > Apparently I misremembered. The platform-independent layer isn't doing that canonicalization of enum types to > associated integral types. But I think it should be in some places. Thanks @kimbarrett for your review. I'll think it more after my holiday. ------------- PR: https://git.openjdk.java.net/jdk/pull/496 From kbarrett at openjdk.java.net Sun Oct 4 03:04:37 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 4 Oct 2020 03:04:37 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) In-Reply-To: References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> <4aGn4WWgiS5YyPD2c6E6oqZh_QYicXwlAhVPYbHCK8s=.be75166e-2965-4655-8f85-6871959fbea8@github.com> Message-ID: On Sun, 4 Oct 2020 00:11:35 GMT, Jie Fu wrote: >> Apparently I misremembered. The platform-independent layer isn't doing that canonicalization of enum types to >> associated integral types. But I think it should be in some places. > > Thanks @kimbarrett for your review. > I'll think it more after my holiday. What version of clang? gcc (at least recent versions) allows enum types (both scoped and unscoped) for both the __sync_xxx functions and for the __atomic_xxx functions. (The documentation for both say the type can be an integral scalar or pointer type. Enums are not integral types.) So this seems to be a clang incompatibility with gcc, which may be a clang bug. The __sync_xxx functions have been legacy since gcc4.7, having been superseded by the __atomic_xxx functions. Could zero be updated here? Would that help? If clang is incompatible with gcc for the __sync_xxx functions, it might also be incompatible for the __atomic_xxx functions. BTW, the memory ordering by the zero implementation of Atomic::xchg in terms of __sync_lock_test_and_set looks wrong to me. I think the fence() is on the wrong side of the __sync_xxx operation. ------------- PR: https://git.openjdk.java.net/jdk/pull/496 From rrich at openjdk.java.net Sun Oct 4 08:09:38 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Sun, 4 Oct 2020 08:09:38 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: On Sat, 3 Oct 2020 09:45:29 GMT, Thomas Stuefe wrote: >> Let us ship this. Thanks for all your great work, great presentations and for doing all the tedious fixes. > >> Let us ship this. Thanks for all your great work, great presentations and for doing all the tedious fixes. >> >> /Leo > > Great, thank you too for your thorough review work! Hi Thomas, I'm currently working on a review. There are still many sections where you separate 2 lines of code with an empty line. My review is filling up with comments on that. I'm afraid this will hide the few other/real points therefore I'll stop annotating empty lines. Instead I'd like to ask you to look over each file changed (you cannot see it always in the diff on Github) and remove as many empty lines as possible to better match the existing style. `virtualSpaceNode.cpp` would be a good file to start with (e.g. lines 106 and following, 280 and following). You could also grep for { followed by an empty line and } proceeded by an empty line. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From thomas.stuefe at gmail.com Sun Oct 4 09:14:44 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 4 Oct 2020 11:14:44 +0200 Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: On Sun, Oct 4, 2020 at 10:12 AM Richard Reingruber wrote: > On Sat, 3 Oct 2020 09:45:29 GMT, Thomas Stuefe wrote: > > >> Let us ship this. Thanks for all your great work, great presentations > and for doing all the tedious fixes. > > > >> Let us ship this. Thanks for all your great work, great presentations > and for doing all the tedious fixes. > >> > >> /Leo > > > > Great, thank you too for your thorough review work! > > Hi Thomas, I'm currently working on a review. There are still many > sections where you separate 2 lines of code with an > empty line. My review is filling up with comments on that. I prefer not to. Condensing the code as you propose would make the code less readable. I took great care to preserve a readable flow. I'm afraid this will hide the few other/real points > therefore I'll stop annotating empty lines. Instead I'd like to ask you to > look over each file changed (you cannot see > it always in the diff on Github) and remove as many empty lines as > possible to better match the existing style. > The existing style is inconsistent, it seems to be a matter of taste. You can find examples for different styles throughout the hotspot code base. Hotspot style guide says nothing about having to squeeze code together. On the contrary: Whitespaces: -- - Use good taste to break lines and align corresponding tokens on adjacent lines. .. - Use more spaces and blank lines between larger constructs, such as classes or function definitions. .. `virtualSpaceNode.cpp` would be a good file to start with (e.g. lines 106 > and following, 280 and following). You could > also grep for { followed by an empty line and } proceeded by an empty > line. Thanks, Richard. > > If it is important to you I will remove the empty lines even though I think it hurts readability. But I am eager to ship this PR, so please let us concentrate on real issues. If you have still concerns let us discuss those. Cheers, Thomas ------------- > > PR: https://git.openjdk.java.net/jdk/pull/336 From jiefu at openjdk.java.net Sun Oct 4 12:00:36 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Sun, 4 Oct 2020 12:00:36 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) In-Reply-To: References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> <4aGn4WWgiS5YyPD2c6E6oqZh_QYicXwlAhVPYbHCK8s=.be75166e-2965-4655-8f85-6871959fbea8@github.com> Message-ID: On Sun, 4 Oct 2020 03:01:56 GMT, Kim Barrett wrote: >> Thanks @kimbarrett for your review. >> I'll think it more after my holiday. > > What version of clang? > > gcc (at least recent versions) allows enum types (both scoped and unscoped) for both the __sync_xxx functions and for > the __atomic_xxx functions. (The documentation for both say the type can be an integral scalar or pointer type. Enums > are not integral types.) So this seems to be a clang incompatibility with gcc, which may be a clang bug. > > The __sync_xxx functions have been legacy since gcc4.7, having been superseded by the __atomic_xxx functions. Could > zero be updated here? Would that help? If clang is incompatible with gcc for the __sync_xxx functions, it might also > be incompatible for the __atomic_xxx functions. BTW, the memory ordering by the zero implementation of Atomic::xchg in > terms of __sync_lock_test_and_set looks wrong to me. I think the fence() is on the wrong side of the __sync_xxx > operation. The following two versions of clang can reproduce the bug. $ clang -v Apple clang version 11.0.0 (clang-1100.0.33.16) Target: x86_64-apple-darwin19.0.0 Thread model: posix # clang -v clang version 10.0.0-4ubuntu1 Target: x86_64-pc-linux-gnu Thread model: posix ------------- PR: https://git.openjdk.java.net/jdk/pull/496 From stuefe at openjdk.java.net Sun Oct 4 12:51:51 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 4 Oct 2020 12:51:51 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v10] In-Reply-To: References: Message-ID: <4tm8-iZBy3FrqW4GVqXVnN7PUzTAA5rsPqojd4SKZJI=.84e9836b-655f-4dc0-b838-67db50135a53@github.com> > Hi all, > > this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the > delay, had vacation then the entrance of Skara delayed things a bit. > For the delta diff please see [3]. > > This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all > feedback individually in this PR body, but I incorporated almost all into the new revision. > What changed since the last version: > > - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the > group consent. > > - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for > overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth > class loader which made it rather pointless. Now I run it always. > > - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. > > - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) > > Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. > > - In ChunkManager::purge() I improved the comments after discussions with Leo. > > - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due > to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run > every time. > > - Fixed indentation issues as Leo requested > > - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested > > - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes > and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more > flexible since it allows us to have list with purge-able and non-purge-able nodes. > > - and various smaller fixes, mainly on request of Leo. > > @lkorinth: > >> VirtualSpaceNode.hpp >> >>102 // Start pointer of the area. >>103 MetaWord* const _base; >> >>How does this differ from _rs._base? Really needed? >> >>105 // Size, in words, of the whole node >>106 const size_t _word_size; >> >>Can we not calculate this from _rs.size()? > > You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it > is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly > improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at > some point and make those members const - as they should be - then I would rewrite this as you suggest. > Thanks, again, for all your review work! > > ------ > > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html > [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Remove some empty lines ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/336/files - new: https://git.openjdk.java.net/jdk/pull/336/files/ece884f1..4cc94c50 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=08-09 Stats: 362 lines in 18 files changed: 1 ins; 356 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/336/head:pull/336 PR: https://git.openjdk.java.net/jdk/pull/336 From thomas.stuefe at gmail.com Sun Oct 4 12:53:01 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 4 Oct 2020 14:53:01 +0200 Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: > > > > If it is important to you I will remove the empty lines even though I > think it hurts readability. But I am eager to ship this PR, so please let > us concentrate on real issues. If you have still concerns let us discuss > those. > > Okay, I removed some empty lines to move forward. Thanks, Thomas > From bulasevich at openjdk.java.net Sun Oct 4 18:17:38 2020 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Sun, 4 Oct 2020 18:17:38 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) In-Reply-To: References: Message-ID: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com> On Fri, 2 Oct 2020 16:34:49 GMT, Severin Gehwolf wrote: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and > look for `cgroup` FS-type lines which aren't also mounted purely for systemd. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [ ] Submit testing (still running) src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 72: > 70: * Pattern explanation: > 71: * > 72: * /`````\ /`````\ /`````\ /```````\ /```````\ /```\ (8) /```````\ (10) + (11) Alternatively, consider the inline comment: private static final Pattern MOUNTINFO_PATTERN = Pattern.compile( "^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+" + // (1) + (2) + (3) "([^\\s]+)\\s+([^\\s]+)\\s+" + // (4) + (5) - group 1,2: mount point, mount options "[^-]+-\\s+" + // (6) + (7) + (8) "([^\\s]+)\\s+" + // (9) - group 3: fstype ".*$"); // (10) + (11) src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 80: > 78: */ > 79: private static final Pattern MOUNTINFO_PATTERN = > 80: > Pattern.compile("^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+([^\\s]+)\\s+([^\\s]+)\\s+[^-]+-\\s+([^\\s]+)\\s+.*$"); Only group_3 = fstype is used in the pattern, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From bulasevich at openjdk.java.net Sun Oct 4 18:17:37 2020 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Sun, 4 Oct 2020 18:17:37 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 16:39:09 GMT, Severin Gehwolf wrote: >> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the >> affected system, `/proc/self/mountinfo` contains a line such as this one: >> >> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd >> >> >> Note that `/proc/cgroups` looks like this: >> >> #subsys_name hierarchy num_cgroups enabled >> cpuset 0 1 1 >> cpu 0 1 1 >> cpuacct 0 1 1 >> blkio 0 1 1 >> memory 0 1 1 >> devices 0 1 1 >> freezer 0 1 1 >> net_cls 0 1 1 >> perf_event 0 1 1 >> net_prio 0 1 1 >> hugetlb 0 1 1 >> pids 0 1 1 >> >> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo >> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in >> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, >> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to >> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's >> cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and >> look for `cgroup` FS-type lines which aren't also mounted purely for systemd. >> **Testing** >> >> - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) >> - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) >> - [x] Added regression test which fails prior the patch and passes after >> - [ ] Submit testing (still running) > > @bulasevich Do you want to give this a spin? The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From rrich at openjdk.java.net Mon Oct 5 08:14:40 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 5 Oct 2020 08:14:40 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: On Sun, 4 Oct 2020 08:06:36 GMT, Richard Reingruber wrote: >>> Let us ship this. Thanks for all your great work, great presentations and for doing all the tedious fixes. >>> >>> /Leo >> >> Great, thank you too for your thorough review work! > > Hi Thomas, I'm currently working on a review. There are still many sections where you separate 2 lines of code with an > empty line. My review is filling up with comments on that. I'm afraid this will hide the few other/real points > therefore I'll stop annotating empty lines. Instead I'd like to ask you to look over each file changed (you cannot see > it always in the diff on Github) and remove as many empty lines as possible to better match the existing style. > `virtualSpaceNode.cpp` would be a good file to start with (e.g. lines 106 and following, 280 and following). You could > also grep for { followed by an empty line and } proceeded by an empty line. Thanks, Richard. > > > _Mailing list message from [Thomas St??fe](mailto:thomas.stuefe at gmail.com) on > [hotspot-gc-dev](mailto:hotspot-gc-dev at openjdk.java.net):_ > > > > If it is important to you I will remove the empty lines even though I > > think it hurts readability. But I am eager to ship this PR, so please let > > us concentrate on real issues. If you have still concerns let us discuss > > those. > > Okay, I removed some empty lines to move forward. > > Thanks, Thomas > > > Thank's for doing it, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From sgehwolf at openjdk.java.net Mon Oct 5 08:39:47 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 5 Oct 2020 08:39:47 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v2] In-Reply-To: References: Message-ID: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and > look for `cgroup` FS-type lines which aren't also mounted purely for systemd. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [ ] Submit testing (still running) Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/485/files - new: https://git.openjdk.java.net/jdk/pull/485/files/b7c7f510..6c4fadd1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=00-01 Stats: 17 lines in 1 file changed: 4 ins; 10 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Mon Oct 5 08:39:48 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 5 Oct 2020 08:39:48 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v2] In-Reply-To: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com> References: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com> Message-ID: On Sun, 4 Oct 2020 18:12:14 GMT, Boris Ulasevich wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) > > src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 72: > >> 70: * Pattern explanation: >> 71: * >> 72: * /`````\ /`````\ /`````\ /```````\ /```````\ /```\ (8) /```````\ (10) + (11) > > Alternatively, consider the inline comment: > > private static final Pattern MOUNTINFO_PATTERN = Pattern.compile( > "^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+" + // (1) + (2) + (3) > "([^\\s]+)\\s+([^\\s]+)\\s+" + // (4) + (5) - group 1,2: mount point, mount options > "[^-]+-\\s+" + // (6) + (7) + (8) > "([^\\s]+)\\s+" + // (9) - group 3: fstype > ".*$"); // (10) + (11) Good suggestion. I've changed it to what you've suggested and removed the unused groups 1 and 2. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Mon Oct 5 09:02:37 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 5 Oct 2020 09:02:37 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) In-Reply-To: References: Message-ID: On Sun, 4 Oct 2020 18:14:37 GMT, Boris Ulasevich wrote: > The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed. Thanks for the review and for testing it! ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Mon Oct 5 09:02:38 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 5 Oct 2020 09:02:38 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v2] In-Reply-To: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com> References: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com> Message-ID: On Sun, 4 Oct 2020 18:12:39 GMT, Boris Ulasevich wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) > > src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 80: > >> 78: */ >> 79: private static final Pattern MOUNTINFO_PATTERN = >> 80: >> Pattern.compile("^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+([^\\s]+)\\s+([^\\s]+)\\s+[^-]+-\\s+([^\\s]+)\\s+.*$"); > > Only group_3 = fstype is used in the pattern, right? Yes. I've removed unused groups now, though. Originally, my thinking was that `mount root` and `mount path` would be useful too so I kept it in. It would certainly be useful for getting rid of reading `/proc/self/mountinfo` twice on the Java side. As a future enhancement we could do away with double parsing of mount info by keeping track of relevant cgroup controller info. I've filed [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) to track this. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From rrich at openjdk.java.net Mon Oct 5 09:27:45 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 5 Oct 2020 09:27:45 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v8] In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 13:17:27 GMT, Thomas Stuefe wrote: >> Hi all, >> >> this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the >> delay, had vacation then the entrance of Skara delayed things a bit. >> For the delta diff please see [3]. >> >> This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all >> feedback individually in this PR body, but I incorporated almost all into the new revision. >> What changed since the last version: >> >> - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the >> group consent. >> >> - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for >> overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth >> class loader which made it rather pointless. Now I run it always. >> >> - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. >> >> - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) >> >> Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. >> >> - In ChunkManager::purge() I improved the comments after discussions with Leo. >> >> - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due >> to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run >> every time. >> >> - Fixed indentation issues as Leo requested >> >> - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested >> >> - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes >> and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more >> flexible since it allows us to have list with purge-able and non-purge-able nodes. >> >> - and various smaller fixes, mainly on request of Leo. >> >> @lkorinth: >> >>> VirtualSpaceNode.hpp >>> >>>102 // Start pointer of the area. >>>103 MetaWord* const _base; >>> >>>How does this differ from _rs._base? Really needed? >>> >>>105 // Size, in words, of the whole node >>>106 const size_t _word_size; >>> >>>Can we not calculate this from _rs.size()? >> >> You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it >> is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly >> improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at >> some point and make those members const - as they should be - then I would rewrite this as you suggest. >> Thanks, again, for all your review work! >> >> ------ >> >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html >> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html >> [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d > > Thomas Stuefe 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 jep387 > - Remove accidentally added file > - Merge branch 'jep387' of github.com:tstuefe/jdk into jep387 > - Create submit.yml > - Review feedback Ioi > - cds MaxMetaspaceSize test does not need MaxMetaspaceSize increase > - Make MetaspaceGuardAllocations a diagnostic flag (2) > - Make MetaspaceGuardAllocations a diagnostic flag > - Style fixes > - Remove empty lines from include sections > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/f80a6066...f5cf615b Hi Thomas, I've viewed 41/166 files. I'm sending you my findings so far so we can work concurrently. Also I'm curious how it goes sending a partial review and then continuing. Probably I won't manage to review all the tests but I do hope I get to read all files of the implementation. Working on it now... Btw: I couldn't find out how to navigate from one of my comments to the line of code. At least, when I click on the file name, this brings me to a view of the patch at the version I commented on so the line numbers are correct even if they changed in the head revision of the pr. Cheers, Richard. src/hotspot/share/services/virtualMemoryTracker.cpp line 679: > 677: } > 678: > 679: void MetaspaceSnapshot::snapshot(MetaspaceSnapshot& mss) { This is not part of your change, but aren't `ClassType` and `NonClassType` mixed up in the body of `MetaspaceSnapshot::snapshot` method? src/hotspot/share/memory/metaspace.cpp line 482: > 480: bool Metaspace::initialized() { > 481: return metaspace::MetaspaceContext::context_nonclass() != NULL && > 482: (using_class_space() ? metaspace::MetaspaceContext::context_class() != NULL : true); Better delegate to `Metaspace::class_space_is_initialized` here? ------------- Changes requested by rrich (Committer). PR: https://git.openjdk.java.net/jdk/pull/336 From rrich at openjdk.java.net Mon Oct 5 09:27:50 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 5 Oct 2020 09:27:50 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 06:39:26 GMT, Thomas Stuefe wrote: >> Hi all, >> >> this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the >> delay, had vacation then the entrance of Skara delayed things a bit. >> For the delta diff please see [3]. >> >> This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all >> feedback individually in this PR body, but I incorporated almost all into the new revision. >> What changed since the last version: >> >> - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the >> group consent. >> >> - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for >> overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth >> class loader which made it rather pointless. Now I run it always. >> >> - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. >> >> - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) >> >> Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. >> >> - In ChunkManager::purge() I improved the comments after discussions with Leo. >> >> - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due >> to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run >> every time. >> >> - Fixed indentation issues as Leo requested >> >> - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested >> >> - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes >> and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more >> flexible since it allows us to have list with purge-able and non-purge-able nodes. >> >> - and various smaller fixes, mainly on request of Leo. >> >> @lkorinth: >> >>> VirtualSpaceNode.hpp >>> >>>102 // Start pointer of the area. >>>103 MetaWord* const _base; >>> >>>How does this differ from _rs._base? Really needed? >>> >>>105 // Size, in words, of the whole node >>>106 const size_t _word_size; >>> >>>Can we not calculate this from _rs.size()? >> >> You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it >> is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly >> improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at >> some point and make those members const - as they should be - then I would rewrite this as you suggest. >> Thanks, again, for all your review work! >> >> ------ >> >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html >> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html >> [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - Misc. Review feedback > - Move ClassLoaderMetaspace to own include and correct includes src/hotspot/share/memory/classLoaderMetaspace.cpp line 90: > 88: } > 89: > 90: UL2(debug, "born (SpcMgr nonclass: " PTR_FORMAT ", SpcMgr class: " PTR_FORMAT ".", I'd suggest to replace 'SpcMgr [non]class' with '[non]class arena' or similar since SpaceManager is removed with the change. src/hotspot/share/memory/classLoaderMetaspace.cpp line 58: > 56: > 57: static bool use_class_space(Metaspace::MetadataType mdType) { > 58: return use_class_space(Metaspace::is_class_space_allocation(mdType)); Calling `use_class_space()` is not needed. `Metaspace::is_class_space_allocation()` already queries `Metaspace::using_class_space()` src/hotspot/share/memory/classLoaderMetaspace.cpp line 55: > 53: } > 54: return false; > 55: } The following would be equivalent and a lot shorter static bool use_class_space(bool is_class) { return Metaspace::using_class_space() && is_class; } src/hotspot/share/memory/classLoaderMetaspace.cpp line 160: > 158: DEBUG_ONLY(InternalStats::inc_num_deallocs();) > 159: > 160: } Too many empty lines if you're asking me ;) src/hotspot/share/memory/metaspace.hpp line 136: > 134: > 135: static void report_metadata_oome(ClassLoaderData* loader_data, size_t word_size, > 136: MetaspaceObj::Type type, Metaspace::MetadataType mdtype, TRAPS); The change is not necessary. You havn't changed the definition either (metaspace.cpp:830, link does not seem to work). https://github.com/openjdk/jdk/pull/336/files#diff-07bf2be25d84c251ed6107aab47fd009R830 src/hotspot/share/memory/metaspace/allocationGuard.hpp line 68: > 66: // -XX:+MetaspaceGuardAllocations. When active, it disables deallocation handling - since > 67: // freeblock handling in the freeblock lists would get too complex - so one may run leaks > 68: // in deallocation-heavvy scenarios (e.g. lots of class redefinitions). Typo: heavvy src/hotspot/share/memory/metaspace/binList.hpp line 141: > 139: assert(_blocks[i2] != NULL, "mask mismatch"); > 140: return i2; > 141: } There would be `count_leading_zeros()`. If I'm not mistaken, it is _trailing_ zeros that are counted. So you could use [count_trailing_zeros()](https://github.com/openjdk/jdk/blob/d296708ca66ab15e31a05f963a5e162a3e3f07f9/src/hotspot/share/utilities/count_trailing_zeros.hpp#L31) src/hotspot/share/memory/metaspace/blockTree.hpp line 219: > 217: > 218: // Given a node n and an insertion point, insert n under insertion point. > 219: void insert(Node* insertion_point, Node* n) { Could be static src/hotspot/share/memory/metaspace/blockTree.hpp line 193: > 191: n2 = succ; > 192: succ = succ->_parent; > 193: } You could inline just the then-block into `remove_node_from_tree()` which is the only caller of `successor()` src/hotspot/share/memory/metaspace/blockTree.hpp line 174: > 172: return pred; > 173: } > 174: Looks like `predecessor()` is not used. src/hotspot/share/memory/metaspace/freeChunkList.hpp line 74: > 72: // structure can easily be optimized (e.g. a BST). But for now lets keep this simple. > 73: > 74: class FreeChunkList { This is about the 3rd list implementation (so far) in this change (boilerplate code!). It would be awesome if one or two could be replaced with [LinkedList](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/linkedlist.hpp). Currently this is not possible, because `LinkedListNodes` cannot be placed into the payload. What about filing a RFE about adding and using a `LinkedList` implementation that allows this? src/hotspot/share/memory/metaspace/chunkManager.hpp line 118: > 116: > 117: // On success, returns a chunk of level of , but at most . > 118: // The first first of the chunk are guaranteed to be committed. Typo: first first. src/hotspot/share/memory/metaspace/chunkManager.cpp line 55: > 53: DEBUG_ONLY(c->verify()); > 54: > 55: const chunklevel_t lvl = c->level(); lvl is unused. src/hotspot/share/memory/metaspace/chunkManager.cpp line 144: > 142: DEBUG_ONLY(chunklevel::check_valid_level(max_level);) > 143: DEBUG_ONLY(chunklevel::check_valid_level(preferred_level);) > 144: assert(max_level >= preferred_level, "invalid level."); This assert is redundant. It has the same condition as the assert on line 135. src/hotspot/share/memory/metaspace/rootChunkArea.cpp line 89: > 87: // created chunk pair) > 88: // - then create a new chunk header of the same level, set its memory range > 89: // to cover the second halfof the old chunk. Typo: halfof src/hotspot/share/memory/metaspace/rootChunkArea.cpp line 110: > 108: // half chunk splinter. > 109: // Instead, just split split split and delay building up the double linked list of the > 110: // new chunks at the end of all splits. This comment does not match the code below anymore, does it? ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From sgehwolf at openjdk.java.net Mon Oct 5 10:12:39 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 5 Oct 2020 10:12:39 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 09:00:17 GMT, Severin Gehwolf wrote: >> The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed. > >> The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed. > > Thanks for the review and for testing it! @bobvandette Could you perhaps have a look at this? Many thanks in advance! ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Mon Oct 5 10:16:49 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 5 Oct 2020 10:16:49 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v3] In-Reply-To: References: Message-ID: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com> > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and > look for `cgroup` FS-type lines which aren't also mounted purely for systemd. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [x] Submit testing Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Fix typo in comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/485/files - new: https://git.openjdk.java.net/jdk/pull/485/files/6c4fadd1..d334ac60 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From stuefe at openjdk.java.net Mon Oct 5 10:22:40 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 5 Oct 2020 10:22:40 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v8] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 09:25:16 GMT, Richard Reingruber wrote: > Hi Thomas, > > I've viewed 41/166 files. I'm sending you my findings so far so we can work concurrently. Also I'm curious how it goes > sending a partial review and then continuing. You just finish one Review (with "comment" or "reqzest changes"), and later start a new Review. Only downside is that you get multiple mails in the ML, but I think that is okay here. > > Probably I won't manage to review all the tests but I do hope I get to read all files of the implementation. Working on > it now... Totally fine. The implementation in hotspot is the important part. > Btw: I couldn't find out how to navigate from one of my comments to the line of code. At least, when I click on the > file name, this brings me to a view of the patch at the version I commented on so the line numbers are correct even if > they changed in the head revision of the pr. The line of code a comment applies to is the lowest in the code excerpt shown atop of the comment. Unless the comment applied to multiple lines, then it shows (eg "Comment on lines +105 to +110"). > > Cheers, Richard. Thanks, Tomas ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Mon Oct 5 10:28:44 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 5 Oct 2020 10:28:44 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v8] In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 19:58:31 GMT, Richard Reingruber wrote: >> Thomas Stuefe 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 jep387 >> - Remove accidentally added file >> - Merge branch 'jep387' of github.com:tstuefe/jdk into jep387 >> - Create submit.yml >> - Review feedback Ioi >> - cds MaxMetaspaceSize test does not need MaxMetaspaceSize increase >> - Make MetaspaceGuardAllocations a diagnostic flag (2) >> - Make MetaspaceGuardAllocations a diagnostic flag >> - Style fixes >> - Remove empty lines from include sections >> - ... and 3 more: https://git.openjdk.java.net/jdk/compare/f80a6066...f5cf615b > > src/hotspot/share/services/virtualMemoryTracker.cpp line 679: > >> 677: } >> 678: >> 679: void MetaspaceSnapshot::snapshot(MetaspaceSnapshot& mss) { > > This is not part of your change, but aren't `ClassType` and `NonClassType` mixed up in the body of > `MetaspaceSnapshot::snapshot` method? Looks like it. I opened https://bugs.openjdk.java.net/browse/JDK-8254012. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Mon Oct 5 10:34:42 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 5 Oct 2020 10:34:42 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 14:15:04 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - Misc. Review feedback >> - Move ClassLoaderMetaspace to own include and correct includes > > src/hotspot/share/memory/classLoaderMetaspace.cpp line 90: > >> 88: } >> 89: >> 90: UL2(debug, "born (SpcMgr nonclass: " PTR_FORMAT ", SpcMgr class: " PTR_FORMAT ".", > > I'd suggest to replace 'SpcMgr [non]class' with '[non]class arena' or similar since SpaceManager is removed with the > change. Right. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From mdoerr at openjdk.java.net Mon Oct 5 11:00:38 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 5 Oct 2020 11:00:38 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 09:00:54 GMT, Robbin Ehn wrote: >> The issue is that this test doesn't consider Handshake All operation. >> Depending if/when such operation is scheduled it can lockup the VM thread. >> And the safepoint that should timeout never happens. >> See issue for more information. >> >> So I changed the test to "try timeout" the safepoint, but if there was no safepoint (blocked by a handshake all), we >> retry. We sleep unsafe much longer than the interval SafepointALot generates operations, which 'guarantees' we will >> timeout if there is no handshake all. (some extreme case of kernel scheduling causing a very long context switch could >> also make us not timeout) Passes t1, t3, and repeat runs of the test. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Update with input from reviews Thanks for reimplementing it to resolve problems with handshake all operations. test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 97: Can we check for another frame like e.g. WB_WaitUnsafe? AbortVMOnSafepointTimeout is designed to provide a stack trace of the thread which is blocking the safepoint. ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From stuefe at openjdk.java.net Mon Oct 5 11:55:41 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 5 Oct 2020 11:55:41 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: <9h4RKsj-Y2rn-yZbvNNx0G8ZMNmGiZn5rqfsLfWYXDE=.81b1f9dc-7c13-4c79-b12f-54a1a609ac0b@github.com> On Sat, 3 Oct 2020 08:02:25 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - Misc. Review feedback >> - Move ClassLoaderMetaspace to own include and correct includes > > src/hotspot/share/memory/metaspace/binList.hpp line 141: > >> 139: assert(_blocks[i2] != NULL, "mask mismatch"); >> 140: return i2; >> 141: } > > There would be `count_leading_zeros()`. > If I'm not mistaken, it is _trailing_ zeros that are counted. So you could use > [count_trailing_zeros()](https://github.com/openjdk/jdk/blob/d296708ca66ab15e31a05f963a5e162a3e3f07f9/src/hotspot/share/utilities/count_trailing_zeros.hpp#L31) Right. I'll just remove the comment. > src/hotspot/share/memory/metaspace.hpp line 136: > >> 134: >> 135: static void report_metadata_oome(ClassLoaderData* loader_data, size_t word_size, >> 136: MetaspaceObj::Type type, Metaspace::MetadataType mdtype, TRAPS); > > The change is not necessary. > You havn't changed the definition either (metaspace.cpp:830, link does not seem to work). > https://github.com/openjdk/jdk/pull/336/files#diff-07bf2be25d84c251ed6107aab47fd009R830 The enums moved around a lot until ending up at the exact place as before the patch. I'll remove the scope. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From rrich at openjdk.java.net Mon Oct 5 12:01:40 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 5 Oct 2020 12:01:40 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: <9h4RKsj-Y2rn-yZbvNNx0G8ZMNmGiZn5rqfsLfWYXDE=.81b1f9dc-7c13-4c79-b12f-54a1a609ac0b@github.com> References: <9h4RKsj-Y2rn-yZbvNNx0G8ZMNmGiZn5rqfsLfWYXDE=.81b1f9dc-7c13-4c79-b12f-54a1a609ac0b@github.com> Message-ID: On Mon, 5 Oct 2020 11:52:38 GMT, Thomas Stuefe wrote: >> src/hotspot/share/memory/metaspace/binList.hpp line 141: >> >>> 139: assert(_blocks[i2] != NULL, "mask mismatch"); >>> 140: return i2; >>> 141: } >> >> There would be `count_leading_zeros()`. >> If I'm not mistaken, it is _trailing_ zeros that are counted. So you could use >> [count_trailing_zeros()](https://github.com/openjdk/jdk/blob/d296708ca66ab15e31a05f963a5e162a3e3f07f9/src/hotspot/share/utilities/count_trailing_zeros.hpp#L31) > > Right. I'll just remove the comment. It's not just the comment. I think you should replace the while-loop with [count_trailing_zeros()](https://github.com/openjdk/jdk/blob/d296708ca66ab15e31a05f963a5e162a3e3f07f9/src/hotspot/share/utilities/count_trailing_zeros.hpp#L31). ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From gziemski at openjdk.java.net Mon Oct 5 12:25:50 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 5 Oct 2020 12:25:50 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms Message-ID: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> This is a fresh start for https://github.com/openjdk/jdk/pull/157 Please review this change that refactors common POSIX code into a separate file. Currently there appears to be quite a bit of duplicated code among POSIX platforms, which makes it difficult to apply single fix to the signal code. With this fix, we will only need to touch single file for common POSIX code fixes from now on. --------- ### Progress - [x] Change must not contain extraneous whitespace - [x] Commit message must refer to an issue - [ ] Change must be properly reviewed ### Download `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` `$ git checkout pull/497` ------------- Commit messages: - Address David's review issues - Revert "Add AIX specific SA code" - Add AIX specific SA code - Remove leftover AIX signal code - removed white spaces - Refactored common POSIX signal code into seperate file Changes: https://git.openjdk.java.net/jdk/pull/497/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=497&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252324 Stats: 5361 lines in 21 files changed: 1739 ins; 3529 del; 93 mod Patch: https://git.openjdk.java.net/jdk/pull/497.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497 PR: https://git.openjdk.java.net/jdk/pull/497 From stuefe at openjdk.java.net Mon Oct 5 12:25:50 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 5 Oct 2020 12:25:50 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: On Sat, 3 Oct 2020 17:12:30 GMT, Gerard Ziemski wrote: > This is a fresh start for https://github.com/openjdk/jdk/pull/157 > > Please review this change that refactors common POSIX code into a separate > file. > > Currently there appears to be quite a bit of duplicated code among POSIX > platforms, which makes it difficult to apply single fix to the signal code. > With this fix, we will only need to touch single file for common POSIX > code fixes from now on. > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > > > ### Download > `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` > `$ git checkout pull/497` I put the new patch into our test queue to give it another spin. Will take a last look next week. ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From stuefe at openjdk.java.net Mon Oct 5 12:28:43 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 5 Oct 2020 12:28:43 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: On Sat, 3 Oct 2020 12:06:01 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - Misc. Review feedback >> - Move ClassLoaderMetaspace to own include and correct includes > > src/hotspot/share/memory/metaspace/blockTree.hpp line 193: > >> 191: n2 = succ; >> 192: succ = succ->_parent; >> 193: } > > You could inline just the then-block into `remove_node_from_tree()` which is the only caller of `successor()` I rather leave it, I find it clearer that way. > src/hotspot/share/memory/metaspace/blockTree.hpp line 219: > >> 217: >> 218: // Given a node n and an insertion point, insert n under insertion point. >> 219: void insert(Node* insertion_point, Node* n) { > > Could be static True. > src/hotspot/share/memory/classLoaderMetaspace.cpp line 160: > >> 158: DEBUG_ONLY(InternalStats::inc_num_deallocs();) >> 159: >> 160: } > > Too many empty lines if you're asking me ;) Okay will fix. > src/hotspot/share/memory/metaspace/blockTree.hpp line 174: > >> 172: return pred; >> 173: } >> 174: > > Looks like `predecessor()` is not used. Will remove. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From thomas.stuefe at gmail.com Mon Oct 5 12:30:29 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 5 Oct 2020 14:30:29 +0200 Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: On Mon, Oct 5, 2020 at 2:26 PM Thomas Stuefe wrote: > On Sat, 3 Oct 2020 17:12:30 GMT, Gerard Ziemski > wrote: > > > This is a fresh start for https://github.com/openjdk/jdk/pull/157 > > > > Please review this change that refactors common POSIX code into a > separate > > file. > > > > Currently there appears to be quite a bit of duplicated code among POSIX > > platforms, which makes it difficult to apply single fix to the signal > code. > > With this fix, we will only need to touch single file for common POSIX > > code fixes from now on. > > > > --------- > > ### Progress > > - [x] Change must not contain extraneous whitespace > > - [x] Commit message must refer to an issue > > - [ ] Change must be properly reviewed > > > > > > > > ### Download > > `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` > > `$ git checkout pull/497` > > I put the new patch into our test queue to give it another spin. Will take > a last look next week. > > I wrote this comment yesterday evening, the GitHub ML bot seems to be rather slow. Yesterday was Sunday, so I mean this week. ------------- > > PR: https://git.openjdk.java.net/jdk/pull/497 > From rehn at openjdk.java.net Mon Oct 5 12:38:41 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 5 Oct 2020 12:38:41 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 10:55:08 GMT, Martin Doerr wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update with input from reviews > > test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 97: > > > Can we check for another frame like e.g. WB_WaitUnsafe? AbortVMOnSafepointTimeout is designed to provide a stack trace > of the thread which is blocking the safepoint. Since top frame is always different (platform dependent, e.g. clock_nanosleep) I removed that. But "sun.hotspot.WhiteBox.waitUnsafe" or "TestAbortVMOnSafepointTimeout$Test.main" should be below, we could use something like that. So sure I'll add it back with "TestAbortVMOnSafepointTimeout$Test.main". ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From stuefe at openjdk.java.net Mon Oct 5 12:39:16 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 5 Oct 2020 12:39:16 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: On Sat, 3 Oct 2020 20:29:14 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - Misc. Review feedback >> - Move ClassLoaderMetaspace to own include and correct includes > > src/hotspot/share/memory/metaspace/freeChunkList.hpp line 74: > >> 72: // structure can easily be optimized (e.g. a BST). But for now lets keep this simple. >> 73: >> 74: class FreeChunkList { > > This is about the 3rd list implementation (so far) in this change (boilerplate code!). It would be awesome if one or > two could be replaced with > [LinkedList](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/linkedlist.hpp). Currently this is > not possible, because `LinkedListNodes` cannot be placed into the payload. What about filing a RFE about adding and > using a `LinkedList` implementation that allows this? Yes, this could possibly be done. Its a bit of a matter of taste. In this case note that FreeChunkList orders chunks by commit state on insert, and does other stuff particular to that list, so you will need to revive that functionality. As it is now I find this coding clear and easy to read. Any solution we arrive at after factoring out should not be worse. > src/hotspot/share/memory/metaspace/chunkManager.hpp line 118: > >> 116: >> 117: // On success, returns a chunk of level of , but at most . >> 118: // The first first of the chunk are guaranteed to be committed. > > Typo: first first. ok ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From zgu at openjdk.java.net Mon Oct 5 12:43:36 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 5 Oct 2020 12:43:36 GMT Subject: RFR: 8253948: Memory leak in ImageFileReader [v2] In-Reply-To: References: Message-ID: > ImageFileReader allocates ImageModuleData in ImageFileReader::open(), but never free. > > Also renamed module_data to _module_data to be consistent with other member variables. > > Test: > - [x] tier1 on Linux x86_64 Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Fix indents ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/490/files - new: https://git.openjdk.java.net/jdk/pull/490/files/925fb03b..18326c81 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=490&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=490&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/490.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/490/head:pull/490 PR: https://git.openjdk.java.net/jdk/pull/490 From stuefe at openjdk.java.net Mon Oct 5 12:47:12 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 5 Oct 2020 12:47:12 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: On Sat, 3 Oct 2020 21:34:46 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - Misc. Review feedback >> - Move ClassLoaderMetaspace to own include and correct includes > > src/hotspot/share/memory/metaspace/chunkManager.cpp line 144: > >> 142: DEBUG_ONLY(chunklevel::check_valid_level(max_level);) >> 143: DEBUG_ONLY(chunklevel::check_valid_level(preferred_level);) >> 144: assert(max_level >= preferred_level, "invalid level."); > > This assert is redundant. It has the same condition as the assert on line 135. True. (The line numbers are off in this snippet btw. The real code is at 125ff. Not sure what happened.) > src/hotspot/share/memory/metaspace/rootChunkArea.cpp line 110: > >> 108: // half chunk splinter. >> 109: // Instead, just split split split and delay building up the double linked list of the >> 110: // new chunks at the end of all splits. > > This comment does not match the code below anymore, does it? Right, good catch, this was for an earlier version. Found the original code too hard to read and too error prone. I'll remove the comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From alanb at openjdk.java.net Mon Oct 5 12:49:41 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 5 Oct 2020 12:49:41 GMT Subject: RFR: 8253948: Memory leak in ImageFileReader [v2] In-Reply-To: References: Message-ID: <5pMS58rzRBTEFEEBc2rEVbAs6aL-79XW4gG6ztemSYY=.7884a8c4-1b6c-45d8-ad6c-aded06291705@github.com> On Sat, 3 Oct 2020 16:17:50 GMT, Alan Bateman wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indents > > The jimage file is opened at startup and should never be closed. However the jrtfs provider (used by IDEs and other > tools to access the resources in a target run-time image) may run into it so good to get it fixed. > Can you fix the formatting to use 4-space indentation consistently? I should have been clearer. The indentation issues are with changed lines 375, 446-447, and 581. ------------- PR: https://git.openjdk.java.net/jdk/pull/490 From rehn at openjdk.java.net Mon Oct 5 12:55:42 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 5 Oct 2020 12:55:42 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 12:33:56 GMT, Robbin Ehn wrote: >> test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 97: >> >> >> Can we check for another frame like e.g. WB_WaitUnsafe? AbortVMOnSafepointTimeout is designed to provide a stack trace >> of the thread which is blocking the safepoint. > > Since top frame is always different (platform dependent, e.g. clock_nanosleep) I removed that. > And only top frame is in output. The other frames are only in hs_err. > > So I couldn't keep it. > > You have some idea how to? I update comment before mail was sent, still the old comment was sent, please see edited comment :) ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From rrich at openjdk.java.net Mon Oct 5 13:05:44 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 5 Oct 2020 13:05:44 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 12:35:20 GMT, Thomas Stuefe wrote: >> src/hotspot/share/memory/metaspace/freeChunkList.hpp line 74: >> >>> 72: // structure can easily be optimized (e.g. a BST). But for now lets keep this simple. >>> 73: >>> 74: class FreeChunkList { >> >> This is about the 3rd list implementation (so far) in this change (boilerplate code!). It would be awesome if one or >> two could be replaced with >> [LinkedList](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/linkedlist.hpp). Currently this is >> not possible, because `LinkedListNodes` cannot be placed into the payload. What about filing a RFE about adding and >> using a `LinkedList` implementation that allows this? > > Yes, this could possibly be done. Its a bit of a matter of taste. In this case note that FreeChunkList orders chunks by > commit state on insert, and does other stuff particular to that list, so you will need to revive that functionality. As > it is now I find this coding clear and easy to read. Any solution we arrive at after factoring out should not be worse. I have not yet looked closely at freeChunkList.[ch]pp. Maybe `FreeChunkList` isn't a good candidate for doing it. I still think there is potential for reuse. I'm ok with postponing it though. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From zgu at openjdk.java.net Mon Oct 5 13:07:54 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 5 Oct 2020 13:07:54 GMT Subject: RFR: 8253948: Memory leak in ImageFileReader [v3] In-Reply-To: References: Message-ID: > ImageFileReader allocates ImageModuleData in ImageFileReader::open(), but never free. > > Also renamed module_data to _module_data to be consistent with other member variables. > > Test: > - [x] tier1 on Linux x86_64 Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: More indentation fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/490/files - new: https://git.openjdk.java.net/jdk/pull/490/files/18326c81..c066d4ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=490&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=490&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/490.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/490/head:pull/490 PR: https://git.openjdk.java.net/jdk/pull/490 From alanb at openjdk.java.net Mon Oct 5 13:11:53 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 5 Oct 2020 13:11:53 GMT Subject: RFR: 8253948: Memory leak in ImageFileReader [v3] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 13:07:54 GMT, Zhengyu Gu wrote: >> ImageFileReader allocates ImageModuleData in ImageFileReader::open(), but never free. >> >> Also renamed module_data to _module_data to be consistent with other member variables. >> >> Test: >> - [x] tier1 on Linux x86_64 > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > More indentation fixes Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/490 From zgu at openjdk.java.net Mon Oct 5 13:12:44 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 5 Oct 2020 13:12:44 GMT Subject: Integrated: 8253960: Memory leak in Java_java_lang_ClassLoader_defineClass0() In-Reply-To: References: Message-ID: On Sat, 3 Oct 2020 00:05:40 GMT, Zhengyu Gu wrote: > The memory leak is quite obvious. Early return results 'body' not been released. > > Test: > > - [x] tier1 on Linux x86_64 This pull request has now been integrated. Changeset: 19219a96 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/19219a96 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8253960: Memory leak in Java_java_lang_ClassLoader_defineClass0() Reviewed-by: mchung, stuefe, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/492 From rrich at openjdk.java.net Mon Oct 5 13:13:46 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 5 Oct 2020 13:13:46 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v9] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 12:42:22 GMT, Thomas Stuefe wrote: > True. > > (The line numbers are off in this snippet btw. The real code is at 125ff. Not sure what happened.) This is what I meant in my review-message: > > Btw: I couldn't find out how to navigate from one of my comments to the line of code. At least, when I click on the > > file name, this brings me to a view of the patch at the version I commented on so the line numbers are correct even if > > they changed in the head revision of the pr. > > The line of code a comment applies to is the lowest in the code excerpt shown atop of the comment. Unless the comment > applied to multiple lines, then it shows (eg "Comment on lines +105 to +110"). If you click on the `chunkManager.cpp` in the comment header, this will bring you to the version of the file I commented on, and the line numbers there should match the numbers in the comment's code snippet. You will also see the this comment there. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Mon Oct 5 13:38:03 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 5 Oct 2020 13:38:03 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: > Hi all, > > this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the > delay, had vacation then the entrance of Skara delayed things a bit. > For the delta diff please see [3]. > > This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all > feedback individually in this PR body, but I incorporated almost all into the new revision. > What changed since the last version: > > - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the > group consent. > > - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for > overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth > class loader which made it rather pointless. Now I run it always. > > - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. > > - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) > > Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. > > - In ChunkManager::purge() I improved the comments after discussions with Leo. > > - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due > to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run > every time. > > - Fixed indentation issues as Leo requested > > - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested > > - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes > and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more > flexible since it allows us to have list with purge-able and non-purge-able nodes. > > - and various smaller fixes, mainly on request of Leo. > > @lkorinth: > >> VirtualSpaceNode.hpp >> >>102 // Start pointer of the area. >>103 MetaWord* const _base; >> >>How does this differ from _rs._base? Really needed? >> >>105 // Size, in words, of the whole node >>106 const size_t _word_size; >> >>Can we not calculate this from _rs.size()? > > You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it > is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly > improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at > some point and make those members const - as they should be - then I would rewrite this as you suggest. > Thanks, again, for all your review work! > > ------ > > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html > [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Review Feedback Richard 1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/336/files - new: https://git.openjdk.java.net/jdk/pull/336/files/4cc94c50..128c494d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=09-10 Stats: 61 lines in 10 files changed: 0 ins; 52 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/336/head:pull/336 PR: https://git.openjdk.java.net/jdk/pull/336 From zgu at openjdk.java.net Mon Oct 5 13:54:47 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 5 Oct 2020 13:54:47 GMT Subject: Integrated: 8253948: Memory leak in ImageFileReader In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 20:47:16 GMT, Zhengyu Gu wrote: > ImageFileReader allocates ImageModuleData in ImageFileReader::open(), but never free. > > Also renamed module_data to _module_data to be consistent with other member variables. > > Test: > - [x] tier1 on Linux x86_64 This pull request has now been integrated. Changeset: 81dae70f Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/81dae70f Stats: 15 lines in 2 files changed: 10 ins; 0 del; 5 mod 8253948: Memory leak in ImageFileReader Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/490 From pchilanomate at openjdk.java.net Mon Oct 5 14:03:44 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 5 Oct 2020 14:03:44 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 10:58:01 GMT, Martin Doerr wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update with input from reviews > > Thanks for reimplementing it to resolve problems with handshake all operations. > > LGTM > > Thanks! There is an update, please consider. Still looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From pchilanomate at openjdk.java.net Mon Oct 5 14:12:55 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 5 Oct 2020 14:12:55 GMT Subject: RFR: 8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() [v2] In-Reply-To: References: Message-ID: > Hi all, > > Please review the following patch. Current ThreadCrashProtection() implementation uses static members which requires > the use of Thread::muxAcquire() to allow only one user at a time. We can avoid this synchronization requirement if each > thread has its own ThreadCrashProtection *data. I tested it builds on Linux, macOS and Windows. Since the > JfrThreadSampler is the only one using this I run all the tests from test/jdk/jdk/jfr/. I also run some tests with JFR > enabled while forcing a crash in OSThreadSampler::protected_task() and tests passed with several "Thread method sampler > crashed" UL output. Also run tiers1-3. Thanks, Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Remove _crash_mux ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/376/files - new: https://git.openjdk.java.net/jdk/pull/376/files/c3168cc7..00539d6f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=376&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=376&range=00-01 Stats: 101 lines in 14 files changed: 45 ins; 35 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/376.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/376/head:pull/376 PR: https://git.openjdk.java.net/jdk/pull/376 From mdoerr at openjdk.java.net Mon Oct 5 14:47:43 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 5 Oct 2020 14:47:43 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 09:00:54 GMT, Robbin Ehn wrote: >> The issue is that this test doesn't consider Handshake All operation. >> Depending if/when such operation is scheduled it can lockup the VM thread. >> And the safepoint that should timeout never happens. >> See issue for more information. >> >> So I changed the test to "try timeout" the safepoint, but if there was no safepoint (blocked by a handshake all), we >> retry. We sleep unsafe much longer than the interval SafepointALot generates operations, which 'guarantees' we will >> timeout if there is no handshake all. (some extreme case of kernel scheduling causing a very long context switch could >> also make us not timeout) Passes t1, t3, and repeat runs of the test. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Update with input from reviews Looks good to me. Thanks. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/465 From mdoerr at openjdk.java.net Mon Oct 5 14:47:43 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 5 Oct 2020 14:47:43 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 12:52:41 GMT, Robbin Ehn wrote: >> Since top frame is always different (platform dependent, e.g. clock_nanosleep) I removed that. >> And only top frame is in output. The other frames are only in hs_err. >> >> So I couldn't keep it. >> >> You have some idea how to? > > I update comment before mail was sent, still the old comment was sent, please see edited comment :) You're rigth, OutputAnalyzer can only see the top frame which is platform dependent. I think scanning the hs_err file would be too complicated. So I'm ok with omitting the check. ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From pchilanomate at openjdk.java.net Mon Oct 5 15:02:43 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 5 Oct 2020 15:02:43 GMT Subject: RFR: 8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() [v2] In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 14:05:36 GMT, Patricio Chilano Mateo wrote: >> Like David I would also like to know more about the motivation. Is the feature expected to be used by a larger number >> of threads? If so, there might be concerns about scalability that was not considered initially. >> I agree that we have seen less, and for a long time almost no, asserts related to thread sampling in our testing with >> fastdebug builds (only product builds run with the protection). At the same time, I am not sure how representative that >> is considering all the code that is out there. We should also keep in mind that we have upcoming features that will >> have slightly different stack layouts which will affect how stackwalking is achieved, so I would recommend keeping the >> established safety mechanism. > > I looked at the users of Thread::muxAcquire/muxRelease and this was one of the two places where it is used. If we are > going to have a crash protection mechanism for general use then the fields should not be static. Now, if we know only > the JfrThreadSampler uses it and we want to optimize away that pointer in the thread object then that makes sense, but > then we should remove _crash_mux. Please see the update. Since there was concern about adding a new pointer in the Thread class I kept the fields as static and just removed _crash_mux. I also fixed the comment about the class being used by the JfrSampler instead of the Watcher thread. ------------- PR: https://git.openjdk.java.net/jdk/pull/376 From dcubed at openjdk.java.net Mon Oct 5 15:35:51 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 5 Oct 2020 15:35:51 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: <9CQIDFYeLLRibIAwy6T_XgWPoB4STYNycFra37XBvGw=.34931f06-646a-4b93-be55-594bfdea6931@github.com> References: <9CQIDFYeLLRibIAwy6T_XgWPoB4STYNycFra37XBvGw=.34931f06-646a-4b93-be55-594bfdea6931@github.com> Message-ID: On Fri, 2 Oct 2020 06:48:35 GMT, Robbin Ehn wrote: >> test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 71: >> >>> 69: ProcessBuilder pb = ProcessTools.createJavaProcessBuilder( >>> 70: "-XX:+UnlockDiagnosticVMOptions", >>> 71: "-XX:-UseBiasedLocking", >> >> I think "-XX:-UseBiasedLocking" is specified to make sure >> that Biased Locking is disabled even in test tasks where it >> is enabled by task specific flags. > > Yes. But now this test is fine with using biased locking. Okay thanks for the clarification. >> test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 79: >> >>> 77: } >>> 78: } >>> 79: output.shouldNotHaveExitValue(0); >> >> Looks like the test doesn't require that this mesg get printed: >> `System.out.println("This message would occur after some time.");` >> >> And it is set up to detect that the SafepointTimeout happened >> which is what we want the test to verify at the core. > > The line "This message would occur after some time." should never be print if VM is working. > If the VM fails for some reason and the timeout is not performed, line: > "Timed out while spinning to reach a safepoint." is never printed and the OutputAnalyzer fails the test. > If we did timeout and it was printed we know that we didn't print the other message, since the only thread that can > timeout is the one printing that message. > The second part verifies that the SIGILL was delivered. Okay, but then this message when you're reading the code is misleading: `System.out.println("This message would occur after some time.");` It should be printing something like: `System.out.println("This message only prints if something is broken.");` ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From dcubed at openjdk.java.net Mon Oct 5 15:35:50 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 5 Oct 2020 15:35:50 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 09:00:54 GMT, Robbin Ehn wrote: >> The issue is that this test doesn't consider Handshake All operation. >> Depending if/when such operation is scheduled it can lockup the VM thread. >> And the safepoint that should timeout never happens. >> See issue for more information. >> >> So I changed the test to "try timeout" the safepoint, but if there was no safepoint (blocked by a handshake all), we >> retry. We sleep unsafe much longer than the interval SafepointALot generates operations, which 'guarantees' we will >> timeout if there is no handshake all. (some extreme case of kernel scheduling causing a very long context switch could >> also make us not timeout) Passes t1, t3, and repeat runs of the test. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Update with input from reviews Changes requested by dcubed (Reviewer). src/hotspot/share/prims/whitebox.cpp line 77: > 75: #include "runtime/jniHandles.inline.hpp" > 76: #include "runtime/os.hpp" > 77: #include "runtime/safepoint.hpp" I don't think you need this include change anymore. test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 74: > 72: Integer waitTime = Integer.parseInt(args[0]); > 73: WhiteBox wb = WhiteBox.getWhiteBox(); > 74: // While no safepoint timeout. Perhaps: // Loop here to cause a safepoint timeout. ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From dcubed at openjdk.java.net Mon Oct 5 15:43:46 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 5 Oct 2020 15:43:46 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: <9CQIDFYeLLRibIAwy6T_XgWPoB4STYNycFra37XBvGw=.34931f06-646a-4b93-be55-594bfdea6931@github.com> References: <9CQIDFYeLLRibIAwy6T_XgWPoB4STYNycFra37XBvGw=.34931f06-646a-4b93-be55-594bfdea6931@github.com> Message-ID: On Fri, 2 Oct 2020 06:37:21 GMT, Robbin Ehn wrote: >> test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 30: >> >>> 28: /* >>> 29: * @test TestAbortVMOnSafepointTimeout >>> 30: * @summary Check if VM can kill thread which doesn't reach safepoint. >> >> Not your bug, but this summary is wrong. Perhaps: >> `@summary Check if VM aborts when a thread doesn't reach safepoint.` > > The timeout shots a SIGILL on the 'slow' thread, it does not abort (it do abort if it can't send the signal). > Test also checks that the log says we have done this. Okay thanks for the clarification. ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From dcubed at openjdk.java.net Mon Oct 5 15:47:49 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 5 Oct 2020 15:47:49 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 15:33:01 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update with input from reviews > > Changes requested by dcubed (Reviewer). Robbin replied: > David H. wrote: > > That all said, for the record, we really should have a handshake timeout mechanism the same as we have the safepoint > > timeout mechanism. > > We have a timeout mechanism but default off HandshakeTimeout. > But it doesn't fire SIGILL to troubled thread as safepoint does. What's the conclusion here? Are there going to be changes to the test to use the HandshakeTimeout option? Should the test have failed in a different way than it did? ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From dcubed at openjdk.java.net Mon Oct 5 16:04:49 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 5 Oct 2020 16:04:49 GMT Subject: RFR: 8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() [v2] In-Reply-To: References: Message-ID: <6g3N73cRwxc_aVJHe711bK1AJkU2ZO1ftMT-FBAoTVc=.84bc1115-679f-43f7-95d3-4f3d3ed1a58e@github.com> On Mon, 5 Oct 2020 14:12:55 GMT, Patricio Chilano Mateo wrote: >> Hi all, >> >> Please review the following patch. Current ThreadCrashProtection() implementation uses static members which requires >> the use of Thread::muxAcquire() to allow only one user at a time. We can avoid this synchronization requirement if each >> thread has its own ThreadCrashProtection *data. I tested it builds on Linux, macOS and Windows. Since the >> JfrThreadSampler is the only one using this I run all the tests from test/jdk/jdk/jfr/. I also run some tests with JFR >> enabled while forcing a crash in OSThreadSampler::protected_task() and tests passed with several "Thread method sampler >> crashed" UL output. Also run tiers1-3. Thanks, Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Remove _crash_mux Looks good. I only have minor suggested changes, but it's you call on whether to make those changes. src/hotspot/os/posix/os_posix.cpp line 1530: > 1528: os::ThreadCrashProtection::ThreadCrashProtection() { > 1529: assert(Thread::current()->is_JfrSampler_thread(), "should be JFRSampler"); > 1530: _protected_thread = Thread::current(); Perhaps this: `_protected_thread = Thread::current();` `assert(_protected_thread->is_JfrSampler_thread(), "should be JFRSampler");` would be a little more clean. src/hotspot/os/windows/os_windows.cpp line 5005: > 5003: os::ThreadCrashProtection::ThreadCrashProtection() { > 5004: assert(Thread::current()->is_JfrSampler_thread(), "should be JFRSampler"); > 5005: _protected_thread = Thread::current(); Perhaps this: `_protected_thread = Thread::current();` `assert(_protected_thread->is_JfrSampler_thread(), "should be JFRSampler");` would be a little more clean. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/376 From ccheung at openjdk.java.net Mon Oct 5 16:54:42 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 5 Oct 2020 16:54:42 GMT Subject: Integrated: 8224509: Incorrect alignment in CDS related allocation code on 32-bit platforms In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 22:40:46 GMT, Calvin Cheung wrote: > CDS aligns pointers and sizes to BytesPerWord. On 64-bit, BytesPerWord = 8. On 32-bit, BytesPerWord = 4. > > To make the alignment consistent between 64- and 32-bit platforms, this patch changes the alignment value to 8. > > Testing: tiers 1 - 4 > built linux-x86-debug. This pull request has now been integrated. Changeset: ea27a54b Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/ea27a54b Stats: 14 lines in 5 files changed: 5 ins; 1 del; 8 mod 8224509: Incorrect alignment in CDS related allocation code on 32-bit platforms Reviewed-by: iklam, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/476 From pchilanomate at openjdk.java.net Mon Oct 5 17:58:52 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 5 Oct 2020 17:58:52 GMT Subject: RFR: 8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() [v3] In-Reply-To: References: Message-ID: <98biyNTA4E1VgV3o666M0XMs5nmAYERQMLpeZ2cNJh0=.eb5fe2a8-f476-4d95-86d6-ad0a7fa3c02d@github.com> > Hi all, > > Please review the following patch. Current ThreadCrashProtection() implementation uses static members which requires > the use of Thread::muxAcquire() to allow only one user at a time. We can avoid this synchronization requirement if each > thread has its own ThreadCrashProtection *data. I tested it builds on Linux, macOS and Windows. Since the > JfrThreadSampler is the only one using this I run all the tests from test/jdk/jdk/jfr/. I also run some tests with JFR > enabled while forcing a crash in OSThreadSampler::protected_task() and tests passed with several "Thread method sampler > crashed" UL output. Also run tiers1-3. Thanks, Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Address Dan's comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/376/files - new: https://git.openjdk.java.net/jdk/pull/376/files/00539d6f..b93e94b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=376&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=376&range=01-02 Stats: 4 lines in 2 files changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/376.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/376/head:pull/376 PR: https://git.openjdk.java.net/jdk/pull/376 From ioi.lam at oracle.com Mon Oct 5 18:22:08 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 5 Oct 2020 11:22:08 -0700 Subject: RFR: 8253909: Implement detailed map file for CDS In-Reply-To: References: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> Message-ID: Hi Thomas, Thanks for the review! On 10/1/20 11:26 PM, Thomas Stuefe wrote: > Not a full review, just some drive-by comments. > > src/hotspot/share/memory/archiveBuilder.cpp line 723: > >> 721: // Dump all the data [base...top). Pretend that the base address >> 722: // will be mapped to runtime_base at run-time. >> 723: static void write_data(address base, address top, address runtime_base) { > Consider printing the data with os::print_hex_dump() instead. Would slim down this coding. Fixed. I had to modify os::print_hex_dump() to optionally print a "logical" address. > src/hotspot/share/memory/archiveBuilder.cpp line 769: > >> 767: log_info(cds, map)("Log level = info"); >> 768: log_info(cds, map)("Run with -Xlog:cds+map=debug for more detailed information"); >> 769: log_info(cds, map)("Run with -Xlog:cds+map=trace for even more detailed information"); > Matter of taste, but I do not think usage information belongs into a log. Removed > src/hotspot/share/memory/archiveBuilder.cpp line 759: > >> 757: GrowableArray *closed_heap_regions, >> 758: GrowableArray *open_heap_regions, >> 759: char* bitmap, size_t bitmap_size_in_bytes) { > Consider, instead of directly writing to UL, writing to an outputStream*. That would make the code more versatile and > reusable. You can then use LogStream to print to UL with the same result. UL allows several logging levels. I don't know how to do that with outputStream (without passing 3 different outputStreams). > src/hotspot/share/memory/archiveBuilder.cpp line 609: > >> 607: // picked by the OS. At runtime, we try to map at a fixed location (SharedBaseAddress). For >> 608: // consistency, we log everything using runtime addresses. >> 609: class ArchiveBuilder::CDSMapLogger { > AllStatic? Fixed > src/hotspot/share/memory/archiveBuilder.cpp line 775: > >> 773: address header_end = header + mapinfo->header()->header_size(); >> 774: write_region("header", header, header_end, 0); >> 775: write_data(header, header_end, 0); > Consider writing out the header members human-readable, that would be more useful than a hexdump. I'd also print them > already at Info level, since often the header info is the only thing interesting. Done. I attached the updated example logs to the bug report. > src/hotspot/share/memory/filemap.hpp line 461: > >> 459: void write_region(int region, char* base, size_t size, >> 460: bool read_only, bool allow_exec); >> 461: char* write_bitmap_region(const CHeapBitMap* ptrmap, > Can you add a comment here and in MetaspaceShared::write_core_archive_regions() that the returned bitmap is c-heap > allocated and needs to be freed? Fixed. Thanks - Ioi From rehn at openjdk.java.net Mon Oct 5 18:24:46 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 5 Oct 2020 18:24:46 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 15:14:16 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update with input from reviews > > src/hotspot/share/prims/whitebox.cpp line 77: > >> 75: #include "runtime/jniHandles.inline.hpp" >> 76: #include "runtime/os.hpp" >> 77: #include "runtime/safepoint.hpp" > > I don't think you need this include change anymore. Fixed > test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java line 74: > >> 72: Integer waitTime = Integer.parseInt(args[0]); >> 73: WhiteBox wb = WhiteBox.getWhiteBox(); >> 74: // While no safepoint timeout. > > Perhaps: // Loop here to cause a safepoint timeout. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From rehn at openjdk.java.net Mon Oct 5 18:24:45 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 5 Oct 2020 18:24:45 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: References: Message-ID: <_lTsmQHKLm72VMTs4jDuZcTprHyNmX38FlA7IyTY0rk=.a5b3f1db-15ad-4d0b-ab5d-7503f25015a6@github.com> On Fri, 2 Oct 2020 09:00:54 GMT, Robbin Ehn wrote: >> The issue is that this test doesn't consider Handshake All operation. >> Depending if/when such operation is scheduled it can lockup the VM thread. >> And the safepoint that should timeout never happens. >> See issue for more information. >> >> So I changed the test to "try timeout" the safepoint, but if there was no safepoint (blocked by a handshake all), we >> retry. We sleep unsafe much longer than the interval SafepointALot generates operations, which 'guarantees' we will >> timeout if there is no handshake all. (some extreme case of kernel scheduling causing a very long context switch could >> also make us not timeout) Passes t1, t3, and repeat runs of the test. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Update with input from reviews Pushing the small update in a minute. ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From rehn at openjdk.java.net Mon Oct 5 18:24:47 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 5 Oct 2020 18:24:47 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: References: <9CQIDFYeLLRibIAwy6T_XgWPoB4STYNycFra37XBvGw=.34931f06-646a-4b93-be55-594bfdea6931@github.com> Message-ID: On Mon, 5 Oct 2020 15:31:01 GMT, Daniel D. Daugherty wrote: >> The line "This message would occur after some time." should never be print if VM is working. >> If the VM fails for some reason and the timeout is not performed, line: >> "Timed out while spinning to reach a safepoint." is never printed and the OutputAnalyzer fails the test. >> If we did timeout and it was printed we know that we didn't print the other message, since the only thread that can >> timeout is the one printing that message. >> The second part verifies that the SIGILL was delivered. > > Okay, but then this message when you're reading the code is misleading: > `System.out.println("This message would occur after some time.");` > It should be printing something like: > `System.out.println("This message only prints if something is broken.");` > > Update: Yes, I realize that this is an existing problem, but it's still reads wrong. I removed comment in last update, since it can't be printed. ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From iklam at openjdk.java.net Mon Oct 5 18:26:55 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 5 Oct 2020 18:26:55 GMT Subject: RFR: 8253909: Implement detailed map file for CDS [v2] In-Reply-To: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> References: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> Message-ID: > For analyzing the contents of a CDS archive, we need a "map file" that describes the archive in different levels of > detail. This can be done using unified logging. E.g., > java -Xshare:dump -Xlog:cds+map=trace:file=cds.map:none:filesize=0 > > For example, we can use the map file for troubleshooting [JDK-8253495](https://bugs.openjdk.java.net/browse/JDK-8253495) > (runtime/cds/DeterministicDump.java broken). We can diff two different cds.map files to see where the non-deterministic > contents come from. > See attachments in [JDK-8253909](https://bugs.openjdk.java.net/browse/JDK-8253909) for example map files at the > info/debug/trace levels. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Feedback from Thomas Stuefe ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/474/files - new: https://git.openjdk.java.net/jdk/pull/474/files/44ad4be3..5dc43c70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=474&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=474&range=00-01 Stats: 165 lines in 6 files changed: 97 ins; 37 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/474/head:pull/474 PR: https://git.openjdk.java.net/jdk/pull/474 From pchilanomate at openjdk.java.net Mon Oct 5 18:29:42 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 5 Oct 2020 18:29:42 GMT Subject: RFR: 8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() [v2] In-Reply-To: <6g3N73cRwxc_aVJHe711bK1AJkU2ZO1ftMT-FBAoTVc=.84bc1115-679f-43f7-95d3-4f3d3ed1a58e@github.com> References: <6g3N73cRwxc_aVJHe711bK1AJkU2ZO1ftMT-FBAoTVc=.84bc1115-679f-43f7-95d3-4f3d3ed1a58e@github.com> Message-ID: On Mon, 5 Oct 2020 16:02:06 GMT, Daniel D. Daugherty wrote: > Looks good. I only have minor suggested changes, but it's your call > on whether to make those changes. Thanks Dan! Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/376 From rehn at openjdk.java.net Mon Oct 5 18:34:04 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 5 Oct 2020 18:34:04 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v2] In-Reply-To: <_lTsmQHKLm72VMTs4jDuZcTprHyNmX38FlA7IyTY0rk=.a5b3f1db-15ad-4d0b-ab5d-7503f25015a6@github.com> References: <_lTsmQHKLm72VMTs4jDuZcTprHyNmX38FlA7IyTY0rk=.a5b3f1db-15ad-4d0b-ab5d-7503f25015a6@github.com> Message-ID: On Mon, 5 Oct 2020 18:21:43 GMT, Robbin Ehn wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update with input from reviews > > Pushing the small update in a minute. > Robbin replied: > > > David H. wrote: > > > That all said, for the record, we really should have a handshake timeout mechanism the same as we have the safepoint > > > timeout mechanism. > > > > > > We have a timeout mechanism but default off HandshakeTimeout. > > But it doesn't fire SIGILL to troubled thread as safepoint does. > > What's the conclusion here? Are there going to be changes to the > test to use the HandshakeTimeout option? Should the test have > failed in a different way than it did? In https://bugs.openjdk.java.net/browse/JDK-8198730 I'm have been looking into setting these (safepoint and handshake timeout ) to default 1 second. There were some impediments which now seems to have been resolved. If any of these operations takes longer you want to know it because A: you have a bug, or B: you have performance problems. So I don't think the default value is what any user wants. ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From rehn at openjdk.java.net Mon Oct 5 18:34:04 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 5 Oct 2020 18:34:04 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v3] In-Reply-To: References: Message-ID: > The issue is that this test doesn't consider Handshake All operation. > Depending if/when such operation is scheduled it can lockup the VM thread. > And the safepoint that should timeout never happens. > See issue for more information. > > So I changed the test to "try timeout" the safepoint, but if there was no safepoint (blocked by a handshake all), we > retry. We sleep unsafe much longer than the interval SafepointALot generates operations, which 'guarantees' we will > timeout if there is no handshake all. (some extreme case of kernel scheduling causing a very long context switch could > also make us not timeout) Passes t1, t3, and repeat runs of the test. Robbin Ehn 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: - Fixed include and comment - Merge branch 'master' into 8253794 - Update with input from reviews - Fixed test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/465/files - new: https://git.openjdk.java.net/jdk/pull/465/files/90fb3106..b63b6a09 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=465&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=465&range=01-02 Stats: 8155 lines in 239 files changed: 3444 ins; 1770 del; 2941 mod Patch: https://git.openjdk.java.net/jdk/pull/465.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/465/head:pull/465 PR: https://git.openjdk.java.net/jdk/pull/465 From dcubed at openjdk.java.net Mon Oct 5 18:34:47 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 5 Oct 2020 18:34:47 GMT Subject: RFR: 8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() [v3] In-Reply-To: <98biyNTA4E1VgV3o666M0XMs5nmAYERQMLpeZ2cNJh0=.eb5fe2a8-f476-4d95-86d6-ad0a7fa3c02d@github.com> References: <98biyNTA4E1VgV3o666M0XMs5nmAYERQMLpeZ2cNJh0=.eb5fe2a8-f476-4d95-86d6-ad0a7fa3c02d@github.com> Message-ID: <67I7j2D5BCSLfYcsRMc5_VRb0jRpih53mMJh8wO0Zgk=.f94d6749-e86e-496c-b223-5f1ca57d4409@github.com> On Mon, 5 Oct 2020 17:58:52 GMT, Patricio Chilano Mateo wrote: >> Hi all, >> >> Please review the following patch. Current ThreadCrashProtection() implementation uses static members which requires >> the use of Thread::muxAcquire() to allow only one user at a time. We can avoid this synchronization requirement if each >> thread has its own ThreadCrashProtection *data. I tested it builds on Linux, macOS and Windows. Since the >> JfrThreadSampler is the only one using this I run all the tests from test/jdk/jdk/jfr/. I also run some tests with JFR >> enabled while forcing a crash in OSThreadSampler::protected_task() and tests passed with several "Thread method sampler >> crashed" UL output. Also run tiers1-3. Thanks, Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Address Dan's comments Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/376 From dcubed at openjdk.java.net Mon Oct 5 18:45:51 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 5 Oct 2020 18:45:51 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v3] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 18:34:04 GMT, Robbin Ehn wrote: >> The issue is that this test doesn't consider Handshake All operation. >> Depending if/when such operation is scheduled it can lockup the VM thread. >> And the safepoint that should timeout never happens. >> See issue for more information. >> >> So I changed the test to "try timeout" the safepoint, but if there was no safepoint (blocked by a handshake all), we >> retry. We sleep unsafe much longer than the interval SafepointALot generates operations, which 'guarantees' we will >> timeout if there is no handshake all. (some extreme case of kernel scheduling causing a very long context switch could >> also make us not timeout) Passes t1, t3, and repeat runs of the test. > > Robbin Ehn 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: > - Fixed include and comment > - Merge branch 'master' into 8253794 > - Update with input from reviews > - Fixed test Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/465 From rehn at openjdk.java.net Mon Oct 5 18:52:46 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 5 Oct 2020 18:52:46 GMT Subject: RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts [v3] In-Reply-To: References: Message-ID: <1HFCvpyTXeU3CT2i_HPePoYxkQcUkFY_CRh-NCp1Pbw=.30f77ae5-d0f9-43f7-a6a6-0454478562d0@github.com> On Mon, 5 Oct 2020 18:43:05 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 incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since >> the last revision: >> - Fixed include and comment >> - Merge branch 'master' into 8253794 >> - Update with input from reviews >> - Fixed test > > Thumbs up. Thanks for review @pchilano, @dcubed-ojdk, @TheRealMDoerr. Update was trivial so integrating in a bit. ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From rehn at openjdk.java.net Mon Oct 5 19:21:45 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 5 Oct 2020 19:21:45 GMT Subject: Integrated: 8253794: TestAbortVMOnSafepointTimeout never timeouts In-Reply-To: References: Message-ID: On Thu, 1 Oct 2020 14:35:45 GMT, Robbin Ehn wrote: > The issue is that this test doesn't consider Handshake All operation. > Depending if/when such operation is scheduled it can lockup the VM thread. > And the safepoint that should timeout never happens. > See issue for more information. > > So I changed the test to "try timeout" the safepoint, but if there was no safepoint (blocked by a handshake all), we > retry. We sleep unsafe much longer than the interval SafepointALot generates operations, which 'guarantees' we will > timeout if there is no handshake all. (some extreme case of kernel scheduling causing a very long context switch could > also make us not timeout) Passes t1, t3, and repeat runs of the test. This pull request has now been integrated. Changeset: c9d0407e Author: Robbin Ehn URL: https://git.openjdk.java.net/jdk/commit/c9d0407e Stats: 67 lines in 3 files changed: 22 ins; 36 del; 9 mod 8253794: TestAbortVMOnSafepointTimeout never timeouts Reviewed-by: pchilanomate, dcubed, mdoerr ------------- PR: https://git.openjdk.java.net/jdk/pull/465 From bobv at openjdk.java.net Mon Oct 5 19:25:45 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Mon, 5 Oct 2020 19:25:45 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v3] In-Reply-To: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com> References: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com> Message-ID: On Mon, 5 Oct 2020 10:16:49 GMT, Severin Gehwolf wrote: >> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the >> affected system, `/proc/self/mountinfo` contains a line such as this one: >> >> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd >> >> >> Note that `/proc/cgroups` looks like this: >> >> #subsys_name hierarchy num_cgroups enabled >> cpuset 0 1 1 >> cpu 0 1 1 >> cpuacct 0 1 1 >> blkio 0 1 1 >> memory 0 1 1 >> devices 0 1 1 >> freezer 0 1 1 >> net_cls 0 1 1 >> perf_event 0 1 1 >> net_prio 0 1 1 >> hugetlb 0 1 1 >> pids 0 1 1 >> >> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo >> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in >> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, >> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to >> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's >> cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and >> look for `cgroup` FS-type lines which aren't also mounted purely for systemd. >> **Testing** >> >> - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) >> - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) >> - [x] Added regression test which fails prior the patch and passes after >> - [x] Submit testing > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in comment src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 150: > 148: // find anyway in that case. > 149: try (Stream mntInfo = CgroupUtil.readFilePrivileged(Paths.get(mountInfo))) { > 150: boolean anyCgroupMounted = mntInfo.anyMatch(CgroupSubsystemFactory::noSystemdCgroupLine); I'd prefer a similar approach to the hotspot side where you do a positive check for controllers we are interested in rather than a negative check for systemd. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From coleenp at openjdk.java.net Mon Oct 5 19:26:47 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 5 Oct 2020 19:26:47 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: <7pAVBmJQ5-g7wIvO402eFQprNmW90yCFR5scfw_esYQ=.172e1eae-f8bd-4c41-bf58-bc38499d5e8c@github.com> On Sat, 3 Oct 2020 17:12:30 GMT, Gerard Ziemski wrote: > This is a fresh start for https://github.com/openjdk/jdk/pull/157 > > Please review this change that refactors common POSIX code into a separate > file. > > Currently there appears to be quite a bit of duplicated code among POSIX > platforms, which makes it difficult to apply single fix to the signal code. > With this fix, we will only need to touch single file for common POSIX > code fixes from now on. > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > > > ### Download > `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` > `$ git checkout pull/497` Thank you for doing this change! If you can change these places where there are a couple of comments, that would be great. Marked as reviewed by coleenp (Reviewer). src/hotspot/os/posix/signals_posix.hpp line 28: > 26: #define OS_POSIX_SIGNALS_POSIX_HPP > 27: > 28: #include "memory/allocation.hpp" There's a new memory/allStatic.hpp header file you can include instead. src/hotspot/os/posix/signals_posix.hpp line 35: > 33: // Signal number used to suspend/resume a thread > 34: // do not use any signal number less than SIGSEGV, see 4355769 > 35: static int SR_signum = SIGUSR2; Can you hide this in the .cpp file so that you can avoid including in the header file? And use forward declarations for outputStream, ucontext_t, and siginfo_t. src/hotspot/os/aix/os_aix.cpp line 1459: > 1457: // that will interfere with OOM killling. > 1458: PosixSignals::print_signal_handler(st, SIGDANGER, buf, buflen); > 1459: } I wonder with some #ifdefs, this could also be moved to posix_signals.cpp. Not for this change but maybe a follow-up RFE. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/497 From coleenp at openjdk.java.net Mon Oct 5 19:28:43 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 5 Oct 2020 19:28:43 GMT Subject: RFR: 8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() [v3] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 21:04:39 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/thread.hpp line 756: >> >>> 754: } >>> 755: #endif >>> 756: >> >> Could this be pushed down into osThread ? > > Yes, it can but it's not that clean I think given the osthread indirections. Here's how it looks: > https://github.com/pchilano/jdk/commit/73a41ad867b4b7466cdddc87173828b4e80f8179 > I think another alternative could be to remove the "#ifndef _WINDOWS" clause and define an empty > check_crash_protection() method in os_windows.hpp Ok, yes, I saw the ifdef WINDOWS and thought it should be more os platform specific, but if you had an empty method in os_windows.hpp that would be better imo. It's not as nice in osthread. Thank you for considering it. ------------- PR: https://git.openjdk.java.net/jdk/pull/376 From coleenp at openjdk.java.net Mon Oct 5 19:28:42 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 5 Oct 2020 19:28:42 GMT Subject: RFR: 8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() [v3] In-Reply-To: <98biyNTA4E1VgV3o666M0XMs5nmAYERQMLpeZ2cNJh0=.eb5fe2a8-f476-4d95-86d6-ad0a7fa3c02d@github.com> References: <98biyNTA4E1VgV3o666M0XMs5nmAYERQMLpeZ2cNJh0=.eb5fe2a8-f476-4d95-86d6-ad0a7fa3c02d@github.com> Message-ID: On Mon, 5 Oct 2020 17:58:52 GMT, Patricio Chilano Mateo wrote: >> Hi all, >> >> Please review the following patch. Current ThreadCrashProtection() implementation uses static members which requires >> the use of Thread::muxAcquire() to allow only one user at a time. We can avoid this synchronization requirement if each >> thread has its own ThreadCrashProtection *data. I tested it builds on Linux, macOS and Windows. Since the >> JfrThreadSampler is the only one using this I run all the tests from test/jdk/jdk/jfr/. I also run some tests with JFR >> enabled while forcing a crash in OSThreadSampler::protected_task() and tests passed with several "Thread method sampler >> crashed" UL output. Also run tiers1-3. Thanks, Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Address Dan's comments LGTM! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/376 From dholmes at openjdk.java.net Mon Oct 5 23:07:41 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 5 Oct 2020 23:07:41 GMT Subject: RFR: 8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() [v3] In-Reply-To: <98biyNTA4E1VgV3o666M0XMs5nmAYERQMLpeZ2cNJh0=.eb5fe2a8-f476-4d95-86d6-ad0a7fa3c02d@github.com> References: <98biyNTA4E1VgV3o666M0XMs5nmAYERQMLpeZ2cNJh0=.eb5fe2a8-f476-4d95-86d6-ad0a7fa3c02d@github.com> Message-ID: On Mon, 5 Oct 2020 17:58:52 GMT, Patricio Chilano Mateo wrote: >> Hi all, >> >> Please review the following patch. Current ThreadCrashProtection() implementation uses static members which requires >> the use of Thread::muxAcquire() to allow only one user at a time. We can avoid this synchronization requirement if each >> thread has its own ThreadCrashProtection *data. I tested it builds on Linux, macOS and Windows. Since the >> JfrThreadSampler is the only one using this I run all the tests from test/jdk/jdk/jfr/. I also run some tests with JFR >> enabled while forcing a crash in OSThreadSampler::protected_task() and tests passed with several "Thread method sampler >> crashed" UL output. Also run tiers1-3. Thanks, Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Address Dan's comments So let me see if I've got this straight. Prior to JDK-8183925 CrashProtection was exclusively for the WatcherThread. JDK-8183925 generalized that to allow any(?) thread to use it. Now as the only client is the JfrSampler thread we are making crash protection exclusively only available to it. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/376 From coleenp at openjdk.java.net Mon Oct 5 23:58:40 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 5 Oct 2020 23:58:40 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: <7pAVBmJQ5-g7wIvO402eFQprNmW90yCFR5scfw_esYQ=.172e1eae-f8bd-4c41-bf58-bc38499d5e8c@github.com> References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> <7pAVBmJQ5-g7wIvO402eFQprNmW90yCFR5scfw_esYQ=.172e1eae-f8bd-4c41-bf58-bc38499d5e8c@github.com> Message-ID: On Mon, 5 Oct 2020 19:15:15 GMT, Coleen Phillimore wrote: >> This is a fresh start for https://github.com/openjdk/jdk/pull/157 >> >> Please review this change that refactors common POSIX code into a separate >> file. >> >> Currently there appears to be quite a bit of duplicated code among POSIX >> platforms, which makes it difficult to apply single fix to the signal code. >> With this fix, we will only need to touch single file for common POSIX >> code fixes from now on. >> >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` >> `$ git checkout pull/497` > > src/hotspot/os/posix/signals_posix.hpp line 35: > >> 33: // Signal number used to suspend/resume a thread >> 34: // do not use any signal number less than SIGSEGV, see 4355769 >> 35: static int SR_signum = SIGUSR2; > > Can you hide this in the .cpp file so that you can avoid including in the header file? > > And use forward declarations for outputStream, ucontext_t, and siginfo_t. Note that these changes are not important enough to rerun testing for this cleanup, so you can make it a new RFE. Thank you for doing consolidation! ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From dholmes at openjdk.java.net Tue Oct 6 01:57:42 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Oct 2020 01:57:42 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: <5lDxPFHbSWr4Hfz7zPz8KWjdQS4WLlpnmCjVTNjv_gA=.73ad62a2-c9d9-456f-abf4-52949b0813cb@github.com> On Sat, 3 Oct 2020 17:12:30 GMT, Gerard Ziemski wrote: > This is a fresh start for https://github.com/openjdk/jdk/pull/157 > > Please review this change that refactors common POSIX code into a separate > file. > > Currently there appears to be quite a bit of duplicated code among POSIX > platforms, which makes it difficult to apply single fix to the signal code. > With this fix, we will only need to touch single file for common POSIX > code fixes from now on. > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > > > ### Download > `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` > `$ git checkout pull/497` This looks good. One request to delete a meaningless comment block. Thanks, David src/hotspot/os/posix/signals_posix.cpp line 1574: > 1572: // supported Bsd platforms). Note that BsdThreads/LinuxThreads need to block > 1573: // this signal for all threads to work properly. So we don't have > 1574: // to use hard-coded signal number when setting up the mask. This comment block (lines 1571-1574) should be deleted. It was originally in the Linux code and pertained to the old LinuxThreads implementation which has not been relevant for years. It was erroneously copied across to the BSD port, where Linux was globally replaced with Bsd, resulting in a reference to the non-existent BsdThreads. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/497 From dholmes at openjdk.java.net Tue Oct 6 01:57:43 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Oct 2020 01:57:43 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> <7pAVBmJQ5-g7wIvO402eFQprNmW90yCFR5scfw_esYQ=.172e1eae-f8bd-4c41-bf58-bc38499d5e8c@github.com> Message-ID: On Mon, 5 Oct 2020 23:56:25 GMT, Coleen Phillimore wrote: >> src/hotspot/os/posix/signals_posix.hpp line 35: >> >>> 33: // Signal number used to suspend/resume a thread >>> 34: // do not use any signal number less than SIGSEGV, see 4355769 >>> 35: static int SR_signum = SIGUSR2; >> >> Can you hide this in the .cpp file so that you can avoid including in the header file? >> >> And use forward declarations for outputStream, ucontext_t, and siginfo_t. > > Note that these changes are not important enough to rerun testing for this cleanup, so you can make it a new RFE. > Thank you for doing consolidation! In reply to Coleen's query - SR_signum is referenced from the os_*.cpp files so needs to be in the header file now. ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From pchilanomate at openjdk.java.net Tue Oct 6 03:28:41 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 6 Oct 2020 03:28:41 GMT Subject: RFR: 8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() [v3] In-Reply-To: References: <98biyNTA4E1VgV3o666M0XMs5nmAYERQMLpeZ2cNJh0=.eb5fe2a8-f476-4d95-86d6-ad0a7fa3c02d@github.com> Message-ID: On Mon, 5 Oct 2020 23:05:02 GMT, David Holmes wrote: > So let me see if I've got this straight. Prior to JDK-8183925 CrashProtection was exclusively for the WatcherThread. > JDK-8183925 generalized that to allow any(?) thread to use it. Now as the only client is the JfrSampler thread we are > making crash protection exclusively only available to it. Exactly. ------------- PR: https://git.openjdk.java.net/jdk/pull/376 From pchilanomate at openjdk.java.net Tue Oct 6 03:31:41 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 6 Oct 2020 03:31:41 GMT Subject: RFR: 8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() [v3] In-Reply-To: References: <98biyNTA4E1VgV3o666M0XMs5nmAYERQMLpeZ2cNJh0=.eb5fe2a8-f476-4d95-86d6-ad0a7fa3c02d@github.com> Message-ID: <9uHq9quEXtCm4tFPl-U9yw3Ulv9Ytt2HyemTOgszAIA=.84d45968-3d64-4cbd-8dc1-2f457c678f6c@github.com> On Tue, 6 Oct 2020 03:25:53 GMT, Patricio Chilano Mateo wrote: >> So let me see if I've got this straight. Prior to JDK-8183925 CrashProtection was exclusively for the WatcherThread. >> JDK-8183925 generalized that to allow any(?) thread to use it. Now as the only client is the JfrSampler thread we are >> making crash protection exclusively only available to it. > >> So let me see if I've got this straight. Prior to JDK-8183925 CrashProtection was exclusively for the WatcherThread. >> JDK-8183925 generalized that to allow any(?) thread to use it. Now as the only client is the JfrSampler thread we are >> making crash protection exclusively only available to it. > > Exactly. Thanks @dcubed-ojdk, @coleenp and @dholmes-ora for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/376 From stuefe at openjdk.java.net Tue Oct 6 06:06:41 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 06:06:41 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: On Sat, 3 Oct 2020 17:12:30 GMT, Gerard Ziemski wrote: > This is a fresh start for https://github.com/openjdk/jdk/pull/157 > > Please review this change that refactors common POSIX code into a separate > file. > > Currently there appears to be quite a bit of duplicated code among POSIX > platforms, which makes it difficult to apply single fix to the signal code. > With this fix, we will only need to touch single file for common POSIX > code fixes from now on. > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > > > ### Download > `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` > `$ git checkout pull/497` Looks good to me. All remarks are just proposals for follow ups. Our nightly tests on AIX went through with the current version of the patch. Ship it. Thanks for your work! src/hotspot/os/bsd/os_bsd.cpp line 2285: > 2283: > 2284: void os::SuspendedThreadTask::internal_do_task() { > 2285: if (PosixSignals::do_suspend(_thread->osthread())) { Future RFE: os::SuspendedThreadTask::internal_do_task() can be unified across posix platforms. src/hotspot/os/bsd/os_bsd.cpp line 2152: > 2150: if (!ReduceSignalUsage) { > 2151: PosixSignals::jdk_misc_signal_init(); > 2152: } This whole section could be unified too into an own PosixSignals::initial_signal_stuff() function. Potentially for a future RFE. src/hotspot/os/posix/signals_posix.cpp line 104: > 102: static const struct { > 103: int sig; const char* name; > 104: } Please remove newlines. This is one declaration: static const struct { ,, } g_signal_info[] = { src/hotspot/os/posix/signals_posix.cpp line 454: > 452: void* ucontext, > 453: int abort_if_unrecognized); > 454: #endif Future cleanup: I think it will be difficult to unify the platform specific signal handlers (but worthwhile). But the naming could be at least the same, no reason to have the platform in the name. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/497 From stuefe at openjdk.java.net Tue Oct 6 06:06:42 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 06:06:42 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: <7pAVBmJQ5-g7wIvO402eFQprNmW90yCFR5scfw_esYQ=.172e1eae-f8bd-4c41-bf58-bc38499d5e8c@github.com> References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> <7pAVBmJQ5-g7wIvO402eFQprNmW90yCFR5scfw_esYQ=.172e1eae-f8bd-4c41-bf58-bc38499d5e8c@github.com> Message-ID: On Mon, 5 Oct 2020 19:23:21 GMT, Coleen Phillimore wrote: >> This is a fresh start for https://github.com/openjdk/jdk/pull/157 >> >> Please review this change that refactors common POSIX code into a separate >> file. >> >> Currently there appears to be quite a bit of duplicated code among POSIX >> platforms, which makes it difficult to apply single fix to the signal code. >> With this fix, we will only need to touch single file for common POSIX >> code fixes from now on. >> >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` >> `$ git checkout pull/497` > > src/hotspot/os/aix/os_aix.cpp line 1459: > >> 1457: // that will interfere with OOM killling. >> 1458: PosixSignals::print_signal_handler(st, SIGDANGER, buf, buflen); >> 1459: } > > I wonder with some #ifdefs, this could also be moved to posix_signals.cpp. Not for this change but maybe a follow-up > RFE. Yes, this os::print_signal_handlers() and os::print_signal_handler() could be unified across Posix platforms. At least the latter. (Personally I also would like to print all signal handlers from 1.., regardless of whether its one of "us". E.g. if process overrides SIGCHILD that is interesting too.) ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From stuefe at openjdk.java.net Tue Oct 6 06:06:43 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 06:06:43 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> <7pAVBmJQ5-g7wIvO402eFQprNmW90yCFR5scfw_esYQ=.172e1eae-f8bd-4c41-bf58-bc38499d5e8c@github.com> Message-ID: On Tue, 6 Oct 2020 01:52:21 GMT, David Holmes wrote: >> Note that these changes are not important enough to rerun testing for this cleanup, so you can make it a new RFE. >> Thank you for doing consolidation! > > In reply to Coleen's query - SR_signum is referenced from the os_*.cpp files so needs to be in the header file now. I wondered why this is not const then I saw that it can be overwritten with an environment variable "_JAVA_SR_SIGNUM". Is this still needed? Seems to be an odd way of specifying a VM parameter. And it seems to be untested (I did not find any tests for that in the open codebase). ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From stuefe at openjdk.java.net Tue Oct 6 06:48:46 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 06:48:46 GMT Subject: RFR: 8253909: Implement detailed map file for CDS [v2] In-Reply-To: References: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> Message-ID: On Mon, 5 Oct 2020 18:26:55 GMT, Ioi Lam wrote: >> For analyzing the contents of a CDS archive, we need a "map file" that describes the archive in different levels of >> detail. This can be done using unified logging. E.g., >> java -Xshare:dump -Xlog:cds+map=trace:file=cds.map:none:filesize=0 >> >> For example, we can use the map file for troubleshooting [JDK-8253495](https://bugs.openjdk.java.net/browse/JDK-8253495) >> (runtime/cds/DeterministicDump.java broken). We can diff two different cds.map files to see where the non-deterministic >> contents come from. >> See attachments in [JDK-8253909](https://bugs.openjdk.java.net/browse/JDK-8253909) for example map files at the >> info/debug/trace levels. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Feedback from Thomas Stuefe Changes requested by stuefe (Reviewer). src/hotspot/share/memory/filemap.cpp line 301: > 299: st->print_cr("- ptrmap_size_in_bits: " SIZE_FORMAT, _ptrmap_size_in_bits); > 300: } > 301: Great, thank you! src/hotspot/share/runtime/os.hpp line 693: > 691: static void print_hex_dump(outputStream* st, address start, address end, int unitsize) { > 692: print_hex_dump(st, start, end, unitsize, /*bytes_per_line=*/16, /*logical_start=*/start); > 693: } This is a bit unclear. Could we do it like this instead: // Print a hex dump from [start .. end). Output lines are prefixed with addresses. static void print_hex_dump(outputStream* st, address start, address end, int unitsize) // Print a hex dump from [base+start .. base+end). Output lines are prefixed with offset in relation to base. static void print_hex_dump(outputStream* st, address base, intx start, intx end, int unitsize) ------------- PR: https://git.openjdk.java.net/jdk/pull/474 From rrich at openjdk.java.net Tue Oct 6 06:48:51 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Oct 2020 06:48:51 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 13:38:03 GMT, Thomas Stuefe wrote: >> Hi all, >> >> this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the >> delay, had vacation then the entrance of Skara delayed things a bit. >> For the delta diff please see [3]. >> >> This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all >> feedback individually in this PR body, but I incorporated almost all into the new revision. >> What changed since the last version: >> >> - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the >> group consent. >> >> - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for >> overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth >> class loader which made it rather pointless. Now I run it always. >> >> - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. >> >> - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) >> >> Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. >> >> - In ChunkManager::purge() I improved the comments after discussions with Leo. >> >> - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due >> to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run >> every time. >> >> - Fixed indentation issues as Leo requested >> >> - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested >> >> - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes >> and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more >> flexible since it allows us to have list with purge-able and non-purge-able nodes. >> >> - and various smaller fixes, mainly on request of Leo. >> >> @lkorinth: >> >>> VirtualSpaceNode.hpp >>> >>>102 // Start pointer of the area. >>>103 MetaWord* const _base; >>> >>>How does this differ from _rs._base? Really needed? >>> >>>105 // Size, in words, of the whole node >>>106 const size_t _word_size; >>> >>>Can we not calculate this from _rs.size()? >> >> You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it >> is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly >> improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at >> some point and make those members const - as they should be - then I would rewrite this as you suggest. >> Thanks, again, for all your review work! >> >> ------ >> >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html >> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html >> [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Review Feedback Richard 1 Hi Thomas, this is batch 2. I'm now at 61/166 files :) Cheers, Richard. src/hotspot/share/memory/metaspace/binList.hpp line 135: > 133: i2++; > 134: m >>= 1; > 135: } I think you overlooked my proposal to make use of `count_trailing_zeros()` instead of this while-loop. src/hotspot/share/memory/metaspace/metaspaceArena.cpp line 81: > 79: METACHUNK_FULL_FORMAT_ARGS(c)); > 80: } > 81: } Have you thought about splitting the chunk if possible and returning the free chunk to the ChunkManager? If you return it to the free list of this class loader then only this loader can make use of it. If you return it to the CM then every loader can make use of it and, potentially, it can even be uncommitted. src/hotspot/share/memory/metaspace/counters.hpp line 108: > 106: assert(old >= 1, > 107: "underflow (" UINT64_FORMAT "-1)", (uint64_t)old); > 108: #endif The assertion is incorrect because it is not atomic wrt the actual update. I commented on this before. It should be fairly easy to write a multi-thread gtest that produces false positives of the assertion (if it is easy to write a multi-threaded gtest). The person affected by a false positive crash will be not too amused. I suggest to fix or remove the assertion. src/hotspot/share/memory/metaspace/counters.hpp line 121: > 119: assert(old >= v, > 120: "underflow (" UINT64_FORMAT "+" UINT64_FORMAT ")", (uint64_t)old, (uint64_t)v); > 121: #endif The assertion is incorrect because it is not atomic wrt the actual update (see above). I suggest to fix or remove the assertion. src/hotspot/share/memory/metaspace/metachunk.cpp line 141: > 139: void Metachunk::uncommit() { > 140: MutexLocker cl(MetaspaceExpand_lock, Mutex::_no_safepoint_check_flag); > 141: uncommit_locked(); `uncommit()` seems to be unused. src/hotspot/share/memory/metaspace/metachunk.hpp line 253: > 251: // commit granule size (in other words, we cannot uncommit chunks smaller than > 252: // a commit granule size). > 253: void uncommit(); `uncommit()` seems to be unused. src/hotspot/share/memory/metaspace/metaspaceArena.hpp line 114: > 112: > 113: // free block list > 114: FreeBlocks* fbl() const { return _fbl; } `fbl()` seems to be unused. src/hotspot/share/memory/metaspace/chunkManager.cpp line 349: > 347: c->uncommit_locked(); > 348: } > 349: } This seems redundant. To me it looks as if all chunks larger than `commit_granule_words()` are uncommited anyway when they are returned to the free list. What am I missing? Oh wait, I found a mail where you explained: > Arguably, (2) may be redundant since we uncommit chunks >= commit granule size > already before, when returning them to the ChunkManager (see > Chunkmanager::return_chunk_locked()). I left it in as a safeguard. You should explain this in the comment. I'd actually prefer only to assert that all blocks on the free list are uncommitted. src/hotspot/share/memory/metaspace/metaspaceReporter.cpp line 292: > 290: non_class_cm_stat.print_on(out, scale); > 291: out->cr(); > 292: } Unconditional line 272 and conditional lines 274, and 289 are identical. Looks like a bug (double accounting). src/hotspot/share/memory/metaspace/chunkManager.hpp line 102: > 100: > 101: // Uncommit all chunks equal or below the given level. > 102: void uncommit_free_chunks(chunklevel_t max_level); `uncommit_free_chunks(chunklevel_t max_level)` is declared but not defined. Should be removed. src/hotspot/share/memory/metaspace/chunklevel.hpp line 39: > 37: // Chunks are managed by a binary buddy allocator. > 38: > 39: // Chunk sizes range from 1K to 4MB (64bit). Also on 32 bit, right? I don't see a distinction. src/hotspot/share/memory/metaspace/commitMask.hpp line 123: > 121: // Mark a whole address range [start, end) as committed. > 122: // Return the number of words which had already been committed before this operation. > 123: size_t mark_range_as_committed(const MetaWord* start, size_t word_size) { The return value is not used. The statements to compute it should be removed. src/hotspot/share/memory/metaspace/commitMask.hpp line 139: > 137: // Mark a whole address range [start, end) as uncommitted. > 138: // Return the number of words which had already been uncommitted before this operation. > 139: size_t mark_range_as_uncommitted(const MetaWord* start, size_t word_size) { The return value is not used. The statements to compute it should be removed. src/hotspot/share/memory/metaspace/freeBlocks.hpp line 42: > 40: // Class FreeBlocks manages deallocated blocks in Metaspace. > 41: // > 42: // In Metaspace, allocated memory blocks may be release prematurely. This is Typo: release src/hotspot/share/memory/metaspace/freeChunkList.hpp line 69: > 67: // uncommitted or committed to at least one commit granule size). > 68: // - in all likelihood chunks, when added to this list, are either fully committed > 69: // or fully uncommitted (see Settings::uncommit_on_return_min_word_size()). `Settings::uncommit_on_return_min_word_size()` does not exist. src/hotspot/share/memory/metaspace/freeChunkList.hpp line 179: > 177: return NULL; > 178: } > 179: Seems to be unused. src/hotspot/share/memory/metaspace/freeChunkList.hpp line 63: > 61: // n committed words to satisfy the caller requested committed word size. We stop > 62: // searching at the first fully uncommitted chunk. > 63: // The comment is outdated, isn't it? src/hotspot/share/memory/metaspace/metachunk.hpp line 154: > 152: // This means only read or modify these members under expand lock protection. > 153: Metachunk* _prev_in_vs; > 154: Metachunk* _next_in_vs; I think the field `_next_in_vs` could be eliminated. The next chunk begins at the `end()` of this chunk. src/hotspot/share/memory/metaspace/metachunk.hpp line 243: > 241: > 242: bool ensure_fully_committed() { return ensure_committed(word_size()); } > 243: bool ensure_fully_committed_locked() { return ensure_committed_locked(word_size()); } `ensure_fully_committed()` and `ensure_fully_committed_locked()` seem to be unused. ------------- Changes requested by rrich (Committer). PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Tue Oct 6 06:58:45 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 06:58:45 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 15:34:54 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Review Feedback Richard 1 > > src/hotspot/share/memory/metaspace/binList.hpp line 135: > >> 133: i2++; >> 134: m >>= 1; >> 135: } > > I think you overlooked my proposal to make use of `count_trailing_zeros()` instead of this while-loop. Good point. Lets do this in a follow-up though. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From iklam at openjdk.java.net Tue Oct 6 06:59:41 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Oct 2020 06:59:41 GMT Subject: RFR: 8253909: Implement detailed map file for CDS [v2] In-Reply-To: References: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> Message-ID: On Tue, 6 Oct 2020 06:44:54 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback from Thomas Stuefe > > src/hotspot/share/runtime/os.hpp line 693: > >> 691: static void print_hex_dump(outputStream* st, address start, address end, int unitsize) { >> 692: print_hex_dump(st, start, end, unitsize, /*bytes_per_line=*/16, /*logical_start=*/start); >> 693: } > > This is a bit unclear. Could we do it like this instead: > > // Print a hex dump from [start .. end). Output lines are prefixed with addresses. > static void print_hex_dump(outputStream* st, address start, address end, int unitsize) > > > // Print a hex dump from [base+start .. base+end). Output lines are prefixed with offset in relation to base. > static void print_hex_dump(outputStream* st, address base, intx start, intx end, int unitsize) But this is not what I want. I am calling with parameters like: print_hex_dump(st, /*start=*/0x7ffff0000, end, unitsize, bytes_per_line, /*logical_start=*/0x800000000); So my buffer is at some random address, but I want the print out to pretend that it started at 0x800000000. ------------- PR: https://git.openjdk.java.net/jdk/pull/474 From stuefe at openjdk.java.net Tue Oct 6 07:03:47 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 07:03:47 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: <5eZv8D9bqgHWrLPSQ0JDRffb7kSACeFeHRu1G4UO_UE=.00612fea-7d63-4ff2-9f8b-4a08e3cdc766@github.com> On Mon, 5 Oct 2020 16:04:16 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Review Feedback Richard 1 > > src/hotspot/share/memory/metaspace/metaspaceArena.cpp line 81: > >> 79: METACHUNK_FULL_FORMAT_ARGS(c)); >> 80: } >> 81: } > > Have you thought about splitting the chunk if possible and returning the free chunk to the ChunkManager? If you return > it to the free list of this class loader then only this loader can make use of it. If you return it to the CM then > every loader can make use of it and, potentially, it can even be uncommitted. Yes, but in practice, the benefit would be slim: - it is very rare that you retire a chunk which is not even halfway used. For that to happen a metaspace allocation must be requested larger than half of the current chunk. Does not happen that often. - This only affects the committed portion of the chunk. So, for larger chunks - where this could hurt - the waste (waste in the sense as "unnecessarily earmarked for one loader only") mostly consists of address space only, not committed space. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From david.holmes at oracle.com Tue Oct 6 07:10:22 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Oct 2020 17:10:22 +1000 Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> <7pAVBmJQ5-g7wIvO402eFQprNmW90yCFR5scfw_esYQ=.172e1eae-f8bd-4c41-bf58-bc38499d5e8c@github.com> Message-ID: <4e77fe12-5d96-dd73-3813-9b61e117c27a@oracle.com> On 6/10/2020 4:06 pm, Thomas Stuefe wrote: > On Tue, 6 Oct 2020 01:52:21 GMT, David Holmes wrote: > >>> Note that these changes are not important enough to rerun testing for this cleanup, so you can make it a new RFE. >>> Thank you for doing consolidation! >> >> In reply to Coleen's query - SR_signum is referenced from the os_*.cpp files so needs to be in the header file now. > > I wondered why this is not const then I saw that it can be overwritten with an environment variable "_JAVA_SR_SIGNUM". > Is this still needed? Seems to be an odd way of specifying a VM parameter. And it seems to be untested (I did not find > any tests for that in the open codebase). Yes this is still needed to allow apps that use SIGUSR2 themselves to set a different signal for suspend/resume. Does anyone use this? I've no idea. But not a reason to remove functionality. I'd have to do some archaeology to see why its set via an env var. But you are right that it isn't tested - though the code is pretty straight-forward. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/497 > From dholmes at openjdk.java.net Tue Oct 6 07:32:41 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Oct 2020 07:32:41 GMT Subject: RFR: 8253889: Remove ExecMem constant In-Reply-To: References: Message-ID: On Sat, 3 Oct 2020 05:30:54 GMT, Thomas Stuefe wrote: >>> Maybe it did something in the past. Now it just seems to be a complicated way to say "false". >> >> I think that's a Hotspot style. There are few other places where "symbolic values" for boolean parameters are used. For >> example, `CodeBlobToOopClosure::FixRelocations`. `grep 'static const bool'` identify a few more. I personally find it a >> tad more readable. So, it is not as useless... > >> > Maybe it did something in the past. Now it just seems to be a complicated way to say "false". >> >> I think that's a Hotspot style. There are few other places where "symbolic values" for boolean parameters are used. For >> example, `CodeBlobToOopClosure::FixRelocations`. `grep 'static const bool'` identify a few more. I personally find it a >> tad more readable. So, it is not as useless... > > Well in that case it is applied very inconsistently since most call sites just use false. Lets see if anyone else has > an opinion on this. It is a way of documenting the boolean more clearly. This example was introduced by JDK-8013057. In the RFR: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-June/007617.html Dan writes: > As a secondary change, while visiting all os::commit_memory() calls, I also updated them to use the new ExecMem enum in > order to make the executable status of the memory more clear. Since executable memory can be an attack vector, it is > prudent to make the executable status of memory crystal clear. This also allowed me to remove the default executable > flag value of 'false'. Now all new uses of commit_memory() must be clear about the executable status of the memory. So IMO this is not something that needs changing. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/454 From rrich at openjdk.java.net Tue Oct 6 08:11:45 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Oct 2020 08:11:45 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 06:55:40 GMT, Thomas Stuefe wrote: >> src/hotspot/share/memory/metaspace/binList.hpp line 135: >> >>> 133: i2++; >>> 134: m >>= 1; >>> 135: } >> >> I think you overlooked my proposal to make use of `count_trailing_zeros()` instead of this while-loop. > > Good point. Lets do this in a follow-up though. Honestly, without this the optimization is questionable. Iterating the bits in `_mask` is like iterating the list heads. `is_empty()` can be easily optimized with a counter, but even this is questionable. The change is tiny and easy to test: just leave the while-loop as an assertion and run some class redefinition tests then remove the loop. I'd object postponing it. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From sgehwolf at openjdk.java.net Tue Oct 6 08:34:42 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 6 Oct 2020 08:34:42 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v3] In-Reply-To: References: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com> Message-ID: <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com> On Mon, 5 Oct 2020 19:22:04 GMT, Bob Vandette wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in comment > > src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 150: > >> 148: // find anyway in that case. >> 149: try (Stream mntInfo = CgroupUtil.readFilePrivileged(Paths.get(mountInfo))) { >> 150: boolean anyCgroupMounted = mntInfo.anyMatch(CgroupSubsystemFactory::noSystemdCgroupLine); > > I'd prefer a similar approach to the hotspot side where you do a positive check for controllers we are interested in > rather than a negative check for systemd. OK. I'll probably fold JDK-8254001 into this one then. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From ysuenaga at openjdk.java.net Tue Oct 6 09:30:43 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 6 Oct 2020 09:30:43 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: On Tue, 6 Oct 2020 05:52:51 GMT, Thomas Stuefe wrote: >> This is a fresh start for https://github.com/openjdk/jdk/pull/157 >> >> Please review this change that refactors common POSIX code into a separate >> file. >> >> Currently there appears to be quite a bit of duplicated code among POSIX >> platforms, which makes it difficult to apply single fix to the signal code. >> With this fix, we will only need to touch single file for common POSIX >> code fixes from now on. >> >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` >> `$ git checkout pull/497` > > src/hotspot/os/posix/signals_posix.cpp line 454: > >> 452: void* ucontext, >> 453: int abort_if_unrecognized); >> 454: #endif > > Future cleanup: I think it will be difficult to unify the platform specific signal handlers (but worthwhile). But the > naming could be at least the same, no reason to have the platform in the name. I agree with @tstuefe . Can we rename them to `JVM_handle_posix_signal` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From ysuenaga at openjdk.java.net Tue Oct 6 09:30:44 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 6 Oct 2020 09:30:44 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: On Sat, 3 Oct 2020 17:12:30 GMT, Gerard Ziemski wrote: > This is a fresh start for https://github.com/openjdk/jdk/pull/157 > > Please review this change that refactors common POSIX code into a separate > file. > > Currently there appears to be quite a bit of duplicated code among POSIX > platforms, which makes it difficult to apply single fix to the signal code. > With this fix, we will only need to touch single file for common POSIX > code fixes from now on. > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > > > ### Download > `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` > `$ git checkout pull/497` src/hotspot/os/posix/signals_posix.cpp line 688: > 686: tty->print(" found:"); > 687: print_sa_flags(tty, act.sa_flags); > 688: tty->cr(); Can we use unified logging at here? If do so, we should out them with single line. src/hotspot/os/posix/signals_posix.cpp line 271: > 269: void PosixSignals::jdk_misc_signal_init() { > 270: // Initialize signal structures > 271: ::memset((void*)pending_signals, 0, sizeof(pending_signals)); Is this code needed? `pending_signals` is initialized with `{ 0 }` and also `jdk_misc_signal_init()` would be called from `os::init_2()` . ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From thomas.stuefe at gmail.com Tue Oct 6 10:00:46 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 6 Oct 2020 12:00:46 +0200 Subject: RFR: 8253889: Remove ExecMem constant In-Reply-To: References: Message-ID: Thank you David! I will remove the PR. On Tue, Oct 6, 2020 at 9:35 AM David Holmes wrote: > On Sat, 3 Oct 2020 05:30:54 GMT, Thomas Stuefe wrote: > > >>> Maybe it did something in the past. Now it just seems to be a > complicated way to say "false". > >> > >> I think that's a Hotspot style. There are few other places where > "symbolic values" for boolean parameters are used. For > >> example, `CodeBlobToOopClosure::FixRelocations`. `grep 'static const > bool'` identify a few more. I personally find it a > >> tad more readable. So, it is not as useless... > > > >> > Maybe it did something in the past. Now it just seems to be a > complicated way to say "false". > >> > >> I think that's a Hotspot style. There are few other places where > "symbolic values" for boolean parameters are used. For > >> example, `CodeBlobToOopClosure::FixRelocations`. `grep 'static const > bool'` identify a few more. I personally find it a > >> tad more readable. So, it is not as useless... > > > > Well in that case it is applied very inconsistently since most call > sites just use false. Lets see if anyone else has > > an opinion on this. > > It is a way of documenting the boolean more clearly. This example was > introduced by JDK-8013057. In the RFR: > > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-June/007617.html > > Dan writes: > > > As a secondary change, while visiting all os::commit_memory() calls, I > also updated them to use the new ExecMem enum in > > order to make the executable status of the memory more clear. Since > executable memory can be an attack vector, it is > > prudent to make the executable status of memory crystal clear. This also > allowed me to remove the default executable > > flag value of 'false'. Now all new uses of commit_memory() must be clear > about the executable status of the memory. > > So IMO this is not something that needs changing. > > Thanks, > David > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/454 > From stuefe at openjdk.java.net Tue Oct 6 10:05:40 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 10:05:40 GMT Subject: Withdrawn: 8253889: Remove ExecMem constant In-Reply-To: References: Message-ID: <9mGR9OIOIok86Fn5QcERAF6WavuRCMrVltPmmC5iUB8=.f54ce516-1802-48b1-8399-a9aff6b1c393@github.com> On Thu, 1 Oct 2020 09:22:53 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews please for this trivial cleanup. > > ExecMem is defined in os.hpp as: > > // Executable parameter flag for os::commit_memory() and > // os::commit_memory_or_exit(). > const bool ExecMem = true; > > and only ever used as "!ExecMem" parameter value to the "executable" argument in calls to os::commit_memory(). > > Maybe it did something in the past. Now it just seems to be a complicated way to say "false". This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/454 From stuefe at openjdk.java.net Tue Oct 6 11:09:45 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 11:09:45 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 19:20:02 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Review Feedback Richard 1 > > src/hotspot/share/memory/metaspace/counters.hpp line 108: > >> 106: assert(old >= 1, >> 107: "underflow (" UINT64_FORMAT "-1)", (uint64_t)old); >> 108: #endif > > The assertion is incorrect because it is not atomic wrt the actual update. I commented on this before. It should be > fairly easy to write a multi-thread gtest that produces false positives of the assertion (if it is easy to write a > multi-threaded gtest). The person affected by a false positive crash will be not too amused. I suggest to fix or remove > the assertion. Okay, I feel stupid now but I do not see it. I see the non-atomicity, but not how it could cause a false positive assert here. I see that I could miss an assert, but not the other way around. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Tue Oct 6 11:51:45 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 11:51:45 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: <5eZv8D9bqgHWrLPSQ0JDRffb7kSACeFeHRu1G4UO_UE=.00612fea-7d63-4ff2-9f8b-4a08e3cdc766@github.com> References: <5eZv8D9bqgHWrLPSQ0JDRffb7kSACeFeHRu1G4UO_UE=.00612fea-7d63-4ff2-9f8b-4a08e3cdc766@github.com> Message-ID: On Tue, 6 Oct 2020 07:00:51 GMT, Thomas Stuefe wrote: >> src/hotspot/share/memory/metaspace/metaspaceArena.cpp line 81: >> >>> 79: METACHUNK_FULL_FORMAT_ARGS(c)); >>> 80: } >>> 81: } >> >> Have you thought about splitting the chunk if possible and returning the free chunk to the ChunkManager? If you return >> it to the free list of this class loader then only this loader can make use of it. If you return it to the CM then >> every loader can make use of it and, potentially, it can even be uncommitted. > > Yes, but in practice, the benefit would be slim: > - it is very rare that you retire a chunk which is not even halfway used. For that to happen a metaspace allocation must > be requested larger than half of the current chunk. Does not happen that often. > - This only affects the committed portion of the chunk. So, for larger chunks - where this could hurt - the waste (waste > in the sense as "unnecessarily earmarked for one loader only") mostly consists of address space only, not committed > space. > > I'll still consider it. Albert Yang remarked something similar in an earlier review: > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041357.html > Thing is, returning a chunk to the ChunkManager would require drawing the central context lock. Right now, > salvage_chunk() does only need the CLD-local lock. But then, if it is rare as I wrote initially, it may not matter. > Lets file this for a possible future RFE. Okay, I did some statistics and salvaging chunks which are not at least half-way used is super rare. I opt in this case for just leaving the code as it is since splitting the salvaged chunk would mean complicating the code, apart from drawing the central metaspace context lock. >> src/hotspot/share/memory/metaspace/counters.hpp line 108: >> >>> 106: assert(old >= 1, >>> 107: "underflow (" UINT64_FORMAT "-1)", (uint64_t)old); >>> 108: #endif >> >> The assertion is incorrect because it is not atomic wrt the actual update. I commented on this before. It should be >> fairly easy to write a multi-thread gtest that produces false positives of the assertion (if it is easy to write a >> multi-threaded gtest). The person affected by a false positive crash will be not too amused. I suggest to fix or remove >> the assertion. > > Okay, I feel stupid now but I do not see it. > > I see the non-atomicity, but not how it could cause a false positive assert here. I see that I could miss an assert, > but not the other way around. I will remove the asserts. These classes are scheduled to become general utility classes anyway in a followup RFE, so they will be revisited soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Tue Oct 6 11:51:44 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 11:51:44 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 08:09:23 GMT, Richard Reingruber wrote: >> Good point. Lets do this in a follow-up though. > > Honestly, without this the optimization is questionable. Iterating the bits in `_mask` is like iterating the list > heads. `is_empty()` can be easily optimized with a counter, but even this is questionable. The change is tiny and easy > to test: just leave the while-loop as an assertion and run some class redefinition tests then remove the loop. I'd > object postponing it. Okay. I had my doubt about this optimization too, as had Leo. I'll just scrap it altogether, this will make the code more readable too. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Tue Oct 6 12:07:46 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 12:07:46 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: <191IhQ2nrOX2Zd9Y1HE4QMrGJL-Zd8ic4MrJIZ49g7g=.ac3eeb89-df5e-4a05-ba1b-88fa5cf60b13@github.com> On Mon, 5 Oct 2020 20:39:28 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Review Feedback Richard 1 > > src/hotspot/share/memory/metaspace/metachunk.cpp line 141: > >> 139: void Metachunk::uncommit() { >> 140: MutexLocker cl(MetaspaceExpand_lock, Mutex::_no_safepoint_check_flag); >> 141: uncommit_locked(); > > `uncommit()` seems to be unused. It is used in a number of gtests. I'd prefer to keep it since otherwise I would have to lock manually each time there, and also because of symmetry with other functions. > src/hotspot/share/memory/metaspace/freeChunkList.hpp line 69: > >> 67: // uncommitted or committed to at least one commit granule size). >> 68: // - in all likelihood chunks, when added to this list, are either fully committed >> 69: // or fully uncommitted (see Settings::uncommit_on_return_min_word_size()). > > `Settings::uncommit_on_return_min_word_size()` does not exist. Leftover. Will remove the reference. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Tue Oct 6 12:18:47 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 12:18:47 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 22:41:09 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Review Feedback Richard 1 > > src/hotspot/share/memory/metaspace/freeChunkList.hpp line 63: > >> 61: // n committed words to satisfy the caller requested committed word size. We stop >> 62: // searching at the first fully uncommitted chunk. >> 63: // > > The comment is outdated, isn't it? No, this is still valid, see FreeChunkListVector::search_chunk_ascending/desdending. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Tue Oct 6 12:22:47 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 12:22:47 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 23:23:57 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Review Feedback Richard 1 > > src/hotspot/share/memory/metaspace/metachunk.hpp line 154: > >> 152: // This means only read or modify these members under expand lock protection. >> 153: Metachunk* _prev_in_vs; >> 154: Metachunk* _next_in_vs; > > I think the field `_next_in_vs` could be eliminated. The next chunk begins at the `end()` of this chunk. The idea is good, but at the moment _next_in_vs==NULL marks the last chunk within one root chunk area, and is used e.g. as loop stop. I would have to make Metachunk aware of the root chunk it lives in, which I rather avoid. > src/hotspot/share/memory/metaspace/metachunk.hpp line 243: > >> 241: >> 242: bool ensure_fully_committed() { return ensure_committed(word_size()); } >> 243: bool ensure_fully_committed_locked() { return ensure_committed_locked(word_size()); } > > `ensure_fully_committed()` and `ensure_fully_committed_locked()` seem to be unused. Okay will remove. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Tue Oct 6 12:50:35 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 12:50:35 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v12] In-Reply-To: References: Message-ID: > Hi all, > > this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the > delay, had vacation then the entrance of Skara delayed things a bit. > For the delta diff please see [3]. > > This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all > feedback individually in this PR body, but I incorporated almost all into the new revision. > What changed since the last version: > > - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the > group consent. > > - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for > overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth > class loader which made it rather pointless. Now I run it always. > > - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. > > - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) > > Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. > > - In ChunkManager::purge() I improved the comments after discussions with Leo. > > - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due > to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run > every time. > > - Fixed indentation issues as Leo requested > > - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested > > - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes > and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more > flexible since it allows us to have list with purge-able and non-purge-able nodes. > > - and various smaller fixes, mainly on request of Leo. > > @lkorinth: > >> VirtualSpaceNode.hpp >> >>102 // Start pointer of the area. >>103 MetaWord* const _base; >> >>How does this differ from _rs._base? Really needed? >> >>105 // Size, in words, of the whole node >>106 const size_t _word_size; >> >>Can we not calculate this from _rs.size()? > > You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it > is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly > improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at > some point and make those members const - as they should be - then I would rewrite this as you suggest. > Thanks, again, for all your review work! > > ------ > > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html > [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: - Review Feedback Richard 2 - Fix 32bit build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/336/files - new: https://git.openjdk.java.net/jdk/pull/336/files/128c494d..eacafe49 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=10-11 Stats: 61 lines in 5 files changed: 0 ins; 52 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/336/head:pull/336 PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Tue Oct 6 13:01:05 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 6 Oct 2020 13:01:05 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 12:16:10 GMT, Thomas Stuefe wrote: >> src/hotspot/share/memory/metaspace/freeChunkList.hpp line 63: >> >>> 61: // n committed words to satisfy the caller requested committed word size. We stop >>> 62: // searching at the first fully uncommitted chunk. >>> 63: // >> >> The comment is outdated, isn't it? > > No, this is still valid, see FreeChunkListVector::search_chunk_ascending/desdending. No wait, the last sentence is outdated. Will fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From rrich at openjdk.java.net Tue Oct 6 13:17:18 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Oct 2020 13:17:18 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 13:38:03 GMT, Thomas Stuefe wrote: >> Hi all, >> >> this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the >> delay, had vacation then the entrance of Skara delayed things a bit. >> For the delta diff please see [3]. >> >> This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all >> feedback individually in this PR body, but I incorporated almost all into the new revision. >> What changed since the last version: >> >> - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the >> group consent. >> >> - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for >> overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth >> class loader which made it rather pointless. Now I run it always. >> >> - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. >> >> - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) >> >> Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. >> >> - In ChunkManager::purge() I improved the comments after discussions with Leo. >> >> - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due >> to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run >> every time. >> >> - Fixed indentation issues as Leo requested >> >> - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested >> >> - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes >> and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more >> flexible since it allows us to have list with purge-able and non-purge-able nodes. >> >> - and various smaller fixes, mainly on request of Leo. >> >> @lkorinth: >> >>> VirtualSpaceNode.hpp >>> >>>102 // Start pointer of the area. >>>103 MetaWord* const _base; >>> >>>How does this differ from _rs._base? Really needed? >>> >>>105 // Size, in words, of the whole node >>>106 const size_t _word_size; >>> >>>Can we not calculate this from _rs.size()? >> >> You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it >> is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly >> improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at >> some point and make those members const - as they should be - then I would rewrite this as you suggest. >> Thanks, again, for all your review work! >> >> ------ >> >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html >> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html >> [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Review Feedback Richard 1 Hi Thomas, this is batch 3 with another 3 points. I'm sending it now because I think I cannot reply to your comments otherwise. Cheers, Richard. src/hotspot/share/memory/metaspace/metaspaceSettings.hpp line 45: > 43: // The default size of a non-class VirtualSpaceNode (unless created differently). > 44: // Must be a multiple of the root chunk size. > 45: static const size_t VirtualSpaceNodeDefaultWordSize = chunklevel::MAX_CHUNK_WORD_SIZE * 2; // lets go with 8mb > virt size. Seems a good compromise betw. virt and mapping fragmentation. Member name do not match convention. See doc/hotspot-style.md:206: `VirtualSpaceNodeDefaultWordSize` `VirtualSpaceNodeReserveAlignmentWordSize` `EnlargeChunksInPlace` src/hotspot/share/memory/metaspace/metaspaceArena.cpp line 239: > 237: UL2(trace, "taken from fbl (now: %d, " SIZE_FORMAT ").", > 238: _fbl->count(), _fbl->total_size()); > 239: // Note: Space in the freeblock dictionary counts as already used (see retire_current_chunk()) - `retire_current_chunk()` does not exist. src/hotspot/share/memory/metaspace/metaspaceArena.cpp line 465: > 463: assert(p != NULL && word_size > 0, "Sanity"); > 464: bool found = false; > 465: if (!found) { The if is redundant. The condition is always true. ------------- Changes requested by rrich (Committer). PR: https://git.openjdk.java.net/jdk/pull/336 From rrich at openjdk.java.net Tue Oct 6 13:17:18 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Oct 2020 13:17:18 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: <5eZv8D9bqgHWrLPSQ0JDRffb7kSACeFeHRu1G4UO_UE=.00612fea-7d63-4ff2-9f8b-4a08e3cdc766@github.com> Message-ID: On Tue, 6 Oct 2020 11:47:22 GMT, Thomas Stuefe wrote: >> Yes, but in practice, the benefit would be slim: >> - it is very rare that you retire a chunk which is not even halfway used. For that to happen a metaspace allocation must >> be requested larger than half of the current chunk. Does not happen that often. >> - This only affects the committed portion of the chunk. So, for larger chunks - where this could hurt - the waste (waste >> in the sense as "unnecessarily earmarked for one loader only") mostly consists of address space only, not committed >> space. >> >> I'll still consider it. Albert Yang remarked something similar in an earlier review: >> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041357.html >> Thing is, returning a chunk to the ChunkManager would require drawing the central context lock. Right now, >> salvage_chunk() does only need the CLD-local lock. But then, if it is rare as I wrote initially, it may not matter. >> Lets file this for a possible future RFE. > > Okay, I did some statistics and salvaging chunks which are not at least half-way used is super rare. I opt in this case > for just leaving the code as it is since splitting the salvaged chunk would mean complicating the code, apart from > drawing the central metaspace context lock. Ok. Thanks for doing it. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From rrich at openjdk.java.net Tue Oct 6 13:40:15 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Oct 2020 13:40:15 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: <5eZv8D9bqgHWrLPSQ0JDRffb7kSACeFeHRu1G4UO_UE=.00612fea-7d63-4ff2-9f8b-4a08e3cdc766@github.com> Message-ID: On Tue, 6 Oct 2020 11:48:29 GMT, Thomas Stuefe wrote: >> Okay, I feel stupid now but I do not see it. >> >> I see the non-atomicity, but not how it could cause a false positive assert here. I see that I could miss an assert, >> but not the other way around. > > I will remove the asserts. These classes are scheduled to become general utility classes anyway in a followup RFE, so > they will be revisited soon. It is not as clear as I though. So no need at all to feel stupid. > I will remove the asserts. These classes are scheduled to become general utility classes anyway in a followup RFE, so > they will be revisited soon. I'm ok with that. For the sake of completeness: I'd still think false positives are possible. Please look at the following example: ` 1 _initialized = 0; 2 _c = 0; 3 4 Thread A Thread B 5 6 Atomic::inc(&_c) 7 8 9 10 _initialized = 1; 11 12 while(_initialized == 0) busy_wait(); 13 14 T old = Atomic::load_acquire(&_c); 15 16 assert(old >= 1, "underflow (" UINT64_FORMAT "-1)", (uint64_t)old); 17 18 19 20 Atomic::dec(&_c); ` Loading `old` at line 14 can be done speculatively before the loop, for instance at line 5. There is no barrier that would prevent this. `Atomic::inc` and `Atomic::dec` both have a `` before and a `` after the operation. Because of the effect of the `` in line 18 the `dec()` in line 20 cannot be done before the while in line 12. An underflow is not possible. The assertion can fail though. So probably you could fix the assertion by adding a fence before the load of the `old` value. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From rrich at openjdk.java.net Tue Oct 6 13:40:16 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Oct 2020 13:40:16 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: <191IhQ2nrOX2Zd9Y1HE4QMrGJL-Zd8ic4MrJIZ49g7g=.ac3eeb89-df5e-4a05-ba1b-88fa5cf60b13@github.com> References: <191IhQ2nrOX2Zd9Y1HE4QMrGJL-Zd8ic4MrJIZ49g7g=.ac3eeb89-df5e-4a05-ba1b-88fa5cf60b13@github.com> Message-ID: On Tue, 6 Oct 2020 12:03:34 GMT, Thomas Stuefe wrote: >> src/hotspot/share/memory/metaspace/metachunk.cpp line 141: >> >>> 139: void Metachunk::uncommit() { >>> 140: MutexLocker cl(MetaspaceExpand_lock, Mutex::_no_safepoint_check_flag); >>> 141: uncommit_locked(); >> >> `uncommit()` seems to be unused. > > It is used in a number of gtests. I'd prefer to keep it since otherwise I would have to lock manually each time there, > and also because of symmetry with other functions. Ok, I see. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From dcubed at openjdk.java.net Tue Oct 6 13:56:13 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 6 Oct 2020 13:56:13 GMT Subject: RFR: 8253889: Remove ExecMem constant In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 07:30:25 GMT, David Holmes wrote: >>> > Maybe it did something in the past. Now it just seems to be a complicated way to say "false". >>> >>> I think that's a Hotspot style. There are few other places where "symbolic values" for boolean parameters are used. For >>> example, `CodeBlobToOopClosure::FixRelocations`. `grep 'static const bool'` identify a few more. I personally find it a >>> tad more readable. So, it is not as useless... >> >> Well in that case it is applied very inconsistently since most call sites just use false. Lets see if anyone else has >> an opinion on this. > > It is a way of documenting the boolean more clearly. This example was introduced by JDK-8013057. In the RFR: > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-June/007617.html > > Dan writes: > >> As a secondary change, while visiting all os::commit_memory() calls, I also updated them to use the new ExecMem enum in >> order to make the executable status of the memory more clear. Since executable memory can be an attack vector, it is >> prudent to make the executable status of memory crystal clear. This also allowed me to remove the default executable >> flag value of 'false'. Now all new uses of commit_memory() must be clear about the executable status of the memory. > > So IMO this is not something that needs changing. > > Thanks, > David @dholmes-ora - Thanks for digging up that piece of history! ------------- PR: https://git.openjdk.java.net/jdk/pull/454 From rrich at openjdk.java.net Tue Oct 6 13:57:15 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Oct 2020 13:57:15 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 12:58:25 GMT, Thomas Stuefe wrote: > > > No wait, the last sentence is outdated. Will fix. It is not just the last sentence. > > > No, this is still valid, see FreeChunkListVector::search_chunk_ascending/desdending. These methods look at the first chunk of every list. No list is searched. But it's good. I don't want to be too badly pedantic. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From rrich at openjdk.java.net Tue Oct 6 13:57:16 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 6 Oct 2020 13:57:16 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 12:19:25 GMT, Thomas Stuefe wrote: >> src/hotspot/share/memory/metaspace/metachunk.hpp line 154: >> >>> 152: // This means only read or modify these members under expand lock protection. >>> 153: Metachunk* _prev_in_vs; >>> 154: Metachunk* _next_in_vs; >> >> I think the field `_next_in_vs` could be eliminated. The next chunk begins at the `end()` of this chunk. > > The idea is good, but at the moment _next_in_vs==NULL marks the last chunk within one root chunk area, and is used e.g. > as loop stop. I would have to make Metachunk aware of the root chunk it lives in, which I rather avoid. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From pchilanomate at openjdk.java.net Tue Oct 6 14:52:08 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 6 Oct 2020 14:52:08 GMT Subject: Integrated: 8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() In-Reply-To: References: Message-ID: <4jSWgxAVck9hLarTs08AWrtVS4lqHY0dbkGEUAYyKp8=.28f3bf1b-aa3e-45f4-86d6-b0289b6fde82@github.com> On Mon, 28 Sep 2020 06:07:58 GMT, Patricio Chilano Mateo wrote: > Hi all, > > Please review the following patch. Current ThreadCrashProtection() implementation uses static members which requires > the use of Thread::muxAcquire() to allow only one user at a time. We can avoid this synchronization requirement if each > thread has its own ThreadCrashProtection *data. I tested it builds on Linux, macOS and Windows. Since the > JfrThreadSampler is the only one using this I run all the tests from test/jdk/jdk/jfr/. I also run some tests with JFR > enabled while forcing a crash in OSThreadSampler::protected_task() and tests passed with several "Thread method sampler > crashed" UL output. Also run tiers1-3. Thanks, Patricio This pull request has now been integrated. Changeset: 57493c19 Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/57493c19 Stats: 26 lines in 6 files changed: 6 ins; 18 del; 2 mod 8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() Reviewed-by: dholmes, dcubed, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/376 From gziemski at openjdk.java.net Tue Oct 6 15:42:10 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 6 Oct 2020 15:42:10 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> <7pAVBmJQ5-g7wIvO402eFQprNmW90yCFR5scfw_esYQ=.172e1eae-f8bd-4c41-bf58-bc38499d5e8c@github.com> Message-ID: <7RJZglbhdm7ewDB4U36cHyQB2tisSm5zjzp_Y8xKe4A=.373b95bf-734e-4cf3-a134-deb8347d3071@github.com> On Tue, 6 Oct 2020 05:39:31 GMT, Thomas Stuefe wrote: >> src/hotspot/os/aix/os_aix.cpp line 1459: >> >>> 1457: // that will interfere with OOM killling. >>> 1458: PosixSignals::print_signal_handler(st, SIGDANGER, buf, buflen); >>> 1459: } >> >> I wonder with some #ifdefs, this could also be moved to posix_signals.cpp. Not for this change but maybe a follow-up >> RFE. > > Yes, this os::print_signal_handlers() and os::print_signal_handler() could be unified across Posix platforms. At least > the latter. > (Personally I also would like to print all signal handlers from 1.., regardless of whether its > one of "us". E.g. if process overrides SIGCHILD that is interesting too.) Will be addressed in https://bugs.openjdk.java.net/browse/JDK-8253742 ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From gziemski at openjdk.java.net Tue Oct 6 15:42:12 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 6 Oct 2020 15:42:12 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: On Tue, 6 Oct 2020 05:43:49 GMT, Thomas Stuefe wrote: >> This is a fresh start for https://github.com/openjdk/jdk/pull/157 >> >> Please review this change that refactors common POSIX code into a separate >> file. >> >> Currently there appears to be quite a bit of duplicated code among POSIX >> platforms, which makes it difficult to apply single fix to the signal code. >> With this fix, we will only need to touch single file for common POSIX >> code fixes from now on. >> >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` >> `$ git checkout pull/497` > > src/hotspot/os/bsd/os_bsd.cpp line 2285: > >> 2283: >> 2284: void os::SuspendedThreadTask::internal_do_task() { >> 2285: if (PosixSignals::do_suspend(_thread->osthread())) { > > Future RFE: os::SuspendedThreadTask::internal_do_task() can be unified across posix platforms. Will be addressed in https://bugs.openjdk.java.net/browse/JDK-8253742 > src/hotspot/os/bsd/os_bsd.cpp line 2152: > >> 2150: if (!ReduceSignalUsage) { >> 2151: PosixSignals::jdk_misc_signal_init(); >> 2152: } > > This whole section could be unified too into an own PosixSignals::initial_signal_stuff() function. Potentially for a > future RFE. Will be addressed in https://bugs.openjdk.java.net/browse/JDK-8253742 ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From gziemski at openjdk.java.net Tue Oct 6 15:42:12 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 6 Oct 2020 15:42:12 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: On Tue, 6 Oct 2020 09:16:59 GMT, Yasumasa Suenaga wrote: >> src/hotspot/os/posix/signals_posix.cpp line 454: >> >>> 452: void* ucontext, >>> 453: int abort_if_unrecognized); >>> 454: #endif >> >> Future cleanup: I think it will be difficult to unify the platform specific signal handlers (but worthwhile). But the >> naming could be at least the same, no reason to have the platform in the name. > > I agree with @tstuefe . Can we rename them to `JVM_handle_posix_signal` ? Will be addressed in https://bugs.openjdk.java.net/browse/JDK-8253742 ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From gziemski at openjdk.java.net Tue Oct 6 15:42:13 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 6 Oct 2020 15:42:13 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: On Tue, 6 Oct 2020 09:18:49 GMT, Yasumasa Suenaga wrote: >> This is a fresh start for https://github.com/openjdk/jdk/pull/157 >> >> Please review this change that refactors common POSIX code into a separate >> file. >> >> Currently there appears to be quite a bit of duplicated code among POSIX >> platforms, which makes it difficult to apply single fix to the signal code. >> With this fix, we will only need to touch single file for common POSIX >> code fixes from now on. >> >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` >> `$ git checkout pull/497` > > src/hotspot/os/posix/signals_posix.cpp line 688: > >> 686: tty->print(" found:"); >> 687: print_sa_flags(tty, act.sa_flags); >> 688: tty->cr(); > > Can we use unified logging at here? If do so, we should out them with single line. Will be addressed in https://bugs.openjdk.java.net/browse/JDK-8253742 > src/hotspot/os/posix/signals_posix.cpp line 271: > >> 269: void PosixSignals::jdk_misc_signal_init() { >> 270: // Initialize signal structures >> 271: ::memset((void*)pending_signals, 0, sizeof(pending_signals)); > > Is this code needed? `pending_signals` is initialized with `{ 0 }` and also `jdk_misc_signal_init()` would be called > from `os::init_2()` . Will be addressed in https://bugs.openjdk.java.net/browse/JDK-8253742 ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From gziemski at openjdk.java.net Tue Oct 6 15:51:09 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 6 Oct 2020 15:51:09 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: <_cZGP32A32FFLVeIv3ubPV9zhGMUekX77PiaQFngmdU=.fc5e9ce1-d223-4bdf-abef-d50ead80d379@github.com> On Tue, 6 Oct 2020 06:03:37 GMT, Thomas Stuefe wrote: >> This is a fresh start for https://github.com/openjdk/jdk/pull/157 >> >> Please review this change that refactors common POSIX code into a separate >> file. >> >> Currently there appears to be quite a bit of duplicated code among POSIX >> platforms, which makes it difficult to apply single fix to the signal code. >> With this fix, we will only need to touch single file for common POSIX >> code fixes from now on. >> >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` >> `$ git checkout pull/497` > > Looks good to me. All remarks are just proposals for follow ups. Our nightly tests on AIX went through with the current > version of the patch. Ship it. Thanks for your work! Thank you all very much for your feedback and suggestions. I explicitly did not to put any fixes in this PR, as it was only about refactoring the existing code and I think everyone understands that. Any non-trivial suggestions, many of which I wanted to see fixed myself while working on this refactoring, will be addressed in https://bugs.openjdk.java.net/browse/JDK-8253742 In this, hopefully last commit, I will implement 2 trivial changes: - David's request to delete comment on 4528190 - Thomas' request to delete empty lines which hopefully means that Thomas does not need to spin yet another test at SAP. > src/hotspot/os/posix/signals_posix.cpp line 104: > >> 102: static const struct { >> 103: int sig; const char* name; >> 104: } > > Please remove newlines. This is one declaration: > > static const struct { > ,, > } g_signal_info[] = { Fixed, will commit shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From gziemski at openjdk.java.net Tue Oct 6 15:51:09 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 6 Oct 2020 15:51:09 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: <5lDxPFHbSWr4Hfz7zPz8KWjdQS4WLlpnmCjVTNjv_gA=.73ad62a2-c9d9-456f-abf4-52949b0813cb@github.com> References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> <5lDxPFHbSWr4Hfz7zPz8KWjdQS4WLlpnmCjVTNjv_gA=.73ad62a2-c9d9-456f-abf4-52949b0813cb@github.com> Message-ID: On Tue, 6 Oct 2020 01:44:11 GMT, David Holmes wrote: >> This is a fresh start for https://github.com/openjdk/jdk/pull/157 >> >> Please review this change that refactors common POSIX code into a separate >> file. >> >> Currently there appears to be quite a bit of duplicated code among POSIX >> platforms, which makes it difficult to apply single fix to the signal code. >> With this fix, we will only need to touch single file for common POSIX >> code fixes from now on. >> >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` >> `$ git checkout pull/497` > > src/hotspot/os/posix/signals_posix.cpp line 1574: > >> 1572: // supported Bsd platforms). Note that BsdThreads/LinuxThreads need to block >> 1573: // this signal for all threads to work properly. So we don't have >> 1574: // to use hard-coded signal number when setting up the mask. > > This comment block (lines 1571-1574) should be deleted. It was originally in the Linux code and pertained to the old > LinuxThreads implementation which has not been relevant for years. It was erroneously copied across to the BSD port, > where Linux was globally replaced with Bsd, resulting in a reference to the non-existent BsdThreads. Fixed, will commit shortly. ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From gziemski at openjdk.java.net Tue Oct 6 15:59:26 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 6 Oct 2020 15:59:26 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms [v2] In-Reply-To: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: > This is a fresh start for https://github.com/openjdk/jdk/pull/157 > > Please review this change that refactors common POSIX code into a separate > file. > > Currently there appears to be quite a bit of duplicated code among POSIX > platforms, which makes it difficult to apply single fix to the signal code. > With this fix, we will only need to touch single file for common POSIX > code fixes from now on. > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > > > ### Download > `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` > `$ git checkout pull/497` Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: Remove old comment about 4528190, remove empty lines in g_signal_info struct ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/497/files - new: https://git.openjdk.java.net/jdk/pull/497/files/06b104d0..e6c781e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=497&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=497&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/497.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497 PR: https://git.openjdk.java.net/jdk/pull/497 From hseigel at openjdk.java.net Tue Oct 6 19:00:13 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 6 Oct 2020 19:00:13 GMT Subject: RFR: 8254061 Missing space in flag description Message-ID: Please review this trivial change to add a blank before 'dumped'. The change was tested with -XX:+PrintFlagsWithComments. Thanks, Harold ------------- Commit messages: - 8254061 Missing space in flag description Changes: https://git.openjdk.java.net/jdk/pull/531/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=531&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254061 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/531.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/531/head:pull/531 PR: https://git.openjdk.java.net/jdk/pull/531 From coleenp at openjdk.java.net Tue Oct 6 19:22:06 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 6 Oct 2020 19:22:06 GMT Subject: RFR: 8254061 Missing space in flag description In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 18:55:55 GMT, Harold Seigel wrote: > Please review this trivial change to add a blank before 'dumped'. The change was tested > with -XX:+PrintFlagsWithComments. > Thanks, Harold Looks good + trivial. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/531 From hseigel at openjdk.java.net Tue Oct 6 19:22:06 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 6 Oct 2020 19:22:06 GMT Subject: Integrated: 8254061 Missing space in flag description In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 18:55:55 GMT, Harold Seigel wrote: > Please review this trivial change to add a blank before 'dumped'. The change was tested > with -XX:+PrintFlagsWithComments. > Thanks, Harold This pull request has now been integrated. Changeset: 82fe023b Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/82fe023b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8254061: Missing space in flag description Reviewed-by: coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/531 From ccheung at openjdk.java.net Tue Oct 6 20:49:10 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 6 Oct 2020 20:49:10 GMT Subject: RFR: 8253909: Implement detailed map file for CDS [v2] In-Reply-To: References: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> Message-ID: On Mon, 5 Oct 2020 18:26:55 GMT, Ioi Lam wrote: >> For analyzing the contents of a CDS archive, we need a "map file" that describes the archive in different levels of >> detail. This can be done using unified logging. E.g., >> java -Xshare:dump -Xlog:cds+map=trace:file=cds.map:none:filesize=0 >> >> For example, we can use the map file for troubleshooting [JDK-8253495](https://bugs.openjdk.java.net/browse/JDK-8253495) >> (runtime/cds/DeterministicDump.java broken). We can diff two different cds.map files to see where the non-deterministic >> contents come from. >> See attachments in [JDK-8253909](https://bugs.openjdk.java.net/browse/JDK-8253909) for example map files at the >> info/debug/trace levels. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Feedback from Thomas Stuefe One nit in archiveBuilder.cpp. Marked as reviewed by ccheung (Reviewer). src/hotspot/share/memory/archiveBuilder.cpp line 788: > 786: char* bitmap, size_t bitmap_size_in_bytes) { > 787: if (log_is_enabled(Info, cds, map)) { > 788: CDSMapLogger::write(this, mapinfo, closed_heap_regions,open_heap_regions, Needs a space before `open_heap_regions`. src/hotspot/share/memory/filemap.cpp line 1311: > 1309: > 1310: write_region(MetaspaceShared::bm, (char*)buffer, size_in_bytes, /*read_only=*/true, /*allow_exec=*/false); > 1311: return (char*)buffer; `buffer` is declared as `char*`, no need to typecast. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/474 From iignatyev at openjdk.java.net Tue Oct 6 20:53:12 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 6 Oct 2020 20:53:12 GMT Subject: RFR: 8254095: remove jdk.test.lib.Utils::distro() method Message-ID: Hi all, could you please review this trivial cleanup? from JBS: > jdk.test.lib.Utils::distro() is not used by any of the tests and can be removed. Thanks, -- Igor ------------- Commit messages: - 8254095: remove jdk.test.lib.Utils::distro() method Changes: https://git.openjdk.java.net/jdk/pull/532/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=532&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254095 Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/532.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/532/head:pull/532 PR: https://git.openjdk.java.net/jdk/pull/532 From dholmes at openjdk.java.net Tue Oct 6 22:00:08 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Oct 2020 22:00:08 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms [v2] In-Reply-To: References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: On Tue, 6 Oct 2020 15:59:26 GMT, Gerard Ziemski wrote: >> This is a fresh start for https://github.com/openjdk/jdk/pull/157 >> >> Please review this change that refactors common POSIX code into a separate >> file. >> >> Currently there appears to be quite a bit of duplicated code among POSIX >> platforms, which makes it difficult to apply single fix to the signal code. >> With this fix, we will only need to touch single file for common POSIX >> code fixes from now on. >> >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` >> `$ git checkout pull/497` > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > Remove old comment about 4528190, remove empty lines in g_signal_info struct Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From bchristi at openjdk.java.net Tue Oct 6 22:51:06 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 6 Oct 2020 22:51:06 GMT Subject: RFR: 8254095: remove jdk.test.lib.Utils::distro() method In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 20:47:10 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial cleanup? from JBS: >> jdk.test.lib.Utils::distro() is not used by any of the tests and can be removed. > > Thanks, > -- Igor Looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/532 From bchristi at openjdk.java.net Tue Oct 6 23:01:06 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 6 Oct 2020 23:01:06 GMT Subject: RFR: 8254095: remove jdk.test.lib.Utils::distro() method In-Reply-To: References: Message-ID: <_vHhJCsLIGcTr4cEV7zZ-F54HCPs_dApITgRI0SphH8=.ab94bb15-1534-4cfc-8fad-60b2db81ee03@github.com> On Tue, 6 Oct 2020 20:47:10 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial cleanup? from JBS: >> jdk.test.lib.Utils::distro() is not used by any of the tests and can be removed. > > Thanks, > -- Igor Marked as reviewed by bchristi (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/532 From iignatyev at openjdk.java.net Tue Oct 6 23:01:06 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 6 Oct 2020 23:01:06 GMT Subject: RFR: 8254095: remove jdk.test.lib.Utils::distro() method In-Reply-To: <_vHhJCsLIGcTr4cEV7zZ-F54HCPs_dApITgRI0SphH8=.ab94bb15-1534-4cfc-8fad-60b2db81ee03@github.com> References: <_vHhJCsLIGcTr4cEV7zZ-F54HCPs_dApITgRI0SphH8=.ab94bb15-1534-4cfc-8fad-60b2db81ee03@github.com> Message-ID: On Tue, 6 Oct 2020 22:56:03 GMT, Brent Christian wrote: >> Hi all, >> >> could you please review this trivial cleanup? from JBS: >>> jdk.test.lib.Utils::distro() is not used by any of the tests and can be removed. >> >> Thanks, >> -- Igor > > Marked as reviewed by bchristi (Reviewer). Thanks, Brent. ------------- PR: https://git.openjdk.java.net/jdk/pull/532 From iignatyev at openjdk.java.net Tue Oct 6 23:01:07 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 6 Oct 2020 23:01:07 GMT Subject: Integrated: 8254095: remove jdk.test.lib.Utils::distro() method In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 20:47:10 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial cleanup? from JBS: >> jdk.test.lib.Utils::distro() is not used by any of the tests and can be removed. > > Thanks, > -- Igor This pull request has now been integrated. Changeset: 2a0389a8 Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/2a0389a8 Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod 8254095: remove jdk.test.lib.Utils::distro() method Reviewed-by: bchristi ------------- PR: https://git.openjdk.java.net/jdk/pull/532 From ysuenaga at openjdk.java.net Wed Oct 7 00:21:07 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 7 Oct 2020 00:21:07 GMT Subject: RFR: 8252324: Signal related code should be shared among POSIX platforms [v2] In-Reply-To: References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: On Tue, 6 Oct 2020 15:59:26 GMT, Gerard Ziemski wrote: >> This is a fresh start for https://github.com/openjdk/jdk/pull/157 >> >> Please review this change that refactors common POSIX code into a separate >> file. >> >> Currently there appears to be quite a bit of duplicated code among POSIX >> platforms, which makes it difficult to apply single fix to the signal code. >> With this fix, we will only need to touch single file for common POSIX >> code fixes from now on. >> >> --------- >> ### Progress >> - [x] Change must not contain extraneous whitespace >> - [x] Commit message must refer to an issue >> - [ ] Change must be properly reviewed >> >> >> >> ### Download >> `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` >> `$ git checkout pull/497` > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > Remove old comment about 4528190, remove empty lines in g_signal_info struct Marked as reviewed by ysuenaga (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From sgehwolf at openjdk.java.net Wed Oct 7 08:11:25 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 7 Oct 2020 08:11:25 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v4] In-Reply-To: References: Message-ID: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. For the Java side the proposal is to add some parsing for mountinfo lines and > look for `cgroup` FS-type lines which aren't also mounted purely for systemd. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [x] Submit testing Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/485/files - new: https://git.openjdk.java.net/jdk/pull/485/files/d334ac60..5e2ca2dc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=02-03 Stats: 548 lines in 5 files changed: 284 ins; 193 del; 71 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Wed Oct 7 08:11:25 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 7 Oct 2020 08:11:25 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v3] In-Reply-To: <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com> References: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com> <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com> Message-ID: On Tue, 6 Oct 2020 08:32:25 GMT, Severin Gehwolf wrote: >> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 150: >> >>> 148: // find anyway in that case. >>> 149: try (Stream mntInfo = CgroupUtil.readFilePrivileged(Paths.get(mountInfo))) { >>> 150: boolean anyCgroupMounted = mntInfo.anyMatch(CgroupSubsystemFactory::noSystemdCgroupLine); >> >> I'd prefer a similar approach to the hotspot side where you do a positive check for controllers we are interested in >> rather than a negative check for systemd. > > OK. I'll probably fold JDK-8254001 into this one then. @bobvandette Done in the latest version. Thoughts? ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Wed Oct 7 08:11:26 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 7 Oct 2020 08:11:26 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v4] In-Reply-To: References: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com> Message-ID: On Mon, 5 Oct 2020 08:59:34 GMT, Severin Gehwolf wrote: >> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 80: >> >>> 78: */ >>> 79: private static final Pattern MOUNTINFO_PATTERN = >>> 80: >>> Pattern.compile("^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+([^\\s]+)\\s+([^\\s]+)\\s+[^-]+-\\s+([^\\s]+)\\s+.*$"); >> >> Only group_3 = fstype is used in the pattern, right? > > Yes. I've removed unused groups now, though. > > Originally, my thinking was that `mount root` and `mount path` would be useful too so I kept it in. It would certainly > be useful for getting rid of reading `/proc/self/mountinfo` twice on the Java side. As a future enhancement we could do > away with double parsing of mount info by keeping track of relevant cgroup controller info. I've filed > [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) to track this. The latest version goes back to using all three as it's beneficial to track that info and use it later on for instantiating the version specific objects. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From shade at openjdk.java.net Wed Oct 7 11:27:14 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 7 Oct 2020 11:27:14 GMT Subject: RFR: 8254144: Non-x86 Zero builds fail with return-type warning in os_linux_zero.cpp Message-ID: Pretty trivial: missing `return` statement for non-void returning function. GCC complains about it in 11u, but not in HEAD. Still, I believe we should fix it everywhere. Testing: - [x] Linux Zero arm32 build, HEAD - [x] Linux Zero arm32 build, 11u ------------- Commit messages: - 8254144: Non-x86 Zero builds fail with return-type warning in os_linux_zero.cpp Changes: https://git.openjdk.java.net/jdk/pull/539/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=539&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254144 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/539/head:pull/539 PR: https://git.openjdk.java.net/jdk/pull/539 From zgu at openjdk.java.net Wed Oct 7 11:41:13 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 7 Oct 2020 11:41:13 GMT Subject: RFR: 8254144: Non-x86 Zero builds fail with return-type warning in os_linux_zero.cpp In-Reply-To: References: Message-ID: On Wed, 7 Oct 2020 11:11:51 GMT, Aleksey Shipilev wrote: > Pretty trivial: missing `return` statement for non-void returning function. GCC complains about it in 11u, but not in > HEAD. Still, I believe we should fix it everywhere. > Testing: > - [x] Linux Zero arm32 build, HEAD > - [x] Linux Zero arm32 build, 11u Looks good and trivial ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/539 From bulasevich at openjdk.java.net Wed Oct 7 11:59:14 2020 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Wed, 7 Oct 2020 11:59:14 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v4] In-Reply-To: References: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com> Message-ID: On Wed, 7 Oct 2020 08:08:13 GMT, Severin Gehwolf wrote: >> Yes. I've removed unused groups now, though. >> >> Originally, my thinking was that `mount root` and `mount path` would be useful too so I kept it in. It would certainly >> be useful for getting rid of reading `/proc/self/mountinfo` twice on the Java side. As a future enhancement we could do >> away with double parsing of mount info by keeping track of relevant cgroup controller info. I've filed >> [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) to track this. > > The latest version goes back to using all three as it's beneficial to track that info and use it later on for > instantiating the version specific objects. ok! ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From stuefe at openjdk.java.net Wed Oct 7 12:20:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 7 Oct 2020 12:20:11 GMT Subject: RFR: 8253909: Implement detailed map file for CDS [v2] In-Reply-To: References: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> Message-ID: On Mon, 5 Oct 2020 18:26:55 GMT, Ioi Lam wrote: >> For analyzing the contents of a CDS archive, we need a "map file" that describes the archive in different levels of >> detail. This can be done using unified logging. E.g., >> java -Xshare:dump -Xlog:cds+map=trace:file=cds.map:none:filesize=0 >> >> For example, we can use the map file for troubleshooting [JDK-8253495](https://bugs.openjdk.java.net/browse/JDK-8253495) >> (runtime/cds/DeterministicDump.java broken). We can diff two different cds.map files to see where the non-deterministic >> contents come from. >> See attachments in [JDK-8253909](https://bugs.openjdk.java.net/browse/JDK-8253909) for example map files at the >> info/debug/trace levels. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Feedback from Thomas Stuefe LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/474 From stuefe at openjdk.java.net Wed Oct 7 12:20:12 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 7 Oct 2020 12:20:12 GMT Subject: RFR: 8253909: Implement detailed map file for CDS [v2] In-Reply-To: References: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> Message-ID: On Tue, 6 Oct 2020 06:57:18 GMT, Ioi Lam wrote: >> src/hotspot/share/runtime/os.hpp line 693: >> >>> 691: static void print_hex_dump(outputStream* st, address start, address end, int unitsize) { >>> 692: print_hex_dump(st, start, end, unitsize, /*bytes_per_line=*/16, /*logical_start=*/start); >>> 693: } >> >> This is a bit unclear. Could we do it like this instead: >> >> // Print a hex dump from [start .. end). Output lines are prefixed with addresses. >> static void print_hex_dump(outputStream* st, address start, address end, int unitsize) >> >> >> // Print a hex dump from [base+start .. base+end). Output lines are prefixed with offset in relation to base. >> static void print_hex_dump(outputStream* st, address base, intx start, intx end, int unitsize) > > But this is not what I want. I am calling with parameters like: > > print_hex_dump(st, /*start=*/0x7ffff0000, end, unitsize, bytes_per_line, /*logical_start=*/0x800000000); > So my buffer is at some random address, but I want the print out to pretend that it started at 0x800000000. Okay. A bit special, usually one would base it at 0 (e.g. printing network packets or similar). I think its okay then. We can revisit this later if needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/474 From vromero at openjdk.java.net Wed Oct 7 13:36:29 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 7 Oct 2020 13:36:29 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v10] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 8246774: implementing Record Classes as a standard feature in Java Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: removing unused jcod file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/7501148d..1bcda595 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=08-09 Stats: 256 lines in 1 file changed: 0 ins; 256 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From shade at openjdk.java.net Wed Oct 7 16:00:28 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 7 Oct 2020 16:00:28 GMT Subject: RFR: 8254144: Non-x86 Zero builds fail with return-type warning in os_linux_zero.cpp [v2] In-Reply-To: References: Message-ID: > Pretty trivial: missing `return` statement for non-void returning function. GCC complains about it in 11u, but not in > HEAD. Still, I believe we should fix it everywhere. > Testing: > - [x] Linux Zero arm32 build, HEAD > - [x] Linux Zero arm32 build, 11u Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Use the common style for compiler silencing comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/539/files - new: https://git.openjdk.java.net/jdk/pull/539/files/f15e4839..a6ea0c5d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=539&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=539&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/539/head:pull/539 PR: https://git.openjdk.java.net/jdk/pull/539 From gziemski at openjdk.java.net Wed Oct 7 16:25:15 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 7 Oct 2020 16:25:15 GMT Subject: Integrated: 8252324: Signal related code should be shared among POSIX platforms In-Reply-To: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> References: <9Gz5VL5_Znao3OGQzWDrjKBSsUKCBmXow3Lc1J80Xsc=.2f079f3f-e9dc-4bbc-b592-8d3c926ed459@github.com> Message-ID: On Sat, 3 Oct 2020 17:12:30 GMT, Gerard Ziemski wrote: > This is a fresh start for https://github.com/openjdk/jdk/pull/157 > > Please review this change that refactors common POSIX code into a separate > file. > > Currently there appears to be quite a bit of duplicated code among POSIX > platforms, which makes it difficult to apply single fix to the signal code. > With this fix, we will only need to touch single file for common POSIX > code fixes from now on. > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [x] Change must be properly reviewed > > > > ### Download > `$ git fetch https://git.openjdk.java.net/jdk pull/497/head:pull/497` > `$ git checkout pull/497` This pull request has now been integrated. Changeset: 4fe07ccc Author: Gerard Ziemski URL: https://git.openjdk.java.net/jdk/commit/4fe07ccc Stats: 5355 lines in 21 files changed: 1733 ins; 3529 del; 93 mod 8252324: Signal related code should be shared among POSIX platforms Reviewed-by: coleenp, dholmes, stuefe, ysuenaga ------------- PR: https://git.openjdk.java.net/jdk/pull/497 From iklam at openjdk.java.net Wed Oct 7 17:59:22 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 7 Oct 2020 17:59:22 GMT Subject: RFR: 8253909: Implement detailed map file for CDS [v3] In-Reply-To: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> References: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> Message-ID: > For analyzing the contents of a CDS archive, we need a "map file" that describes the archive in different levels of > detail. This can be done using unified logging. E.g., > java -Xshare:dump -Xlog:cds+map=trace:file=cds.map:none:filesize=0 > > For example, we can use the map file for troubleshooting [JDK-8253495](https://bugs.openjdk.java.net/browse/JDK-8253495) > (runtime/cds/DeterministicDump.java broken). We can diff two different cds.map files to see where the non-deterministic > contents come from. > See attachments in [JDK-8253909](https://bugs.openjdk.java.net/browse/JDK-8253909) for example map files at the > info/debug/trace levels. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into 8253909-cds-map-file - Calvin's comments - Feedback from Thomas Stuefe - 8253909: Implement detailed map file for CDS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/474/files - new: https://git.openjdk.java.net/jdk/pull/474/files/5dc43c70..dc2d346e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=474&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=474&range=01-02 Stats: 19722 lines in 442 files changed: 9447 ins; 6388 del; 3887 mod Patch: https://git.openjdk.java.net/jdk/pull/474.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/474/head:pull/474 PR: https://git.openjdk.java.net/jdk/pull/474 From bobv at openjdk.java.net Wed Oct 7 19:09:08 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Wed, 7 Oct 2020 19:09:08 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v3] In-Reply-To: References: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com> <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com> Message-ID: <-Ghp9lTLaabHLOEnriSryHKOCx-cgIcS1sE4B8tmrm0=.4becaccc-6cb0-480b-b975-540d24f9949c@github.com> On Wed, 7 Oct 2020 08:06:58 GMT, Severin Gehwolf wrote: >> OK. I'll probably fold JDK-8254001 into this one then. > > @bobvandette Done in the latest version. Thoughts? I'm a little uncomfortable making such a dramatic change just to fix this small isolated problem. I think about all the churn we've had on these files and the backports to come. Could you just add a CgroupSubsystemFactory::isValidSubsystem function which checks for cpuset, cpuacct, memory, etc instead of the major change? ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From iignatyev at openjdk.java.net Wed Oct 7 19:10:12 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 7 Oct 2020 19:10:12 GMT Subject: RFR: 8254182: remove Utils.tryFindJvmPid/waitForJvmPid Message-ID: `jdk.test.lib.Utils::tryFindJvmPid` and `waitForJvmPid` methods aren't used and should be removed ------------- Commit messages: - remove Utils.tryFindJvmPid/waitForJvmPid Changes: https://git.openjdk.java.net/jdk/pull/550/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=550&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254182 Stats: 57 lines in 1 file changed: 0 ins; 57 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/550.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/550/head:pull/550 PR: https://git.openjdk.java.net/jdk/pull/550 From rriggs at openjdk.java.net Wed Oct 7 19:33:08 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 7 Oct 2020 19:33:08 GMT Subject: RFR: 8254182: remove Utils.tryFindJvmPid/waitForJvmPid In-Reply-To: References: Message-ID: <3pli82gIvQ5koDh_kfFsD4y9UtkxFFIclt8y2kn2w5Q=.07687424-cc5f-48a8-a347-72a6051bbbcf@github.com> On Wed, 7 Oct 2020 19:01:45 GMT, Igor Ignatyev wrote: > `jdk.test.lib.Utils::tryFindJvmPid` and `waitForJvmPid` methods aren't used and should be removed Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/550 From sgehwolf at openjdk.java.net Wed Oct 7 19:34:12 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 7 Oct 2020 19:34:12 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v3] In-Reply-To: <-Ghp9lTLaabHLOEnriSryHKOCx-cgIcS1sE4B8tmrm0=.4becaccc-6cb0-480b-b975-540d24f9949c@github.com> References: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com> <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com> <-Ghp9lTLaabHLOEnriSryHKOCx-cgIcS1sE4B8tmrm0=.4becaccc-6cb0-480b-b975-540d24f9949c@github.com> Message-ID: On Wed, 7 Oct 2020 19:05:57 GMT, Bob Vandette wrote: >> @bobvandette Done in the latest version. Thoughts? > > I'm a little uncomfortable making such a dramatic change just to fix this small isolated problem. I think about all > the churn we've had on these files and the backports to come. Could you just add a > CgroupSubsystemFactory::isValidSubsystem function which checks for cpuset, cpuacct, memory, etc instead of the major > change? Thanks for having a look! Sure, we could do that instead. I'm not sure this is the best solution going forward, though. Thinking about JDK 17... Anyway, I'll look into a more conservative fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From iignatyev at openjdk.java.net Thu Oct 8 06:49:28 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 8 Oct 2020 06:49:28 GMT Subject: RFR: 8254182: remove Utils.tryFindJvmPid/waitForJvmPid In-Reply-To: <3pli82gIvQ5koDh_kfFsD4y9UtkxFFIclt8y2kn2w5Q=.07687424-cc5f-48a8-a347-72a6051bbbcf@github.com> References: <3pli82gIvQ5koDh_kfFsD4y9UtkxFFIclt8y2kn2w5Q=.07687424-cc5f-48a8-a347-72a6051bbbcf@github.com> Message-ID: On Wed, 7 Oct 2020 19:30:44 GMT, Roger Riggs wrote: >> `jdk.test.lib.Utils::tryFindJvmPid` and `waitForJvmPid` methods aren't used and should be removed > > Marked as reviewed by rriggs (Reviewer). Thanks Roger! ------------- PR: https://git.openjdk.java.net/jdk/pull/550 From iignatyev at openjdk.java.net Thu Oct 8 07:00:52 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 8 Oct 2020 07:00:52 GMT Subject: Integrated: 8254182: remove Utils.tryFindJvmPid/waitForJvmPid In-Reply-To: References: Message-ID: On Wed, 7 Oct 2020 19:01:45 GMT, Igor Ignatyev wrote: > `jdk.test.lib.Utils::tryFindJvmPid` and `waitForJvmPid` methods aren't used and should be removed This pull request has now been integrated. Changeset: 7733a0e7 Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/7733a0e7 Stats: 57 lines in 1 file changed: 0 ins; 57 del; 0 mod 8254182: remove Utils.tryFindJvmPid/waitForJvmPid Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/550 From iklam at openjdk.java.net Thu Oct 8 07:01:35 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 8 Oct 2020 07:01:35 GMT Subject: Integrated: 8253909: Implement detailed map file for CDS In-Reply-To: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> References: <_ewEBEnYDnAeQeVCQLivcsyF3EoNvq6Yj9haPZKFFIw=.fb2217af-62eb-4472-8544-0bfa7bca1e30@github.com> Message-ID: <4Umstm0fOm_xGB9PgDM8rBOAbuYHJdlMNxzk4iRAQXo=.45aa0ab3-1d28-4be3-bfb4-98a024aaa707@github.com> On Thu, 1 Oct 2020 20:06:32 GMT, Ioi Lam wrote: > For analyzing the contents of a CDS archive, we need a "map file" that describes the archive in different levels of > detail. This can be done using unified logging. E.g., > java -Xshare:dump -Xlog:cds+map=trace:file=cds.map:none:filesize=0 > > For example, we can use the map file for troubleshooting [JDK-8253495](https://bugs.openjdk.java.net/browse/JDK-8253495) > (runtime/cds/DeterministicDump.java broken). We can diff two different cds.map files to see where the non-deterministic > contents come from. > See attachments in [JDK-8253909](https://bugs.openjdk.java.net/browse/JDK-8253909) for example map files at the > info/debug/trace levels. This pull request has now been integrated. Changeset: d1e94eeb Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/d1e94eeb Stats: 395 lines in 10 files changed: 335 ins; 19 del; 41 mod 8253909: Implement detailed map file for CDS Reviewed-by: stuefe, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/474 From shade at openjdk.java.net Thu Oct 8 07:41:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 8 Oct 2020 07:41:57 GMT Subject: RFR: 8254144: Non-x86 Zero builds fail with return-type warning in os_linux_zero.cpp [v3] In-Reply-To: References: Message-ID: > Pretty trivial: missing `return` statement for non-void returning function. GCC complains about it in 11u, but not in > HEAD. Still, I believe we should fix it everywhere. > Testing: > - [x] Linux Zero arm32 build, HEAD > - [x] Linux Zero arm32 build, 11u 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-8254144-zero-non-x86-return - Use the common style for compiler silencing comments - 8254144: Non-x86 Zero builds fail with return-type warning in os_linux_zero.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/539/files - new: https://git.openjdk.java.net/jdk/pull/539/files/a6ea0c5d..78488b62 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=539&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=539&range=01-02 Stats: 8688 lines in 123 files changed: 4495 ins; 3691 del; 502 mod Patch: https://git.openjdk.java.net/jdk/pull/539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/539/head:pull/539 PR: https://git.openjdk.java.net/jdk/pull/539 From shade at openjdk.java.net Thu Oct 8 08:15:45 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 8 Oct 2020 08:15:45 GMT Subject: Integrated: 8254144: Non-x86 Zero builds fail with return-type warning in os_linux_zero.cpp In-Reply-To: References: Message-ID: On Wed, 7 Oct 2020 11:11:51 GMT, Aleksey Shipilev wrote: > Pretty trivial: missing `return` statement for non-void returning function. GCC complains about it in 11u, but not in > HEAD. Still, I believe we should fix it everywhere. > Testing: > - [x] Linux Zero arm32 build, HEAD > - [x] Linux Zero arm32 build, 11u This pull request has now been integrated. Changeset: 8f9e4792 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/8f9e4792 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8254144: Non-x86 Zero builds fail with return-type warning in os_linux_zero.cpp Reviewed-by: zgu ------------- PR: https://git.openjdk.java.net/jdk/pull/539 From thomas.schatzl at oracle.com Thu Oct 8 08:31:12 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 8 Oct 2020 10:31:12 +0200 Subject: guarantee(object->mark() == markWord::INFLATING()) failed: invariant In-Reply-To: References: Message-ID: <7edeb04f-7a6f-ed8d-da5b-a51b5ebfa32f@oracle.com> Hi Martin, On 01.10.20 20:52, Doerr, Martin wrote: > Hi, > > we have seen a crash when running Spec JVM 2008 on a Power9 machine. > It occurred only once so I can't tell if it is a PPC64 specific or weak memory model specific issue. > Locking code has worked very solid for many years on this platform. > > # Internal Error (synchronizer.cpp:1953), pid=18455, tid=19363 > # guarantee(object->mark() == markWord::INFLATING()) failed: invariant > > V [libjvm.so+0xe463cc] ObjectSynchronizer::inflate(Thread*, oopDesc*, ObjectSynchronizer::InflateCause)+0x76c > V [libjvm.so+0xe467ac] ObjectSynchronizer::exit(oopDesc*, BasicLock*, Thread*)+0x4c > V [libjvm.so+0xda18a0] SharedRuntime::complete_monitor_unlocking_C(oopDesc*, BasicLock*, JavaThread*)+0xc0 > J 5765 c2 sun.nio.cs.StreamEncoder.flushBuffer()V java.base at 16.0.0.1-internal (42 bytes) @ 0x00007fff95e1d84c [0x00007fff95e1d400+0x000000000000044c] > J 6249 c2 java.io.PrintStream.println(Ljava/lang/String;)V java.base at 16.0.0.1-internal (44 bytes) @ 0x00007fff95f1f1a0 [0x00007fff95f1ea80+0x0000000000000720] > J 6534 c1 spec.benchmarks.crypto.aes.Main.runEncryptDecrypt(Ljavax/crypto/SecretKey;Ljava/lang/String;Ljava/lang/String;)V (93 bytes) @ 0x00007fff8e575794 [0x00007fff8e574e00+0x0000000000000994] > j spec.benchmarks.crypto.aes.Main.harnessMain()V+69 > ... > > object->_mark points to a stack lock: > 0x00007ffe67dfdbc8 is pointing into the stack for thread: 0x00007ffeec10d5e0 > content of stack slot 0x7ffe67dfdbc8: 0x0000000000000009 > which belongs to the crashing thread: > Current thread (0x00007ffeec10d5e0): JavaThread "BenchmarkThread crypto.aes 5" [_thread_in_Java, id=19363, stack(0x00007ffe67c00000,0x00007ffe67e00000)] > > I wonder how this can happen. Can it be related to asynchronous lock deflation? > Any ideas are welcome. > This reminds me a bit of JDK-8248438 because of the stack trace. This will be fixed by JDK-8254164. You can you check whether its the same issue using the following keys: Using g1 (the snippet does not show even that) - the markword contains a self-forwarded pointer AND/OR - the most recent gc has been a mixed gc with an optional evacuation phase and an evacuation failure (can be seen in a gc log) If you can manage to verify the first, this is a duplicate of JDK-8254164 (note that that bug is there since JDK 13). If you can only verify the latter, there is very high probability that this is the issue. Thanks, Thomas From github.com+4146708+a74nh at openjdk.java.net Thu Oct 8 12:50:45 2020 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Thu, 8 Oct 2020 12:50:45 GMT Subject: RFR: 8253843: AArch64: Use ishst for storestore barrier In-Reply-To: References: <4bvHnsfvpM8MDmGCQgOkn2ovdeeGLJO5Vh8tYR9p2mc=.4563c186-e164-4295-a49b-06ce715fef72@github.com> Message-ID: On Fri, 2 Oct 2020 08:56:29 GMT, Alan Hayward wrote: >> PRs for mainline should be reviewed on mainline mailing lists. The xxx-port mailing lists are supposed to be used for >> changes applied to port specific repositories, hence the is no label mapping for them here. You can of course reply >> directly to the PR email and add the additional mailing list. > >> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on >> [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_ >> On 30/09/2020 17:29, Alan Hayward wrote: >> >> > AArch64 orderAccess uses gcc built in atomic functions, which expand >> > inline to DMB barrier instructions. Specifically, they call the following: >> > FULL_MEM_BARRIER -> DMB ISH >> > READ_MEM_BARRIER -> DMB ISHLD >> > WRITE_MEM_BARRIER -> DMB ISH >> > However, storestore should be optimised to use ISHST. >> > In addition, __sync_synchronize is marked as legacy. See: >> > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html >> > In order for the code to match, >> >> To match what? > > Original version of my patch just switched storestore to call asm dmb ishst > But then it looks very odd that one function in the file is using asm and the > rest of the file is using the C++ functions. > >> >> > I switched everything to call dmbs directly. >> >> We are now able to use modern C++, which means that we can use real >> C++ atomic operations. Going back to inline asms would be a >> regression. >> >> The trouble with using asms for this is that the compiler does not >> know what is going on inside an asm. If you use an asm with a memory >> clobber for a StoreStore barrier, the compiler has to treat the asm as >> a full memory barrier, so it cannot move any loads and stores across >> the StoreStore. So, paradoxically, you might be making things worse. >> > > Ok, I agree with that. (maybe a comment in the code would be useful here) > > At the risk of asking something that's probably been asked before ....Why > then do we have inline asm for other targets? Wouldn't it be better to > have a common (or OS?) level file for these functions? > > Also, it looks like using the C++ atomic functions there seems to be no way to > generate a dmb ishst. > >> > Also, add AArch64 to the orderAccess documentation table. >> >> Please don't. it's more complicated than that, and it's not necessary. >> > > Happy to drop that. But, if it is more complicated than that, then is it wrong > for other architectures too? Should that whole table be removed? Closing this. Inline asm is the wrong way to go; it's not sensible to commonise everything else to the c++ functions; there's no C++ atomic function for ishst. ------------- PR: https://git.openjdk.java.net/jdk/pull/427 From github.com+4146708+a74nh at openjdk.java.net Thu Oct 8 12:50:46 2020 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Thu, 8 Oct 2020 12:50:46 GMT Subject: Withdrawn: 8253843: AArch64: Use ishst for storestore barrier In-Reply-To: <4bvHnsfvpM8MDmGCQgOkn2ovdeeGLJO5Vh8tYR9p2mc=.4563c186-e164-4295-a49b-06ce715fef72@github.com> References: <4bvHnsfvpM8MDmGCQgOkn2ovdeeGLJO5Vh8tYR9p2mc=.4563c186-e164-4295-a49b-06ce715fef72@github.com> Message-ID: On Wed, 30 Sep 2020 08:34:14 GMT, Alan Hayward wrote: > AArch64 orderAccess uses gcc built in atomic functions, which expand > inline to DMB barrier instructions. Specifically, they call the following: > > FULL_MEM_BARRIER -> DMB ISH > READ_MEM_BARRIER -> DMB ISHLD > WRITE_MEM_BARRIER -> DMB ISH > > However, storestore should be optimised to use ISHST. > > In addition, __sync_synchronize is marked as legacy. See: > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html > > In order for the code to match, I switched everything to call dmbs directly. > > Also, add AArch64 to the orderAccess documentation table. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/427 From sgehwolf at openjdk.java.net Thu Oct 8 12:51:54 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 8 Oct 2020 12:51:54 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) In-Reply-To: References: Message-ID: On Mon, 5 Oct 2020 10:10:23 GMT, Severin Gehwolf wrote: >>> The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed. >> >> Thanks for the review and for testing it! > > @bobvandette Could you perhaps have a look at this? Many thanks in advance! @bobvandette How about this? ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Thu Oct 8 12:51:54 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 8 Oct 2020 12:51:54 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v5] In-Reply-To: References: Message-ID: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also > to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific > objects. In order to not regress here, I've added more tests. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [x] Submit testing Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/485/files - new: https://git.openjdk.java.net/jdk/pull/485/files/5e2ca2dc..e72ac219 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=03-04 Stats: 514 lines in 5 files changed: 159 ins; 231 del; 124 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From rehn at openjdk.java.net Thu Oct 8 13:14:53 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 8 Oct 2020 13:14:53 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread Message-ID: It's unsafe for all threads except VM thread to access the current vm operation. This part of the assert is also faulty: If we are not at safepoint and the operation requester (calling thread) would be the owner of the lock do not mean it is safe for current thread. Passes t1-5. (also note VMThread::vm_operation() assert current thread is VM thread, and I have seen no such assert) Thanks ------------- Commit messages: - Removed vm op caller check Changes: https://git.openjdk.java.net/jdk/pull/563/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=563&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253833 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/563.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/563/head:pull/563 PR: https://git.openjdk.java.net/jdk/pull/563 From bobv at openjdk.java.net Thu Oct 8 13:14:46 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Thu, 8 Oct 2020 13:14:46 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v5] In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 12:51:54 GMT, Severin Gehwolf wrote: >> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the >> affected system, `/proc/self/mountinfo` contains a line such as this one: >> >> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd >> >> >> Note that `/proc/cgroups` looks like this: >> >> #subsys_name hierarchy num_cgroups enabled >> cpuset 0 1 1 >> cpu 0 1 1 >> cpuacct 0 1 1 >> blkio 0 1 1 >> memory 0 1 1 >> devices 0 1 1 >> freezer 0 1 1 >> net_cls 0 1 1 >> perf_event 0 1 1 >> net_prio 0 1 1 >> hugetlb 0 1 1 >> pids 0 1 1 >> >> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo >> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in >> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, >> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to >> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's >> cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also >> to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific >> objects. In order to not regress here, I've added more tests. >> **Testing** >> >> - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) >> - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) >> - [x] Added regression test which fails prior the patch and passes after >> - [x] Submit testing > > Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. The pull request contains one new > commit since the last revision: > 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 185: > 183: } else { > 184: // fallback to old, pre JDK-8245543, behaviour > 185: return line.contains("cgroup"); Why are you doing this fallback rather than returning false?? ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From shade at openjdk.java.net Thu Oct 8 13:25:47 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 8 Oct 2020 13:25:47 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 13:08:51 GMT, Robbin Ehn wrote: > It's unsafe for all threads except VM thread to access the current vm operation. > This part of the assert is also faulty: > If we are not at safepoint and the operation requester (calling thread) would be the owner of the lock do not mean it > is safe for current thread. > Passes t1-5. (also note VMThread::vm_operation() assert current thread is VM thread, and I have seen no such assert) > > Thanks Looks okay to me. Is it significantly different from `assert_locked_or_safepoint_weak` now? ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From rehn at openjdk.java.net Thu Oct 8 13:38:46 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 8 Oct 2020 13:38:46 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: <019zCJFPV1Yy-pPtk6y0p87QlLMkGb9mEXbPl-AGu_0=.51111053-d1b1-4a52-8058-83341a5da4d1@github.com> On Thu, 8 Oct 2020 13:22:55 GMT, Aleksey Shipilev wrote: > Looks okay to me. Is it significantly different from `assert_locked_or_safepoint_weak` now? Weak just checks if lock is locked while this one check if current thread is the owner. So only one line differ. You want me to do try to share the rest of the code? ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From sgehwolf at openjdk.java.net Thu Oct 8 13:38:59 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 8 Oct 2020 13:38:59 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6] In-Reply-To: References: Message-ID: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also > to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific > objects. In order to not regress here, I've added more tests. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [x] Submit testing Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Return false in case of no pattern match ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/485/files - new: https://git.openjdk.java.net/jdk/pull/485/files/e72ac219..37f5b093 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=04-05 Stats: 7 lines in 1 file changed: 2 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Thu Oct 8 13:39:00 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 8 Oct 2020 13:39:00 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v5] In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 13:12:02 GMT, Bob Vandette wrote: >> Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. The pull request contains one new >> commit since the last revision: >> 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) > > src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 185: > >> 183: } else { >> 184: // fallback to old, pre JDK-8245543, behaviour >> 185: return line.contains("cgroup"); > > Why are you doing this fallback rather than returning false?? The idea was to have have some basics working even though the pattern doesn't match for some reason. I guess we can remove that as it's rather unlikely to not match. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From shade at openjdk.java.net Thu Oct 8 13:42:43 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 8 Oct 2020 13:42:43 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: <019zCJFPV1Yy-pPtk6y0p87QlLMkGb9mEXbPl-AGu_0=.51111053-d1b1-4a52-8058-83341a5da4d1@github.com> References: <019zCJFPV1Yy-pPtk6y0p87QlLMkGb9mEXbPl-AGu_0=.51111053-d1b1-4a52-8058-83341a5da4d1@github.com> Message-ID: <60dE4HuhdTqYBkKgt3PvU8fs7rqLLKmNti3GaRIQ9Io=.f2fb6035-2955-4dac-9867-3875e37b9503@github.com> On Thu, 8 Oct 2020 13:36:11 GMT, Robbin Ehn wrote: > > Looks okay to me. Is it significantly different from `assert_locked_or_safepoint_weak` now? > > Weak just checks if lock is locked while this one check if current thread is the owner. > So only one line differ. You want me to do try to share the rest of the code? Ah, okay. No action needed, as long as you saw the other versions and decided not to do anything with them. ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From bobv at openjdk.java.net Thu Oct 8 14:03:48 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Thu, 8 Oct 2020 14:03:48 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6] In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 13:38:59 GMT, Severin Gehwolf wrote: >> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the >> affected system, `/proc/self/mountinfo` contains a line such as this one: >> >> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd >> >> >> Note that `/proc/cgroups` looks like this: >> >> #subsys_name hierarchy num_cgroups enabled >> cpuset 0 1 1 >> cpu 0 1 1 >> cpuacct 0 1 1 >> blkio 0 1 1 >> memory 0 1 1 >> devices 0 1 1 >> freezer 0 1 1 >> net_cls 0 1 1 >> perf_event 0 1 1 >> net_prio 0 1 1 >> hugetlb 0 1 1 >> pids 0 1 1 >> >> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo >> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in >> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, >> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to >> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's >> cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also >> to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific >> objects. In order to not regress here, I've added more tests. >> **Testing** >> >> - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) >> - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) >> - [x] Added regression test which fails prior the patch and passes after >> - [x] Submit testing > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Return false in case of no pattern match Marked as reviewed by bobv (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From bobv at openjdk.java.net Thu Oct 8 14:03:50 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Thu, 8 Oct 2020 14:03:50 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v5] In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 13:36:20 GMT, Severin Gehwolf wrote: >> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 185: >> >>> 183: } else { >>> 184: // fallback to old, pre JDK-8245543, behaviour >>> 185: return line.contains("cgroup"); >> >> Why are you doing this fallback rather than returning false?? > > The idea was to have have some basics working even though the pattern doesn't match for some reason. I guess we can > remove that as it's rather unlikely to not match. The change looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From aph at redhat.com Thu Oct 8 14:10:14 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Oct 2020 15:10:14 +0100 Subject: RFR: 8253843: AArch64: Use ishst for storestore barrier In-Reply-To: References: <4bvHnsfvpM8MDmGCQgOkn2ovdeeGLJO5Vh8tYR9p2mc=.4563c186-e164-4295-a49b-06ce715fef72@github.com> Message-ID: On 08/10/2020 13:50, Alan Hayward wrote: > Closing this. Inline asm is the wrong way to go; it's not sensible to commonise everything else to the c++ functions; > there's no C++ atomic function for ishst. I think that's right. If some convincing benchmark data were to show that naked StoreStore was faster I would not object, but in the absence of that I'll lean towards caution. -- 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 dgriffiths at undo.io Thu Oct 8 14:11:36 2020 From: dgriffiths at undo.io (David Griffiths) Date: Thu, 8 Oct 2020 15:11:36 +0100 Subject: ScopeDescs incorrect in Java 8 Message-ID: Hi, I am writing some code which makes use of ScopeDesc info in a live JVM and am seeing what looks like a bug in Java 8. I realise this is now ancient technology but wondered if anybody could just point me in vaguely the right direction to try and find the cause. The bug does not exist in Java 11 onwards so I think it must have been fixed. In a nutshell, I'm finding that the mere presence of a particular line at the end of a method completely screws the ScopeDescs for the complete method - the compiled code no longer lines up with the associated ScopeDescs. I'm running with the options "-XX:-Inline -XX:TieredStopAtLevel=1" (there is a reason for this). The method (called enough times to JIT compile) is: 16 static void topMethod(int a, int b) { 17 int c = a + 1; 18 int d = iMethodA(a) + iMethodB(a); 19 int e = iMethodA(a) * (iMethodA(b) - iMethodB(b)); 20 vMethod(a); 21 testArgs(7.0); 22 } Simply changing the last line to testArgs(a) results in the ScopeDescs being ok! The called methods are trivial one liners. This is the bad compile info (nops and blank lines removed): [Verified Entry Point] 0x00007f24675adb20: mov [rsp-0x14000], eax 0x00007f24675adb27: push rbp 0x00007f24675adb28: sub rsp, 0x50 static void topMethod(int, int) @0x00007f246204c790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 5, line = 18 locals ('a', stack[32], normal) ('b', stack[36], normal) ('c', stack[40], normal) ([3], illegal) ([4], illegal) 0x00007f24675adb2c: mov [rsp+0x24], edx static void topMethod(int, int) @0x00007f246204c790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 9, line = 18 0x00007f24675adb30: mov rdi, rsi 0x00007f24675adb33: inc edi 0x00007f24675adb35: mov rbx, rsi 0x00007f24675adb38: mov rsi, rbx 0x00007f24675adb3b: mov [rsp+0x28], edi static void topMethod(int, int) @0x00007f246204c790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 9, line = 18 locals ('a', stack[32], normal) ('b', stack[36], normal) ('c', stack[40], normal) ([3], illegal) ([4], illegal) expressions ([0], stack[44], normal) 0x00007f24675adb3f: mov [rsp+0x20], ebx static void topMethod(int, int) @0x00007f246204c790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 15, line = 19 0x00007f24675adb47: call 0x00007F24675AD520 0x00007f24675adb4c: mov esi, [rsp+0x20] 0x00007f24675adb50: mov [rsp+0x2C], eax static void topMethod(int, int) @0x00007f246204c790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 15, line = 19 locals ('a', stack[32], normal) ('b', stack[36], normal) ('c', stack[40], normal) ('d', stack[48], normal) ([4], illegal) 0x00007f24675adb57: call 0x00007F24675AD7E0 static void topMethod(int, int) @0x00007f246204c790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 19, line = 19 0x00007f24675adb5c: mov edi, [rsp+0x2C] 0x00007f24675adb60: add edi, eax 0x00007f24675adb62: mov esi, [rsp+0x20] static void topMethod(int, int) @0x00007f246204c790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 19, line = 19 locals ('a', stack[32], normal) ('b', stack[36], normal) ('c', stack[40], normal) ('d', stack[48], normal) ([4], illegal) expressions ([0], stack[52], normal) 0x00007f24675adb66: mov [rsp+0x30], edi static void topMethod(int, int) @0x00007f246204c790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 23, line = 19 0x00007f24675adb6f: call 0x00007F24675AD520 static void topMethod(int, int) @0x00007f246204c790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 23, line = 19 locals ('a', stack[32], normal) ('b', stack[36], normal) ('c', stack[40], normal) ('d', stack[48], normal) ([4], illegal) expressions ([0], stack[52], normal) ([1], stack[56], normal) 0x00007f24675adb74: mov esi, [rsp+0x24] 0x00007f24675adb78: mov [rsp+0x34], eax 0x00007f24675adb7f: call 0x00007F24675AD520 0x00007f24675adb84: mov esi, [rsp+0x24] static void topMethod(int, int) @0x00007f246204c790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 31, line = 20 0x00007f24675adb88: mov [rsp+0x38], eax 0x00007f24675adb8f: call 0x00007F24675AD7E0 static void topMethod(int, int) @0x00007f246204c790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 31, line = 20 locals ('a', stack[32], normal) ('b', stack[36], normal) ('c', stack[40], normal) ('d', stack[48], normal) ('e', stack[60], normal) 0x00007f24675adb94: mov esi, [rsp+0x38] 0x00007f24675adb98: sub esi, eax 0x00007f24675adb9a: mov eax, [rsp+0x34] static void topMethod(int, int) @0x00007f246204c790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 37, line = 21 0x00007f24675adb9e: imul eax, esi 0x00007f24675adba1: mov esi, [rsp+0x20] static void topMethod(int, int) @0x00007f246204c790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 37, line = 21 locals ('a', stack[32], normal) ('b', stack[36], normal) ('c', stack[40], normal) ('d', stack[48], normal) ('e', stack[60], normal) 0x00007f24675adba5: mov [rsp+0x3C], eax 0x00007f24675adbaf: call 0x00007F24675AE080 0x00007f24675adbb4: vmovsd xmm0, qword ptr [0x00007F24675ADB00] 0x00007f24675adbbf: call 0x00007F24675AE4C0 0x00007f24675adbc4: add rsp, 0x50 0x00007f24675adbc8: pop rbp 0x00007f24675adbc9: test [0x00007F247EDB0100], eax 0x00007f24675adbcf: ret Note for instance the subtraction which incorrectly appears between descriptors for lines 20 and 21. The local variable info is also incorrect with the value of "d" for instance supposedly available on the stack whilst it is still being computed. By contrast this is what the info looks like with "a" instead of "7.0": [Verified Entry Point] 0x00007f1fc910ea40: mov [rsp-0x14000], eax 0x00007f1fc910ea47: push rbp 0x00007f1fc910ea48: sub rsp, 0x50 static void topMethod(int, int) @0x00007f1fc4553790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 0, line = 17 0x00007f1fc910ea4c: mov [rsp+0x20], esi 0x00007f1fc910ea50: mov [rsp+0x24], edx 0x00007f1fc910ea54: mov rdi, rsi 0x00007f1fc910ea57: inc edi 0x00007f1fc910ea59: mov rbx, rsi 0x00007f1fc910ea5c: mov rsi, rbx static void topMethod(int, int) @0x00007f1fc4553790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 5, line = 18 0x00007f1fc910ea5f: mov [rsp+0x28], edi 0x00007f1fc910ea67: call 0x00007F1FC910E460 static void topMethod(int, int) @0x00007f1fc4553790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 5, line = 18 locals ('a', stack[32], normal) ('b', stack[36], normal) ('c', stack[40], normal) ([3], illegal) ([4], illegal) 0x00007f1fc910ea6c: mov esi, [rsp+0x20] static void topMethod(int, int) @0x00007f1fc4553790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 9, line = 18 0x00007f1fc910ea70: mov [rsp+0x2C], eax 0x00007f1fc910ea77: call 0x00007F1FC910E720 static void topMethod(int, int) @0x00007f1fc4553790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 9, line = 18 locals ('a', stack[32], normal) ('b', stack[36], normal) ('c', stack[40], normal) ([3], illegal) ([4], illegal) expressions ([0], stack[44], normal) 0x00007f1fc910ea7c: mov edi, [rsp+0x2C] 0x00007f1fc910ea80: add edi, eax 0x00007f1fc910ea82: mov esi, [rsp+0x20] static void topMethod(int, int) @0x00007f1fc4553790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 15, line = 19 0x00007f1fc910ea86: mov [rsp+0x30], edi 0x00007f1fc910ea8f: call 0x00007F1FC910E460 static void topMethod(int, int) @0x00007f1fc4553790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 15, line = 19 locals ('a', stack[32], normal) ('b', stack[36], normal) ('c', stack[40], normal) ('d', stack[48], normal) ([4], illegal) 0x00007f1fc910ea94: mov esi, [rsp+0x24] static void topMethod(int, int) @0x00007f1fc4553790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 19, line = 19 0x00007f1fc910ea98: mov [rsp+0x34], eax 0x00007f1fc910ea9f: call 0x00007F1FC910E460 static void topMethod(int, int) @0x00007f1fc4553790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 19, line = 19 locals ('a', stack[32], normal) ('b', stack[36], normal) ('c', stack[40], normal) ('d', stack[48], normal) ([4], illegal) expressions ([0], stack[52], normal) 0x00007f1fc910eaa4: mov esi, [rsp+0x24] static void topMethod(int, int) @0x00007f1fc4553790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 23, line = 19 0x00007f1fc910eaa8: mov [rsp+0x38], eax 0x00007f1fc910eaaf: call 0x00007F1FC910E720 static void topMethod(int, int) @0x00007f1fc4553790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 23, line = 19 locals ('a', stack[32], normal) ('b', stack[36], normal) ('c', stack[40], normal) ('d', stack[48], normal) ([4], illegal) expressions ([0], stack[52], normal) ([1], stack[56], normal) 0x00007f1fc910eab4: mov esi, [rsp+0x38] 0x00007f1fc910eab8: sub esi, eax 0x00007f1fc910eaba: mov eax, [rsp+0x34] 0x00007f1fc910eabe: imul eax, esi 0x00007f1fc910eac1: mov esi, [rsp+0x20] static void topMethod(int, int) @0x00007f1fc4553790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 31, line = 20 0x00007f1fc910eac5: mov [rsp+0x3C], eax 0x00007f1fc910eacf: call 0x00007F1FC910EF80 static void topMethod(int, int) @0x00007f1fc4553790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 31, line = 20 locals ('a', stack[32], normal) ('b', stack[36], normal) ('c', stack[40], normal) ('d', stack[48], normal) ('e', stack[60], normal) 0x00007f1fc910ead4: mov esi, [rsp+0x20] 0x00007f1fc910ead8: vcvtsi2sd xmm0, xmm0, esi 0x00007f1fc910eadf: call 0x00007F1FC910F3C0 static void topMethod(int, int) @0x00007f1fc4553790 of public class io.undo.test.GetStateTest @0x0000000100060028 @ bci = 36, line = 21 locals ('a', stack[32], normal) ('b', stack[36], normal) ('c', stack[40], normal) ('d', stack[48], normal) ('e', stack[60], normal) 0x00007f1fc910eae4: add rsp, 0x50 0x00007f1fc910eae8: pop rbp 0x00007f1fc910eae9: test [0x00007F1FE124F100], eax 0x00007f1fc910eaef: ret As you can see the scope info is completely different. I'm just looking to understand what changed after Java 8 to fix this? Any pointers, no matter how vague, would be helpful! PS: this is for our java reverse debugger - https://undo.io/solutions/products/java/ - which works ok but would be even better if we could recreate compiled code state in an interpreter. That's why I'm messing with ScopeDescs. Thanks, David -- David Griffiths, Senior Software Engineer Undo | Accelerate software defect resolution by eliminating the guesswork in failure diagnosis From aph at redhat.com Thu Oct 8 14:25:53 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Oct 2020 15:25:53 +0100 Subject: ScopeDescs incorrect in Java 8 In-Reply-To: References: Message-ID: On 08/10/2020 15:11, David Griffiths wrote: > I'm running with the options "-XX:-Inline -XX:TieredStopAtLevel=1" (there > is a reason for this). The method (called enough times to JIT compile) is: > > 16 static void topMethod(int a, int b) { > 17 int c = a + 1; > 18 int d = iMethodA(a) + iMethodB(a); > 19 int e = iMethodA(a) * (iMethodA(b) - iMethodB(b)); > 20 vMethod(a); > 21 testArgs(7.0); > 22 } > > Simply changing the last line to testArgs(a) results in the ScopeDescs > being ok! The called methods are trivial one liners. This is the bad > compile info (nops and blank lines removed): Please send us a full test case. -- 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 sgehwolf at openjdk.java.net Thu Oct 8 14:49:46 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 8 Oct 2020 14:49:46 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6] In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 14:01:26 GMT, Bob Vandette wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Return false in case of no pattern match > > Marked as reviewed by bobv (Committer). Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From coleenp at openjdk.java.net Thu Oct 8 14:54:46 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Oct 2020 14:54:46 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 13:08:51 GMT, Robbin Ehn wrote: > It's unsafe for all threads except VM thread to access the current vm operation. > This part of the assert is also faulty: > If we are not at safepoint and the operation requester (calling thread) would be the owner of the lock do not mean it > is safe for current thread. > Passes t1-5. (also note VMThread::vm_operation() assert current thread is VM thread, and I have seen no such assert) > > Thanks Marked as reviewed by coleenp (Reviewer). src/hotspot/share/runtime/mutexLocker.cpp line 173: > 171: if (!Universe::is_fully_initialized()) return; > 172: fatal("must own lock %s", lock->name()); > 173: } You could refactor this like: assert_locked_or_safepoint(lock) { if (lock->owned_by_self()) return; assert_locked_or_safepoint_weak(lock); } ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From coleenp at openjdk.java.net Thu Oct 8 14:54:48 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Oct 2020 14:54:48 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On Thu, 8 Oct 2020 14:51:16 GMT, Coleen Phillimore wrote: >> It's unsafe for all threads except VM thread to access the current vm operation. >> This part of the assert is also faulty: >> If we are not at safepoint and the operation requester (calling thread) would be the owner of the lock do not mean it >> is safe for current thread. >> Passes t1-5. (also note VMThread::vm_operation() assert current thread is VM thread, and I have seen no such assert) >> >> Thanks > > src/hotspot/share/runtime/mutexLocker.cpp line 173: > >> 171: if (!Universe::is_fully_initialized()) return; >> 172: fatal("must own lock %s", lock->name()); >> 173: } > > You could refactor this like: > assert_locked_or_safepoint(lock) { > if (lock->owned_by_self()) return; > assert_locked_or_safepoint_weak(lock); > } Nah, never mind. It's a short function. ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From dcubed at openjdk.java.net Thu Oct 8 16:01:23 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 8 Oct 2020 16:01:23 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 13:08:51 GMT, Robbin Ehn wrote: > It's unsafe for all threads except VM thread to access the current vm operation. > This part of the assert is also faulty: > If we are not at safepoint and the operation requester (calling thread) would be the owner of the lock do not mean it > is safe for current thread. > Passes t1-5. (also note VMThread::vm_operation() assert current thread is VM thread, and I have seen no such assert) > > Thanks I'm good with the change, but I had one question about code above the code that you deleted. src/hotspot/share/runtime/mutexLocker.cpp line 171: > 169: if (lock->owned_by_self()) return; > 170: if (SafepointSynchronize::is_at_safepoint()) return; > 171: if (!Universe::is_fully_initialized()) return; Is this bailout on L171 for the code you are deleting (old L172-4) or for the fatal() on old L175? ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/563 From dcubed at openjdk.java.net Thu Oct 8 16:09:20 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 8 Oct 2020 16:09:20 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 15:57:22 GMT, Daniel D. Daugherty wrote: >> It's unsafe for all threads except VM thread to access the current vm operation. >> This part of the assert is also faulty: >> If we are not at safepoint and the operation requester (calling thread) would be the owner of the lock do not mean it >> is safe for current thread. >> Passes t1-5. (also note VMThread::vm_operation() assert current thread is VM thread, and I have seen no such assert) >> >> Thanks > > src/hotspot/share/runtime/mutexLocker.cpp line 171: > >> 169: if (lock->owned_by_self()) return; >> 170: if (SafepointSynchronize::is_at_safepoint()) return; >> 171: if (!Universe::is_fully_initialized()) return; > > Is this bailout on L171 for the code you are deleting (old L172-4) > or for the fatal() on old L175? I was hope that "git blame" would help, but most of this code is ancient: da18495f385b (Coleen Phillimore 2019-08-22 09:51:36 -0400 166) void assert_locked_or_safepoint(const Mutex* lock) { 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 167) // check if this thread owns the lock (common case) 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 168) assert(lock != NULL, "Need non-NULL lock"); 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 169) if (lock->owned_by_self()) return; 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 170) if (SafepointSynchronize::is_at_safepoint()) return; 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 171) if (!Universe::is_fully_initialized()) return; 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 172) // see if invoker of VM operation owns it 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 173) VM_Operation* op = VMThread::vm_operation(); 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 174) if (op != NULL && op->calling_thread() == lock->owner()) return; 1e71f6773659 (David Lindholm 2015-09-29 11:02:08 +0200 175) fatal("must own lock %s", lock->name()); 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 176) } Update: Stripped the filename from the "git blame" output so it wasn't quite so wide... Update: Changing to a `code` quote helped the formatting a bit... ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From dgriffiths at undo.io Thu Oct 8 17:09:58 2020 From: dgriffiths at undo.io (David Griffiths) Date: Thu, 8 Oct 2020 18:09:58 +0100 Subject: ScopeDescs incorrect in Java 8 In-Reply-To: References: Message-ID: Ok, will do. I noticed a mismatch between the assembler produced by my use of HTMLGenerator and that from -XX:CompileCommand=print so need to figure out if I'm doing something stupid first (e.g. I see the use of "7.0" results in a constant section being produced and codeBegin() != getEntryPoint() so could be something related to that). Cheers, David On Thu, 8 Oct 2020 at 15:25, Andrew Haley wrote: > On 08/10/2020 15:11, David Griffiths wrote: > > I'm running with the options "-XX:-Inline -XX:TieredStopAtLevel=1" (there > > is a reason for this). The method (called enough times to JIT compile) > is: > > > > 16 static void topMethod(int a, int b) { > > 17 int c = a + 1; > > 18 int d = iMethodA(a) + iMethodB(a); > > 19 int e = iMethodA(a) * (iMethodA(b) - iMethodB(b)); > > 20 vMethod(a); > > 21 testArgs(7.0); > > 22 } > > > > Simply changing the last line to testArgs(a) results in the ScopeDescs > > being ok! The called methods are trivial one liners. This is the bad > > compile info (nops and blank lines removed): > > Please send us a full test case. > > -- > 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 > > -- David Griffiths, Senior Software Engineer Undo | Accelerate software defect resolution by eliminating the guesswork in failure diagnosis From iignatyev at openjdk.java.net Thu Oct 8 18:38:25 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 8 Oct 2020 18:38:25 GMT Subject: RFR: 8254262: jdk.test.lib.Utils::createTemp* don't pass attrs Message-ID: <9NETUjutw3W3c0XTyqoSsC_TbHNEs1NaYrayyiuXNZk=.d583222d-cae2-4aeb-b168-f48d1eb7af61@github.com> Hi all, `jdk.test.lib.Utils::createTempFile` and `createTempDirectory` methods accept `attrs`, but don't pass it to `java.nio.file.Files::createTempFile` and `createTempDirectory` methods respectively. could you please review this trivial patch which fixes that? Thanks, -- Igor ------------- Commit messages: - 8254262: jdk.test.lib.Utils::createTemp* don't pass attrs Changes: https://git.openjdk.java.net/jdk/pull/567/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=567&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254262 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/567.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/567/head:pull/567 PR: https://git.openjdk.java.net/jdk/pull/567 From shade at openjdk.java.net Thu Oct 8 18:58:27 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 8 Oct 2020 18:58:27 GMT Subject: RFR: 8254262: jdk.test.lib.Utils::createTemp* don't pass attrs In-Reply-To: <9NETUjutw3W3c0XTyqoSsC_TbHNEs1NaYrayyiuXNZk=.d583222d-cae2-4aeb-b168-f48d1eb7af61@github.com> References: <9NETUjutw3W3c0XTyqoSsC_TbHNEs1NaYrayyiuXNZk=.d583222d-cae2-4aeb-b168-f48d1eb7af61@github.com> Message-ID: <3kUWPKiFahlK6wXm5PaM0Q5N4hs4btNm0_X1Bm3W4J0=.78fa431f-82a5-45f9-a9da-ce06d6e8a7f6@github.com> On Thu, 8 Oct 2020 18:32:15 GMT, Igor Ignatyev wrote: > Hi all, > > `jdk.test.lib.Utils::createTempFile` and `createTempDirectory` methods accept `attrs`, but don't pass it to > `java.nio.file.Files::createTempFile` and `createTempDirectory` methods respectively. could you please review this > trivial patch which fixes that? Thanks, > -- Igor Looks fine. There seems to be no uses of `Utils.createTempFile` or `Utils.createTempDirectory` with extended attributes, so there is no affected tests, and no further testing needed, right? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/567 From mdoerr at openjdk.java.net Thu Oct 8 19:11:23 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 8 Oct 2020 19:11:23 GMT Subject: RFR: 8254244: Some code emitted by TemplateTable::branch is unused when running TieredCompilation In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 15:26:22 GMT, Claes Redestad wrote: > On x86, arm, aarch64 and s390, TemplateTable::branch emits code to allocate a MethodData which is never called if > running TieredCompilation. Skipping it slightly reduces interpreter code size and results in a minor startup > improvement (~100k instructions less). The PPC implementation differs significantly, and is left untouched. Hi Claes, looks good. Seems like PPC was implemented like SPARC which was a bit different and is not affected by this issue. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/564 From iignatyev at openjdk.java.net Thu Oct 8 19:12:22 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 8 Oct 2020 19:12:22 GMT Subject: RFR: 8254262: jdk.test.lib.Utils::createTemp* don't pass attrs In-Reply-To: <3kUWPKiFahlK6wXm5PaM0Q5N4hs4btNm0_X1Bm3W4J0=.78fa431f-82a5-45f9-a9da-ce06d6e8a7f6@github.com> References: <9NETUjutw3W3c0XTyqoSsC_TbHNEs1NaYrayyiuXNZk=.d583222d-cae2-4aeb-b168-f48d1eb7af61@github.com> <3kUWPKiFahlK6wXm5PaM0Q5N4hs4btNm0_X1Bm3W4J0=.78fa431f-82a5-45f9-a9da-ce06d6e8a7f6@github.com> Message-ID: On Thu, 8 Oct 2020 18:55:38 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> `jdk.test.lib.Utils::createTempFile` and `createTempDirectory` methods accept `attrs`, but don't pass it to >> `java.nio.file.Files::createTempFile` and `createTempDirectory` methods respectively. could you please review this >> trivial patch which fixes that? Thanks, >> -- Igor > > Looks fine. There seems to be no uses of `Utils.createTempFile` or `Utils.createTempDirectory` with extended > attributes, so there is no affected tests, and no further testing needed, right? Thanks for your review, Aleksey. > There seems to be no uses of `Utils.createTempFile` or `Utils.createTempDirectory` with extended attributes, so there > is no affected tests, and no further testing needed, right? correct. I should have stated that in the descriptions, there are no existing tests that specify `attrs`, hence no affected tests, and no testing needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/567 From iignatyev at openjdk.java.net Thu Oct 8 19:12:24 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 8 Oct 2020 19:12:24 GMT Subject: Integrated: 8254262: jdk.test.lib.Utils::createTemp* don't pass attrs In-Reply-To: <9NETUjutw3W3c0XTyqoSsC_TbHNEs1NaYrayyiuXNZk=.d583222d-cae2-4aeb-b168-f48d1eb7af61@github.com> References: <9NETUjutw3W3c0XTyqoSsC_TbHNEs1NaYrayyiuXNZk=.d583222d-cae2-4aeb-b168-f48d1eb7af61@github.com> Message-ID: On Thu, 8 Oct 2020 18:32:15 GMT, Igor Ignatyev wrote: > Hi all, > > `jdk.test.lib.Utils::createTempFile` and `createTempDirectory` methods accept `attrs`, but don't pass it to > `java.nio.file.Files::createTempFile` and `createTempDirectory` methods respectively. could you please review this > trivial patch which fixes that? Thanks, > -- Igor This pull request has now been integrated. Changeset: 5351ba6c Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/5351ba6c Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8254262: jdk.test.lib.Utils::createTemp* don't pass attrs Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/567 From redestad at openjdk.java.net Thu Oct 8 19:38:21 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 8 Oct 2020 19:38:21 GMT Subject: RFR: 8254244: Some code emitted by TemplateTable::branch is unused when running TieredCompilation In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 19:08:14 GMT, Martin Doerr wrote: > Hi Claes, looks good. Seems like PPC was implemented like SPARC which was a bit different and is not affected by this > issue. Martin, thanks for reviewing and checking PPC. ------------- PR: https://git.openjdk.java.net/jdk/pull/564 From dholmes at openjdk.java.net Thu Oct 8 22:17:19 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Oct 2020 22:17:19 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 13:08:51 GMT, Robbin Ehn wrote: > It's unsafe for all threads except VM thread to access the current vm operation. > This part of the assert is also faulty: > If we are not at safepoint and the operation requester (calling thread) would be the owner of the lock do not mean it > is safe for current thread. > Passes t1-5. (also note VMThread::vm_operation() assert current thread is VM thread, and I have seen no such assert) > > Thanks Changes requested by dholmes (Reviewer). src/hotspot/share/runtime/mutexLocker.cpp line 170: > 168: assert(lock != NULL, "Need non-NULL lock"); > 169: if (lock->owned_by_self()) return; > 170: if (SafepointSynchronize::is_at_safepoint()) return; This is actually inadequate as it would only be safe (in a lock sneaking sense) if at a safepoint AND in the vmThread. Ditto for L179. ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From dholmes at openjdk.java.net Thu Oct 8 22:17:20 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Oct 2020 22:17:20 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 16:03:07 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/mutexLocker.cpp line 171: >> >>> 169: if (lock->owned_by_self()) return; >>> 170: if (SafepointSynchronize::is_at_safepoint()) return; >>> 171: if (!Universe::is_fully_initialized()) return; >> >> Is this bailout on L171 for the code you are deleting (old L172-4) >> or for the fatal() on old L175? > > I was hope that "git blame" would help, but most of this code is ancient: > > da18495f385b (Coleen Phillimore 2019-08-22 09:51:36 -0400 166) void assert_locked_or_safepoint(const Mutex* lock) { > 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 167) // check if this thread owns the lock (common case) > 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 168) assert(lock != NULL, "Need non-NULL lock"); > 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 169) if (lock->owned_by_self()) return; > 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 170) if (SafepointSynchronize::is_at_safepoint()) return; > 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 171) if (!Universe::is_fully_initialized()) return; > 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 172) // see if invoker of VM operation owns it > 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 173) VM_Operation* op = VMThread::vm_operation(); > 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 174) if (op != NULL && op->calling_thread() == > lock->owner()) return; 1e71f6773659 (David Lindholm 2015-09-29 11:02:08 +0200 175) fatal("must own lock %s", > lock->name()); 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 176) } > > Update: Stripped the filename from the "git blame" output so it wasn't quite so wide... > Update: Changing to a `code` quote helped the formatting a bit... The initialization bail-out was added "1.86 99/02/19 17:05:07", but no comments or associated bug report. ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From coleenp at openjdk.java.net Thu Oct 8 22:54:18 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Oct 2020 22:54:18 GMT Subject: RFR: 8254244: Some code emitted by TemplateTable::branch is unused when running TieredCompilation In-Reply-To: References: Message-ID: <2cdAlTHn54yHIQHnof6uahQCXbiFSlrSd5kE08xIPKA=.b6c96518-6aa2-4fab-9a9d-2f304080db74@github.com> On Thu, 8 Oct 2020 15:26:22 GMT, Claes Redestad wrote: > On x86, arm, aarch64 and s390, TemplateTable::branch emits code to allocate a MethodData which is never called if > running TieredCompilation. Skipping it slightly reduces interpreter code size and results in a minor startup > improvement (~100k instructions less). The PPC implementation differs significantly, and is left untouched. LGTM! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/564 From iveresov at openjdk.java.net Fri Oct 9 01:27:19 2020 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 9 Oct 2020 01:27:19 GMT Subject: RFR: 8254244: Some code emitted by TemplateTable::branch is unused when running TieredCompilation In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 15:26:22 GMT, Claes Redestad wrote: > On x86, arm, aarch64 and s390, TemplateTable::branch emits code to allocate a MethodData which is never called if > running TieredCompilation. Skipping it slightly reduces interpreter code size and results in a minor startup > improvement (~100k instructions less). The PPC implementation differs significantly, and is left untouched. Marked as reviewed by iveresov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/564 From rehn at openjdk.java.net Fri Oct 9 06:16:18 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 9 Oct 2020 06:16:18 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 22:11:12 GMT, David Holmes wrote: >> I was hope that "git blame" would help, but most of this code is ancient: >> >> da18495f385b (Coleen Phillimore 2019-08-22 09:51:36 -0400 166) void assert_locked_or_safepoint(const Mutex* lock) { >> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 167) // check if this thread owns the lock (common case) >> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 168) assert(lock != NULL, "Need non-NULL lock"); >> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 169) if (lock->owned_by_self()) return; >> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 170) if (SafepointSynchronize::is_at_safepoint()) return; >> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 171) if (!Universe::is_fully_initialized()) return; >> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 172) // see if invoker of VM operation owns it >> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 173) VM_Operation* op = VMThread::vm_operation(); >> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 174) if (op != NULL && op->calling_thread() == >> lock->owner()) return; 1e71f6773659 (David Lindholm 2015-09-29 11:02:08 +0200 175) fatal("must own lock %s", >> lock->name()); 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 176) } >> >> Update: Stripped the filename from the "git blame" output so it wasn't quite so wide... >> Update: Changing to a `code` quote helped the formatting a bit... > > The initialization bail-out was added "1.86 99/02/19 17:05:07", but no comments or associated bug report. Universe is initialized before VM thread is ready to process operations. So while that bail-out is true, there can never be any vm ops. I believe instead of: `if (!Universe::is_fully_initialized()) return;` We really want: `if (Threads::number_of_threads() == 0) return;` But I'm not sure and totally out of scope. ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From rehn at openjdk.java.net Fri Oct 9 06:21:22 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 9 Oct 2020 06:21:22 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 22:02:34 GMT, David Holmes wrote: >> It's unsafe for all threads except VM thread to access the current vm operation. >> This part of the assert is also faulty: >> If we are not at safepoint and the operation requester (calling thread) would be the owner of the lock do not mean it >> is safe for current thread. >> Passes t1-5. (also note VMThread::vm_operation() assert current thread is VM thread, and I have seen no such assert) >> >> Thanks > > src/hotspot/share/runtime/mutexLocker.cpp line 170: > >> 168: assert(lock != NULL, "Need non-NULL lock"); >> 169: if (lock->owned_by_self()) return; >> 170: if (SafepointSynchronize::is_at_safepoint()) return; > > This is actually inadequate as it would only be safe (in a lock sneaking sense) if at a safepoint AND in the vmThread. > Ditto for L179. It is also safe for threads respecting the safepoint e.g. GC safepoint worker (safepoint cannot end until the safepoint workers stops). In some cases we do not use Mutex during safepoint when executing with such thread. But an entire over-haul of these asserts and what the implicit rules are is out of scope here. ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From shade at openjdk.java.net Fri Oct 9 09:27:20 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Oct 2020 09:27:20 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6] In-Reply-To: References: Message-ID: <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com> On Thu, 8 Oct 2020 13:38:59 GMT, Severin Gehwolf wrote: >> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the >> affected system, `/proc/self/mountinfo` contains a line such as this one: >> >> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd >> >> >> Note that `/proc/cgroups` looks like this: >> >> #subsys_name hierarchy num_cgroups enabled >> cpuset 0 1 1 >> cpu 0 1 1 >> cpuacct 0 1 1 >> blkio 0 1 1 >> memory 0 1 1 >> devices 0 1 1 >> freezer 0 1 1 >> net_cls 0 1 1 >> perf_event 0 1 1 >> net_prio 0 1 1 >> hugetlb 0 1 1 >> pids 0 1 1 >> >> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo >> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in >> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, >> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to >> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's >> cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also >> to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific >> objects. In order to not regress here, I've added more tests. >> **Testing** >> >> - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) >> - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) >> - [x] Added regression test which fails prior the patch and passes after >> - [x] Submit testing > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Return false in case of no pattern match This looks fine to me. Consider a minor nit below. src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 183: > 181: } > 182: } > 183: return relevantControllerFound; If I am reading the code right, then `relevantControllerFound` can be replaced with just `return true` or `return false`? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Fri Oct 9 09:49:19 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 9 Oct 2020 09:49:19 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6] In-Reply-To: <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com> References: <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com> Message-ID: On Fri, 9 Oct 2020 09:23:22 GMT, Aleksey Shipilev wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Return false in case of no pattern match > > src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 183: > >> 181: } >> 182: } >> 183: return relevantControllerFound; > > If I am reading the code right, then `relevantControllerFound` can be replaced with just `return true` or `return > false`? I don't think so. It starts out as `false` and is being set to true on lines 180 and 174. So we could change it to `return false` here iff lines 174 and 180 would `return true`. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From shade at openjdk.java.net Fri Oct 9 09:54:19 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Oct 2020 09:54:19 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6] In-Reply-To: References: <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com> Message-ID: On Fri, 9 Oct 2020 09:46:55 GMT, Severin Gehwolf wrote: >> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 183: >> >>> 181: } >>> 182: } >>> 183: return relevantControllerFound; >> >> If I am reading the code right, then `relevantControllerFound` can be replaced with just `return true` or `return >> false`? > > I don't think so. It starts out as `false` and is being set to true on lines 180 and 174. So we could change it to > `return false` here iff lines 174 and 180 would `return true`. Yes, that's what I meant: instead of dragging the boolean flag, do the early `return true`, or `return false` otherwise. Your choice if you want to make that change. ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From dgriffiths at undo.io Fri Oct 9 10:14:11 2020 From: dgriffiths at undo.io (David Griffiths) Date: Fri, 9 Oct 2020 11:14:11 +0100 Subject: ScopeDescs incorrect in Java 8 In-Reply-To: References: Message-ID: I've managed to fix it in PCDesc.getRealPC but am a bit baffled as to the nature of the fix. In the bad case (7.0) we have a constants area at the start like this: Decoding compiled method 0x00007fe077bf56d0: Code: [Constants] 0x00007fe077bf5880 (offset: 0): 0x00000000 0x401c000000000000 0x00007fe077bf5884 (offset: 4): 0x401c0000 0x00007fe077bf5888 (offset: 8): 0xf4f4f4f4 0xf4f4f4f4f4f4f4f4 0x00007fe077bf588c (offset: 12): 0xf4f4f4f4 0x00007fe077bf5890 (offset: 16): 0xf4f4f4f4 0xf4f4f4f4f4f4f4f4 0x00007fe077bf5894 (offset: 20): 0xf4f4f4f4 0x00007fe077bf5898 (offset: 24): 0xf4f4f4f4 0xf4f4f4f4f4f4f4f4 0x00007fe077bf589c (offset: 28): 0xf4f4f4f4 [Disassembling for mach='i386:x86-64'] [Entry Point] [Verified Entry Point] # {method} {0x00007fe07292c790} 'topMethod' '(II)V' in 'io/undo/test/GetStateTest' # parm0: rsi = int # parm1: rdx = int # [sp+0x60] (sp of caller) 0x00007fe077bf58a0: mov %eax,-0x14000(%rsp) ; {no_reloc} 0x00007fe077bf58a7: push %rbp 0x00007fe077bf58a8: sub $0x50,%rsp ;*iload_0 ; - io.undo.test.GetStateTest::topMethod at 0 (line 17) the problem is that the PCDesc.getRealPC returns the pc offset plus codeBegin(). But in this case codeBegin points at the constants area (0x00007fe077bf5880) not the entry point (0x00007fe077bf58a0) and so all the PCDescs are incorrect. Simply changing PCDesc.getRealPC to use code.getEntryPoint() instead fixes the problem. Ah... wait... found it. There is a bug in CodeBlob: public Address codeBegin() { return headerBegin().addOffsetTo(contentOffsetField.getValue(addr)); } That should be codeOffsetField! On Thu, 8 Oct 2020 at 18:09, David Griffiths wrote: > Ok, will do. I noticed a mismatch between the assembler produced by my use > of HTMLGenerator and that from -XX:CompileCommand=print so need to figure > out if I'm doing something stupid first (e.g. I see the use of "7.0" > results in a constant section being produced and codeBegin() != > getEntryPoint() so could be something related to that). > > Cheers, > > David > > On Thu, 8 Oct 2020 at 15:25, Andrew Haley wrote: > >> On 08/10/2020 15:11, David Griffiths wrote: >> > I'm running with the options "-XX:-Inline -XX:TieredStopAtLevel=1" >> (there >> > is a reason for this). The method (called enough times to JIT compile) >> is: >> > >> > 16 static void topMethod(int a, int b) { >> > 17 int c = a + 1; >> > 18 int d = iMethodA(a) + iMethodB(a); >> > 19 int e = iMethodA(a) * (iMethodA(b) - iMethodB(b)); >> > 20 vMethod(a); >> > 21 testArgs(7.0); >> > 22 } >> > >> > Simply changing the last line to testArgs(a) results in the ScopeDescs >> > being ok! The called methods are trivial one liners. This is the bad >> > compile info (nops and blank lines removed): >> >> Please send us a full test case. >> >> -- >> 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 >> >> > > -- > David Griffiths, Senior Software Engineer > > Undo | Accelerate software defect resolution by > eliminating the guesswork in failure diagnosis > -- David Griffiths, Senior Software Engineer Undo | Accelerate software defect resolution by eliminating the guesswork in failure diagnosis From sgehwolf at openjdk.java.net Fri Oct 9 10:24:34 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 9 Oct 2020 10:24:34 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v7] In-Reply-To: References: Message-ID: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also > to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific > objects. In order to not regress here, I've added more tests. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [x] Submit testing Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Drop local variable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/485/files - new: https://git.openjdk.java.net/jdk/pull/485/files/37f5b093..c18be739 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=05-06 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Fri Oct 9 10:24:34 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 9 Oct 2020 10:24:34 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v6] In-Reply-To: References: <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com> Message-ID: On Fri, 9 Oct 2020 09:51:29 GMT, Aleksey Shipilev wrote: >> I don't think so. It starts out as `false` and is being set to true on lines 180 and 174. So we could change it to >> `return false` here iff lines 174 and 180 would `return true`. > > Yes, that's what I meant: instead of dragging the boolean flag, do the early `return true`, or `return false` > otherwise. Your choice if you want to make that change. OK, done. Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From redestad at openjdk.java.net Fri Oct 9 11:05:20 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 9 Oct 2020 11:05:20 GMT Subject: Integrated: 8254244: Some code emitted by TemplateTable::branch is unused when running TieredCompilation In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 15:26:22 GMT, Claes Redestad wrote: > On x86, arm, aarch64 and s390, TemplateTable::branch emits code to allocate a MethodData which is never called if > running TieredCompilation. Skipping it slightly reduces interpreter code size and results in a minor startup > improvement (~100k instructions less). The PPC implementation differs significantly, and is left untouched. This pull request has now been integrated. Changeset: 9cecc167 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/9cecc167 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod 8254244: Some code emitted by TemplateTable::branch is unused when running TieredCompilation Reviewed-by: mdoerr, coleenp, iveresov ------------- PR: https://git.openjdk.java.net/jdk/pull/564 From redestad at openjdk.java.net Fri Oct 9 11:05:19 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 9 Oct 2020 11:05:19 GMT Subject: RFR: 8254244: Some code emitted by TemplateTable::branch is unused when running TieredCompilation In-Reply-To: References: Message-ID: <_tZ22A8zQFoc4rzir_sU0zgwnPJZWQ1sjVAG1Zx7U1w=.08100886-d809-4f4d-a086-c136ce38ee8c@github.com> On Fri, 9 Oct 2020 01:24:41 GMT, Igor Veresov wrote: >> On x86, arm, aarch64 and s390, TemplateTable::branch emits code to allocate a MethodData which is never called if >> running TieredCompilation. Skipping it slightly reduces interpreter code size and results in a minor startup >> improvement (~100k instructions less). The PPC implementation differs significantly, and is left untouched. > > Marked as reviewed by iveresov (Reviewer). Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/564 From aph at redhat.com Fri Oct 9 12:55:26 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Oct 2020 13:55:26 +0100 Subject: ScopeDescs incorrect in Java 8 In-Reply-To: References: Message-ID: On 09/10/2020 11:14, David Griffiths wrote: > > Ah... wait... found it. There is a bug in CodeBlob: > > ? public Address codeBegin() { > ? ? return headerBegin().addOffsetTo(contentOffsetField.getValue(addr)); > ? } > > That should be codeOffsetField! Wow. Here's part of the patch that added codeBegin(): + public Address codeBegin() { + return headerBegin().addOffsetTo(contentOffsetField.getValue(addr)); + } + + public Address codeEnd() { return headerBegin().addOffsetTo(dataOffsetField.getValue(addr)); } It looks like much of this code was rewritten in 8151956, Support non-continuous CodeBlobs in HotSpot, so the bug no longer exists. If you can come up with a bug report that explains the bug in more detail and why your fix is correct, please post it as a reply to this mail. I'll create the bug database entry and we'll get it fixed as a JDK 8-only bug. (CC: added, jdk8u-dev) -- 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 david.holmes at oracle.com Fri Oct 9 13:34:35 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Oct 2020 23:34:35 +1000 Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: <3bfe0407-0ea3-8c1c-6337-fa283c18f578@oracle.com> On 9/10/2020 4:16 pm, Robbin Ehn wrote: > On Thu, 8 Oct 2020 22:11:12 GMT, David Holmes wrote: > >>> I was hope that "git blame" would help, but most of this code is ancient: >>> >>> da18495f385b (Coleen Phillimore 2019-08-22 09:51:36 -0400 166) void assert_locked_or_safepoint(const Mutex* lock) { >>> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 167) // check if this thread owns the lock (common case) >>> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 168) assert(lock != NULL, "Need non-NULL lock"); >>> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 169) if (lock->owned_by_self()) return; >>> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 170) if (SafepointSynchronize::is_at_safepoint()) return; >>> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 171) if (!Universe::is_fully_initialized()) return; >>> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 172) // see if invoker of VM operation owns it >>> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 173) VM_Operation* op = VMThread::vm_operation(); >>> 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 174) if (op != NULL && op->calling_thread() == >>> lock->owner()) return; 1e71f6773659 (David Lindholm 2015-09-29 11:02:08 +0200 175) fatal("must own lock %s", >>> lock->name()); 8153779ad32d (J. Duke 2007-12-01 00:00:00 +0000 176) } >>> >>> Update: Stripped the filename from the "git blame" output so it wasn't quite so wide... >>> Update: Changing to a `code` quote helped the formatting a bit... >> >> The initialization bail-out was added "1.86 99/02/19 17:05:07", but no comments or associated bug report. > > Universe is initialized before VM thread is ready to process operations. > So while that bail-out is true, there can never be any vm ops. > > I believe instead of: > `if (!Universe::is_fully_initialized()) return;` > We really want: > `if (Threads::number_of_threads() == 0) return;` > But I'm not sure and totally out of scope. The way these things typically work is: - code crashes because X has not yet been initialized - X is known to be initialized when Universe::is_fully_initialized() => skip if !Universe::is_fully_initialized() X likely relates to a later check that can't be made early during VM init. So we just have to skip it. Without knowing what X actually is we can't say if there is a more precise expression to check. Of course X may no longer exist. :) Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/563 > From david.holmes at oracle.com Fri Oct 9 13:40:03 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Oct 2020 23:40:03 +1000 Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: <45e10f92-092a-fc68-99a6-43106067893b@oracle.com> On 9/10/2020 4:21 pm, Robbin Ehn wrote: > On Thu, 8 Oct 2020 22:02:34 GMT, David Holmes wrote: > >>> It's unsafe for all threads except VM thread to access the current vm operation. >>> This part of the assert is also faulty: >>> If we are not at safepoint and the operation requester (calling thread) would be the owner of the lock do not mean it >>> is safe for current thread. >>> Passes t1-5. (also note VMThread::vm_operation() assert current thread is VM thread, and I have seen no such assert) >>> >>> Thanks >> >> src/hotspot/share/runtime/mutexLocker.cpp line 170: >> >>> 168: assert(lock != NULL, "Need non-NULL lock"); >>> 169: if (lock->owned_by_self()) return; >>> 170: if (SafepointSynchronize::is_at_safepoint()) return; >> >> This is actually inadequate as it would only be safe (in a lock sneaking sense) if at a safepoint AND in the vmThread. >> Ditto for L179. > > It is also safe for threads respecting the safepoint e.g. GC safepoint worker (safepoint cannot end until the safepoint > workers stops). In some cases we do not use Mutex during safepoint when executing with such thread. True > But an entire over-haul of these asserts and what the implicit rules are is out of scope here. Yes and I think if we can't formulate the exact condition then logically we have: (is_at_safepoint() && is_VMThread()) || (is_at_safepoint() && complexConditionWeHaveToAssumeIsTrue()) which simplifies to just is_at_safepoint() :) Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/563 > From dcubed at openjdk.java.net Fri Oct 9 14:30:13 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 9 Oct 2020 14:30:13 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 22:14:17 GMT, David Holmes wrote: >> It's unsafe for all threads except VM thread to access the current vm operation. >> This part of the assert is also faulty: >> If we are not at safepoint and the operation requester (calling thread) would be the owner of the lock do not mean it >> is safe for current thread. >> Passes t1-5. (also note VMThread::vm_operation() assert current thread is VM thread, and I have seen no such assert) >> >> Thanks > > Changes requested by dholmes (Reviewer). > > But an entire over-haul of these asserts and what the implicit rules are is out of scope here. > > Yes and I think if we can't formulate the exact condition then logically > we have: > > (is_at_safepoint() && is_VMThread()) || (is_at_safepoint() && > complexConditionWeHaveToAssumeIsTrue()) > > which simplifies to just > > is_at_safepoint() > > :) I love `complexConditionWeHaveToAssumeIsTrue()`!! Ahhhhh... thanks for giving me a reason to smile on Friday morning!! ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From jiefu at openjdk.java.net Fri Oct 9 14:33:17 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 9 Oct 2020 14:33:17 GMT Subject: RFR: 8254297: Zero and Minimal VMs are broken with undeclared identifier 'DerivedPointerTable' after JDK-8253180 Message-ID: The change fixes Zero and Minimal builds broken after JDK-8253180. Two build errors were fixed: 1 ./src/hotspot/share/runtime/frame.cpp:1047:38: error: use of undeclared identifier 'DerivedPointerTable' oops_do_internal(f, cf, map, true, DerivedPointerTable::is_active() ? 2. ./src/hotspot/share/utilities/vmError.cpp: In static member function 'static void VMError::print_stack_trace(outputStream*, JavaThread*, char*, int, bool)': ./src/hotspot/share/utilities/vmError.cpp:214:28: error: no matching function for call to 'StackFrameStream::StackFrameStream(JavaThread*&)' StackFrameStream sfs(jt); ^ ------------- Commit messages: - Zero and Minimal VMs are broken with undeclared identifier 'DerivedPointerTable' after JDK-8253180 Changes: https://git.openjdk.java.net/jdk/pull/578/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=578&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254297 Stats: 7 lines in 3 files changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/578.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/578/head:pull/578 PR: https://git.openjdk.java.net/jdk/pull/578 From pchilanomate at openjdk.java.net Fri Oct 9 14:37:21 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 9 Oct 2020 14:37:21 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() Message-ID: Hi all, Please review the following patch that removes the call to handle_special_runtime_exit_condition() in ~ThreadInVMForHandshake(). This check was added by 8223572 to prevent a JavaThread that was suspended while trying to process a handshake to transition back to java without noticing it was suspended. Since 8238761, a JavaThread executing HandshakeState::process_by_self() will never become safe. It comes from an unsafe state and remains unsafe, so it cannot be suspended during that time. Removing this check also removes one of the reasons SafepointMechanism::process_if_requested() is recursive (the other one remains SafepointSynchronize::block()). Tested in mach5, tiers 1-7. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.java.net/jdk/pull/577/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=577&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254263 Stats: 28 lines in 3 files changed: 5 ins; 20 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/577/head:pull/577 PR: https://git.openjdk.java.net/jdk/pull/577 From iignatyev at openjdk.java.net Fri Oct 9 14:38:20 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 9 Oct 2020 14:38:20 GMT Subject: RFR: 8254261: fix javadocs in jdk.test.lib.Utils Message-ID: <_Kpcz6grFPqls7ipSE78giOf1U_LuZRD4mdBCPFDinc=.9f5c565b-e7f3-4be0-a1a0-923ed07ed3e1@github.com> Hi all, could you please review this trivial fix of javadocs in `jdk.test.lib.Utils`? -- Igor ------------- Commit messages: - 8254261: fix javadocs in jdk.test.lib.Utils Changes: https://git.openjdk.java.net/jdk/pull/566/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=566&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254261 Stats: 27 lines in 1 file changed: 4 ins; 2 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/566.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/566/head:pull/566 PR: https://git.openjdk.java.net/jdk/pull/566 From shade at openjdk.java.net Fri Oct 9 14:43:14 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Oct 2020 14:43:14 GMT Subject: RFR: 8254261: fix javadocs in jdk.test.lib.Utils In-Reply-To: <_Kpcz6grFPqls7ipSE78giOf1U_LuZRD4mdBCPFDinc=.9f5c565b-e7f3-4be0-a1a0-923ed07ed3e1@github.com> References: <_Kpcz6grFPqls7ipSE78giOf1U_LuZRD4mdBCPFDinc=.9f5c565b-e7f3-4be0-a1a0-923ed07ed3e1@github.com> Message-ID: On Thu, 8 Oct 2020 18:27:16 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial fix of javadocs in `jdk.test.lib.Utils`? > > -- Igor Looks fine to me. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/566 From iignatyev at openjdk.java.net Fri Oct 9 14:50:13 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 9 Oct 2020 14:50:13 GMT Subject: RFR: 8254261: fix javadocs in jdk.test.lib.Utils In-Reply-To: References: <_Kpcz6grFPqls7ipSE78giOf1U_LuZRD4mdBCPFDinc=.9f5c565b-e7f3-4be0-a1a0-923ed07ed3e1@github.com> Message-ID: On Fri, 9 Oct 2020 14:40:41 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> could you please review this trivial fix of javadocs in `jdk.test.lib.Utils`? >> >> -- Igor > > Looks fine to me. Thanks Aleksey. ------------- PR: https://git.openjdk.java.net/jdk/pull/566 From iignatyev at openjdk.java.net Fri Oct 9 14:50:14 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 9 Oct 2020 14:50:14 GMT Subject: Integrated: 8254261: fix javadocs in jdk.test.lib.Utils In-Reply-To: <_Kpcz6grFPqls7ipSE78giOf1U_LuZRD4mdBCPFDinc=.9f5c565b-e7f3-4be0-a1a0-923ed07ed3e1@github.com> References: <_Kpcz6grFPqls7ipSE78giOf1U_LuZRD4mdBCPFDinc=.9f5c565b-e7f3-4be0-a1a0-923ed07ed3e1@github.com> Message-ID: On Thu, 8 Oct 2020 18:27:16 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this trivial fix of javadocs in `jdk.test.lib.Utils`? > > -- Igor This pull request has now been integrated. Changeset: 7e80c989 Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/7e80c989 Stats: 27 lines in 1 file changed: 4 ins; 2 del; 21 mod 8254261: fix javadocs in jdk.test.lib.Utils Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/566 From shade at openjdk.java.net Fri Oct 9 14:56:26 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Oct 2020 14:56:26 GMT Subject: RFR: 8254297: Zero and Minimal VMs are broken with undeclared identifier 'DerivedPointerTable' after JDK-8253180 In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 14:22:06 GMT, Jie Fu wrote: > The change fixes Zero and Minimal builds broken after JDK-8253180. > > Two build errors were fixed: > 1 ./src/hotspot/share/runtime/frame.cpp:1047:38: error: use of undeclared identifier 'DerivedPointerTable' > oops_do_internal(f, cf, map, true, DerivedPointerTable::is_active() ? > > 2. ./src/hotspot/share/utilities/vmError.cpp: In static member function 'static void > VMError::print_stack_trace(outputStream*, JavaThread*, char*, int, bool)': > ./src/hotspot/share/utilities/vmError.cpp:214:28: error: no matching function for call to > 'StackFrameStream::StackFrameStream(JavaThread*&)' > StackFrameStream sfs(jt); > ^ I think this is fine. @fisk might need to ack this. src/hotspot/share/compiler/oopMap.cpp line 196: > 194: #if COMPILER2_OR_JVMCI > 195: DerivedPointerTable::add(derived, base); > 196: #endif // COMPILER2_OR_JVMCI This looks correct and actually reverses the JDK-8253180 change. It is correct because `DerivedPointerTable` is protected by the same `#if`: #if COMPILER2_OR_JVMCI class DerivedPointerTable : public AllStatic { ... src/hotspot/share/runtime/frame.cpp line 1053: > 1051: #else > 1052: oops_do_internal(f, cf, map, true, DerivedPointerIterationMode::_ignore); > 1053: #endif We could have used `COMPILER2_OR_JVMCI_PRESENT` inline macro, but I think that would be messier. src/hotspot/share/utilities/vmError.cpp line 214: > 212: > 213: // Print the frames > 214: StackFrameStream sfs(jt, true /* update */, true /* process_frames */); This looks correct, also because it does the same thing as L227 below does. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/578 From eosterlund at openjdk.java.net Fri Oct 9 15:00:18 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 9 Oct 2020 15:00:18 GMT Subject: RFR: 8254297: Zero and Minimal VMs are broken with undeclared identifier 'DerivedPointerTable' after JDK-8253180 In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 14:22:06 GMT, Jie Fu wrote: > The change fixes Zero and Minimal builds broken after JDK-8253180. > > Two build errors were fixed: > 1 ./src/hotspot/share/runtime/frame.cpp:1047:38: error: use of undeclared identifier 'DerivedPointerTable' > oops_do_internal(f, cf, map, true, DerivedPointerTable::is_active() ? > > 2. ./src/hotspot/share/utilities/vmError.cpp: In static member function 'static void > VMError::print_stack_trace(outputStream*, JavaThread*, char*, int, bool)': > ./src/hotspot/share/utilities/vmError.cpp:214:28: error: no matching function for call to > 'StackFrameStream::StackFrameStream(JavaThread*&)' > StackFrameStream sfs(jt); > ^ Looks good. Thanks for fixing. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/578 From shade at openjdk.java.net Fri Oct 9 15:05:11 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Oct 2020 15:05:11 GMT Subject: RFR: 8254297: Zero and Minimal VMs are broken with undeclared identifier 'DerivedPointerTable' after JDK-8253180 In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 14:57:10 GMT, Erik ?sterlund wrote: >> The change fixes Zero and Minimal builds broken after JDK-8253180. >> >> Two build errors were fixed: >> 1 ./src/hotspot/share/runtime/frame.cpp:1047:38: error: use of undeclared identifier 'DerivedPointerTable' >> oops_do_internal(f, cf, map, true, DerivedPointerTable::is_active() ? >> >> 2. ./src/hotspot/share/utilities/vmError.cpp: In static member function 'static void >> VMError::print_stack_trace(outputStream*, JavaThread*, char*, int, bool)': >> ./src/hotspot/share/utilities/vmError.cpp:214:28: error: no matching function for call to >> 'StackFrameStream::StackFrameStream(JavaThread*&)' >> StackFrameStream sfs(jt); >> ^ > > Looks good. Thanks for fixing. Since mainline contains both #546 (merged yesterday) and #296 (merged today), most testing would now fail on builds steps. @DamonFool, please integrate as soon as possible! ------------- PR: https://git.openjdk.java.net/jdk/pull/578 From jiefu at openjdk.java.net Fri Oct 9 15:21:12 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 9 Oct 2020 15:21:12 GMT Subject: RFR: 8254297: Zero and Minimal VMs are broken with undeclared identifier 'DerivedPointerTable' after JDK-8253180 In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 15:02:19 GMT, Aleksey Shipilev wrote: >> Looks good. Thanks for fixing. > > Since mainline contains both #546 (merged yesterday) and #296 (merged today), most testing would now fail on builds > steps. @DamonFool, please integrate as soon as possible! Thanks @shipilev and @fisk for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/578 From jiefu at openjdk.java.net Fri Oct 9 15:21:12 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 9 Oct 2020 15:21:12 GMT Subject: Integrated: 8254297: Zero and Minimal VMs are broken with undeclared identifier 'DerivedPointerTable' after JDK-8253180 In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 14:22:06 GMT, Jie Fu wrote: > The change fixes Zero and Minimal builds broken after JDK-8253180. > > Two build errors were fixed: > 1 ./src/hotspot/share/runtime/frame.cpp:1047:38: error: use of undeclared identifier 'DerivedPointerTable' > oops_do_internal(f, cf, map, true, DerivedPointerTable::is_active() ? > > 2. ./src/hotspot/share/utilities/vmError.cpp: In static member function 'static void > VMError::print_stack_trace(outputStream*, JavaThread*, char*, int, bool)': > ./src/hotspot/share/utilities/vmError.cpp:214:28: error: no matching function for call to > 'StackFrameStream::StackFrameStream(JavaThread*&)' > StackFrameStream sfs(jt); > ^ This pull request has now been integrated. Changeset: aaa0a2a0 Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/aaa0a2a0 Stats: 7 lines in 3 files changed: 6 ins; 0 del; 1 mod 8254297: Zero and Minimal VMs are broken with undeclared identifier 'DerivedPointerTable' after JDK-8253180 Reviewed-by: shade, eosterlund ------------- PR: https://git.openjdk.java.net/jdk/pull/578 From rehn at openjdk.java.net Fri Oct 9 16:00:14 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 9 Oct 2020 16:00:14 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 14:27:07 GMT, Daniel D. Daugherty wrote: > > > But an entire over-haul of these asserts and what the implicit rules are is out of scope here. > > > > > > Yes and I think if we can't formulate the exact condition then logically > > we have: > > (is_at_safepoint() && is_VMThread()) || (is_at_safepoint() && > > complexConditionWeHaveToAssumeIsTrue()) > > which simplifies to just > > is_at_safepoint() > > :) > > I love `complexConditionWeHaveToAssumeIsTrue()`!! > Ahhhhh... thanks for giving me a reason to smile on Friday morning!! :) ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From sgehwolf at openjdk.java.net Fri Oct 9 16:29:18 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 9 Oct 2020 16:29:18 GMT Subject: Integrated: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 16:34:49 GMT, Severin Gehwolf wrote: > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also > to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific > objects. In order to not regress here, I've added more tests. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [x] Submit testing This pull request has now been integrated. Changeset: 2bbf8a2a Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/2bbf8a2a Stats: 97 lines in 4 files changed: 91 ins; 1 del; 5 mod 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) Reviewed-by: bobv, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/485 From sgehwolf at openjdk.java.net Fri Oct 9 16:29:18 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 9 Oct 2020 16:29:18 GMT Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) [v8] In-Reply-To: References: Message-ID: <_DreJpVrpxOcrH7gxEJKUJDhl4j1QEfaTsSSwzb2AyY=.a3befe30-3cf2-44a6-b86e-ebf108988651@github.com> > An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the > affected system, `/proc/self/mountinfo` contains a line such as this one: > > 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd > > > Note that `/proc/cgroups` looks like this: > > #subsys_name hierarchy num_cgroups enabled > cpuset 0 1 1 > cpu 0 1 1 > cpuacct 0 1 1 > blkio 0 1 1 > memory 0 1 1 > devices 0 1 1 > freezer 0 1 1 > net_cls 0 1 1 > perf_event 0 1 1 > net_prio 0 1 1 > hugetlb 0 1 1 > pids 0 1 1 > > This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo > line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in > mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`, > `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to > set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's > cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar. For the Java side the proposal is also > to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific > objects. In order to not regress here, I've added more tests. > **Testing** > > - [x] Linux x86_64 container tests on cgroup v1 (fastdebug) > - [x] Linux x86_64 container tests on cgroup v2 (fastdebug) > - [x] Added regression test which fails prior the patch and passes after > - [x] Submit testing Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible) ------------- Changes: https://git.openjdk.java.net/jdk/pull/485/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=07 Stats: 97 lines in 4 files changed: 91 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/485.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485 PR: https://git.openjdk.java.net/jdk/pull/485 From rehn at openjdk.java.net Fri Oct 9 16:53:12 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 9 Oct 2020 16:53:12 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: <8kcr2FT2UdyHGxrbw7rukKkThCS3TVviezdAZUgvynQ=.bee5b14e-74a4-4000-a6a3-201e857acef0@github.com> On Thu, 8 Oct 2020 13:22:55 GMT, Aleksey Shipilev wrote: >> It's unsafe for all threads except VM thread to access the current vm operation. >> This part of the assert is also faulty: >> If we are not at safepoint and the operation requester (calling thread) would be the owner of the lock do not mean it >> is safe for current thread. >> Passes t1-5. (also note VMThread::vm_operation() assert current thread is VM thread, and I have seen no such assert) >> >> Thanks > > Looks okay to me. Is it significantly different from `assert_locked_or_safepoint_weak` now? @shipilev and @dholmes-ora you are not listed under "Reviewers" commit message part, can you press the magic button(s) (approve?) so you get the credit! ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From shade at openjdk.java.net Fri Oct 9 16:53:12 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Oct 2020 16:53:12 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: <748buPUDZYSQUCmisd_ZyaXc0LfNl2eDsBfd5qbaNas=.b5cedf8d-e28f-406a-b95b-eaa4fe773c0b@github.com> On Thu, 8 Oct 2020 13:08:51 GMT, Robbin Ehn wrote: > It's unsafe for all threads except VM thread to access the current vm operation. > This part of the assert is also faulty: > If we are not at safepoint and the operation requester (calling thread) would be the owner of the lock do not mean it > is safe for current thread. > Passes t1-5. (also note VMThread::vm_operation() assert current thread is VM thread, and I have seen no such assert) > > Thanks Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From ccheung at openjdk.java.net Fri Oct 9 22:49:30 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 9 Oct 2020 22:49:30 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v4] In-Reply-To: References: Message-ID: > Following up on archiving lambda proxy classes in dynamic CDS archive > ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of > lambda proxy classes in static CDS archive. > When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved > during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will > be of the following format: > `@lambda-proxy: ` > > e.g. > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` > > When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above > `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool > indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool > entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index > and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. > During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not > found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> > IsCDSDumpingEnabled) is involved in the core-libs code.) > Testing: tiers 1,2,3,4. > > Performance results (javac on HelloWorld on linux-x64): > Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " > 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- > 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- > 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- > 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- > 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- > 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- > 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- > 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- > 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- > 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- > ============================================================ > 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- > instr delta = -161497801 -7.2542% > time delta = -24.722 ms -6.5951% 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: - Merge branch 'master' into 8247666 - 1. Symbolic encoding of lambda proxy resolution. An example of @lambda-proxy in the classlist: @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambdabash ()V ()V 2. Removed BadCPIndex.java; added LambdaProxyClassList.java test. 3. Mandy's comments. - Merge branch 'master' into 8247666 - exclude archived lambda proxy classes in the classlist - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi - fix extraneous whitespace - 8247666 (initial commit) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/364/files - new: https://git.openjdk.java.net/jdk/pull/364/files/c82b39f1..09cf61c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=02-03 Stats: 24905 lines in 572 files changed: 15353 ins; 6792 del; 2760 mod Patch: https://git.openjdk.java.net/jdk/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364 PR: https://git.openjdk.java.net/jdk/pull/364 From ccheung at openjdk.java.net Fri Oct 9 23:06:12 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 9 Oct 2020 23:06:12 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v3] In-Reply-To: References: Message-ID: On Fri, 2 Oct 2020 22:47:43 GMT, Mandy Chung 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 five additional commits since >> the last revision: >> - Merge branch 'master' into 8247666 >> - exclude archived lambda proxy classes in the classlist >> - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi >> - fix extraneous whitespace >> - 8247666 (initial commit) > >> @lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233 > @lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355 > > It seems very fragile to require listing the CP index to `invokedynamic` entries of a class file. Have you considered > a simpler usage model without CP indices and default to all `invokedynamic` to `LambdaMetaFactory`? Hi Mandy, Thanks for your review. We've tried the approach of archiving all the lambda proxy classes of a given class but we feel that there will be too many unused lambda proxy classes in the archive and it will also increase the CDS archive size. So we opted for a little more complicated approach by storing the symbolic encoding lambda proxy resolution in the classlist. During dumping, the same info will be retrieved from the constant pool entry and compared with the one from the classlist. An example of the entry in the classlist is: `@lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambda$main$0 ()V ()V` With the above approach, the number of lambda proxy classes the default CDS archive is 67. If we archive all the lambda proxy classes of a given class, the number is 279. Webrev 03 contains the above change and also addresses your other comments. Thanks! Calvin > src/java.base/share/classes/jdk/internal/misc/CDS.java line 56: > >> 54: * Check if CDS dumping is enabled via the DynamicDumpSharedSpaces or the DumpSharedSpaces flag. >> 55: */ >> 56: public static native boolean isCDSDumpingEnabled(); > > I suggest to rename `CDS::isCDSDumpingEnabled` to `CDS:isDumpingEnabled` as this method is a static method in `CDS` > case and the word `CDS` in the method name is just noise. > JVM entry point `JVM_IsCDSDumpingEnabled` is good. Fixed in webrev 03. > src/hotspot/share/prims/jvm.cpp line 3834: > >> 3832: >> 3833: JVM_ENTRY(jboolean, JVM_IsCDSDumpingEnabled(JNIEnv* env)) >> 3834: JVMWrapper("JVM_IsCDSDumpingEnable"); > > typo: missing `d` s/Enable/Enabled/ Fixed in webrev 03. ------------- PR: https://git.openjdk.java.net/jdk/pull/364 From dcubed at openjdk.java.net Sat Oct 10 03:19:15 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 10 Oct 2020 03:19:15 GMT Subject: RFR: 8254335: logging/logStream.hpp includes memory/resourceArea.hpp but doesn't need it Message-ID: While cleaning up the logging in Erik's new code for: JDK-8253064 monitor list simplifications and getting rid of TSM I noticed that logging/logStream.hpp includes memory/resourceArea.hpp but doesn't need it. That include was added to logging/logStream.hpp by: JDK-8153659 Create a CHeap backed LogStream class but logging/logStream.hpp has since evolved to no longer use ResourceMarks in the header file. Looks like that work was done via: JDK-8181917: Refactor UL LogStreams to avoid using resource area Of course, removing the include of memory/resourceArea.hpp reveals other code that uses ResourceMark(s), but never bothered to include memory/resourceArea.hpp. ------------- Commit messages: - Update copyright years as needed. - JDK-8254335: logging/logStream.hpp includes memory/resourceArea.hpp but doesn't need it Changes: https://git.openjdk.java.net/jdk/pull/584/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=584&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254335 Stats: 16 lines in 11 files changed: 10 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/584.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/584/head:pull/584 PR: https://git.openjdk.java.net/jdk/pull/584 From jiefu at openjdk.java.net Sat Oct 10 03:20:16 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 10 Oct 2020 03:20:16 GMT Subject: RFR: 8254348: Build fails when cds is disabled after JDK-8247536 Message-ID: <30zEO4089CAS2qoui6htaQQ__huagwLISw_w6bd83rM=.74ee8634-be3d-426b-816c-4533780feb31@github.com> Please review this trivial fix. Thanks. ------------- Commit messages: - 8254348: Build fails when cds is disabled after JDK-8247536 Changes: https://git.openjdk.java.net/jdk/pull/586/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=586&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254348 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/586.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/586/head:pull/586 PR: https://git.openjdk.java.net/jdk/pull/586 From jiefu at openjdk.java.net Sat Oct 10 03:20:17 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 10 Oct 2020 03:20:17 GMT Subject: RFR: 8254348: Build fails when cds is disabled after JDK-8247536 In-Reply-To: <30zEO4089CAS2qoui6htaQQ__huagwLISw_w6bd83rM=.74ee8634-be3d-426b-816c-4533780feb31@github.com> References: <30zEO4089CAS2qoui6htaQQ__huagwLISw_w6bd83rM=.74ee8634-be3d-426b-816c-4533780feb31@github.com> Message-ID: On Sat, 10 Oct 2020 03:15:34 GMT, Jie Fu wrote: > Please review this trivial fix. > Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/586 From dcubed at openjdk.java.net Sat Oct 10 03:23:12 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 10 Oct 2020 03:23:12 GMT Subject: RFR: 8254335: logging/logStream.hpp includes memory/resourceArea.hpp but doesn't need it In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 22:03:59 GMT, Daniel D. Daugherty wrote: > While cleaning up the logging in Erik's new code for: > > JDK-8253064 monitor list simplifications and getting rid of TSM > > I noticed that logging/logStream.hpp includes memory/resourceArea.hpp > but doesn't need it. > > That include was added to logging/logStream.hpp by: > > JDK-8153659 Create a CHeap backed LogStream class > > but logging/logStream.hpp has since evolved to no longer > use ResourceMarks in the header file. Looks like that work > was done via: > > JDK-8181917: Refactor UL LogStreams to avoid using resource area > > Of course, removing the include of memory/resourceArea.hpp reveals > other code that uses ResourceMark(s), but never bothered to include > memory/resourceArea.hpp. I ran a Mach5 Tier[1-3] and all tests passed. There was a single failed test task, but all the tests passed and the artifact upload timed out. ------------- PR: https://git.openjdk.java.net/jdk/pull/584 From dcubed at openjdk.java.net Sat Oct 10 03:26:08 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 10 Oct 2020 03:26:08 GMT Subject: RFR: 8254348: Build fails when cds is disabled after JDK-8247536 In-Reply-To: <30zEO4089CAS2qoui6htaQQ__huagwLISw_w6bd83rM=.74ee8634-be3d-426b-816c-4533780feb31@github.com> References: <30zEO4089CAS2qoui6htaQQ__huagwLISw_w6bd83rM=.74ee8634-be3d-426b-816c-4533780feb31@github.com> Message-ID: On Sat, 10 Oct 2020 03:15:34 GMT, Jie Fu wrote: > Please review this trivial fix. > Thanks. Thumbs up! I agree that this is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/586 From jiefu at openjdk.java.net Sat Oct 10 04:29:09 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 10 Oct 2020 04:29:09 GMT Subject: RFR: 8254348: Build fails when cds is disabled after JDK-8247536 In-Reply-To: References: <30zEO4089CAS2qoui6htaQQ__huagwLISw_w6bd83rM=.74ee8634-be3d-426b-816c-4533780feb31@github.com> Message-ID: On Sat, 10 Oct 2020 03:23:16 GMT, Daniel D. Daugherty wrote: >> Please review this trivial fix. >> Thanks. > > Thumbs up! I agree that this is a trivial fix. Thanks @dcubed-ojdk for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/586 From jiefu at openjdk.java.net Sat Oct 10 04:29:10 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 10 Oct 2020 04:29:10 GMT Subject: Integrated: 8254348: Build fails when cds is disabled after JDK-8247536 In-Reply-To: <30zEO4089CAS2qoui6htaQQ__huagwLISw_w6bd83rM=.74ee8634-be3d-426b-816c-4533780feb31@github.com> References: <30zEO4089CAS2qoui6htaQQ__huagwLISw_w6bd83rM=.74ee8634-be3d-426b-816c-4533780feb31@github.com> Message-ID: On Sat, 10 Oct 2020 03:15:34 GMT, Jie Fu wrote: > Please review this trivial fix. > Thanks. This pull request has now been integrated. Changeset: ec41046c Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/ec41046c Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8254348: Build fails when cds is disabled after JDK-8247536 Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/586 From kbarrett at openjdk.java.net Sat Oct 10 05:23:09 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 10 Oct 2020 05:23:09 GMT Subject: RFR: 8254335: logging/logStream.hpp includes memory/resourceArea.hpp but doesn't need it In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 22:03:59 GMT, Daniel D. Daugherty wrote: > While cleaning up the logging in Erik's new code for: > > JDK-8253064 monitor list simplifications and getting rid of TSM > > I noticed that logging/logStream.hpp includes memory/resourceArea.hpp > but doesn't need it. > > That include was added to logging/logStream.hpp by: > > JDK-8153659 Create a CHeap backed LogStream class > > but logging/logStream.hpp has since evolved to no longer > use ResourceMarks in the header file. Looks like that work > was done via: > > JDK-8181917: Refactor UL LogStreams to avoid using resource area > > Of course, removing the include of memory/resourceArea.hpp reveals > other code that uses ResourceMark(s), but never bothered to include > memory/resourceArea.hpp. Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/584 From iklam at openjdk.java.net Sat Oct 10 07:29:12 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 10 Oct 2020 07:29:12 GMT Subject: RFR: 8254335: logging/logStream.hpp includes memory/resourceArea.hpp but doesn't need it In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 22:03:59 GMT, Daniel D. Daugherty wrote: > While cleaning up the logging in Erik's new code for: > > JDK-8253064 monitor list simplifications and getting rid of TSM > > I noticed that logging/logStream.hpp includes memory/resourceArea.hpp > but doesn't need it. > > That include was added to logging/logStream.hpp by: > > JDK-8153659 Create a CHeap backed LogStream class > > but logging/logStream.hpp has since evolved to no longer > use ResourceMarks in the header file. Looks like that work > was done via: > > JDK-8181917: Refactor UL LogStreams to avoid using resource area > > Of course, removing the include of memory/resourceArea.hpp reveals > other code that uses ResourceMark(s), but never bothered to include > memory/resourceArea.hpp. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/584 From dholmes at openjdk.java.net Sat Oct 10 11:51:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 10 Oct 2020 11:51:10 GMT Subject: RFR: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 13:08:51 GMT, Robbin Ehn wrote: > It's unsafe for all threads except VM thread to access the current vm operation. > This part of the assert is also faulty: > If we are not at safepoint and the operation requester (calling thread) would be the owner of the lock do not mean it > is safe for current thread. > Passes t1-5. (also note VMThread::vm_operation() assert current thread is VM thread, and I have seen no such assert) > > Thanks Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From dcubed at openjdk.java.net Sat Oct 10 12:52:12 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 10 Oct 2020 12:52:12 GMT Subject: RFR: 8254335: logging/logStream.hpp includes memory/resourceArea.hpp but doesn't need it In-Reply-To: References: Message-ID: On Sat, 10 Oct 2020 07:26:28 GMT, Ioi Lam wrote: >> While cleaning up the logging in Erik's new code for: >> >> JDK-8253064 monitor list simplifications and getting rid of TSM >> >> I noticed that logging/logStream.hpp includes memory/resourceArea.hpp >> but doesn't need it. >> >> That include was added to logging/logStream.hpp by: >> >> JDK-8153659 Create a CHeap backed LogStream class >> >> but logging/logStream.hpp has since evolved to no longer >> use ResourceMarks in the header file. Looks like that work >> was done via: >> >> JDK-8181917: Refactor UL LogStreams to avoid using resource area >> >> Of course, removing the include of memory/resourceArea.hpp reveals >> other code that uses ResourceMark(s), but never bothered to include >> memory/resourceArea.hpp. > > Marked as reviewed by iklam (Reviewer). @kimbarrett and @iklam - Thanks for the reviews! I'm merging and rebuilding now to make sure no new missing includes of memory/resourceArea.hpp have cropped up. ------------- PR: https://git.openjdk.java.net/jdk/pull/584 From dcubed at openjdk.java.net Sat Oct 10 13:42:12 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 10 Oct 2020 13:42:12 GMT Subject: Integrated: 8254335: logging/logStream.hpp includes memory/resourceArea.hpp but doesn't need it In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 22:03:59 GMT, Daniel D. Daugherty wrote: > While cleaning up the logging in Erik's new code for: > > JDK-8253064 monitor list simplifications and getting rid of TSM > > I noticed that logging/logStream.hpp includes memory/resourceArea.hpp > but doesn't need it. > > That include was added to logging/logStream.hpp by: > > JDK-8153659 Create a CHeap backed LogStream class > > but logging/logStream.hpp has since evolved to no longer > use ResourceMarks in the header file. Looks like that work > was done via: > > JDK-8181917: Refactor UL LogStreams to avoid using resource area > > Of course, removing the include of memory/resourceArea.hpp reveals > other code that uses ResourceMark(s), but never bothered to include > memory/resourceArea.hpp. This pull request has now been integrated. Changeset: cc52358c Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/cc52358c Stats: 16 lines in 11 files changed: 10 ins; 1 del; 5 mod 8254335: logging/logStream.hpp includes memory/resourceArea.hpp but doesn't need it Reviewed-by: kbarrett, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/584 From iklam at openjdk.java.net Sun Oct 11 04:37:15 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Sun, 11 Oct 2020 04:37:15 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows Message-ID: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert to fail. **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to access each individual cloned vtable. **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just do the bare minimum to fix the bug, it will be pretty hard to review. I would suggest that the reviewers look at just the new version of the code and see if it's working as described (instead of looking at the diff to understand what the bug was and how it has been fixed). This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. I plan to change that into templates in a future RFE. ------------- Commit messages: - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows Changes: https://git.openjdk.java.net/jdk/pull/591/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=591&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254125 Stats: 136 lines in 5 files changed: 18 ins; 59 del; 59 mod Patch: https://git.openjdk.java.net/jdk/pull/591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/591/head:pull/591 PR: https://git.openjdk.java.net/jdk/pull/591 From rrich at openjdk.java.net Sun Oct 11 06:46:09 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Sun, 11 Oct 2020 06:46:09 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 14:10:16 GMT, Patricio Chilano Mateo wrote: > Hi all, > > Please review the following patch that removes the call to handle_special_runtime_exit_condition() in > ~ThreadInVMForHandshake(). This check was added by 8223572 to prevent a JavaThread that was suspended while trying to > process a handshake to transition back to java without noticing it was suspended. Since 8238761, a JavaThread executing > HandshakeState::process_by_self() will never become safe. It comes from an unsafe state and remains unsafe, so it > cannot be suspended during that time. Removing this check also removes one of the reasons > SafepointMechanism::process_if_requested() is recursive (the other one remains SafepointSynchronize::block()). Tested > in mach5, tiers 1-7. Thanks, Patricio Hi Patricio, the change looks good. Thanks, Richard. ------------- Marked as reviewed by rrich (Committer). PR: https://git.openjdk.java.net/jdk/pull/577 From stuefe at openjdk.java.net Sun Oct 11 06:53:29 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 11 Oct 2020 06:53:29 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v13] In-Reply-To: References: Message-ID: > Hi all, > > this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the > delay, had vacation then the entrance of Skara delayed things a bit. > For the delta diff please see [3]. > > This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all > feedback individually in this PR body, but I incorporated almost all into the new revision. > What changed since the last version: > > - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the > group consent. > > - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for > overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth > class loader which made it rather pointless. Now I run it always. > > - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. > > - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) > > Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. > > - In ChunkManager::purge() I improved the comments after discussions with Leo. > > - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due > to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run > every time. > > - Fixed indentation issues as Leo requested > > - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested > > - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes > and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more > flexible since it allows us to have list with purge-able and non-purge-able nodes. > > - and various smaller fixes, mainly on request of Leo. > > @lkorinth: > >> VirtualSpaceNode.hpp >> >>102 // Start pointer of the area. >>103 MetaWord* const _base; >> >>How does this differ from _rs._base? Really needed? >> >>105 // Size, in words, of the whole node >>106 const size_t _word_size; >> >>Can we not calculate this from _rs.size()? > > You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it > is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly > improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at > some point and make those members const - as they should be - then I would rewrite this as you suggest. > Thanks, again, for all your review work! > > ------ > > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html > [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d Thomas Stuefe has updated the pull request incrementally with three additional commits since the last revision: - Fix retrieval from FreeChunkList; add test; update comments - Loosen unnecessarily strict restriction of allowed chunk states on ChunkManager::return_chunk - Assert that in reclaim=none mode new chunks are fully committed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/336/files - new: https://git.openjdk.java.net/jdk/pull/336/files/eacafe49..2c97008f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=11-12 Stats: 204 lines in 6 files changed: 167 ins; 17 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/336/head:pull/336 PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Sun Oct 11 07:08:13 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 11 Oct 2020 07:08:13 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 13:53:34 GMT, Richard Reingruber wrote: >> The idea is good, but at the moment _next_in_vs==NULL marks the last chunk within one root chunk area, and is used e.g. >> as loop stop. I would have to make Metachunk aware of the root chunk it lives in, which I rather avoid. > > Ok. Thought about this a bit more, your proposal does not work. Metachunk are stored in C-Heap and are physically separated from the chunks they represent. _next_in_vs points to the MetaChunk header **representing** the chunk following the current chunk. Sort of like this: +---------+ +---------+ +---------+ |MetaChunk| <--next/prev_in_vs--> |MetaChunk| <--next/prev_in_vs--> |MetaChunk| +---------+ +---------+ +---------+ | | | base base base | / | / -------------------------- / / / -------------------------------------------------- | | / v v v +---------+---------+---------+---------+ | chunk | chunk | chunk | chunk | +---------+---------+---------+---------+ Given a pointer to the start of a chunk (or, payload), there is no way to get to the MetaChunk representing it. Therefore Metachunk::end() is no help. Therefore I need to store _prev_in_vs and _next_in_vs in the MetaChunk Header. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Sun Oct 11 07:48:15 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 11 Oct 2020 07:48:15 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 13:52:41 GMT, Richard Reingruber wrote: >> No wait, the last sentence is outdated. Will fix. > >> >> >> No wait, the last sentence is outdated. Will fix. > > It is not just the last sentence. > >> >> >> No, this is still valid, see FreeChunkListVector::search_chunk_ascending/desdending. > > These methods look at the first chunk of every list. No list is searched. > > But it's good. I don't want to be too badly pedantic. Fixed with https://github.com/openjdk/jdk/pull/336/commits/2c97008fcc526989f49002e88abeea3d1f3dcdd5 ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Sun Oct 11 07:52:29 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 11 Oct 2020 07:52:29 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v14] In-Reply-To: References: Message-ID: > Hi all, > > this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the > delay, had vacation then the entrance of Skara delayed things a bit. > For the delta diff please see [3]. > > This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all > feedback individually in this PR body, but I incorporated almost all into the new revision. > What changed since the last version: > > - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the > group consent. > > - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for > overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth > class loader which made it rather pointless. Now I run it always. > > - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. > > - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) > > Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. > > - In ChunkManager::purge() I improved the comments after discussions with Leo. > > - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due > to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run > every time. > > - Fixed indentation issues as Leo requested > > - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested > > - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes > and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more > flexible since it allows us to have list with purge-able and non-purge-able nodes. > > - and various smaller fixes, mainly on request of Leo. > > @lkorinth: > >> VirtualSpaceNode.hpp >> >>102 // Start pointer of the area. >>103 MetaWord* const _base; >> >>How does this differ from _rs._base? Really needed? >> >>105 // Size, in words, of the whole node >>106 const size_t _word_size; >> >>Can we not calculate this from _rs.size()? > > You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it > is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly > improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at > some point and make those members const - as they should be - then I would rewrite this as you suggest. > Thanks, again, for all your review work! > > ------ > > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html > [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Add ASCII art to better describe Metachunk relationship to their payload ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/336/files - new: https://git.openjdk.java.net/jdk/pull/336/files/2c97008f..b6e8b842 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=12-13 Stats: 74 lines in 1 file changed: 64 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/336/head:pull/336 PR: https://git.openjdk.java.net/jdk/pull/336 From dholmes at openjdk.java.net Sun Oct 11 22:23:09 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 11 Oct 2020 22:23:09 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 14:10:16 GMT, Patricio Chilano Mateo wrote: > Hi all, > > Please review the following patch that removes the call to handle_special_runtime_exit_condition() in > ~ThreadInVMForHandshake(). This check was added by 8223572 to prevent a JavaThread that was suspended while trying to > process a handshake to transition back to java without noticing it was suspended. Since 8238761, a JavaThread executing > HandshakeState::process_by_self() will never become safe. It comes from an unsafe state and remains unsafe, so it > cannot be suspended during that time. Removing this check also removes one of the reasons > SafepointMechanism::process_if_requested() is recursive (the other one remains SafepointSynchronize::block()). Tested > in mach5, tiers 1-7. Thanks, Patricio Just to clarify my own understanding. Looking at the original problem scenario in JDK-8223572 we have: - T calls _semaphore.wait_with_safepoint_check() - T transitions from _thread_in_vm to _thread_blocked - The VM thread completes H and calls _semaphore.signal() - Before T can transition back to _thread_in_vm, the VM thread schedules another safepoint and executes VM_ThreadSuspend on behalf of a JVMTI agent that wants to suspend T The key change in JDK-8238761 is that we now call: ` MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag);` so there is longer the possibility of T becoming handshake-safe and so the VM_ThreadSuspend cannot happen. src/hotspot/share/runtime/interfaceSupport.inline.hpp line 146: > 144: > 145: ~ThreadInVMForHandshake() { > 146: assert(_thread->thread_state() == _thread_in_vm, "should only call when leaving VM after handshake"); Can we also assert `!_thread->has_special_runtime_exit_condition()`? Or at least that the value of this has not changed between the TIVFH constructor and destructor. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/577 From pchilanomate at openjdk.java.net Mon Oct 12 04:43:08 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 12 Oct 2020 04:43:08 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: References: Message-ID: On Sun, 11 Oct 2020 22:20:47 GMT, David Holmes wrote: > Just to clarify my own understanding. Looking at the original problem scenario in JDK-8223572 we have: > > * T calls _semaphore.wait_with_safepoint_check() > * T transitions from _thread_in_vm to _thread_blocked > * The VM thread completes H and calls _semaphore.signal() > * Before T can transition back to _thread_in_vm, the VM thread schedules another safepoint and > executes VM_ThreadSuspend on behalf of a JVMTI agent that wants to suspend T > > The key change in JDK-8238761 is that we now call: > > ` MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag);` > > so there is longer the possibility of T becoming handshake-safe and so the VM_ThreadSuspend cannot happen. Exactly. ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From pchilanomate at openjdk.java.net Mon Oct 12 04:59:09 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 12 Oct 2020 04:59:09 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: References: Message-ID: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> On Sun, 11 Oct 2020 22:09:30 GMT, David Holmes wrote: >> Hi all, >> >> Please review the following patch that removes the call to handle_special_runtime_exit_condition() in >> ~ThreadInVMForHandshake(). This check was added by 8223572 to prevent a JavaThread that was suspended while trying to >> process a handshake to transition back to java without noticing it was suspended. Since 8238761, a JavaThread executing >> HandshakeState::process_by_self() will never become safe. It comes from an unsafe state and remains unsafe, so it >> cannot be suspended during that time. Removing this check also removes one of the reasons >> SafepointMechanism::process_if_requested() is recursive (the other one remains SafepointSynchronize::block()). Tested >> in mach5, tiers 1-7. Thanks, Patricio > > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 146: > >> 144: >> 145: ~ThreadInVMForHandshake() { >> 146: assert(_thread->thread_state() == _thread_in_vm, "should only call when leaving VM after handshake"); > > Can we also assert `!_thread->has_special_runtime_exit_condition()`? Or at least that the value of this has not changed > between the TIVFH constructor and destructor. has_special_runtime_exit_condition() checks for async exceptions, external_suspend and JFR suspend. The last two can actually be set while we are in the handshake. It doesn't mean that the caller will consider the target suspended, but the _suspend_flags might be different at construction and destruction of TIVFH. As for async exceptions, I realized we have a similar issue as the one described in 8223572 when calling handle_polling_page_exception() on a return poll: - T calls ThreadSafepointState::handle_polling_page_exception() because another thread called T.stop() (which we implement with a handshake) - T calls SafepointMechanism::process_if_requested(thread()) - T calls HandshakeState::process_self_inner() and processes the handshake which calls set_pending_async_exception() - T returns from SafepointMechanism::process_if_requested(thread()) and goes back to java without calling check_and_handle_async_exceptions() to throw the ThreadDeath() exception I'm not sure if delaying the throw of ThreadDeath is allowed, so if we need to keep the current behaviour I can add a call to check_and_handle_async_exceptions(): @@ -987,6 +987,7 @@ void ThreadSafepointState::handle_polling_page_exception() { // Process pending operation SafepointMechanism::process_if_requested(thread()); + thread()->check_and_handle_async_exceptions(); // restore oop result, if any ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From rehn at openjdk.java.net Mon Oct 12 06:06:11 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 12 Oct 2020 06:06:11 GMT Subject: Integrated: 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 13:08:51 GMT, Robbin Ehn wrote: > It's unsafe for all threads except VM thread to access the current vm operation. > This part of the assert is also faulty: > If we are not at safepoint and the operation requester (calling thread) would be the owner of the lock do not mean it > is safe for current thread. > Passes t1-5. (also note VMThread::vm_operation() assert current thread is VM thread, and I have seen no such assert) > > Thanks This pull request has now been integrated. Changeset: 45b09a3f Author: Robbin Ehn URL: https://git.openjdk.java.net/jdk/commit/45b09a3f Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8253833: mutexLocker assert_locked_or_safepoint should not access VMThread state from non-VM-thread Reviewed-by: shade, coleenp, dcubed, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/563 From shade at openjdk.java.net Mon Oct 12 06:48:17 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 12 Oct 2020 06:48:17 GMT Subject: RFR: 8254558: Remove unimplemented Arguments::do_pd_flag_adjustments Message-ID: <9BU7Zou_CQFdh82atKnQxTu1PqnyneyfaFdnk5-TOik=.012b83d4-1948-4aa7-b03f-da5bb53127ef@github.com> It does not seem to be used at all. Let's remove it. Testing: - [x] Linux x86_64 build - [x] Text search for `do_pd_flag_adjustments` in entire `src/` ------------- Commit messages: - 8254558: Remove unimplemented Arguments::do_pd_flag_adjustments Changes: https://git.openjdk.java.net/jdk/pull/597/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=597&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254558 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/597.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/597/head:pull/597 PR: https://git.openjdk.java.net/jdk/pull/597 From shade at openjdk.java.net Mon Oct 12 07:01:16 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 12 Oct 2020 07:01:16 GMT Subject: RFR: 8254559: Remove unimplemented JVMFlag::get_locked_message_ext Message-ID: The definition was removed with JDK-8224599, the declaration was left behind. Testing: - [x] Linux x86_64 build - [x] Text search for `get_locked_message_ext` in entire `src/` ------------- Commit messages: - 8254559: Remove unimplemented JVMFlag::get_locked_message_ext Changes: https://git.openjdk.java.net/jdk/pull/598/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=598&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254559 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/598.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/598/head:pull/598 PR: https://git.openjdk.java.net/jdk/pull/598 From dholmes at openjdk.java.net Mon Oct 12 07:09:11 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 12 Oct 2020 07:09:11 GMT Subject: RFR: 8254558: Remove unimplemented Arguments::do_pd_flag_adjustments In-Reply-To: <9BU7Zou_CQFdh82atKnQxTu1PqnyneyfaFdnk5-TOik=.012b83d4-1948-4aa7-b03f-da5bb53127ef@github.com> References: <9BU7Zou_CQFdh82atKnQxTu1PqnyneyfaFdnk5-TOik=.012b83d4-1948-4aa7-b03f-da5bb53127ef@github.com> Message-ID: On Mon, 12 Oct 2020 06:43:40 GMT, Aleksey Shipilev wrote: > It does not seem to be used at all. Let's remove it. > > Testing: > - [x] Linux x86_64 build > - [x] Text search for `do_pd_flag_adjustments` in entire `src/` Trivially good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/597 From dholmes at openjdk.java.net Mon Oct 12 07:12:09 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 12 Oct 2020 07:12:09 GMT Subject: RFR: 8254559: Remove unimplemented JVMFlag::get_locked_message_ext In-Reply-To: References: Message-ID: <6tCVB5PYHQ6tRscXO9ZigDYqr7-vk2rS8RoL3Wit_xc=.0fc9fd09-d454-429a-918b-5e0d352f6c07@github.com> On Mon, 12 Oct 2020 06:56:06 GMT, Aleksey Shipilev wrote: > The definition was removed with JDK-8224599, the declaration was left behind. > > Testing: > - [x] Linux x86_64 build > - [x] Text search for `get_locked_message_ext` in entire `src/` Trivially good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/598 From tschatzl at openjdk.java.net Mon Oct 12 07:36:09 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 12 Oct 2020 07:36:09 GMT Subject: RFR: 8254559: Remove unimplemented JVMFlag::get_locked_message_ext In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 06:56:06 GMT, Aleksey Shipilev wrote: > The definition was removed with JDK-8224599, the declaration was left behind. > > Testing: > - [x] Linux x86_64 build > - [x] Text search for `get_locked_message_ext` in entire `src/` Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/598 From rrich at openjdk.java.net Mon Oct 12 08:15:09 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 12 Oct 2020 08:15:09 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> References: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> Message-ID: On Mon, 12 Oct 2020 04:55:51 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 146: >> >>> 144: >>> 145: ~ThreadInVMForHandshake() { >>> 146: assert(_thread->thread_state() == _thread_in_vm, "should only call when leaving VM after handshake"); >> >> Can we also assert `!_thread->has_special_runtime_exit_condition()`? Or at least that the value of this has not changed >> between the TIVFH constructor and destructor. > > has_special_runtime_exit_condition() checks for async exceptions, external_suspend and JFR suspend. The last two can > actually be set while we are in the handshake. It doesn't mean that the caller will consider the target suspended, but > the _suspend_flags might be different at construction and destruction of TIVFH. As for async exceptions, I realized we > have a similar issue as the one described in 8223572 when calling handle_polling_page_exception() on a return poll: > - T calls ThreadSafepointState::handle_polling_page_exception() because another thread called T.stop() (which we > implement with a handshake) > - T calls SafepointMechanism::process_if_requested(thread()) > - T calls HandshakeState::process_self_inner() and processes the handshake which calls set_pending_async_exception() > - T returns from SafepointMechanism::process_if_requested(thread()) and goes back to java without calling > check_and_handle_async_exceptions() to throw the ThreadDeath() exception > > I'm not sure if delaying the throw of ThreadDeath is allowed, so if we need to keep the current behaviour I can add a > call to check_and_handle_async_exceptions(): > @@ -987,6 +987,7 @@ void ThreadSafepointState::handle_polling_page_exception() { > // Process pending operation > SafepointMechanism::process_if_requested(thread()); > + thread()->check_and_handle_async_exceptions(); > > // restore oop result, if any Reading that comment I realized that this change would break in flight pr #119 To refresh memories: there I'm adding a new suspend flag currently required for object reallocation. I'm using a handshake to synchronize with the suspendee thread S. After the handshake it is guaranteed that the stack of S is walkable and S cannot push/pop frames. This would not work anymore. I could replace the handshakes (in [escapeBarrier.cpp line 172, 218](https://github.com/openjdk/jdk/pull/119/files#diff-b72c15f49cba82da2158d4e9a4ab0e92R172-R173)) with vm operations though. Should be ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From shade at openjdk.java.net Mon Oct 12 09:44:10 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 12 Oct 2020 09:44:10 GMT Subject: RFR: 8254559: Remove unimplemented JVMFlag::get_locked_message_ext In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 07:33:44 GMT, Thomas Schatzl wrote: >> The definition was removed with JDK-8224599, the declaration was left behind. >> >> Testing: >> - [x] Linux x86_64 build >> - [x] Text search for `get_locked_message_ext` in entire `src/` > > Marked as reviewed by tschatzl (Reviewer). Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/598 From shade at openjdk.java.net Mon Oct 12 09:44:10 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 12 Oct 2020 09:44:10 GMT Subject: Integrated: 8254559: Remove unimplemented JVMFlag::get_locked_message_ext In-Reply-To: References: Message-ID: <8oK-tnUpsIzSS8GdCdgAM7yawd1NEbtOwfPwWIWmHw4=.506000a5-4e9e-4161-a9ea-33ceeb966cfb@github.com> On Mon, 12 Oct 2020 06:56:06 GMT, Aleksey Shipilev wrote: > The definition was removed with JDK-8224599, the declaration was left behind. > > Testing: > - [x] Linux x86_64 build > - [x] Text search for `get_locked_message_ext` in entire `src/` This pull request has now been integrated. Changeset: 638f9109 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/638f9109 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8254559: Remove unimplemented JVMFlag::get_locked_message_ext Reviewed-by: dholmes, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/598 From shade at openjdk.java.net Mon Oct 12 10:38:15 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 12 Oct 2020 10:38:15 GMT Subject: RFR: 8254558: Remove unimplemented Arguments::do_pd_flag_adjustments In-Reply-To: References: <9BU7Zou_CQFdh82atKnQxTu1PqnyneyfaFdnk5-TOik=.012b83d4-1948-4aa7-b03f-da5bb53127ef@github.com> Message-ID: On Mon, 12 Oct 2020 07:06:03 GMT, David Holmes wrote: >> It does not seem to be used at all. Let's remove it. >> >> Testing: >> - [x] Linux x86_64 build >> - [x] Text search for `do_pd_flag_adjustments` in entire `src/` > > Trivially good. > Thanks, > David Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/597 From shade at openjdk.java.net Mon Oct 12 10:38:16 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 12 Oct 2020 10:38:16 GMT Subject: Integrated: 8254558: Remove unimplemented Arguments::do_pd_flag_adjustments In-Reply-To: <9BU7Zou_CQFdh82atKnQxTu1PqnyneyfaFdnk5-TOik=.012b83d4-1948-4aa7-b03f-da5bb53127ef@github.com> References: <9BU7Zou_CQFdh82atKnQxTu1PqnyneyfaFdnk5-TOik=.012b83d4-1948-4aa7-b03f-da5bb53127ef@github.com> Message-ID: <6X7z76Vtik46dTN2Nc06R8TeUlpLU1hKhQ6dq0X8U7c=.fbece505-938f-42c2-b526-2a28b84dd808@github.com> On Mon, 12 Oct 2020 06:43:40 GMT, Aleksey Shipilev wrote: > It does not seem to be used at all. Let's remove it. > > Testing: > - [x] Linux x86_64 build > - [x] Text search for `do_pd_flag_adjustments` in entire `src/` This pull request has now been integrated. Changeset: 295a44af Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/295a44af Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8254558: Remove unimplemented Arguments::do_pd_flag_adjustments Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/597 From coleenp at openjdk.java.net Mon Oct 12 13:05:24 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 12 Oct 2020 13:05:24 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v14] In-Reply-To: References: Message-ID: On Sun, 11 Oct 2020 07:52:29 GMT, Thomas Stuefe wrote: >> Hi all, >> >> this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the >> delay, had vacation then the entrance of Skara delayed things a bit. >> For the delta diff please see [3]. >> >> This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all >> feedback individually in this PR body, but I incorporated almost all into the new revision. >> What changed since the last version: >> >> - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the >> group consent. >> >> - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for >> overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth >> class loader which made it rather pointless. Now I run it always. >> >> - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. >> >> - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) >> >> Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. >> >> - In ChunkManager::purge() I improved the comments after discussions with Leo. >> >> - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due >> to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run >> every time. >> >> - Fixed indentation issues as Leo requested >> >> - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested >> >> - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes >> and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more >> flexible since it allows us to have list with purge-able and non-purge-able nodes. >> >> - and various smaller fixes, mainly on request of Leo. >> >> @lkorinth: >> >>> VirtualSpaceNode.hpp >>> >>>102 // Start pointer of the area. >>>103 MetaWord* const _base; >>> >>>How does this differ from _rs._base? Really needed? >>> >>>105 // Size, in words, of the whole node >>>106 const size_t _word_size; >>> >>>Can we not calculate this from _rs.size()? >> >> You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it >> is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly >> improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at >> some point and make those members const - as they should be - then I would rewrite this as you suggest. >> Thanks, again, for all your review work! >> >> ------ >> >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html >> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html >> [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Add ASCII art to better describe Metachunk relationship to their payload I still approve this change. src/hotspot/share/memory/metaspace/metachunk.hpp line 166: > 164: // | chunk | chunk | chunk | > 165: // +---------+---------+-------------------+ > 166: // Do you have this same picture twice? Other than that, thank you for the ascii art. I think it'll help understand all of this code. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/336 From pchilanomate at openjdk.java.net Mon Oct 12 13:10:11 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 12 Oct 2020 13:10:11 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: References: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> Message-ID: On Mon, 12 Oct 2020 08:12:04 GMT, Richard Reingruber wrote: >> has_special_runtime_exit_condition() checks for async exceptions, external_suspend and JFR suspend. The last two can >> actually be set while we are in the handshake. It doesn't mean that the caller will consider the target suspended, but >> the _suspend_flags might be different at construction and destruction of TIVFH. As for async exceptions, I realized we >> have a similar issue as the one described in 8223572 when calling handle_polling_page_exception() on a return poll: >> - T calls ThreadSafepointState::handle_polling_page_exception() because another thread called T.stop() (which we >> implement with a handshake) >> - T calls SafepointMechanism::process_if_requested(thread()) >> - T calls HandshakeState::process_self_inner() and processes the handshake which calls set_pending_async_exception() >> - T returns from SafepointMechanism::process_if_requested(thread()) and goes back to java without calling >> check_and_handle_async_exceptions() to throw the ThreadDeath() exception >> >> I'm not sure if delaying the throw of ThreadDeath is allowed, so if we need to keep the current behaviour I can add a >> call to check_and_handle_async_exceptions(): >> @@ -987,6 +987,7 @@ void ThreadSafepointState::handle_polling_page_exception() { >> // Process pending operation >> SafepointMechanism::process_if_requested(thread()); >> + thread()->check_and_handle_async_exceptions(); >> >> // restore oop result, if any > > Reading that comment I realized that this change would break in flight pr #119 > > To refresh memories: there I'm adding a new suspend flag currently required for object reallocation. I'm using a > handshake to synchronize with the suspendee thread S. After the handshake it is guaranteed that the stack of S is > walkable and S cannot push/pop frames. This would not work anymore. I could replace the handshakes (in > [escapeBarrier.cpp line 172, > 218](https://github.com/openjdk/jdk/pull/119/files#diff-b72c15f49cba82da2158d4e9a4ab0e92R172-R173)) with vm operations > though. Should be ok. I see. You should still be able to use handshakes. I think the issue is that in handle_polling_page_exception(), instead of calling SafepointMechanism::process_if_requested(thread()), we should be doing { ThreadInVMfromJava __tiv(thread());} and { ThreadInVMfromJavaNoAsyncException __tiv(thread());} for the polling on return and not on return respectively. That will process a safepoint/handshake and then check the special conditions before going back to java. ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From stuefe at openjdk.java.net Mon Oct 12 13:13:27 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 12 Oct 2020 13:13:27 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v14] In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 13:01:50 GMT, Coleen Phillimore wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Add ASCII art to better describe Metachunk relationship to their payload > > src/hotspot/share/memory/metaspace/metachunk.hpp line 166: > >> 164: // | chunk | chunk | chunk | >> 165: // +---------+---------+-------------------+ >> 166: // > > Do you have this same picture twice? Other than that, thank you for the ascii art. I think it'll help understand all > of this code. Thought you like it :) The first picture describes the general division between headers and (possibly distant) chunks, the latter how the _prev_in_vs/_next_in_vs chains headers for adjacent chunks together. The latter is a result of some confusion Richard and I had during our last review round. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Mon Oct 12 14:47:43 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 12 Oct 2020 14:47:43 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v15] In-Reply-To: References: Message-ID: > Hi all, > > this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the > delay, had vacation then the entrance of Skara delayed things a bit. > For the delta diff please see [3]. > > This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all > feedback individually in this PR body, but I incorporated almost all into the new revision. > What changed since the last version: > > - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the > group consent. > > - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for > overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth > class loader which made it rather pointless. Now I run it always. > > - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. > > - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) > > Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. > > - In ChunkManager::purge() I improved the comments after discussions with Leo. > > - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due > to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run > every time. > > - Fixed indentation issues as Leo requested > > - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested > > - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes > and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more > flexible since it allows us to have list with purge-able and non-purge-able nodes. > > - and various smaller fixes, mainly on request of Leo. > > @lkorinth: > >> VirtualSpaceNode.hpp >> >>102 // Start pointer of the area. >>103 MetaWord* const _base; >> >>How does this differ from _rs._base? Really needed? >> >>105 // Size, in words, of the whole node >>106 const size_t _word_size; >> >>Can we not calculate this from _rs.size()? > > You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it > is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly > improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at > some point and make those members const - as they should be - then I would rewrite this as you suggest. > Thanks, again, for all your review work! > > ------ > > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html > [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d Thomas Stuefe 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 - Richard feedback 3 - Add ASCII art to better describe Metachunk relationship to their payload - Fix retrieval from FreeChunkList; add test; update comments - Loosen unnecessarily strict restriction of allowed chunk states on ChunkManager::return_chunk - Assert that in reclaim=none mode new chunks are fully committed - Review Feedback Richard 2 - Fix 32bit build - Review Feedback Richard 1 - Remove some empty lines - ... and 15 more: https://git.openjdk.java.net/jdk/compare/c7f00640...e895bfa0 ------------- Changes: https://git.openjdk.java.net/jdk/pull/336/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=14 Stats: 23023 lines in 174 files changed: 14779 ins; 7020 del; 1224 mod Patch: https://git.openjdk.java.net/jdk/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/336/head:pull/336 PR: https://git.openjdk.java.net/jdk/pull/336 From rrich at openjdk.java.net Mon Oct 12 15:27:10 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 12 Oct 2020 15:27:10 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: References: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> Message-ID: On Mon, 12 Oct 2020 13:07:51 GMT, Patricio Chilano Mateo wrote: >> Reading that comment I realized that this change would break in flight pr #119 >> >> To refresh memories: there I'm adding a new suspend flag currently required for object reallocation. I'm using a >> handshake to synchronize with the suspendee thread S. After the handshake it is guaranteed that the stack of S is >> walkable and S cannot push/pop frames. This would not work anymore. I could replace the handshakes (in >> [escapeBarrier.cpp line 172, >> 218](https://github.com/openjdk/jdk/pull/119/files#diff-b72c15f49cba82da2158d4e9a4ab0e92R172-R173)) with vm operations >> though. Should be ok. > > I see. You should still be able to use handshakes. I think the issue is that in handle_polling_page_exception(), > instead of calling SafepointMechanism::process_if_requested(thread()), we should be doing { ThreadInVMfromJava > __tiv(thread());} and { ThreadInVMfromJavaNoAsyncException __tiv(thread());} for the polling on return and not on > return respectively. That will process a safepoint/handshake and then check the special conditions before going back to > java. Yes, looks like this is possible. Wouldn't this also make the block if (state != _thread_blocked_trans && state != _thread_in_vm_trans && thread->has_special_runtime_exit_condition()) { thread->handle_special_runtime_exit_condition( !thread->is_at_poll_safepoint() && (state != _thread_in_native_trans)); } in `SafepointSynchronize::block(JavaThread *thread)`redundant? This would eliminate the recursion you mentioned in the PR synopsis, I think. ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From pchilanomate at openjdk.java.net Mon Oct 12 16:31:14 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 12 Oct 2020 16:31:14 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: References: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> Message-ID: <7NP7HwX5lsOGiUluP_bjJlGMGljLEW5FLfgmJ3beVgI=.e1f30720-2fdb-4cfc-9f27-6baba06f327d@github.com> On Mon, 12 Oct 2020 15:24:13 GMT, Richard Reingruber wrote: >> I see. You should still be able to use handshakes. I think the issue is that in handle_polling_page_exception(), >> instead of calling SafepointMechanism::process_if_requested(thread()), we should be doing { ThreadInVMfromJava >> __tiv(thread());} and { ThreadInVMfromJavaNoAsyncException __tiv(thread());} for the polling on return and not on >> return respectively. That will process a safepoint/handshake and then check the special conditions before going back to >> java. > > Yes, looks like this is possible. > > Wouldn't this also make the block > if (state != _thread_blocked_trans && > state != _thread_in_vm_trans && > thread->has_special_runtime_exit_condition()) { > thread->handle_special_runtime_exit_condition( > !thread->is_at_poll_safepoint() && (state != _thread_in_native_trans)); > } > in `SafepointSynchronize::block(JavaThread *thread)`redundant? This would eliminate the recursion you mentioned in the > PR synopsis, I think. I thought about removing that check, but right now it's also preventing an escape from a suspend. The issue is that when going back to java, we always check if we were suspended and call java_suspend_self_with_safepoint_check() if true. After the do-while(is_external_suspend()) loop we call again SafepointMechanism::process_if_requested(this) to see if we need to stop for a safepoint/handshake. If there is an actual safepoint pending because of a VM_ThreadSuspend() then unless we keep that check the thread will not notice it was suspended after the safepoint and will go back to java. Now, I'm thinking the call to SafepointMechanism::process_if_requested(this) in java_suspend_self_with_safepoint_check() should be moved inside the the do-while(is_external_suspend()). That way we guarantee after returning from java_suspend_self_with_safepoint_check() that no one will be assuming the thread is suspended. And in that case I think that check in SS::block can be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From rrich at openjdk.java.net Mon Oct 12 17:23:17 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 12 Oct 2020 17:23:17 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: <7NP7HwX5lsOGiUluP_bjJlGMGljLEW5FLfgmJ3beVgI=.e1f30720-2fdb-4cfc-9f27-6baba06f327d@github.com> References: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> <7NP7HwX5lsOGiUluP_bjJlGMGljLEW5FLfgmJ3beVgI=.e1f30720-2fdb-4cfc-9f27-6baba06f327d@github.com> Message-ID: On Mon, 12 Oct 2020 16:28:17 GMT, Patricio Chilano Mateo wrote: > I thought about removing that check, but right now it's also preventing an > escape from a suspend. The issue is that when going back to java, we always > check if we were suspended and call java_suspend_self_with_safepoint_check() > if true. After the do-while(is_external_suspend()) loop we call again > SafepointMechanism::process_if_requested(this) to see if we need to stop for a > safepoint/handshake. If there is an actual safepoint pending because of a > VM_ThreadSuspend() then unless we keep that check the thread will not notice > it was suspended after the safepoint and will go back to java. I meant the block could be removed if we put ThreadInVMfromJava/ThreadInVMfromJava (TIVFJ) into handle_polling_page_exception(). In that case the thread would notice and honor the suspend when leaving the TIVFJ block. This would not be too late, would it? > Now, I'm thinking the call to SafepointMechanism::process_if_requested(this) > in java_suspend_self_with_safepoint_check() should be moved inside the the > do-while(is_external_suspend()). That way we guarantee after returning from > java_suspend_self_with_safepoint_check() that no one will be assuming the > thread is suspended. And in that case I think that check in SS::block can be > removed. Yes I agree. Well, I don't want to spam your PR with too many questions / comments. The change still looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From shade at openjdk.java.net Mon Oct 12 17:53:15 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 12 Oct 2020 17:53:15 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows In-Reply-To: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: On Sun, 11 Oct 2020 04:04:56 GMT, Ioi Lam wrote: > **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in > memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each > of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert > to fail. > > **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to > access each individual cloned vtable. > > **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just > do the bare minimum to fix the bug, it will be pretty hard to review. > > I would suggest that the reviewers look at just the new version of the code and see if it's working as described > (instead of looking at the diff to understand what the bug was and how it has been fixed). > This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. > I plan to change that into templates in a future RFE. This looks reasonable to me, but after testing it on x86_32, I wonder if https://bugs.openjdk.java.net/browse/JDK-8254606 is the problem with this patch, or a different issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/591 From pchilanomate at openjdk.java.net Mon Oct 12 18:35:16 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 12 Oct 2020 18:35:16 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: References: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> <7NP7HwX5lsOGiUluP_bjJlGMGljLEW5FLfgmJ3beVgI=.e1f30720-2fdb-4cfc-9f27-6baba06f327d@github.com> Message-ID: On Mon, 12 Oct 2020 17:20:12 GMT, Richard Reingruber wrote: > I meant the block could be removed if we put > ThreadInVMfromJava/ThreadInVMfromJava (TIVFJ) into > handle_polling_page_exception(). In that case the thread would notice and honor > the suspend when leaving the TIVFJ block. This would not be too late, would it? Yes, it will honor the first suspend in the TIVFJ destructor by calling handle_special_runtime_exit_condition(), but even in that case, we would still need the check in SS:block() because of the last call to SafepointMechanism::process_if_requested(thread()) in java_suspend_self_with_safepoint_check(). That could be a new VM_ThreadSuspend() operation to suspend the thread again. So that check in SS:block() is actually needed for all the transitions to java not only the one in handle_polling_page_exception(). But I think we can remove that recursion if we move that call to SafepointMechanism::process_if_requested(thread()) inside the do-while(). ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From pchilanomate at openjdk.java.net Mon Oct 12 18:38:11 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 12 Oct 2020 18:38:11 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: References: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> <7NP7HwX5lsOGiUluP_bjJlGMGljLEW5FLfgmJ3beVgI=.e1f30720-2fdb-4cfc-9f27-6baba06f327d@github.com> Message-ID: On Mon, 12 Oct 2020 18:32:12 GMT, Patricio Chilano Mateo wrote: >>> I thought about removing that check, but right now it's also preventing an >>> escape from a suspend. The issue is that when going back to java, we always >>> check if we were suspended and call java_suspend_self_with_safepoint_check() >>> if true. After the do-while(is_external_suspend()) loop we call again >>> SafepointMechanism::process_if_requested(this) to see if we need to stop for a >>> safepoint/handshake. If there is an actual safepoint pending because of a >>> VM_ThreadSuspend() then unless we keep that check the thread will not notice >>> it was suspended after the safepoint and will go back to java. >> >> I meant the block could be removed if we put >> ThreadInVMfromJava/ThreadInVMfromJava (TIVFJ) into >> handle_polling_page_exception(). In that case the thread would notice and honor >> the suspend when leaving the TIVFJ block. This would not be too late, would it? >> >>> Now, I'm thinking the call to SafepointMechanism::process_if_requested(this) >>> in java_suspend_self_with_safepoint_check() should be moved inside the the >>> do-while(is_external_suspend()). That way we guarantee after returning from >>> java_suspend_self_with_safepoint_check() that no one will be assuming the >>> thread is suspended. And in that case I think that check in SS::block can be >>> removed. >> >> Yes I agree. >> >> Well, I don't want to spam your PR with too many questions / comments. The >> change still looks good to me. > >> I meant the block could be removed if we put >> ThreadInVMfromJava/ThreadInVMfromJava (TIVFJ) into >> handle_polling_page_exception(). In that case the thread would notice and honor >> the suspend when leaving the TIVFJ block. This would not be too late, would it? > > Yes, it will honor the first suspend in the TIVFJ destructor by calling handle_special_runtime_exit_condition(), but > even in that case, we would still need the check in SS:block() because of the last call to > SafepointMechanism::process_if_requested(thread()) in java_suspend_self_with_safepoint_check(). That could be a new > VM_ThreadSuspend() operation to suspend the thread again. So that check in SS:block() is actually needed for all the > transitions to java not only the one in handle_polling_page_exception(). But I think we can remove that recursion if we > move that call to SafepointMechanism::process_if_requested(thread()) inside the do-while(). > > Now, I'm thinking the call to SafepointMechanism::process_if_requested(this) > > in java_suspend_self_with_safepoint_check() should be moved inside the the > > do-while(is_external_suspend()). That way we guarantee after returning from > > java_suspend_self_with_safepoint_check() that no one will be assuming the > > thread is suspended. And in that case I think that check in SS::block can be > > removed. > > Yes I agree. Great. I'll test it out. > Well, I don't want to spam your PR with too many questions / comments. The > change still looks good to me. No problem, it's actually good to have more eyes looking to make sure I don't miss anything. : ) Thanks Richard! ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From minqi at openjdk.java.net Mon Oct 12 19:06:15 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 12 Oct 2020 19:06:15 GMT Subject: RFR: 8254599: CDS dump should not warn about hidden classes Message-ID: Regular hidden class skipping warning in -Xshare:dump is at info log level, it is noise for a normal operation. Changed to debug level, along the change, three test cases in dynamic dumping changed to debug log level to have original message output. Tests: tier1-5 in progress. Passed all local runtime/cds ------------- Commit messages: - 8254599: CDS dump should not warn about hidden classes - Merge branch 'master' of https://github.com/openjdk/jdk - Merge branch 'master' of https://github.com/openjdk/jdk - Merge branch 'master' of https://github.com/openjdk/jdk - Merge remote-tracking branch 'origin/jdk-8252689' - 8252689: Classes are loaded from jrt:/java.base even when CDS is used - 8252689: Classes are loaded from jrt:/java.base even when CDS is used - 8252689: Classes are loaded from jrt:/java.base even when CDS is used Changes: https://git.openjdk.java.net/jdk/pull/614/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=614&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254599 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/614.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/614/head:pull/614 PR: https://git.openjdk.java.net/jdk/pull/614 From redestad at openjdk.java.net Mon Oct 12 19:10:16 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 12 Oct 2020 19:10:16 GMT Subject: RFR: 8254599: CDS dump should not warn about hidden classes In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 18:57:54 GMT, Yumin Qi wrote: > Regular hidden class skipping warning in -Xshare:dump is at info log level, it is noise for a normal operation. Changed > to debug level, along the change, three test cases in dynamic dumping changed to debug log level to have original > message output. Tests: tier1-5 in progress. Passed all local runtime/cds Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/614 From lfoltan at openjdk.java.net Mon Oct 12 19:27:11 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Mon, 12 Oct 2020 19:27:11 GMT Subject: RFR: 8254599: CDS dump should not warn about hidden classes In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 18:57:54 GMT, Yumin Qi wrote: > Regular hidden class skipping warning in -Xshare:dump is at info log level, it is noise for a normal operation. Changed > to debug level, along the change, three test cases in dynamic dumping changed to debug log level to have original > message output. Tests: tier1-5 in progress. Passed all local runtime/cds Looks good Yumin! ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/614 From rrich at openjdk.java.net Mon Oct 12 19:48:14 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 12 Oct 2020 19:48:14 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: References: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> <7NP7HwX5lsOGiUluP_bjJlGMGljLEW5FLfgmJ3beVgI=.e1f30720-2fdb-4cfc-9f27-6baba06f327d@github.com> Message-ID: On Mon, 12 Oct 2020 18:35:51 GMT, Patricio Chilano Mateo wrote: >>> I meant the block could be removed if we put >>> ThreadInVMfromJava/ThreadInVMfromJava (TIVFJ) into >>> handle_polling_page_exception(). In that case the thread would notice and honor >>> the suspend when leaving the TIVFJ block. This would not be too late, would it? >> >> Yes, it will honor the first suspend in the TIVFJ destructor by calling handle_special_runtime_exit_condition(), but >> even in that case, we would still need the check in SS:block() because of the last call to >> SafepointMechanism::process_if_requested(thread()) in java_suspend_self_with_safepoint_check(). That could be a new >> VM_ThreadSuspend() operation to suspend the thread again. So that check in SS:block() is actually needed for all the >> transitions to java not only the one in handle_polling_page_exception(). But I think we can remove that recursion if we >> move that call to SafepointMechanism::process_if_requested(thread()) inside the do-while(). > >> > Now, I'm thinking the call to SafepointMechanism::process_if_requested(this) >> > in java_suspend_self_with_safepoint_check() should be moved inside the the >> > do-while(is_external_suspend()). That way we guarantee after returning from >> > java_suspend_self_with_safepoint_check() that no one will be assuming the >> > thread is suspended. And in that case I think that check in SS::block can be >> > removed. >> >> Yes I agree. > Great. I'll test it out. > >> Well, I don't want to spam your PR with too many questions / comments. The >> change still looks good to me. > No problem, it's actually good to have more eyes looking to make sure I don't miss anything. : ) > Thanks Richard! > > I meant the block could be removed if we put > > ThreadInVMfromJava/ThreadInVMfromJava (TIVFJ) into > > handle_polling_page_exception(). In that case the thread would notice and honor > > the suspend when leaving the TIVFJ block. This would not be too late, would it? > > Yes, it will honor the first suspend in the TIVFJ destructor by calling > handle_special_runtime_exit_condition(), but even in that case, we would still > need the check in SS:block() because of the last call to > SafepointMechanism::process_if_requested(thread()) in > java_suspend_self_with_safepoint_check(). That could be a new > VM_ThreadSuspend() operation to suspend the thread again. Sorry, I have to ask again to really understand this myself. If it is a new VM_ThreadSuspend() that started while the target thread T was still _thread_blocked in java_suspend_self_with_safepoint_check(), then T can not leave the do-while-loop because is_external_suspend() will return true as setting the suspend flag for T cannot be reordered with the begin of the safepoint. Also if T could leave the loop then the safepoint could be ended before T reaches SS::block(). It would escape then to java even though it was suspended. See also review thread for JDK-8252521: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041632.html ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From pchilanomate at openjdk.java.net Mon Oct 12 20:23:13 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 12 Oct 2020 20:23:13 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: References: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> <7NP7HwX5lsOGiUluP_bjJlGMGljLEW5FLfgmJ3beVgI=.e1f30720-2fdb-4cfc-9f27-6baba06f327d@github.com> Message-ID: On Mon, 12 Oct 2020 19:45:20 GMT, Richard Reingruber wrote: > > > I meant the block could be removed if we put > > > ThreadInVMfromJava/ThreadInVMfromJava (TIVFJ) into > > > handle_polling_page_exception(). In that case the thread would notice and honor > > > the suspend when leaving the TIVFJ block. This would not be too late, would it? > > > Yes, it will honor the first suspend in the TIVFJ destructor by calling > > handle_special_runtime_exit_condition(), but even in that case, we would still > > need the check in SS:block() because of the last call to > > SafepointMechanism::process_if_requested(thread()) in > > java_suspend_self_with_safepoint_check(). That could be a new > > VM_ThreadSuspend() operation to suspend the thread again. > > Sorry, I have to ask again to really understand this myself. If it is a new > VM_ThreadSuspend() that started while the target thread T was still > _thread_blocked in java_suspend_self_with_safepoint_check(), then T can not > leave the do-while-loop because is_external_suspend() will return true as > setting the suspend flag for T cannot be reordered with the begin of the > safepoint. The new JVM_SuspendThread() call (up to VM_ThreadSuspend()) is started after the thread sets its state back to _thread_in_Java and exits the do-while() loop but before it calls SafepointMechanism::process_if_requested(this). The thread will see there is a safepoint pending and will block in SS::block(). If there is no check in SS::block(), after the safepoint finishes the thread will return to java_suspend_self_with_safepoint_check(), back to ~ TIVFJ and then back to java. > Also if T could leave the loop then the safepoint could be ended before T > reaches SS::block(). It would escape then to java even though it was suspended. If the VMThread doesn't read the thread's state before it is restored back to _thread_in_Java then the safepoint won't progress since the thread is unsafe (_thread_in_Java). So it will have to wait for the thread to call SS::block(). If the VMThread did read a safe state (_thread_blocked) then it means we will see we were suspended in the do-while() loop and suspend. ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From minqi at openjdk.java.net Mon Oct 12 20:25:08 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 12 Oct 2020 20:25:08 GMT Subject: RFR: 8254599: CDS dump should not warn about hidden classes In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 19:24:33 GMT, Lois Foltan wrote: >> Regular hidden class skipping warning in -Xshare:dump is at info log level, it is noise for a normal operation. Changed >> to debug level, along the change, three test cases in dynamic dumping changed to debug log level to have original >> message output. Tests: tier1-5 in progress. Passed all local runtime/cds > > Looks good Yumin! Thanks Claes and Lois for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/614 From rrich at openjdk.java.net Mon Oct 12 20:34:13 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 12 Oct 2020 20:34:13 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: References: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> <7NP7HwX5lsOGiUluP_bjJlGMGljLEW5FLfgmJ3beVgI=.e1f30720-2fdb-4cfc-9f27-6baba06f327d@github.com> Message-ID: On Mon, 12 Oct 2020 20:20:08 GMT, Patricio Chilano Mateo wrote: >>> > I meant the block could be removed if we put >>> > ThreadInVMfromJava/ThreadInVMfromJava (TIVFJ) into >>> > handle_polling_page_exception(). In that case the thread would notice and honor >>> > the suspend when leaving the TIVFJ block. This would not be too late, would it? >>> >> >>> Yes, it will honor the first suspend in the TIVFJ destructor by calling >>> handle_special_runtime_exit_condition(), but even in that case, we would still >>> need the check in SS:block() because of the last call to >>> SafepointMechanism::process_if_requested(thread()) in >>> java_suspend_self_with_safepoint_check(). That could be a new >>> VM_ThreadSuspend() operation to suspend the thread again. >> >> Sorry, I have to ask again to really understand this myself. If it is a new >> VM_ThreadSuspend() that started while the target thread T was still >> _thread_blocked in java_suspend_self_with_safepoint_check(), then T can not >> leave the do-while-loop because is_external_suspend() will return true as >> setting the suspend flag for T cannot be reordered with the begin of the >> safepoint. >> >> Also if T could leave the loop then the safepoint could be ended before T >> reaches SS::block(). It would escape then to java even though it was suspended. >> >> See also review thread for JDK-8252521: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041632.html > >> > > I meant the block could be removed if we put >> > > ThreadInVMfromJava/ThreadInVMfromJava (TIVFJ) into >> > > handle_polling_page_exception(). In that case the thread would notice and honor >> > > the suspend when leaving the TIVFJ block. This would not be too late, would it? >> >> > Yes, it will honor the first suspend in the TIVFJ destructor by calling >> > handle_special_runtime_exit_condition(), but even in that case, we would still >> > need the check in SS:block() because of the last call to >> > SafepointMechanism::process_if_requested(thread()) in >> > java_suspend_self_with_safepoint_check(). That could be a new >> > VM_ThreadSuspend() operation to suspend the thread again. >> >> Sorry, I have to ask again to really understand this myself. If it is a new >> VM_ThreadSuspend() that started while the target thread T was still >> _thread_blocked in java_suspend_self_with_safepoint_check(), then T can not >> leave the do-while-loop because is_external_suspend() will return true as >> setting the suspend flag for T cannot be reordered with the begin of the >> safepoint. > The new JVM_SuspendThread() call (up to VM_ThreadSuspend()) is started after the thread sets its state back to > _thread_in_Java and exits the do-while() loop but before it calls SafepointMechanism::process_if_requested(this). The > thread will see there is a safepoint pending and will block in SS::block(). If there is no check in SS::block(), after > the safepoint finishes the thread will return to java_suspend_self_with_safepoint_check(), back to ~ TIVFJ and then > back to java. >> Also if T could leave the loop then the safepoint could be ended before T >> reaches SS::block(). It would escape then to java even though it was suspended. > If the VMThread doesn't read the thread's state before it is restored back to _thread_in_Java then the safepoint won't > progress since the thread is unsafe (_thread_in_Java). So it will have to wait for the thread to call SS::block(). If > the VMThread did read a safe state (_thread_blocked) then it means we will see we were suspended in the do-while() loop > and suspend. Understood now. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From hseigel at openjdk.java.net Mon Oct 12 20:40:18 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 12 Oct 2020 20:40:18 GMT Subject: RFR: 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp Message-ID: Hi, Please review this small change to simplify exception throwing in classFileParser.cpp The change was tested with tiers one and two on Windows, Linux x64, and Mac OSX, and with tiers 3-5 on Linux x64. Thanks, Harold ------------- Commit messages: - 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp Changes: https://git.openjdk.java.net/jdk/pull/618/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=618&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254586 Stats: 84 lines in 3 files changed: 37 ins; 31 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/618.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/618/head:pull/618 PR: https://git.openjdk.java.net/jdk/pull/618 From lfoltan at openjdk.java.net Mon Oct 12 21:05:12 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Mon, 12 Oct 2020 21:05:12 GMT Subject: RFR: 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp In-Reply-To: References: Message-ID: <1OKiWoWzQ4kHT-zOoewrJpl_BTOHvgTg7XjcmF0ec-U=.1b6da20e-fd8f-461f-b788-47df0dcab7aa@github.com> On Mon, 12 Oct 2020 20:34:25 GMT, Harold Seigel wrote: > Hi, > Please review this small change to simplify exception throwing in classFileParser.cpp The change was tested with tiers > one and two on Windows, Linux x64, and Mac OSX, and with tiers 3-5 on Linux x64. > Thanks, Harold Looks good Harold! ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/618 From vromero at openjdk.java.net Mon Oct 12 21:35:36 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 12 Oct 2020 21:35:36 GMT Subject: RFR: 8246774: implementing Record Classes as a standard feature in Java [v11] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 8246774: implementing Record Classes as a standard feature in Java Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' into JDK-8246774 - removing unused jcod file - remove unnecessary jtreg tags from tests, remove othervm etc when applicable - adding missing changes to some tests - modifiying @since from 14 to 16 - Remove preview args from ObjectMethodsTest - Remove preview args from record serialization tests - removing the javax.lang.model related code to be moved to a separate bug - 8246774: Record Classes (final) implementation Co-authored-by: Vicente Romero Co-authored-by: Harold Seigel Co-authored-by: Jonathan Gibbons Co-authored-by: Brian Goetz Co-authored-by: Maurizio Cimadamore Co-authored-by: Joe Darcy Co-authored-by: Chris Hegarty Co-authored-by: Jan Lahoda ------------- Changes: https://git.openjdk.java.net/jdk/pull/290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=10 Stats: 856 lines in 109 files changed: 64 ins; 552 del; 240 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From dholmes at openjdk.java.net Mon Oct 12 21:53:14 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 12 Oct 2020 21:53:14 GMT Subject: RFR: 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp In-Reply-To: References: Message-ID: <3pVr_lgpfl7hWGeT_f4cv8Js25cqZfiNyxGdfGfXwUo=.76727719-5e28-4e0d-a3bf-b8313522af90@github.com> On Mon, 12 Oct 2020 20:34:25 GMT, Harold Seigel wrote: > Hi, > Please review this small change to simplify exception throwing in classFileParser.cpp The change was tested with tiers > one and two on Windows, Linux x64, and Mac OSX, and with tiers 3-5 on Linux x64. > Thanks, Harold Hi Harold, Not sure why we couldn't use THROW_MSG in these cases? The helper functions are okay though. But don't use CHECK macro here - just pass THREADS and then return. We know there is a pending exception. Thanks, David src/hotspot/share/classfile/classFileParser.cpp line 4317: > 4315: > 4316: if (super_ik->is_sealed() && !super_ik->has_as_permitted_subclass(this_klass)) { > 4317: classfile_icce_error("class %s cannot inherit from sealed class %s", super_ik, CHECK); You don't want CHECK there - you know there is an exception pending. Just pass THREAD and return afterwards. This goes for all the new callsites. src/hotspot/share/classfile/classFileError.cpp line 81: > 79: } > 80: > 81: void ClassFileParser::classfile_icce_error(const char* msg, Is there a reason we can't just use THROW_MSG at the callsites rather than introducing these helper functions? ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/618 From coleenp at openjdk.java.net Mon Oct 12 22:22:13 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 12 Oct 2020 22:22:13 GMT Subject: RFR: 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp In-Reply-To: References: Message-ID: <0EtNVcXRxwUY4llYvJLVu33j8I6Mws5jzXt_8tGfyFA=.3ab34a5e-3214-4eba-b685-1b7c1c3c6060@github.com> On Mon, 12 Oct 2020 20:34:25 GMT, Harold Seigel wrote: > Hi, > Please review this small change to simplify exception throwing in classFileParser.cpp The change was tested with tiers > one and two on Windows, Linux x64, and Mac OSX, and with tiers 3-5 on Linux x64. > Thanks, Harold Looks good to me. I agree with David's comment to just pass THREAD and return; Saves an implicit if statement in these places. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/618 From coleenp at openjdk.java.net Mon Oct 12 22:22:17 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 12 Oct 2020 22:22:17 GMT Subject: RFR: 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp In-Reply-To: <3pVr_lgpfl7hWGeT_f4cv8Js25cqZfiNyxGdfGfXwUo=.76727719-5e28-4e0d-a3bf-b8313522af90@github.com> References: <3pVr_lgpfl7hWGeT_f4cv8Js25cqZfiNyxGdfGfXwUo=.76727719-5e28-4e0d-a3bf-b8313522af90@github.com> Message-ID: On Mon, 12 Oct 2020 21:44:45 GMT, David Holmes wrote: >> Hi, >> Please review this small change to simplify exception throwing in classFileParser.cpp The change was tested with tiers >> one and two on Windows, Linux x64, and Mac OSX, and with tiers 3-5 on Linux x64. >> Thanks, Harold > > src/hotspot/share/classfile/classFileError.cpp line 81: > >> 79: } >> 80: >> 81: void ClassFileParser::classfile_icce_error(const char* msg, > > Is there a reason we can't just use THROW_MSG at the callsites rather than introducing these helper functions? I think it's intended to match existing usage. ------------- PR: https://git.openjdk.java.net/jdk/pull/618 From coleenp at openjdk.java.net Mon Oct 12 22:36:20 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 12 Oct 2020 22:36:20 GMT Subject: RFR: 8254158: Consolidate per-platform stack overflow handling code Message-ID: Moved the duplicated code from posix based platform/cpu combinations into os_posix.cpp. Left a little function to determine frame at stack banging point for compiled methods (you can suggest a better name for it) to capture the difference. There are a bit of ifdefs but now there are less copies. Tested with tier1-3 and stack overflow tests in vmTestbase/nsk/stress/stack on linux-x86-debug,macosx-x86-debug,windows-x86-debug. Built aarch64, arm32, ppc, s390, and zero. Testing on these platforms would be welcome. Thanks, Coleen ------------- Commit messages: - 8254158: Consolidate per-platform stack overflow handling code Changes: https://git.openjdk.java.net/jdk/pull/620/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=620&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254158 Stats: 632 lines in 10 files changed: 119 ins; 464 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/620.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/620/head:pull/620 PR: https://git.openjdk.java.net/jdk/pull/620 From iklam at openjdk.java.net Mon Oct 12 22:47:12 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 12 Oct 2020 22:47:12 GMT Subject: RFR: 8254599: CDS dump should not warn about hidden classes In-Reply-To: References: Message-ID: <1H0KmmSdccG3i2W2LauXUuc0HcaK0031MdzYU0L9CqI=.6c96ac66-7b55-47b4-9da2-284ead0e3889@github.com> On Mon, 12 Oct 2020 18:57:54 GMT, Yumin Qi wrote: > Regular hidden class skipping warning in -Xshare:dump is at info log level, it is noise for a normal operation. Changed > to debug level, along the change, three test cases in dynamic dumping changed to debug log level to have original > message output. Tests: tier1-5 in progress. Passed all local runtime/cds Changes requested by iklam (Reviewer). src/hotspot/share/classfile/systemDictionaryShared.cpp line 1349: > 1347: > 1348: if (k->is_hidden() && !is_registered_lambda_proxy_class(k)) { > 1349: log_debug(cds)("Skipping %s: %s", k->name()->as_C_string(), "Hidden class"); A ResourceMark is needed here for calling k->name()->as_C_string(). ------------- PR: https://git.openjdk.java.net/jdk/pull/614 From minqi at openjdk.java.net Mon Oct 12 23:33:20 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 12 Oct 2020 23:33:20 GMT Subject: RFR: 8254599: CDS dump should not warn about hidden classes [v2] In-Reply-To: References: Message-ID: <9dZCb2JSJhup9FSSb1W15BOW0Hi5eru5axnkaahywBI=.b247c10f-2074-4911-a575-6aa608950250@github.com> > Regular hidden class skipping warning in -Xshare:dump is at info log level, it is noise for a normal operation. Changed > to debug level, along the change, three test cases in dynamic dumping changed to debug log level to have original > message output. Tests: tier1-5 in progress. Passed all local runtime/cds Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: ResourceMark needed for logging ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/614/files - new: https://git.openjdk.java.net/jdk/pull/614/files/ded59cf2..e35b2025 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=614&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=614&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/614.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/614/head:pull/614 PR: https://git.openjdk.java.net/jdk/pull/614 From minqi at openjdk.java.net Mon Oct 12 23:37:15 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 12 Oct 2020 23:37:15 GMT Subject: RFR: 8254599: CDS dump should not warn about hidden classes [v2] In-Reply-To: <1H0KmmSdccG3i2W2LauXUuc0HcaK0031MdzYU0L9CqI=.6c96ac66-7b55-47b4-9da2-284ead0e3889@github.com> References: <1H0KmmSdccG3i2W2LauXUuc0HcaK0031MdzYU0L9CqI=.6c96ac66-7b55-47b4-9da2-284ead0e3889@github.com> Message-ID: On Mon, 12 Oct 2020 22:44:25 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> ResourceMark needed for logging > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 1349: > >> 1347: >> 1348: if (k->is_hidden() && !is_registered_lambda_proxy_class(k)) { >> 1349: log_debug(cds)("Skipping %s: %s", k->name()->as_C_string(), "Hidden class"); > > A ResourceMark is needed here for calling k->name()->as_C_string(). Thanks, yes here needs a ResourceMark. ------------- PR: https://git.openjdk.java.net/jdk/pull/614 From iklam at openjdk.java.net Mon Oct 12 23:40:12 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 12 Oct 2020 23:40:12 GMT Subject: RFR: 8254599: CDS dump should not warn about hidden classes [v2] In-Reply-To: <9dZCb2JSJhup9FSSb1W15BOW0Hi5eru5axnkaahywBI=.b247c10f-2074-4911-a575-6aa608950250@github.com> References: <9dZCb2JSJhup9FSSb1W15BOW0Hi5eru5axnkaahywBI=.b247c10f-2074-4911-a575-6aa608950250@github.com> Message-ID: <3ZwgsXr7Kppp1FV7G49bbFiU58dHBAroATiTSXzAKgM=.bc15ab51-6968-4676-b07c-c66f71cc60bc@github.com> On Mon, 12 Oct 2020 23:33:20 GMT, Yumin Qi wrote: >> Regular hidden class skipping warning in -Xshare:dump is at info log level, it is noise for a normal operation. Changed >> to debug level, along the change, three test cases in dynamic dumping changed to debug log level to have original >> message output. Tests: tier1-5 in progress. Passed all local runtime/cds > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > ResourceMark needed for logging LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/614 From david.holmes at oracle.com Tue Oct 13 02:35:32 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Oct 2020 12:35:32 +1000 Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> References: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> Message-ID: <68363d6e-406b-bb39-77c0-f36fb2e66605@oracle.com> Hi Patricio, On 12/10/2020 2:59 pm, Patricio Chilano Mateo wrote: > On Sun, 11 Oct 2020 22:09:30 GMT, David Holmes wrote: > >>> Hi all, >>> >>> Please review the following patch that removes the call to handle_special_runtime_exit_condition() in >>> ~ThreadInVMForHandshake(). This check was added by 8223572 to prevent a JavaThread that was suspended while trying to >>> process a handshake to transition back to java without noticing it was suspended. Since 8238761, a JavaThread executing >>> HandshakeState::process_by_self() will never become safe. It comes from an unsafe state and remains unsafe, so it >>> cannot be suspended during that time. Removing this check also removes one of the reasons >>> SafepointMechanism::process_if_requested() is recursive (the other one remains SafepointSynchronize::block()). Tested >>> in mach5, tiers 1-7. Thanks, Patricio >> >> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 146: >> >>> 144: >>> 145: ~ThreadInVMForHandshake() { >>> 146: assert(_thread->thread_state() == _thread_in_vm, "should only call when leaving VM after handshake"); >> >> Can we also assert `!_thread->has_special_runtime_exit_condition()`? Or at least that the value of this has not changed >> between the TIVFH constructor and destructor. > > has_special_runtime_exit_condition() checks for async exceptions, external_suspend and JFR suspend. The last two can > actually be set while we are in the handshake. It doesn't mean that the caller will consider the target suspended, but > the _suspend_flags might be different at construction and destruction of TIVFH. Ah right! Oh well :) > As for async exceptions, I realized we > have a similar issue as the one described in 8223572 when calling handle_polling_page_exception() on a return poll: > > - T calls ThreadSafepointState::handle_polling_page_exception() because another thread called T.stop() (which we > implement with a handshake) > - T calls SafepointMechanism::process_if_requested(thread()) > - T calls HandshakeState::process_self_inner() and processes the handshake which calls set_pending_async_exception() > - T returns from SafepointMechanism::process_if_requested(thread()) and goes back to java without calling > check_and_handle_async_exceptions() to throw the ThreadDeath() exception > > I'm not sure if delaying the throw of ThreadDeath is allowed, so if we need to keep the current behaviour I can add a > call to check_and_handle_async_exceptions(): To some extent, given it is a race, a delay is permissible, but I find it highly undesirable. Our biggest problems with async exceptions lately is the unpredictability of their actually getting propagated. So we should fix this. > @@ -987,6 +987,7 @@ void ThreadSafepointState::handle_polling_page_exception() { > // Process pending operation > SafepointMechanism::process_if_requested(thread()); > + thread()->check_and_handle_async_exceptions(); Why directly in handle_polling_page_exception() rather than restoring it to the ~ThreadInVMForHandshake() ? Thanks, David ----- > // restore oop result, if any > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/577 > From minqi at openjdk.java.net Tue Oct 13 04:08:11 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 13 Oct 2020 04:08:11 GMT Subject: Integrated: 8254599: CDS dump should not warn about hidden classes In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 18:57:54 GMT, Yumin Qi wrote: > Regular hidden class skipping warning in -Xshare:dump is at info log level, it is noise for a normal operation. Changed > to debug level, along the change, three test cases in dynamic dumping changed to debug log level to have original > message output. Tests: tier1-5 in progress. Passed all local runtime/cds This pull request has now been integrated. Changeset: e49232a0 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/e49232a0 Stats: 6 lines in 4 files changed: 1 ins; 0 del; 5 mod 8254599: CDS dump should not warn about hidden classes Reviewed-by: redestad, lfoltan, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/614 From iklam at openjdk.java.net Tue Oct 13 05:38:26 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 13 Oct 2020 05:38:26 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v2] In-Reply-To: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: > **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in > memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each > of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert > to fail. > > **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to > access each individual cloned vtable. > > **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just > do the bare minimum to fix the bug, it will be pretty hard to review. > > I would suggest that the reviewers look at just the new version of the code and see if it's working as described > (instead of looking at the diff to understand what the bug was and how it has been fixed). > This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. > I plan to change that into templates in a future RFE. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Fixed more cases with align_up(xxx, SharedSpaceObjectAlignment) - Merge branch 'master' into 8254125-cppvtables-assert-on-win32 - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/591/files - new: https://git.openjdk.java.net/jdk/pull/591/files/addaae99..50dfb2e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=591&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=591&range=00-01 Stats: 6758 lines in 165 files changed: 3923 ins; 1067 del; 1768 mod Patch: https://git.openjdk.java.net/jdk/pull/591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/591/head:pull/591 PR: https://git.openjdk.java.net/jdk/pull/591 From iklam at openjdk.java.net Tue Oct 13 06:06:12 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 13 Oct 2020 06:06:12 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v2] In-Reply-To: References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: On Mon, 12 Oct 2020 17:50:31 GMT, Aleksey Shipilev wrote: > This looks reasonable to me, but after testing it on x86_32, I wonder if > https://bugs.openjdk.java.net/browse/JDK-8254606 is the problem with this patch, or a different issue. [JDK-8254606](https://bugs.openjdk.java.net/browse/JDK-8254606) is also caused by [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), which has missed some cases where `align_up(xxx, SharedSpaceObjectAlignment)` is necessary. Since the cppVtables assertion fix cannot be easily validated by itself, I've decided to also include the `align_up` fixes in this PR. I have tested the fix on linux-x86 (32-bit) but the latest repo seems a bit flaky. Even if I disable CDS, sometime I get failures in (non-CDS) test cases like `There cannot be a NullPointerException at bci 14 of method byte java.lang.String.coder()`. I was able to run all 200+ CDS tests cases, and I would get about 5 failures due with the above error message. If I ran the failed tests again, they passed. So I **think** I have fixed the 32-bit issues with CDS, but there are probably other problems with the 32-bit build. Note that Oracle no longer supports the 32-bit x86 VMs. So my fix is intended to ensure that the CDS code is using SharedSpaceObjectAlignment properly, and I can only test thoroughly on our supported platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/591 From shade at openjdk.java.net Tue Oct 13 06:11:09 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 13 Oct 2020 06:11:09 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v2] In-Reply-To: References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: On Tue, 13 Oct 2020 06:03:20 GMT, Ioi Lam wrote: > I have tested the fix on linux-x86 (32-bit) but the latest repo seems a bit flaky. Even if I disable CDS, sometime I > get failures in (non-CDS) test cases like `There cannot be a NullPointerException at bci 14 of method byte > java.lang.String.coder()`. That's https://bugs.openjdk.java.net/browse/JDK-8254611 -- I integrated the fix, please merge from master. That said, there are a few failing tests in `tier1` anyway, you can ignore them: - gc/metaspace/TestCapacityUntilGCWrapAround.java - java/foreign/TestMismatch.java - java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java - tools/javac/lambda/T8031967.java ------------- PR: https://git.openjdk.java.net/jdk/pull/591 From iklam at openjdk.java.net Tue Oct 13 06:46:27 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 13 Oct 2020 06:46:27 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v3] In-Reply-To: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: > **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in > memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each > of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert > to fail. > > **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to > access each individual cloned vtable. > > **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just > do the bare minimum to fix the bug, it will be pretty hard to review. > > I would suggest that the reviewers look at just the new version of the code and see if it's working as described > (instead of looking at the diff to understand what the bug was and how it has been fixed). > This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. > I plan to change that into templates in a future RFE. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into 8254125-cppvtables-assert-on-win32 - Fixed more cases with align_up(xxx, SharedSpaceObjectAlignment) - Merge branch 'master' into 8254125-cppvtables-assert-on-win32 - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/591/files - new: https://git.openjdk.java.net/jdk/pull/591/files/50dfb2e2..5002b820 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=591&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=591&range=01-02 Stats: 27 lines in 8 files changed: 12 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/591/head:pull/591 PR: https://git.openjdk.java.net/jdk/pull/591 From iklam at openjdk.java.net Tue Oct 13 06:46:27 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 13 Oct 2020 06:46:27 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v3] In-Reply-To: References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: On Tue, 13 Oct 2020 06:08:11 GMT, Aleksey Shipilev wrote: > > I have tested the fix on linux-x86 (32-bit) but the latest repo seems a bit flaky. Even if I disable CDS, sometime I > > get failures in (non-CDS) test cases like `There cannot be a NullPointerException at bci 14 of method byte > > java.lang.String.coder()`. > > That's https://bugs.openjdk.java.net/browse/JDK-8254611 -- I integrated the fix, please merge from master. Thanks for the info. I merged and all CDS tests passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/591 From shade at openjdk.java.net Tue Oct 13 06:53:13 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 13 Oct 2020 06:53:13 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v3] In-Reply-To: References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: On Tue, 13 Oct 2020 06:46:27 GMT, Ioi Lam wrote: >> **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in >> memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each >> of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert >> to fail. >> >> **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to >> access each individual cloned vtable. >> >> **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just >> do the bare minimum to fix the bug, it will be pretty hard to review. >> >> I would suggest that the reviewers look at just the new version of the code and see if it's working as described >> (instead of looking at the diff to understand what the bug was and how it has been fixed). >> This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. >> I plan to change that into templates in a future RFE. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes > the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last > revision: > - Merge branch 'master' of https://github.com/openjdk/jdk into 8254125-cppvtables-assert-on-win32 > - Fixed more cases with align_up(xxx, SharedSpaceObjectAlignment) > - Merge branch 'master' into 8254125-cppvtables-assert-on-win32 > - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows I tested the new patch, and it passes `tier1` on `Linux x86_32` (well, with some known failures). ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/591 From jiefu at openjdk.java.net Tue Oct 13 13:27:36 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 13 Oct 2020 13:27:36 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) [v2] In-Reply-To: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> Message-ID: <2Vzju45HmrTmZWdDfDCK9GDtcQHqtyrv770dNLZY9fk=.31198327-0445-4512-97b9-2ce6b3c0b8a1@github.com> > __sync_val_compare_and_swap shouldn't call with narrowOop* for clang after JDK-8247912. > Before passing type T to __sync_val_compare_and_swap, the fix converts T to uint32_t* if sizeof(T) == 4. > > Testing: > - Zero VM build on Linux and MacOS with clang > - Zero VM build on Linux with gcc Jie Fu 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: - Replace __sync_val_compare_and_swap whith __atomic_compare_exchange - Merge branch 'master' into JDK-8253970 - Revert changes - 8253970 Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/496/files - new: https://git.openjdk.java.net/jdk/pull/496/files/52ba86d9..420ead76 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=496&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=496&range=00-01 Stats: 32415 lines in 756 files changed: 19888 ins; 7845 del; 4682 mod Patch: https://git.openjdk.java.net/jdk/pull/496.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/496/head:pull/496 PR: https://git.openjdk.java.net/jdk/pull/496 From jiefu at openjdk.java.net Tue Oct 13 13:27:36 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 13 Oct 2020 13:27:36 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) In-Reply-To: References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> <4aGn4WWgiS5YyPD2c6E6oqZh_QYicXwlAhVPYbHCK8s=.be75166e-2965-4655-8f85-6871959fbea8@github.com> Message-ID: On Sun, 4 Oct 2020 11:57:34 GMT, Jie Fu wrote: >> What version of clang? >> >> gcc (at least recent versions) allows enum types (both scoped and unscoped) for both the __sync_xxx functions and for >> the __atomic_xxx functions. (The documentation for both say the type can be an integral scalar or pointer type. Enums >> are not integral types.) So this seems to be a clang incompatibility with gcc, which may be a clang bug. >> >> The __sync_xxx functions have been legacy since gcc4.7, having been superseded by the __atomic_xxx functions. Could >> zero be updated here? Would that help? If clang is incompatible with gcc for the __sync_xxx functions, it might also >> be incompatible for the __atomic_xxx functions. BTW, the memory ordering by the zero implementation of Atomic::xchg in >> terms of __sync_lock_test_and_set looks wrong to me. I think the fence() is on the wrong side of the __sync_xxx >> operation. > > The following two versions of clang can reproduce the bug. > > $ clang -v > Apple clang version 11.0.0 (clang-1100.0.33.16) > Target: x86_64-apple-darwin19.0.0 > Thread model: posix > > # clang -v > clang version 10.0.0-4ubuntu1 > Target: x86_64-pc-linux-gnu > Thread model: posix Hi @kimbarrett , I replace __sync_val_compare_and_swap whith __atomic_compare_exchange and it really woks. Thanks for your help. I also fix the following bug when building zero VM on MacOS. -------------------------------------------------------------- * For target hotspot_variant-zero_libjvm_objs_os_bsd_zero.o: ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:176:21: error: no member named 'in_stack_yellow_reserved_zone' in 'JavaThread' if (thread->in_stack_yellow_reserved_zone(addr)) { ~~~~~~ ^ ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:177:19: error: no member named 'disable_stack_yellow_reserved_zone' in 'JavaThread' thread->disable_stack_yellow_reserved_zone(); ~~~~~~ ^ ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:180:26: error: no member named 'in_stack_red_zone' in 'JavaThread' else if (thread->in_stack_red_zone(addr)) { ~~~~~~ ^ ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:181:19: error: no member named 'disable_stack_red_zone' in 'JavaThread' thread->disable_stack_red_zone(); ~~~~~~ ^ -------------------------------------------------------------- Testing: - Zero VM builds on Linux/x64 with both clang and gcc - Zero VM build on MacOS As for the memory ordering of the zero implementation, it might be better to file another bug to fix it. What do you think? Thanks. Best regards, Jie ------------- PR: https://git.openjdk.java.net/jdk/pull/496 From patricio.chilano.mateo at oracle.com Tue Oct 13 13:58:24 2020 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Tue, 13 Oct 2020 10:58:24 -0300 Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: <68363d6e-406b-bb39-77c0-f36fb2e66605@oracle.com> References: <5VjFlnFaBEKpatp42ps9cPpxzD6XcD-yHpIBQO_vJbM=.3884f5f2-0b4d-44ef-a3a0-2d1157ac27d4@github.com> <68363d6e-406b-bb39-77c0-f36fb2e66605@oracle.com> Message-ID: <12f49b77-9307-0c84-f325-9c53afcb4a64@oracle.com> Hi David, On 10/12/20 11:35 PM, David Holmes wrote: > Hi Patricio, > > On 12/10/2020 2:59 pm, Patricio Chilano Mateo wrote: >> On Sun, 11 Oct 2020 22:09:30 GMT, David Holmes >> wrote: >> >>>> Hi all, >>>> >>>> Please review the following patch that removes the call to >>>> handle_special_runtime_exit_condition() in >>>> ~ThreadInVMForHandshake(). This check was added by 8223572 to >>>> prevent a JavaThread that was suspended while trying to >>>> process a handshake to transition back to java without noticing it >>>> was suspended. Since 8238761, a JavaThread executing >>>> HandshakeState::process_by_self() will never become safe. It comes >>>> from an unsafe state and remains unsafe, so it >>>> cannot be suspended during that time. Removing this check also >>>> removes one of the reasons >>>> SafepointMechanism::process_if_requested() is recursive (the other >>>> one remains SafepointSynchronize::block()). Tested >>>> in mach5, tiers 1-7.? Thanks, Patricio >>> >>> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 146: >>> >>>> 144: >>>> 145:?? ~ThreadInVMForHandshake() { >>>> 146:???? assert(_thread->thread_state() == _thread_in_vm, "should >>>> only call when leaving VM after handshake"); >>> >>> Can we also assert `!_thread->has_special_runtime_exit_condition()`? >>> Or at least that the value of this has not changed >>> between the TIVFH constructor and destructor. >> >> has_special_runtime_exit_condition() checks for async exceptions, >> external_suspend and JFR suspend. The last two can >> actually be set while we are in the handshake. It doesn't mean that >> the caller will consider the target suspended, but >> the _suspend_flags might be different at construction and destruction >> of TIVFH. > > Ah right! Oh well :) > >> As for async exceptions, I realized we >> have a similar issue as the one described in 8223572 when calling >> handle_polling_page_exception() on a return poll: >> >> - T calls ThreadSafepointState::handle_polling_page_exception() >> because another thread called T.stop() (which we >> ?? implement with a handshake) >> - T calls SafepointMechanism::process_if_requested(thread()) >> - T calls HandshakeState::process_self_inner() and processes the >> handshake which calls set_pending_async_exception() >> - T returns from SafepointMechanism::process_if_requested(thread()) >> and goes back to java without calling >> ?? check_and_handle_async_exceptions() to throw the ThreadDeath() >> exception >> >> I'm not sure if delaying the throw of ThreadDeath is allowed, so if >> we need to keep the current behaviour I can add a >> call to check_and_handle_async_exceptions(): > > To some extent, given it is a race, a delay is permissible, but I find > it highly undesirable. Our biggest problems with async exceptions > lately is the unpredictability of their actually getting propagated. > So we should fix this. > >> @@ -987,6 +987,7 @@ void >> ThreadSafepointState::handle_polling_page_exception() { >> ????? // Process pending operation >> ????? SafepointMechanism::process_if_requested(thread()); >> +?? thread()->check_and_handle_async_exceptions(); > > Why directly in handle_polling_page_exception() rather than restoring > it to the ~ThreadInVMForHandshake() ? Having the check in ~TIVFH saves us from missing the async exception for this particular handle_polling_page_exception() on poll return case because if there is and InstallAsyncExceptionClosure handshake then the target will execute it and will notice the async exception on the ~TIVFH. But otherwise it's not useful. If that handshake happened while the target was safe (let's say _thread_blocked somewhere) we will never hit that check since the handshake would be executed by the handshaker. So, having the check directly in handle_polling_page_exception() makes the code in line with other places where we check for async exceptions right before transitioning back to java. In fact we should also check for external_suspend and not rely on the same special_runtime_exit_condition() check at the end of SS:block() as I discussed with Richard, but I can leave that for a different change. Thanks, Patricio > Thanks, > David > ----- > >> ????? // restore oop result, if any >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/577 >> From mdoerr at openjdk.java.net Tue Oct 13 14:15:17 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 13 Oct 2020 14:15:17 GMT Subject: RFR: 8254696: safepointMechanism_aix needs adaptation for JDK-8253180 Message-ID: JDK-8253180 changed SafepointMechanism::default_initialize(). SafepointMechanism::pd_initialize() in safepointMechanism_aix.cpp needs the same changes in order to fix build and initialization. ------------- Commit messages: - 8254696: safepointMechanism_aix needs adaptation for JDK-8253180 Changes: https://git.openjdk.java.net/jdk/pull/635/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=635&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254696 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/635.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/635/head:pull/635 PR: https://git.openjdk.java.net/jdk/pull/635 From coleenp at openjdk.java.net Tue Oct 13 14:26:29 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 13 Oct 2020 14:26:29 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v11] In-Reply-To: References: Message-ID: On Tue, 6 Oct 2020 13:12:16 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Review Feedback Richard 1 > > Hi Thomas, > > this is batch 3 with another 3 points. I'm sending it now because I think I cannot reply to your comments otherwise. > > Cheers, Richard. @reinrich approve this change so @tstuefe can check it in! Anything left can be addressed in a new PR. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From stuefe at openjdk.java.net Tue Oct 13 15:26:19 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 13 Oct 2020 15:26:19 GMT Subject: RFR: JDK-8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out Message-ID: Hi, this is a very simple test fix. TestHeapDumpOnOutOfMemoryErrorInMetaspace tests that Metaspace OOMs result in heap dumps if VM had been started with -XX:+HeapDumpOnOutOfMemoryError. The test fills Metaspace up to the limit (MaxMetaspaceSize) to provoke a Metaspace OOM. It sets MaxMetaspaceSize to 64m 64m gives us room for about ~62000 classes with the current VM. With JEP387, this becomes more like 68000 classes. 6x000 classes are a lot and if test runs on a debug VM they cause long verification times from compiler dependency checks as well as CLDG verification. Both verifications behave quadratic. On our slow ppc machines this often leads to timeouts (test takes about 22 minutes). I lowered MaxMetaspaceSize to 16m which is fine for this test and reduces the number of loaded classes to ~12000 classes resp 15000 with JEP387. This eases verification costs a lot. I also switch off compiler dependency checks because a number of similar runtime tests do the same. I left it at that because that brings down test time on our ppc machine to ~30 seconds, which is fine. ------------- Commit messages: - JDK-8212218 Changes: https://git.openjdk.java.net/jdk/pull/637/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=637&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8212218 Stats: 15 lines in 1 file changed: 13 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/637.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/637/head:pull/637 PR: https://git.openjdk.java.net/jdk/pull/637 From rrich at openjdk.java.net Tue Oct 13 16:00:19 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 13 Oct 2020 16:00:19 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v15] In-Reply-To: References: Message-ID: <4X4ZaiVSAkI3PZYBChk4HTo6X41UOIlidC5dClesGtE=.06d3a0f5-9067-4fac-8dac-251105eb477f@github.com> On Mon, 12 Oct 2020 14:47:43 GMT, Thomas Stuefe wrote: >> Hi all, >> >> this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the >> delay, had vacation then the entrance of Skara delayed things a bit. >> For the delta diff please see [3]. >> >> This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all >> feedback individually in this PR body, but I incorporated almost all into the new revision. >> What changed since the last version: >> >> - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the >> group consent. >> >> - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for >> overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth >> class loader which made it rather pointless. Now I run it always. >> >> - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. >> >> - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) >> >> Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. >> >> - In ChunkManager::purge() I improved the comments after discussions with Leo. >> >> - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due >> to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run >> every time. >> >> - Fixed indentation issues as Leo requested >> >> - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested >> >> - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes >> and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more >> flexible since it allows us to have list with purge-able and non-purge-able nodes. >> >> - and various smaller fixes, mainly on request of Leo. >> >> @lkorinth: >> >>> VirtualSpaceNode.hpp >>> >>>102 // Start pointer of the area. >>>103 MetaWord* const _base; >>> >>>How does this differ from _rs._base? Really needed? >>> >>>105 // Size, in words, of the whole node >>>106 const size_t _word_size; >>> >>>Can we not calculate this from _rs.size()? >> >> You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it >> is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly >> improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at >> some point and make those members const - as they should be - then I would rewrite this as you suggest. >> Thanks, again, for all your review work! >> >> ------ >> >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html >> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html >> [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d > > Thomas Stuefe 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 > - Richard feedback 3 > - Add ASCII art to better describe Metachunk relationship to their payload > - Fix retrieval from FreeChunkList; add test; update comments > - Loosen unnecessarily strict restriction of allowed chunk states on ChunkManager::return_chunk > - Assert that in reclaim=none mode new chunks are fully committed > - Review Feedback Richard 2 > - Fix 32bit build > - Review Feedback Richard 1 > - Remove some empty lines > - ... and 15 more: https://git.openjdk.java.net/jdk/compare/c7f00640...e895bfa0 Hi Thomas, this is a major enhancement and it looks good to me. Congratulations! :) Cheers, Richard. ------------- Marked as reviewed by rrich (Committer). PR: https://git.openjdk.java.net/jdk/pull/336 From minqi at openjdk.java.net Tue Oct 13 16:13:09 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 13 Oct 2020 16:13:09 GMT Subject: RFR: JDK-8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 15:16:03 GMT, Thomas Stuefe wrote: > Hi, > > this is a very simple test fix. > > TestHeapDumpOnOutOfMemoryErrorInMetaspace tests that Metaspace OOMs result in heap dumps if VM had been started > with -XX:+HeapDumpOnOutOfMemoryError. > The test fills Metaspace up to the limit (MaxMetaspaceSize) to provoke a Metaspace OOM. It sets MaxMetaspaceSize to 64m > > 64m gives us room for about ~62000 classes with the current VM. With JEP387, this becomes more like 68000 classes. > > 6x000 classes are a lot and if test runs on a debug VM they cause long verification times from compiler dependency > checks as well as CLDG verification. Both verifications behave quadratic. On our slow ppc machines this often leads to > timeouts (test takes about 22 minutes). I lowered MaxMetaspaceSize to 16m which is fine for this test and reduces the > number of loaded classes to ~12000 classes resp 15000 with JEP387. This eases verification costs a lot. > I also switch off compiler dependency checks because a number of similar runtime tests do the same. > > I left it at that because that brings down test time on our ppc machine to ~30 seconds, which is fine. Is the copyright change necessary? ------------- PR: https://git.openjdk.java.net/jdk/pull/637 From thomas.stuefe at gmail.com Tue Oct 13 16:14:17 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 13 Oct 2020 18:14:17 +0200 Subject: RFR: JDK-8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out In-Reply-To: References: Message-ID: No. I can remove it if you prefer. On Tue, Oct 13, 2020, 18:13 Yumin Qi wrote: > On Tue, 13 Oct 2020 15:16:03 GMT, Thomas Stuefe > wrote: > > > Hi, > > > > this is a very simple test fix. > > > > TestHeapDumpOnOutOfMemoryErrorInMetaspace tests that Metaspace OOMs > result in heap dumps if VM had been started > > with -XX:+HeapDumpOnOutOfMemoryError. > > The test fills Metaspace up to the limit (MaxMetaspaceSize) to provoke a > Metaspace OOM. It sets MaxMetaspaceSize to 64m > > > > 64m gives us room for about ~62000 classes with the current VM. With > JEP387, this becomes more like 68000 classes. > > > > 6x000 classes are a lot and if test runs on a debug VM they cause long > verification times from compiler dependency > > checks as well as CLDG verification. Both verifications behave > quadratic. On our slow ppc machines this often leads to > > timeouts (test takes about 22 minutes). I lowered MaxMetaspaceSize to > 16m which is fine for this test and reduces the > > number of loaded classes to ~12000 classes resp 15000 with JEP387. This > eases verification costs a lot. > > I also switch off compiler dependency checks because a number of similar > runtime tests do the same. > > > > I left it at that because that brings down test time on our ppc machine > to ~30 seconds, which is fine. > > Is the copyright change necessary? > > > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/637 > From iklam at openjdk.java.net Tue Oct 13 16:44:19 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 13 Oct 2020 16:44:19 GMT Subject: RFR: JDK-8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 15:16:03 GMT, Thomas Stuefe wrote: > Hi, > > this is a very simple test fix. > > TestHeapDumpOnOutOfMemoryErrorInMetaspace tests that Metaspace OOMs result in heap dumps if VM had been started > with -XX:+HeapDumpOnOutOfMemoryError. > The test fills Metaspace up to the limit (MaxMetaspaceSize) to provoke a Metaspace OOM. It sets MaxMetaspaceSize to 64m > > 64m gives us room for about ~62000 classes with the current VM. With JEP387, this becomes more like 68000 classes. > > 6x000 classes are a lot and if test runs on a debug VM they cause long verification times from compiler dependency > checks as well as CLDG verification. Both verifications behave quadratic. On our slow ppc machines this often leads to > timeouts (test takes about 22 minutes). I lowered MaxMetaspaceSize to 16m which is fine for this test and reduces the > number of loaded classes to ~12000 classes resp 15000 with JEP387. This eases verification costs a lot. > I also switch off compiler dependency checks because a number of similar runtime tests do the same. > > I left it at that because that brings down test time on our ppc machine to ~30 seconds, which is fine. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/637 From dcubed at openjdk.java.net Tue Oct 13 17:07:21 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 13 Oct 2020 17:07:21 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: References: Message-ID: <88Bxus7_B0JwEiR1koP4Vi7DqfrKiHXmBASWJ5vAWcU=.d2197f2a-76c2-4525-8e61-4c6d590c0bdd@github.com> On Fri, 9 Oct 2020 14:10:16 GMT, Patricio Chilano Mateo wrote: > Hi all, > > Please review the following patch that removes the call to handle_special_runtime_exit_condition() in > ~ThreadInVMForHandshake(). This check was added by 8223572 to prevent a JavaThread that was suspended while trying to > process a handshake to transition back to java without noticing it was suspended. Since 8238761, a JavaThread executing > HandshakeState::process_by_self() will never become safe. It comes from an unsafe state and remains unsafe, so it > cannot be suspended during that time. Removing this check also removes one of the reasons > SafepointMechanism::process_if_requested() is recursive (the other one remains SafepointSynchronize::block()). Tested > in mach5, tiers 1-7. Thanks, Patricio It took me a while to re-read JDK-8223572 and JDK-8238761 and their associated review threads. It's complicated stuff and, every time I thought I might have an issue, I subsequently convinced myself all was good. Thumbs up on this change! ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/577 From hseigel at openjdk.java.net Tue Oct 13 17:13:31 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 13 Oct 2020 17:13:31 GMT Subject: RFR: 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp [v2] In-Reply-To: References: Message-ID: > Hi, > Please review this small change to simplify exception throwing in classFileParser.cpp The change was tested with tiers > one and two on Windows, Linux x64, and Mac OSX, and with tiers 3-5 on Linux x64. > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/618/files - new: https://git.openjdk.java.net/jdk/pull/618/files/feb343c4..3c4d6e26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=618&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=618&range=00-01 Stats: 171 lines in 2 files changed: 77 ins; 0 del; 94 mod Patch: https://git.openjdk.java.net/jdk/pull/618.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/618/head:pull/618 PR: https://git.openjdk.java.net/jdk/pull/618 From hseigel at openjdk.java.net Tue Oct 13 17:17:20 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 13 Oct 2020 17:17:20 GMT Subject: RFR: 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp [v2] In-Reply-To: <0EtNVcXRxwUY4llYvJLVu33j8I6Mws5jzXt_8tGfyFA=.3ab34a5e-3214-4eba-b685-1b7c1c3c6060@github.com> References: <0EtNVcXRxwUY4llYvJLVu33j8I6Mws5jzXt_8tGfyFA=.3ab34a5e-3214-4eba-b685-1b7c1c3c6060@github.com> Message-ID: On Mon, 12 Oct 2020 22:19:31 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp > > Looks good to me. I agree with David's comment to just pass THREAD and return; Saves an implicit if statement in these > places. Thanks for looking at this change! Please review the updated change that replaces CHECK* arguments with THREAD, followed by 'return' statements. This change was made for calls to the new methods and existing calls to classfile_parse_error(). ------------- PR: https://git.openjdk.java.net/jdk/pull/618 From fparain at openjdk.java.net Tue Oct 13 17:18:17 2020 From: fparain at openjdk.java.net (Frederic Parain) Date: Tue, 13 Oct 2020 17:18:17 GMT Subject: RFR: 8254158: Consolidate per-platform stack overflow handling code In-Reply-To: References: Message-ID: <5ibnOcrandZY-mFynRAHro-OffYKnEqT3DPWKXB3yeE=.6a90cc80-87eb-4548-9375-a3c57851cda9@github.com> On Mon, 12 Oct 2020 22:28:40 GMT, Coleen Phillimore wrote: > Moved the duplicated code from posix based platform/cpu combinations into os_posix.cpp. Left a little function to > determine frame at stack banging point for compiled methods (you can suggest a better name for it) to capture the > difference. There are a bit of ifdefs but now there are less copies. > > Tested with tier1-3 and stack overflow tests in vmTestbase/nsk/stress/stack on > linux-x86-debug,macosx-x86-debug,windows-x86-debug. Built aarch64, arm32, ppc, s390, and zero. Testing on these > platforms would be welcome. Thanks, > Coleen Looks good to me. Thank you for refactoring this code. Fred ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.java.net/jdk/pull/620 From coleenp at openjdk.java.net Tue Oct 13 17:41:18 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 13 Oct 2020 17:41:18 GMT Subject: RFR: 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp [v2] In-Reply-To: References: <0EtNVcXRxwUY4llYvJLVu33j8I6Mws5jzXt_8tGfyFA=.3ab34a5e-3214-4eba-b685-1b7c1c3c6060@github.com> Message-ID: On Tue, 13 Oct 2020 17:14:10 GMT, Harold Seigel wrote: >> Looks good to me. I agree with David's comment to just pass THREAD and return; Saves an implicit if statement in these >> places. > > Thanks for looking at this change! Please review the updated change that replaces CHECK* arguments with THREAD, > followed by 'return' statements. This change was made for calls to the new methods and existing calls to > classfile_parse_error(). This looks like a good improvement. It might make the size of the generated code in cfp smaller. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/618 From pchilanomate at openjdk.java.net Tue Oct 13 17:48:26 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 13 Oct 2020 17:48:26 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() [v2] In-Reply-To: References: Message-ID: > Hi all, > > Please review the following patch that removes the call to handle_special_runtime_exit_condition() in > ~ThreadInVMForHandshake(). This check was added by 8223572 to prevent a JavaThread that was suspended while trying to > process a handshake to transition back to java without noticing it was suspended. Since 8238761, a JavaThread executing > HandshakeState::process_by_self() will never become safe. It comes from an unsafe state and remains unsafe, so it > cannot be suspended during that time. Removing this check also removes one of the reasons > SafepointMechanism::process_if_requested() is recursive (the other one remains SafepointSynchronize::block()). Tested > in mach5, tiers 1-7. Thanks, Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: added async exception check ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/577/files - new: https://git.openjdk.java.net/jdk/pull/577/files/d442af8c..d1222d98 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=577&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=577&range=00-01 Stats: 15 lines in 1 file changed: 3 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/577/head:pull/577 PR: https://git.openjdk.java.net/jdk/pull/577 From pchilanomate at openjdk.java.net Tue Oct 13 17:48:26 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 13 Oct 2020 17:48:26 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() [v2] In-Reply-To: <88Bxus7_B0JwEiR1koP4Vi7DqfrKiHXmBASWJ5vAWcU=.d2197f2a-76c2-4525-8e61-4c6d590c0bdd@github.com> References: <88Bxus7_B0JwEiR1koP4Vi7DqfrKiHXmBASWJ5vAWcU=.d2197f2a-76c2-4525-8e61-4c6d590c0bdd@github.com> Message-ID: On Tue, 13 Oct 2020 17:04:04 GMT, Daniel D. Daugherty wrote: > It took me a while to re-read JDK-8223572 and JDK-8238761 > and their associated review threads. It's complicated stuff and, > every time I thought I might have an issue, I subsequently > convinced myself all was good. > > Thumbs up on this change! Thanks Dan! Please see the update. ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From hseigel at openjdk.java.net Tue Oct 13 19:41:12 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 13 Oct 2020 19:41:12 GMT Subject: RFR: 8254158: Consolidate per-platform stack overflow handling code In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 22:28:40 GMT, Coleen Phillimore wrote: > Moved the duplicated code from posix based platform/cpu combinations into os_posix.cpp. Left a little function to > determine frame at stack banging point for compiled methods (you can suggest a better name for it) to capture the > difference. There are a bit of ifdefs but now there are less copies. > > Tested with tier1-3 and stack overflow tests in vmTestbase/nsk/stress/stack on > linux-x86-debug,macosx-x86-debug,windows-x86-debug. Built aarch64, arm32, ppc, s390, and zero. Testing on these > platforms would be welcome. Thanks, > Coleen The changes look good. Thanks for consolidating this code. ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/620 From dcubed at openjdk.java.net Tue Oct 13 19:46:11 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 13 Oct 2020 19:46:11 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() [v2] In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 17:48:26 GMT, Patricio Chilano Mateo wrote: >> Hi all, >> >> Please review the following patch that removes the call to handle_special_runtime_exit_condition() in >> ~ThreadInVMForHandshake(). This check was added by 8223572 to prevent a JavaThread that was suspended while trying to >> process a handshake to transition back to java without noticing it was suspended. Since 8238761, a JavaThread executing >> HandshakeState::process_by_self() will never become safe. It comes from an unsafe state and remains unsafe, so it >> cannot be suspended during that time. Removing this check also removes one of the reasons >> SafepointMechanism::process_if_requested() is recursive (the other one remains SafepointSynchronize::block()). Tested >> in mach5, tiers 1-7. Thanks, Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > added async exception check I good with this change, but I do have some questions buried in the code that you changed. src/hotspot/share/runtime/safepoint.cpp line 947: > 945: void ThreadSafepointState::handle_polling_page_exception() { > 946: JavaThread* self = thread(); > 947: assert(self == Thread::current()->as_Java_thread(), "wrong thread"); Perhaps: s/wrong thread/must be self/ or s/wrong thread/must be calling thread/ src/hotspot/share/runtime/safepoint.cpp line 992: > 990: // Process pending operation > 991: SafepointMechanism::process_if_requested(self); > 992: self->check_and_handle_async_exceptions(); I'm good with the addition of this call to check_and_handle_async_exceptions(). In particular because of this comment block in: src/hotspot/share/runtime/thread.cpp: void JavaThread::check_and_handle_async_exceptions(bool check_unsafe_error) { if (has_last_Java_frame() && has_async_condition()) { // If we are at a polling page safepoint (not a poll return) // then we must defer async exception because live registers // will be clobbered by the exception path. Poll return is // ok because the call we a returning from already collides // with exception handling registers and so there is no issue. // (The exception handling path kills call result registers but // this is ok since the exception kills the result anyway). so check_and_handle_async_exceptions() clearly was expecting to be called when at a " poll return" which is the block that contains this new call. That's all good! What I can't quite figure out is how we "lost" the call to check_and_handle_async_exceptions() that must have been made somehow before. Clearly that function was expecting to be called from a "poll return" site and that's what you're putting back, but how was that call made before and what change got rid of it? ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/577 From pchilanomate at openjdk.java.net Tue Oct 13 20:36:18 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 13 Oct 2020 20:36:18 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() [v2] In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 19:42:18 GMT, Daniel D. Daugherty wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> added async exception check > > src/hotspot/share/runtime/safepoint.cpp line 992: > >> 990: // Process pending operation >> 991: SafepointMechanism::process_if_requested(self); >> 992: self->check_and_handle_async_exceptions(); > > I'm good with the addition of this call to check_and_handle_async_exceptions(). > > In particular because of this comment block in: > > src/hotspot/share/runtime/thread.cpp: > void JavaThread::check_and_handle_async_exceptions(bool check_unsafe_error) { > if (has_last_Java_frame() && has_async_condition()) { > // If we are at a polling page safepoint (not a poll return) > // then we must defer async exception because live registers > // will be clobbered by the exception path. Poll return is > // ok because the call we a returning from already collides > // with exception handling registers and so there is no issue. > // (The exception handling path kills call result registers but > // this is ok since the exception kills the result anyway). > > so check_and_handle_async_exceptions() clearly was expecting to > be called when at a " poll return" which is the block that contains > this new call. That's all good! > > What I can't quite figure out is how we "lost" the call to > check_and_handle_async_exceptions() that must have been > made somehow before. Clearly that function was expecting > to be called from a "poll return" site and that's what you're > putting back, but how was that call made before and what > change got rid of it? The same problematic execution sequence detailed in 8223572 for the external_suspend case was there for async exceptions too. So, while the thread was blocked in the handshake a ThreadStop() operation could have been executed. After returning from the handshake there was no async exception check. We probably never noticed it because the throw would happen anyways on some later transition back to java (vm->java or native->java). As to how was that call made before and what change got rid of it: this code was there before handshakes existed. ThreadStop() was implemented as a safepoint and we were probably relying on the special_runtime_exit_condition() check at the end of SS::block() (exactly like the one I'm removing from ~TIVFH and which I'll try to get rid of to eliminate recursions). ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From coleenp at openjdk.java.net Tue Oct 13 20:43:15 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 13 Oct 2020 20:43:15 GMT Subject: RFR: 8254158: Consolidate per-platform stack overflow handling code In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 19:38:18 GMT, Harold Seigel wrote: >> Moved the duplicated code from posix based platform/cpu combinations into os_posix.cpp. Left a little function to >> determine frame at stack banging point for compiled methods (you can suggest a better name for it) to capture the >> difference. There are a bit of ifdefs but now there are less copies. >> >> Tested with tier1-3 and stack overflow tests in vmTestbase/nsk/stress/stack on >> linux-x86-debug,macosx-x86-debug,windows-x86-debug. Built aarch64, arm32, ppc, s390, and zero. Testing on these >> platforms would be welcome. Thanks, >> Coleen > > The changes look good. Thanks for consolidating this code. Thanks Fred and Harold. ------------- PR: https://git.openjdk.java.net/jdk/pull/620 From coleenp at openjdk.java.net Tue Oct 13 20:46:19 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 13 Oct 2020 20:46:19 GMT Subject: Integrated: 8254158: Consolidate per-platform stack overflow handling code In-Reply-To: References: Message-ID: On Mon, 12 Oct 2020 22:28:40 GMT, Coleen Phillimore wrote: > Moved the duplicated code from posix based platform/cpu combinations into os_posix.cpp. Left a little function to > determine frame at stack banging point for compiled methods (you can suggest a better name for it) to capture the > difference. There are a bit of ifdefs but now there are less copies. > > Tested with tier1-3 and stack overflow tests in vmTestbase/nsk/stress/stack on > linux-x86-debug,macosx-x86-debug,windows-x86-debug. Built aarch64, arm32, ppc, s390, and zero. Testing on these > platforms would be welcome. Thanks, > Coleen This pull request has now been integrated. Changeset: ba5dc67a Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/ba5dc67a Stats: 632 lines in 10 files changed: 119 ins; 464 del; 49 mod 8254158: Consolidate per-platform stack overflow handling code Reviewed-by: fparain, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/620 From dcubed at openjdk.java.net Tue Oct 13 20:57:10 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 13 Oct 2020 20:57:10 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() [v2] In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 20:33:01 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/safepoint.cpp line 992: >> >>> 990: // Process pending operation >>> 991: SafepointMechanism::process_if_requested(self); >>> 992: self->check_and_handle_async_exceptions(); >> >> I'm good with the addition of this call to check_and_handle_async_exceptions(). >> >> In particular because of this comment block in: >> >> src/hotspot/share/runtime/thread.cpp: >> void JavaThread::check_and_handle_async_exceptions(bool check_unsafe_error) { >> if (has_last_Java_frame() && has_async_condition()) { >> // If we are at a polling page safepoint (not a poll return) >> // then we must defer async exception because live registers >> // will be clobbered by the exception path. Poll return is >> // ok because the call we a returning from already collides >> // with exception handling registers and so there is no issue. >> // (The exception handling path kills call result registers but >> // this is ok since the exception kills the result anyway). >> >> so check_and_handle_async_exceptions() clearly was expecting to >> be called when at a " poll return" which is the block that contains >> this new call. That's all good! >> >> What I can't quite figure out is how we "lost" the call to >> check_and_handle_async_exceptions() that must have been >> made somehow before. Clearly that function was expecting >> to be called from a "poll return" site and that's what you're >> putting back, but how was that call made before and what >> change got rid of it? > > The same problematic execution sequence detailed in 8223572 for the external_suspend case was there for async > exceptions too. So, while the thread was blocked in the handshake a ThreadStop() operation could have been executed. > After returning from the handshake there was no async exception check. We probably never noticed it because the throw > would happen anyways on some later transition back to java (vm->java or native->java). As to how was that call made > before and what change got rid of it: this code was there before handshakes existed. ThreadStop() was implemented as a > safepoint and we were probably relying on the special_runtime_exit_condition() check at the end of SS::block() (exactly > like the one I'm removing from ~TIVFH and which I'll try to get rid of to eliminate recursions). Makes sense. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From pchilanomate at openjdk.java.net Tue Oct 13 21:45:26 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 13 Oct 2020 21:45:26 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() [v3] In-Reply-To: References: Message-ID: > Hi all, > > Please review the following patch that removes the call to handle_special_runtime_exit_condition() in > ~ThreadInVMForHandshake(). This check was added by 8223572 to prevent a JavaThread that was suspended while trying to > process a handshake to transition back to java without noticing it was suspended. Since 8238761, a JavaThread executing > HandshakeState::process_by_self() will never become safe. It comes from an unsafe state and remains unsafe, so it > cannot be suspended during that time. Removing this check also removes one of the reasons > SafepointMechanism::process_if_requested() is recursive (the other one remains SafepointSynchronize::block()). Tested > in mach5, tiers 1-7. Thanks, Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: fix assert message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/577/files - new: https://git.openjdk.java.net/jdk/pull/577/files/d1222d98..7f81376d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=577&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=577&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/577/head:pull/577 PR: https://git.openjdk.java.net/jdk/pull/577 From ccheung at openjdk.java.net Tue Oct 13 23:08:22 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 13 Oct 2020 23:08:22 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v5] In-Reply-To: References: Message-ID: > Following up on archiving lambda proxy classes in dynamic CDS archive > ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of > lambda proxy classes in static CDS archive. > When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved > during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will > be of the following format: > `@lambda-proxy: ` > > e.g. > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` > > When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above > `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool > indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool > entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index > and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. > During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not > found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> > IsCDSDumpingEnabled) is involved in the core-libs code.) > Testing: tiers 1,2,3,4. > > Performance results (javac on HelloWorld on linux-x64): > Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " > 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- > 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- > 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- > 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- > 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- > 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- > 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- > 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- > 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- > 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- > ============================================================ > 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- > instr delta = -161497801 -7.2542% > time delta = -24.722 ms -6.5951% Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - fix minimal vm build issues - Merge branch 'master' into 8247666 - Merge branch 'master' into 8247666 - 1. Symbolic encoding of lambda proxy resolution. An example of @lambda-proxy in the classlist: @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambdabash ()V ()V 2. Removed BadCPIndex.java; added LambdaProxyClassList.java test. 3. Mandy's comments. - Merge branch 'master' into 8247666 - exclude archived lambda proxy classes in the classlist - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi - fix extraneous whitespace - 8247666 (initial commit) ------------- Changes: https://git.openjdk.java.net/jdk/pull/364/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=04 Stats: 1839 lines in 32 files changed: 1767 ins; 19 del; 53 mod Patch: https://git.openjdk.java.net/jdk/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364 PR: https://git.openjdk.java.net/jdk/pull/364 From minqi at openjdk.java.net Tue Oct 13 23:52:18 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 13 Oct 2020 23:52:18 GMT Subject: RFR: 8254012: NMT: MetaspaceSnapshot::snapshot uses wrong enum Message-ID: Please review this simple change. Snapshot should be done first on NonClassType which will include ClassType allocation when Metaspace::using_class_space() is false. _class_vsm (a VirtualSpaceManager) is set only for class type allocation when using_class_space is true. The correct order is do snapshot for NonClassType first, then for ClassType if using_class_space. Tests: mach5 tier1-4 in progress. ------------- Commit messages: - 8254012: NMT: MetaspaceSnapshot::snapshot uses wrong enum Changes: https://git.openjdk.java.net/jdk/pull/645/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=645&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254012 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/645.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/645/head:pull/645 PR: https://git.openjdk.java.net/jdk/pull/645 From iklam at openjdk.java.net Wed Oct 14 00:43:12 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Oct 2020 00:43:12 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v5] In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 23:08:22 GMT, Calvin Cheung wrote: >> Following up on archiving lambda proxy classes in dynamic CDS archive >> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of >> lambda proxy classes in static CDS archive. >> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved >> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will >> be of the following format: >> `@lambda-proxy: ` >> >> e.g. >> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` >> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` >> >> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above >> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool >> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool >> entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index >> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. >> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not >> found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> >> IsCDSDumpingEnabled) is involved in the core-libs code.) >> Testing: tiers 1,2,3,4. >> >> Performance results (javac on HelloWorld on linux-x64): >> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " >> 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- >> 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- >> 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- >> 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- >> 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- >> 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- >> 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- >> 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- >> 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- >> 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- >> ============================================================ >> 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- >> instr delta = -161497801 -7.2542% >> time delta = -24.722 ms -6.5951% > > Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains ten commits: > - fix minimal vm build issues > - Merge branch 'master' into 8247666 > - Merge branch 'master' into 8247666 > - 1. Symbolic encoding of lambda proxy resolution. An example of @lambda-proxy in the classlist: > @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambdabash ()V ()V > 2. Removed BadCPIndex.java; added LambdaProxyClassList.java test. > 3. Mandy's comments. > - Merge branch 'master' into 8247666 > - exclude archived lambda proxy classes in the classlist > - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi > - fix extraneous whitespace > - 8247666 (initial commit) Changes requested by iklam (Reviewer). src/hotspot/share/interpreter/linkResolver.cpp line 34: > 32: #include "classfile/symbolTable.hpp" > 33: #include "classfile/systemDictionary.hpp" > 34: #include "classfile/systemDictionaryShared.hpp" Are all the new includes necessary? src/hotspot/share/memory/archiveUtils.cpp line 321: > 319: } > 320: } > 321: } I think if two threads try call ArchiveUtils::log_to_classlist at the same time, the output may be interleaved. classlist_file is a fileStream, which uses fwrite to write to the file. In theory, if you write the whole line at once, the output should be thread safe (at least on POSIX and Windows). But in your case, you would need to first get the whole line into a buffer, and then write it out at once. I think it would be safer, and more convenient, to use a lock to ensure thready safety. Maybe we can convert all uses of classlist_file->print() to something like class ClassListWriter { static fileStream* _classlist_file; MutexLocker locker; public: outputStream* stream() { return _classlist_file; } static bool is_enabled() { return _classlist_file != NULL && _classlist_file->is_open(); } ClassListWriter() : locker(Thread::current(), ClassListFile_lock) {} static void init() { // classlist_file init code from ostrea.cpp } }; // WAS if (DumpLoadedClassList != NULL && classlist_file->is_open()) { if (ClassListWriter::is_enabled()) { ClassListWriter w; w->stream()->print("aaaa"); w->stream()->print("bbbb"); w->stream()->cr(); } src/hotspot/share/oops/instanceKlass.cpp line 4212: > 4210: assert(stream == NULL, "shared class with stream"); > 4211: if (is_hidden()) { > 4212: // Not including archived lambda proxy class in the classlist. I think it's clearer to say `// Don't include archived lambda proxy class in the classlist.` src/java.base/share/classes/jdk/internal/misc/CDS.java line 78: > 76: * Check if CDS dumping is enabled via the DynamicDumpSharedSpaces or the DumpSharedSpaces flag. > 77: */ > 78: public static native boolean isDumpingEnabled(); I think it will be more consistent if we use the same pattern as `CDS::isDumpingClassList()` private static final boolean isDumpingArchive; static { isDumpingClassList = isDumpingArchive0(); } /** * Is the VM writing to a (static or dynamic) CDS archive. */ public static boolean isDumpingArchive() { return isDumpingArchive; } Then in LambdaProxyClassArchive.java, there's no need to keep a separate variable of dumpArchive. You can simply call CDS.isDumpingArchive(). The JIT compiler will automatically inline the call so it will be just as fast. LambdaProxyClassArchive::sharingEnabled should also be rewritten to use this pattern. ------------- PR: https://git.openjdk.java.net/jdk/pull/364 From kim.barrett at oracle.com Wed Oct 14 00:51:08 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 13 Oct 2020 20:51:08 -0400 Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) In-Reply-To: References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> <4aGn4WWgiS5YyPD2c6E6oqZh_QYicXwlAhVPYbHCK8s=.be75166e-2965-4655-8f85-6871959fbea8@github.com> Message-ID: <41AB9EF8-C007-448E-8C90-7B8180ED844D@oracle.com> > On Oct 13, 2020, at 9:27 AM, Jie Fu wrote: > > On Sun, 4 Oct 2020 11:57:34 GMT, Jie Fu wrote: > >>> What version of clang? >>> >>> gcc (at least recent versions) allows enum types (both scoped and unscoped) for both the __sync_xxx functions and for >>> the __atomic_xxx functions. (The documentation for both say the type can be an integral scalar or pointer type. Enums >>> are not integral types.) So this seems to be a clang incompatibility with gcc, which may be a clang bug. >>> >>> The __sync_xxx functions have been legacy since gcc4.7, having been superseded by the __atomic_xxx functions. Could >>> zero be updated here? Would that help? If clang is incompatible with gcc for the __sync_xxx functions, it might also >>> be incompatible for the __atomic_xxx functions. BTW, the memory ordering by the zero implementation of Atomic::xchg in >>> terms of __sync_lock_test_and_set looks wrong to me. I think the fence() is on the wrong side of the __sync_xxx >>> operation. >> >> The following two versions of clang can reproduce the bug. >> >> $ clang -v >> Apple clang version 11.0.0 (clang-1100.0.33.16) >> Target: x86_64-apple-darwin19.0.0 >> Thread model: posix >> >> # clang -v >> clang version 10.0.0-4ubuntu1 >> Target: x86_64-pc-linux-gnu >> Thread model: posix > > Hi @kimbarrett , > > I replace __sync_val_compare_and_swap whith __atomic_compare_exchange and it really woks. > Thanks for your help. Good news that __atomic_compare_exchange works where __sync_val_compare_and_swap doesn't. However, __ATOMIC_SEQ_CST doesn't provide the same semantics as the __sync function, nor the required semantics for HotSpot. I think something like what's in atomic_linux_aarch64.hpp is needed, i.e. T value = compare_value; FULL_MEM_BARRIER; __atomic_compare_exchange(dest, &value, &exchange_value, /*weak/false, __ATOMIC_RELAXED, __ATOMIC_RELAXED); FULL_MEM_BARRIER; return value; See the discussion related to that linux_aarch64 code here: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-November/008164.html > I also fix the following bug when building zero VM on MacOS. > -------------------------------------------------------------- > * For target hotspot_variant-zero_libjvm_objs_os_bsd_zero.o: > ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:176:21: error: no member named 'in_stack_yellow_reserved_zone' in > 'JavaThread' > if (thread->in_stack_yellow_reserved_zone(addr)) { > ~~~~~~ ^ > ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:177:19: error: no member named 'disable_stack_yellow_reserved_zone' in > 'JavaThread' > thread->disable_stack_yellow_reserved_zone(); > ~~~~~~ ^ > ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:180:26: error: no member named 'in_stack_red_zone' in 'JavaThread' > else if (thread->in_stack_red_zone(addr)) { > ~~~~~~ ^ > ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:181:19: error: no member named 'disable_stack_red_zone' in 'JavaThread' > thread->disable_stack_red_zone(); > ~~~~~~ ^ I think this should be a separate bug and PR. This seems to be a result of a recent change (JDK-8253717, pushed a little less than a week ago) not accounting for bsd_zero; the needed change seems to have only been made to linux_zero. > As for the memory ordering of the zero implementation, it might be better to file another bug to fix it. > What do you think? I?m okay with that. The linux_aarch64 implementation looks like a good model for zero. From iklam at openjdk.java.net Wed Oct 14 01:10:11 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Oct 2020 01:10:11 GMT Subject: RFR: 8254012: NMT: MetaspaceSnapshot::snapshot uses wrong enum In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 23:40:54 GMT, Yumin Qi wrote: > Please review this simple change. > Snapshot should be done first on NonClassType which will include ClassType allocation when > Metaspace::using_class_space() is false. _class_vsm (a VirtualSpaceManager) is set only for class type allocation when > using_class_space is true. The correct order is do snapshot for NonClassType first, then for ClassType if > using_class_space. Tests: mach5 tier1-4 in progress. I wonder why this bug has not been discovered until now. It seems like the old code would not work at all when compressed class space is disabled. Do we have any test cases for it? Or, is this feature actually used? ------------- PR: https://git.openjdk.java.net/jdk/pull/645 From kim.barrett at oracle.com Wed Oct 14 01:27:55 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 13 Oct 2020 21:27:55 -0400 Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) In-Reply-To: <41AB9EF8-C007-448E-8C90-7B8180ED844D@oracle.com> References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> <4aGn4WWgiS5YyPD2c6E6oqZh_QYicXwlAhVPYbHCK8s=.be75166e-2965-4655-8f85-6871959fbea8@github.com> <41AB9EF8-C007-448E-8C90-7B8180ED844D@oracle.com> Message-ID: > On Oct 13, 2020, at 8:51 PM, Kim Barrett wrote: > >> I also fix the following bug when building zero VM on MacOS. >> -------------------------------------------------------------- >> * For target hotspot_variant-zero_libjvm_objs_os_bsd_zero.o: >> ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:176:21: error: no member named 'in_stack_yellow_reserved_zone' in >> 'JavaThread' >> if (thread->in_stack_yellow_reserved_zone(addr)) { >> ~~~~~~ ^ >> ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:177:19: error: no member named 'disable_stack_yellow_reserved_zone' in >> 'JavaThread' >> thread->disable_stack_yellow_reserved_zone(); >> ~~~~~~ ^ >> ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:180:26: error: no member named 'in_stack_red_zone' in 'JavaThread' >> else if (thread->in_stack_red_zone(addr)) { >> ~~~~~~ ^ >> ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:181:19: error: no member named 'disable_stack_red_zone' in 'JavaThread' >> thread->disable_stack_red_zone(); >> ~~~~~~ ^ > > I think this should be a separate bug and PR. This seems to be a result of a recent change > (JDK-8253717, pushed a little less than a week ago) not accounting for bsd_zero; the needed > change seems to have only been made to linux_zero. https://bugs.openjdk.java.net/browse/JDK-8254722 From mchung at openjdk.java.net Wed Oct 14 01:47:10 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 14 Oct 2020 01:47:10 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v5] In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 00:40:14 GMT, Ioi Lam wrote: >> Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains ten commits: >> - fix minimal vm build issues >> - Merge branch 'master' into 8247666 >> - Merge branch 'master' into 8247666 >> - 1. Symbolic encoding of lambda proxy resolution. An example of @lambda-proxy in the classlist: >> @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambdabash ()V ()V >> 2. Removed BadCPIndex.java; added LambdaProxyClassList.java test. >> 3. Mandy's comments. >> - Merge branch 'master' into 8247666 >> - exclude archived lambda proxy classes in the classlist >> - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi >> - fix extraneous whitespace >> - 8247666 (initial commit) > > Changes requested by iklam (Reviewer). > `@lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambda$main$0 ()V ()V` Can you explain the format? ------------- PR: https://git.openjdk.java.net/jdk/pull/364 From jiefu at openjdk.java.net Wed Oct 14 02:11:19 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 14 Oct 2020 02:11:19 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) In-Reply-To: References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> <4aGn4WWgiS5YyPD2c6E6oqZh_QYicXwlAhVPYbHCK8s=.be75166e-2965-4655-8f85-6871959fbea8@github.com> Message-ID: <19fcDixjwhehaASUbt7mHAeXDhH9s1j60E4T32kkH7M=.01436eb8-61bf-412e-a9d5-7c1f05c86379@github.com> On Tue, 13 Oct 2020 13:21:31 GMT, Jie Fu wrote: >> The following two versions of clang can reproduce the bug. >> >> $ clang -v >> Apple clang version 11.0.0 (clang-1100.0.33.16) >> Target: x86_64-apple-darwin19.0.0 >> Thread model: posix >> >> # clang -v >> clang version 10.0.0-4ubuntu1 >> Target: x86_64-pc-linux-gnu >> Thread model: posix > > Hi @kimbarrett , > > I replace __sync_val_compare_and_swap whith __atomic_compare_exchange and it really woks. > Thanks for your help. > > I also fix the following bug when building zero VM on MacOS. > -------------------------------------------------------------- > * For target hotspot_variant-zero_libjvm_objs_os_bsd_zero.o: > ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:176:21: error: no member named 'in_stack_yellow_reserved_zone' in > 'JavaThread' > if (thread->in_stack_yellow_reserved_zone(addr)) { > ~~~~~~ ^ > ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:177:19: error: no member named 'disable_stack_yellow_reserved_zone' in > 'JavaThread' > thread->disable_stack_yellow_reserved_zone(); > ~~~~~~ ^ > ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:180:26: error: no member named 'in_stack_red_zone' in 'JavaThread' > else if (thread->in_stack_red_zone(addr)) { > ~~~~~~ ^ > ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:181:19: error: no member named 'disable_stack_red_zone' in 'JavaThread' > thread->disable_stack_red_zone(); > ~~~~~~ ^ > -------------------------------------------------------------- > > Testing: > - Zero VM builds on Linux/x64 with both clang and gcc > - Zero VM build on MacOS > > As for the memory ordering of the zero implementation, it might be better to file another bug to fix it. > What do you think? > > Thanks. > Best regards, > Jie Thanks @kimbarrett for your review. I will spend some time to digest your comments on the memory model semantics. ------------- PR: https://git.openjdk.java.net/jdk/pull/496 From dholmes at openjdk.java.net Wed Oct 14 02:41:12 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Oct 2020 02:41:12 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() [v3] In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 21:45:26 GMT, Patricio Chilano Mateo wrote: >> Hi all, >> >> Please review the following patch that removes the call to handle_special_runtime_exit_condition() in >> ~ThreadInVMForHandshake(). This check was added by 8223572 to prevent a JavaThread that was suspended while trying to >> process a handshake to transition back to java without noticing it was suspended. Since 8238761, a JavaThread executing >> HandshakeState::process_by_self() will never become safe. It comes from an unsafe state and remains unsafe, so it >> cannot be suspended during that time. Removing this check also removes one of the reasons >> SafepointMechanism::process_if_requested() is recursive (the other one remains SafepointSynchronize::block()). Tested >> in mach5, tiers 1-7. Thanks, Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > fix assert message Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From dholmes at openjdk.java.net Wed Oct 14 02:41:13 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Oct 2020 02:41:13 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() [v2] In-Reply-To: References: Message-ID: <-vg0aGYikEYDxiDcNjmpzuIrGiFB6dX7M6AAI5-hBgo=.4960fbd8-d6f4-403b-b9db-8160fd4f08f2@github.com> On Tue, 13 Oct 2020 20:53:54 GMT, Daniel D. Daugherty wrote: >> The same problematic execution sequence detailed in 8223572 for the external_suspend case was there for async >> exceptions too. So, while the thread was blocked in the handshake a ThreadStop() operation could have been executed. >> After returning from the handshake there was no async exception check. We probably never noticed it because the throw >> would happen anyways on some later transition back to java (vm->java or native->java). As to how was that call made >> before and what change got rid of it: this code was there before handshakes existed. ThreadStop() was implemented as a >> safepoint and we were probably relying on the special_runtime_exit_condition() check at the end of SS::block() (exactly >> like the one I'm removing from ~TIVFH and which I'll try to get rid of to eliminate recursions). > > Makes sense. Thanks! Not to belabour this but I don't understand what this sentence: // If we are at a polling page safepoint (not a poll return) is actually making a distinction between. What is a "poll return" here versus a "polling page safepoint"? ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From jiefu at openjdk.java.net Wed Oct 14 02:42:28 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 14 Oct 2020 02:42:28 GMT Subject: RFR: 8254722: bsd_zero builds broken after JDK-8253717 Message-ID: This bug was found while I'm working on JDK-8253970 [1]. JDK-8253717 updated linux_zero but forgot bsd_zero. [1] https://github.com/openjdk/jdk/pull/496#issuecomment-708088798 ------------- Commit messages: - 8254722: bsd_zero builds broken after JDK-8253717 Changes: https://git.openjdk.java.net/jdk/pull/646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=646&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254722 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/646/head:pull/646 PR: https://git.openjdk.java.net/jdk/pull/646 From dholmes at openjdk.java.net Wed Oct 14 02:54:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Oct 2020 02:54:10 GMT Subject: RFR: 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp [v2] In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 17:13:31 GMT, Harold Seigel wrote: >> Hi, >> Please review this small change to simplify exception throwing in classFileParser.cpp The change was tested with tiers >> one and two on Windows, Linux x64, and Mac OSX, and with tiers 3-5 on Linux x64. >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp Looks good - thanks for the extended cleanup. This is why we have the THROW macros to handle the return. :) ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/618 From dholmes at openjdk.java.net Wed Oct 14 03:03:13 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Oct 2020 03:03:13 GMT Subject: RFR: 8254696: safepointMechanism_aix needs adaptation for JDK-8253180 In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 14:09:33 GMT, Martin Doerr wrote: > JDK-8253180 changed SafepointMechanism::default_initialize(). SafepointMechanism::pd_initialize() in > safepointMechanism_aix.cpp needs the same changes in order to fix build and initialization. Looks to be consistent with JDK-8253180 changes. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/635 From dholmes at openjdk.java.net Wed Oct 14 03:04:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Oct 2020 03:04:10 GMT Subject: RFR: 8254722: bsd_zero builds broken after JDK-8253717 In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 02:31:00 GMT, Jie Fu wrote: > This bug was found while I'm working on JDK-8253970 [1]. > JDK-8253717 updated linux_zero but forgot bsd_zero. > > [1] https://github.com/openjdk/jdk/pull/496#issuecomment-708088798 Looks good - and trivial. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/646 From jiefu at openjdk.java.net Wed Oct 14 03:12:18 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 14 Oct 2020 03:12:18 GMT Subject: RFR: 8254722: bsd_zero builds broken after JDK-8253717 In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 03:01:15 GMT, David Holmes wrote: >> This bug was found while I'm working on JDK-8253970 [1]. >> JDK-8253717 updated linux_zero but forgot bsd_zero. >> >> [1] https://github.com/openjdk/jdk/pull/496#issuecomment-708088798 > > Looks good - and trivial. > Thanks, > David Thanks @dholmes-ora for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/646 From jiefu at openjdk.java.net Wed Oct 14 03:12:19 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 14 Oct 2020 03:12:19 GMT Subject: Integrated: 8254722: bsd_zero builds broken after JDK-8253717 In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 02:31:00 GMT, Jie Fu wrote: > This bug was found while I'm working on JDK-8253970 [1]. > JDK-8253717 updated linux_zero but forgot bsd_zero. > > [1] https://github.com/openjdk/jdk/pull/496#issuecomment-708088798 This pull request has now been integrated. Changeset: d50e0de8 Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/d50e0de8 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod 8254722: bsd_zero builds broken after JDK-8253717 Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/646 From minqi at openjdk.java.net Wed Oct 14 03:31:13 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 14 Oct 2020 03:31:13 GMT Subject: RFR: 8254012: NMT: MetaspaceSnapshot::snapshot uses wrong enum In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 01:07:30 GMT, Ioi Lam wrote: > I wonder why this bug has not been discovered until now. It seems like the old code would not work at all when > compressed class space is disabled. Do we have any test cases for it? Or, is this feature actually used? MetaspaceSnapshot predefine the _reserved_in_bytes (and other two, _commited_in_byte, _used_in_bytes) with dimension of MetadataTypeCount, the array of index ClassType is a valid slot. In this bug, if CCP is disabled, the snapshot for ClassType gets updated with zero, but non class type data is not update in snapshot. There is no output for class type data when CCP is disabled. While the original data recording is correct (at allocation) the snapshot did not get it. I will do some tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/645 From pchilanomate at openjdk.java.net Wed Oct 14 03:37:11 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 14 Oct 2020 03:37:11 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() [v2] In-Reply-To: <-vg0aGYikEYDxiDcNjmpzuIrGiFB6dX7M6AAI5-hBgo=.4960fbd8-d6f4-403b-b9db-8160fd4f08f2@github.com> References: <-vg0aGYikEYDxiDcNjmpzuIrGiFB6dX7M6AAI5-hBgo=.4960fbd8-d6f4-403b-b9db-8160fd4f08f2@github.com> Message-ID: <6DYfRkUJZhRfZVyqZy8ZLOljDwnB0qwalRuybTEsUwU=.37c6e66a-47e3-4591-a2a8-e651dd35bbb6@github.com> On Wed, 14 Oct 2020 02:37:59 GMT, David Holmes wrote: >> Makes sense. Thanks! > > Not to belabour this but I don't understand what this sentence: > > // If we are at a polling page safepoint (not a poll return) > > is actually making a distinction between. What is a "poll return" here versus a "polling page safepoint"? "poll return" would be a poll immediately before a return (also found out by reading it from the comments in ThreadSafepointState::handle_polling_page_exception()). So unless the poll in the nmethod was done right before a return, we defer the async exception. There is also a comment before the has_special_runtime_exit_condition() check on SS::block() that explains the reason: // Note: we never deliver an async exception at a polling point as the // compiler may not have an exception handler for it. The polling // code will notice the async and deoptimize and the exception will // be delivered. (Polling at a return point is ok though). Sure is // a lot of bother for a deprecated feature... ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From lmesnik at openjdk.java.net Wed Oct 14 03:38:09 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 14 Oct 2020 03:38:09 GMT Subject: RFR: JDK-8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 15:16:03 GMT, Thomas Stuefe wrote: > Hi, > > this is a very simple test fix. > > TestHeapDumpOnOutOfMemoryErrorInMetaspace tests that Metaspace OOMs result in heap dumps if VM had been started > with -XX:+HeapDumpOnOutOfMemoryError. > The test fills Metaspace up to the limit (MaxMetaspaceSize) to provoke a Metaspace OOM. It sets MaxMetaspaceSize to 64m > > 64m gives us room for about ~62000 classes with the current VM. With JEP387, this becomes more like 68000 classes. > > 6x000 classes are a lot and if test runs on a debug VM they cause long verification times from compiler dependency > checks as well as CLDG verification. Both verifications behave quadratic. On our slow ppc machines this often leads to > timeouts (test takes about 22 minutes). I lowered MaxMetaspaceSize to 16m which is fine for this test and reduces the > number of loaded classes to ~12000 classes resp 15000 with JEP387. This eases verification costs a lot. > I also switch off compiler dependency checks because a number of similar runtime tests do the same. > > I left it at that because that brings down test time on our ppc machine to ~30 seconds, which is fine. Looks good ------------- Marked as reviewed by lmesnik (Committer). PR: https://git.openjdk.java.net/jdk/pull/637 From rehn at openjdk.java.net Wed Oct 14 06:19:16 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 14 Oct 2020 06:19:16 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() [v3] In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 21:45:26 GMT, Patricio Chilano Mateo wrote: >> Hi all, >> >> Please review the following patch that removes the call to handle_special_runtime_exit_condition() in >> ~ThreadInVMForHandshake(). This check was added by 8223572 to prevent a JavaThread that was suspended while trying to >> process a handshake to transition back to java without noticing it was suspended. Since 8238761, a JavaThread executing >> HandshakeState::process_by_self() will never become safe. It comes from an unsafe state and remains unsafe, so it >> cannot be suspended during that time. Removing this check also removes one of the reasons >> SafepointMechanism::process_if_requested() is recursive (the other one remains SafepointSynchronize::block()). Tested >> in mach5, tiers 1-7. Thanks, Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > fix assert message Thanks Patricio. Good getting rid of the recursive case. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/577 From stuefe at openjdk.java.net Wed Oct 14 07:30:09 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 14 Oct 2020 07:30:09 GMT Subject: RFR: 8254012: NMT: MetaspaceSnapshot::snapshot uses wrong enum In-Reply-To: References: Message-ID: <6LK0E9lZUJfMpw0Zl7lHDSBjarajhGJmkdpc6dQ8Aug=.e6e37c02-5784-4328-b82d-650770967bd6@github.com> On Tue, 13 Oct 2020 23:40:54 GMT, Yumin Qi wrote: > Please review this simple change. > Snapshot should be done first on NonClassType which will include ClassType allocation when > Metaspace::using_class_space() is false. _class_vsm (a VirtualSpaceManager) is set only for class type allocation when > using_class_space is true. The correct order is do snapshot for NonClassType first, then for ClassType if > using_class_space. Tests: mach5 tier1-4 in progress. Looks good, thanks for fixing. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/645 From stuefe at openjdk.java.net Wed Oct 14 07:30:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 14 Oct 2020 07:30:11 GMT Subject: RFR: 8254012: NMT: MetaspaceSnapshot::snapshot uses wrong enum In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 03:27:30 GMT, Yumin Qi wrote: > > I wonder why this bug has not been discovered until now. It seems like the old code would not work at all when > > compressed class space is disabled. Do we have any test cases for it? Or, is this feature actually used? > > MetaspaceSnapshot predefine the _reserved_in_bytes (and other two, _commited_in_byte, _used_in_bytes) with dimension of > MetadataTypeCount, the array of index ClassType is a valid slot. In this bug, if CCP is disabled, the snapshot for > ClassType gets updated with zero, but non class type data is not update in snapshot. There is no output for class type > data when CCP is disabled. While the original data recording is correct (at allocation) the snapshot did not get it. I > will do some tests. This is confusing to be sure. The part that is broken by this bug is using the basline..diff functionality if compressed class space is off. All other metaspace numbers are still okay because they are printed via other code paths. Reproduction: >java -XX:-UseCompressedClassPointers -XX:NativeMemoryTracking=summary de.stuefe.repros.metaspace.JustLoadAndLoad & > jcmd JustLoadAndLoad VM.native_memory baseline 7518: Baseline succeeded > jcmd JustLoadAndLoad VM.native_memory summary.diff 7518: Native Memory Tracking: Total: reserved=5015640KB +163200KB, committed=543088KB +161924KB - Class (reserved=427146KB +161234KB, committed=425458KB +159954KB) (classes #6011 +1185) ( instance classes #5706 +1185, array classes #305) (malloc=9354KB +3538KB #41433 +14309) (mmap: reserved=417792KB +157696KB, committed=416104KB +156416KB) ( Metadata: ) << no increase shown ( reserved=0KB, committed=0KB) ( used=0KB) ( free=0KB) ( waste=0KB =-nan%) ``` And no, there are no tests for that. This is an old bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/645 From rrich at openjdk.java.net Wed Oct 14 07:49:09 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 14 Oct 2020 07:49:09 GMT Subject: RFR: 8254012: NMT: MetaspaceSnapshot::snapshot uses wrong enum In-Reply-To: References: Message-ID: <50Fn_rh3YZYdguQIjfn48V74SB6lLRj0N_24u9cksHc=.33b1b9d0-26a1-4a30-883f-341b85b40845@github.com> On Tue, 13 Oct 2020 23:40:54 GMT, Yumin Qi wrote: > Please review this simple change. > Snapshot should be done first on NonClassType which will include ClassType allocation when > Metaspace::using_class_space() is false. _class_vsm (a VirtualSpaceManager) is set only for class type allocation when > using_class_space is true. The correct order is do snapshot for NonClassType first, then for ClassType if > using_class_space. Tests: mach5 tier1-4 in progress. The change looks good // not Reviewer though. Thanks for fixing! ------------- Marked as reviewed by rrich (Committer). PR: https://git.openjdk.java.net/jdk/pull/645 From clanger at openjdk.java.net Wed Oct 14 08:16:12 2020 From: clanger at openjdk.java.net (Christoph Langer) Date: Wed, 14 Oct 2020 08:16:12 GMT Subject: RFR: 8254696: safepointMechanism_aix needs adaptation for JDK-8253180 In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 14:09:33 GMT, Martin Doerr wrote: > JDK-8253180 changed SafepointMechanism::default_initialize(). SafepointMechanism::pd_initialize() in > safepointMechanism_aix.cpp needs the same changes in order to fix build and initialization. Marked as reviewed by clanger (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/635 From mdoerr at openjdk.java.net Wed Oct 14 08:21:21 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 14 Oct 2020 08:21:21 GMT Subject: RFR: 8254696: safepointMechanism_aix needs adaptation for JDK-8253180 In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 08:13:24 GMT, Christoph Langer wrote: >> JDK-8253180 changed SafepointMechanism::default_initialize(). SafepointMechanism::pd_initialize() in >> safepointMechanism_aix.cpp needs the same changes in order to fix build and initialization. > > Marked as reviewed by clanger (Reviewer). Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/635 From mdoerr at openjdk.java.net Wed Oct 14 08:21:22 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 14 Oct 2020 08:21:22 GMT Subject: Integrated: 8254696: safepointMechanism_aix needs adaptation for JDK-8253180 In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 14:09:33 GMT, Martin Doerr wrote: > JDK-8253180 changed SafepointMechanism::default_initialize(). SafepointMechanism::pd_initialize() in > safepointMechanism_aix.cpp needs the same changes in order to fix build and initialization. This pull request has now been integrated. Changeset: 9eeeb8a2 Author: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/9eeeb8a2 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod 8254696: safepointMechanism_aix needs adaptation for JDK-8253180 Reviewed-by: dholmes, clanger ------------- PR: https://git.openjdk.java.net/jdk/pull/635 From stuefe at openjdk.java.net Wed Oct 14 09:41:23 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 14 Oct 2020 09:41:23 GMT Subject: RFR: JDK-8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out [v2] In-Reply-To: References: Message-ID: <7uvT7VUxczUWua3zfElBl-31-Q8sPmwBjCRz2zshxx8=.29c99381-46dc-4e8a-af67-a242f2293840@github.com> > Hi, > > this is a very simple test fix. > > TestHeapDumpOnOutOfMemoryErrorInMetaspace tests that Metaspace OOMs result in heap dumps if VM had been started > with -XX:+HeapDumpOnOutOfMemoryError. > The test fills Metaspace up to the limit (MaxMetaspaceSize) to provoke a Metaspace OOM. It sets MaxMetaspaceSize to 64m > > 64m gives us room for about ~62000 classes with the current VM. With JEP387, this becomes more like 68000 classes. > > 6x000 classes are a lot and if test runs on a debug VM they cause long verification times from compiler dependency > checks as well as CLDG verification. Both verifications behave quadratic. On our slow ppc machines this often leads to > timeouts (test takes about 22 minutes). I lowered MaxMetaspaceSize to 16m which is fine for this test and reduces the > number of loaded classes to ~12000 classes resp 15000 with JEP387. This eases verification costs a lot. > I also switch off compiler dependency checks because a number of similar runtime tests do the same. > > I left it at that because that brings down test time on our ppc machine to ~30 seconds, which is fine. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Remove offending copyright line ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/637/files - new: https://git.openjdk.java.net/jdk/pull/637/files/f380e698..02d094bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=637&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=637&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/637.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/637/head:pull/637 PR: https://git.openjdk.java.net/jdk/pull/637 From stuefe at openjdk.java.net Wed Oct 14 09:41:24 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 14 Oct 2020 09:41:24 GMT Subject: Integrated: JDK-8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 15:16:03 GMT, Thomas Stuefe wrote: > Hi, > > this is a very simple test fix. > > TestHeapDumpOnOutOfMemoryErrorInMetaspace tests that Metaspace OOMs result in heap dumps if VM had been started > with -XX:+HeapDumpOnOutOfMemoryError. > The test fills Metaspace up to the limit (MaxMetaspaceSize) to provoke a Metaspace OOM. It sets MaxMetaspaceSize to 64m > > 64m gives us room for about ~62000 classes with the current VM. With JEP387, this becomes more like 68000 classes. > > 6x000 classes are a lot and if test runs on a debug VM they cause long verification times from compiler dependency > checks as well as CLDG verification. Both verifications behave quadratic. On our slow ppc machines this often leads to > timeouts (test takes about 22 minutes). I lowered MaxMetaspaceSize to 16m which is fine for this test and reduces the > number of loaded classes to ~12000 classes resp 15000 with JEP387. This eases verification costs a lot. > I also switch off compiler dependency checks because a number of similar runtime tests do the same. > > I left it at that because that brings down test time on our ppc machine to ~30 seconds, which is fine. This pull request has now been integrated. Changeset: dc262dfc Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/dc262dfc Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod 8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out Reviewed-by: iklam, lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/637 From david.holmes at oracle.com Wed Oct 14 10:47:48 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Oct 2020 20:47:48 +1000 Subject: RFR: JDK-8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out [v2] In-Reply-To: <7uvT7VUxczUWua3zfElBl-31-Q8sPmwBjCRz2zshxx8=.29c99381-46dc-4e8a-af67-a242f2293840@github.com> References: <7uvT7VUxczUWua3zfElBl-31-Q8sPmwBjCRz2zshxx8=.29c99381-46dc-4e8a-af67-a242f2293840@github.com> Message-ID: Hi Thomas, Unfortunately your change breaks our validation build as this update: * Copyright (c) 2018, 2020 Oracle and/or its affiliates. All rights reserved. is missing a comma after 2020. can you file a bug anf xi please. Thanks, David On 14/10/2020 7:41 pm, Thomas Stuefe wrote: >> Hi, >> >> this is a very simple test fix. >> >> TestHeapDumpOnOutOfMemoryErrorInMetaspace tests that Metaspace OOMs result in heap dumps if VM had been started >> with -XX:+HeapDumpOnOutOfMemoryError. >> The test fills Metaspace up to the limit (MaxMetaspaceSize) to provoke a Metaspace OOM. It sets MaxMetaspaceSize to 64m >> >> 64m gives us room for about ~62000 classes with the current VM. With JEP387, this becomes more like 68000 classes. >> >> 6x000 classes are a lot and if test runs on a debug VM they cause long verification times from compiler dependency >> checks as well as CLDG verification. Both verifications behave quadratic. On our slow ppc machines this often leads to >> timeouts (test takes about 22 minutes). I lowered MaxMetaspaceSize to 16m which is fine for this test and reduces the >> number of loaded classes to ~12000 classes resp 15000 with JEP387. This eases verification costs a lot. >> I also switch off compiler dependency checks because a number of similar runtime tests do the same. >> >> I left it at that because that brings down test time on our ppc machine to ~30 seconds, which is fine. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Remove offending copyright line > > ------------- > > Changes: > - all: https://git.openjdk.java.net/jdk/pull/637/files > - new: https://git.openjdk.java.net/jdk/pull/637/files/f380e698..02d094bf > > Webrevs: > - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=637&range=01 > - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=637&range=00-01 > > Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod > Patch: https://git.openjdk.java.net/jdk/pull/637.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/637/head:pull/637 > > PR: https://git.openjdk.java.net/jdk/pull/637 > From thomas.stuefe at gmail.com Wed Oct 14 10:50:27 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 14 Oct 2020 12:50:27 +0200 Subject: RFR: JDK-8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out [v2] In-Reply-To: References: <7uvT7VUxczUWua3zfElBl-31-Q8sPmwBjCRz2zshxx8=.29c99381-46dc-4e8a-af67-a242f2293840@github.com> Message-ID: Sure! How on earth did this get integrated though? I would have hoped that these tests run beforehand :( On Wed, Oct 14, 2020 at 12:47 PM David Holmes wrote: > Hi Thomas, > > Unfortunately your change breaks our validation build as this update: > > * Copyright (c) 2018, 2020 Oracle and/or its affiliates. All rights > reserved. > > is missing a comma after 2020. can you file a bug anf xi please. > > Thanks, > David > > On 14/10/2020 7:41 pm, Thomas Stuefe wrote: > >> Hi, > >> > >> this is a very simple test fix. > >> > >> TestHeapDumpOnOutOfMemoryErrorInMetaspace tests that Metaspace OOMs > result in heap dumps if VM had been started > >> with -XX:+HeapDumpOnOutOfMemoryError. > >> The test fills Metaspace up to the limit (MaxMetaspaceSize) to provoke > a Metaspace OOM. It sets MaxMetaspaceSize to 64m > >> > >> 64m gives us room for about ~62000 classes with the current VM. With > JEP387, this becomes more like 68000 classes. > >> > >> 6x000 classes are a lot and if test runs on a debug VM they cause long > verification times from compiler dependency > >> checks as well as CLDG verification. Both verifications behave > quadratic. On our slow ppc machines this often leads to > >> timeouts (test takes about 22 minutes). I lowered MaxMetaspaceSize to > 16m which is fine for this test and reduces the > >> number of loaded classes to ~12000 classes resp 15000 with JEP387. This > eases verification costs a lot. > >> I also switch off compiler dependency checks because a number of > similar runtime tests do the same. > >> > >> I left it at that because that brings down test time on our ppc machine > to ~30 seconds, which is fine. > > > > Thomas Stuefe has updated the pull request incrementally with one > additional commit since the last revision: > > > > Remove offending copyright line > > > > ------------- > > > > Changes: > > - all: https://git.openjdk.java.net/jdk/pull/637/files > > - new: > https://git.openjdk.java.net/jdk/pull/637/files/f380e698..02d094bf > > > > Webrevs: > > - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=637&range=01 > > - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=637&range=00-01 > > > > Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod > > Patch: https://git.openjdk.java.net/jdk/pull/637.diff > > Fetch: git fetch https://git.openjdk.java.net/jdk > pull/637/head:pull/637 > > > > PR: https://git.openjdk.java.net/jdk/pull/637 > > > From david.holmes at oracle.com Wed Oct 14 10:51:48 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Oct 2020 20:51:48 +1000 Subject: RFR: JDK-8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out [v2] In-Reply-To: References: <7uvT7VUxczUWua3zfElBl-31-Q8sPmwBjCRz2zshxx8=.29c99381-46dc-4e8a-af67-a242f2293840@github.com> Message-ID: <0ebdc8c7-fbf0-5235-c762-34a42ac0f506@oracle.com> On 14/10/2020 8:50 pm, Thomas St?fe wrote: > Sure! > > How on earth did this get integrated though? I would have hoped that > these tests run beforehand :( No this isn't part of the regular testing. Thanks, David > On Wed, Oct 14, 2020 at 12:47 PM David Holmes > wrote: > > Hi Thomas, > > Unfortunately your change breaks our validation build as this update: > > * Copyright (c) 2018, 2020 Oracle and/or its affiliates. All rights > reserved. > > is missing a comma after 2020. can you file a bug anf xi please. > > Thanks, > David > > On 14/10/2020 7:41 pm, Thomas Stuefe wrote: > >> Hi, > >> > >> this is a very simple test fix. > >> > >> TestHeapDumpOnOutOfMemoryErrorInMetaspace tests that Metaspace > OOMs result in heap dumps if VM had been started > >> with -XX:+HeapDumpOnOutOfMemoryError. > >> The test fills Metaspace up to the limit (MaxMetaspaceSize) to > provoke a Metaspace OOM. It sets MaxMetaspaceSize to 64m > >> > >> 64m gives us room for about ~62000 classes with the current VM. > With JEP387, this becomes more like 68000 classes. > >> > >> 6x000 classes are a lot and if test runs on a debug VM they > cause long verification times from compiler dependency > >> checks as well as CLDG verification. Both verifications behave > quadratic. On our slow ppc machines this often leads to > >> timeouts (test takes about 22 minutes).? I lowered > MaxMetaspaceSize to 16m which is fine for this test and reduces the > >> number of loaded classes to ~12000 classes resp 15000 with > JEP387. This eases verification costs a lot. > >> I also switch off compiler dependency checks because a number of > similar runtime tests do the same. > >> > >> I left it at that because that brings down test time on our ppc > machine to ~30 seconds, which is fine. > > > > Thomas Stuefe has updated the pull request incrementally with one > additional commit since the last revision: > > > >? ? Remove offending copyright line > > > > ------------- > > > > Changes: > >? ? - all: https://git.openjdk.java.net/jdk/pull/637/files > >? ? - new: > https://git.openjdk.java.net/jdk/pull/637/files/f380e698..02d094bf > > > > Webrevs: > >? ?- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=637&range=01 > >? ?- incr: > https://webrevs.openjdk.java.net/?repo=jdk&pr=637&range=00-01 > > > >? ? Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod > >? ? Patch: https://git.openjdk.java.net/jdk/pull/637.diff > >? ? Fetch: git fetch https://git.openjdk.java.net/jdk > pull/637/head:pull/637 > > > > PR: https://git.openjdk.java.net/jdk/pull/637 > > > From stuefe at openjdk.java.net Wed Oct 14 10:52:17 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 14 Oct 2020 10:52:17 GMT Subject: RFR: 8254012: NMT: MetaspaceSnapshot::snapshot uses wrong enum In-Reply-To: <50Fn_rh3YZYdguQIjfn48V74SB6lLRj0N_24u9cksHc=.33b1b9d0-26a1-4a30-883f-341b85b40845@github.com> References: <50Fn_rh3YZYdguQIjfn48V74SB6lLRj0N_24u9cksHc=.33b1b9d0-26a1-4a30-883f-341b85b40845@github.com> Message-ID: On Wed, 14 Oct 2020 07:46:26 GMT, Richard Reingruber wrote: >> Please review this simple change. >> Snapshot should be done first on NonClassType which will include ClassType allocation when >> Metaspace::using_class_space() is false. _class_vsm (a VirtualSpaceManager) is set only for class type allocation when >> using_class_space is true. The correct order is do snapshot for NonClassType first, then for ClassType if >> using_class_space. Tests: mach5 tier1-4 in progress. > > The change looks good // not Reviewer though. > Thanks for fixing! > > > I wonder why this bug has not been discovered until now. It seems like the old code would not work at all when > > > compressed class space is disabled. Do we have any test cases for it? Or, is this feature actually used? > > > > > > MetaspaceSnapshot predefine the _reserved_in_bytes (and other two, _commited_in_byte, _used_in_bytes) with dimension of > > MetadataTypeCount, the array of index ClassType is a valid slot. In this bug, if CCP is disabled, the snapshot for > > ClassType gets updated with zero, but non class type data is not update in snapshot. There is no output for class type > > data when CCP is disabled. While the original data recording is correct (at allocation) the snapshot did not get it. I > > will do some tests. > > This is confusing to be sure. The part that is broken by this bug is using the basline..diff functionality if > compressed class space is off. All other metaspace numbers are still okay because they are printed via other code > paths. Reproduction: > > ``` > >java -XX:-UseCompressedClassPointers -XX:NativeMemoryTracking=summary de.stuefe.repros.metaspace.JustLoadAndLoad & > > jcmd JustLoadAndLoad VM.native_memory baseline > 7518: > Baseline succeeded > > jcmd JustLoadAndLoad VM.native_memory summary.diff > 7518: > > Native Memory Tracking: > > Total: reserved=5015640KB +163200KB, committed=543088KB +161924KB > > - Class (reserved=427146KB +161234KB, committed=425458KB +159954KB) > (classes #6011 +1185) > ( instance classes #5706 +1185, array classes #305) > (malloc=9354KB +3538KB #41433 +14309) > (mmap: reserved=417792KB +157696KB, committed=416104KB +156416KB) > ( Metadata: ) << no increase shown > ( reserved=0KB, committed=0KB) > ( used=0KB) > ( free=0KB) > ( waste=0KB =-nan%) > ``` > > And no, there are no tests for that. This is an old bug. Not sure how Oracle handles this usually, but maybe it makes sense to reformulate the JBS issue and describe above effect? Or, alternatively, open a new one as a duplicate to this bug? When people look into the JBS for this specific NMT bug they may not notice the harmless test error. ------------- PR: https://git.openjdk.java.net/jdk/pull/645 From stuefe at openjdk.java.net Wed Oct 14 11:04:18 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 14 Oct 2020 11:04:18 GMT Subject: RFR: JDK-8254748: Bad Copyright header format after JDK-8212218 Message-ID: Please review this trivial copyright header fix. Thank you. ------------- Commit messages: - JDK-8254748 Changes: https://git.openjdk.java.net/jdk/pull/652/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=652&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254748 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/652/head:pull/652 PR: https://git.openjdk.java.net/jdk/pull/652 From shade at openjdk.java.net Wed Oct 14 11:11:18 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 14 Oct 2020 11:11:18 GMT Subject: RFR: JDK-8254748: Bad Copyright header format after JDK-8212218 In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 10:57:34 GMT, Thomas Stuefe wrote: > Please review this trivial copyright header fix. Thank you. Looks good and trivial. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/652 From dholmes at openjdk.java.net Wed Oct 14 11:11:20 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Oct 2020 11:11:20 GMT Subject: RFR: JDK-8254748: Bad Copyright header format after JDK-8212218 In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 10:57:34 GMT, Thomas Stuefe wrote: > Please review this trivial copyright header fix. Thank you. Looks good and of course trivial. Thanks for taking care of this promptly. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/652 From stuefe at openjdk.java.net Wed Oct 14 11:24:15 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 14 Oct 2020 11:24:15 GMT Subject: Integrated: JDK-8254748: Bad Copyright header format after JDK-8212218 In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 10:57:34 GMT, Thomas Stuefe wrote: > Please review this trivial copyright header fix. Thank you. This pull request has now been integrated. Changeset: ba140b0f Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/ba140b0f Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8254748: Bad Copyright header format after JDK-8212218 Reviewed-by: shade, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/652 From hseigel at openjdk.java.net Wed Oct 14 12:26:14 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 14 Oct 2020 12:26:14 GMT Subject: Integrated: 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp In-Reply-To: References: Message-ID: <4LQ5VmEH_lQfiPK4HesGdCcrnTVbJdyF2ZLxMNRcIH8=.ed1029a7-0b59-41ac-8489-1eec0e903749@github.com> On Mon, 12 Oct 2020 20:34:25 GMT, Harold Seigel wrote: > Hi, > Please review this small change to simplify exception throwing in classFileParser.cpp The change was tested with tiers > one and two on Windows, Linux x64, and Mac OSX, and with tiers 3-5 on Linux x64. > Thanks, Harold This pull request has now been integrated. Changeset: 95e68c63 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/95e68c63 Stats: 236 lines in 3 files changed: 109 ins; 26 del; 101 mod 8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp Reviewed-by: lfoltan, dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/618 From jiefu at openjdk.java.net Wed Oct 14 12:52:35 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 14 Oct 2020 12:52:35 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) [v3] In-Reply-To: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> Message-ID: > __sync_val_compare_and_swap shouldn't call with narrowOop* for clang after JDK-8247912. > Before passing type T to __sync_val_compare_and_swap, the fix converts T to uint32_t* if sizeof(T) == 4. > > Testing: > - Zero VM build on Linux and MacOS with clang > - Zero VM build on Linux with gcc Jie Fu 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-8253970 - Add FULL_MEM_BARRIER - Merge branch 'master' into JDK-8253970 - Revert changes - Replace __sync_val_compare_and_swap whith __atomic_compare_exchange - Merge branch 'master' into JDK-8253970 - Revert changes - 8253970 Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/496/files - new: https://git.openjdk.java.net/jdk/pull/496/files/420ead76..9f0e1293 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=496&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=496&range=01-02 Stats: 3878 lines in 87 files changed: 1268 ins; 1971 del; 639 mod Patch: https://git.openjdk.java.net/jdk/pull/496.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/496/head:pull/496 PR: https://git.openjdk.java.net/jdk/pull/496 From jiefu at openjdk.java.net Wed Oct 14 12:57:11 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 14 Oct 2020 12:57:11 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) In-Reply-To: <19fcDixjwhehaASUbt7mHAeXDhH9s1j60E4T32kkH7M=.01436eb8-61bf-412e-a9d5-7c1f05c86379@github.com> References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> <4aGn4WWgiS5YyPD2c6E6oqZh_QYicXwlAhVPYbHCK8s=.be75166e-2965-4655-8f85-6871959fbea8@github.com> <19fcDixjwhehaASUbt7mHAeXDhH9s1j60E4T32kkH7M=.01436eb8-61bf-412e-a9d5-7c1f05c86379@github.com> Message-ID: On Wed, 14 Oct 2020 02:07:56 GMT, Jie Fu wrote: >> Hi @kimbarrett , >> >> I replace __sync_val_compare_and_swap whith __atomic_compare_exchange and it really woks. >> Thanks for your help. >> >> I also fix the following bug when building zero VM on MacOS. >> -------------------------------------------------------------- >> * For target hotspot_variant-zero_libjvm_objs_os_bsd_zero.o: >> ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:176:21: error: no member named 'in_stack_yellow_reserved_zone' in >> 'JavaThread' >> if (thread->in_stack_yellow_reserved_zone(addr)) { >> ~~~~~~ ^ >> ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:177:19: error: no member named 'disable_stack_yellow_reserved_zone' in >> 'JavaThread' >> thread->disable_stack_yellow_reserved_zone(); >> ~~~~~~ ^ >> ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:180:26: error: no member named 'in_stack_red_zone' in 'JavaThread' >> else if (thread->in_stack_red_zone(addr)) { >> ~~~~~~ ^ >> ./src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp:181:19: error: no member named 'disable_stack_red_zone' in 'JavaThread' >> thread->disable_stack_red_zone(); >> ~~~~~~ ^ >> -------------------------------------------------------------- >> >> Testing: >> - Zero VM builds on Linux/x64 with both clang and gcc >> - Zero VM build on MacOS >> >> As for the memory ordering of the zero implementation, it might be better to file another bug to fix it. >> What do you think? >> >> Thanks. >> Best regards, >> Jie > > Thanks @kimbarrett for your review. > I will spend some time to digest your comments on the memory model semantics. Hi @kimbarrett , I agree with you. All of the atomic operations that imply a read-modify-write action guarantee a two-way memory barrier across that operation. So FULL_MEM_BARRIERs (before and after the atomic operation) should be added. The patch has been updated. Please review it. Thanks. Best regards, Jie ------------- PR: https://git.openjdk.java.net/jdk/pull/496 From shade at openjdk.java.net Wed Oct 14 15:04:19 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 14 Oct 2020 15:04:19 GMT Subject: RFR: 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage Message-ID: `LowMemoryDetector::check_memory_usage` seems declared but not implemented. Current history does not show any definitions since the initial load. Can be removed. Testing: - [x] Linux x86_64 build - [x] Test search for `check_memory_usage` in `src/hotspot` ------------- Commit messages: - 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage Changes: https://git.openjdk.java.net/jdk/pull/659/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=659&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254776 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/659.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/659/head:pull/659 PR: https://git.openjdk.java.net/jdk/pull/659 From shade at openjdk.java.net Wed Oct 14 15:10:23 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 14 Oct 2020 15:10:23 GMT Subject: RFR: 8254777: Remove unimplemented Management::get_loaded_classes Message-ID: There seems to be no definition of `Management::get_loaded_classes` anywhere in current tip or history prior the initial load. Can be removed. Testing: - [x] Linux x86_64 build - [x] Text search for `get_loaded_classes` in `src/hotspot` ------------- Commit messages: - 8254777: Remove unimplemented Management::get_loaded_classes Changes: https://git.openjdk.java.net/jdk/pull/660/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=660&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254777 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/660.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/660/head:pull/660 PR: https://git.openjdk.java.net/jdk/pull/660 From pchilanomate at openjdk.java.net Wed Oct 14 15:20:17 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 14 Oct 2020 15:20:17 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() Message-ID: Hi all, Please review the following patch that removes some uneeded uses of cross_modify_fence() in common code, in particular from ~ThreadBlockInVM(), ~ThreadBlockInVMWithDeadlockCheck() and java_suspend_self_with_safepoint_check(). These fences were added before each JavaThread had to disarm itself (8230594). After a safepoint/handshake each JavaThread will always call SafepointMechanism::process_if_requested_slow() when transitioning out of the safe state and will execute a cross_modify_fence(). Tested with mach5 tiers1-7. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.java.net/jdk/pull/655/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=655&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254264 Stats: 5 lines in 2 files changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/655.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/655/head:pull/655 PR: https://git.openjdk.java.net/jdk/pull/655 From stuefe at openjdk.java.net Wed Oct 14 16:05:19 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 14 Oct 2020 16:05:19 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v15] In-Reply-To: <4X4ZaiVSAkI3PZYBChk4HTo6X41UOIlidC5dClesGtE=.06d3a0f5-9067-4fac-8dac-251105eb477f@github.com> References: <4X4ZaiVSAkI3PZYBChk4HTo6X41UOIlidC5dClesGtE=.06d3a0f5-9067-4fac-8dac-251105eb477f@github.com> Message-ID: On Tue, 13 Oct 2020 15:56:57 GMT, Richard Reingruber wrote: > Hi Thomas, > this is a major enhancement and it looks good to me. Congratulations! :) > Cheers, Richard. Thanks a lot Richard! ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From pchilanomate at openjdk.java.net Wed Oct 14 16:13:18 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 14 Oct 2020 16:13:18 GMT Subject: RFR: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() [v3] In-Reply-To: References: Message-ID: <6ebqgw0DZGoC0fHWviC91_rWw9q8Im74dUAMizMDUCM=.d4497142-635f-486e-9a50-c1812000645c@github.com> On Wed, 14 Oct 2020 06:16:34 GMT, Robbin Ehn wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> fix assert message > > Thanks Patricio. Good getting rid of the recursive case. Thanks @reinrich, @dholmes-ora, @dcubed-ojdk and @robehn for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From ccheung at openjdk.java.net Wed Oct 14 16:27:25 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 14 Oct 2020 16:27:25 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v5] In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 01:44:05 GMT, Mandy Chung wrote: >> Changes requested by iklam (Reviewer). > >> `@lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambda$main$0 ()V ()V` > > Can you explain the format? `@lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V REF_invokeStatic LambHello lambda$main$0 ()V ()V` means `@lambda-proxy ? ? ` It is a symbolic representation of a invoke dynamic constant pool entry. public class LambHello { public static void main(String[] args) { doit(() -> { System.out.println("Hello from Lambda"); }); } static void doit(Runnable t) { t.run(); } } An invoke dynamic constant pool of the above program is: ` - 7 : InvokeDynamic : bootstrap_method_index=43 name_and_type_index=8 arguments={50, 51, 50}` Other constant pool entries related to the above are: - 8 : NameAndType : name_index=9 signature_index=10 - 9 : Utf8 : 'run' - 10 : Utf8 : '()Ljava/lang/Runnable;' - 50 : MethodType : signature_index=6 - 51 : MethodHandle : ref_kind=6 ref_index=52 - 52 : Method : klass_index=12 name_and_type_index=53 - 53 : NameAndType : name_index=39 signature_index=6 - 6 : Utf8 : '()V' - 12 : Class : 'LambHello' {0x0000000800c10040} - 39 : Utf8 : 'lambda$main$0' The info included in the class list are: = LambHello = run = ()Ljava/lang/Runnable; = ()V = REF_invokeStatic = LambHello = lambda$main$0 = ()V = ()V ------------- PR: https://git.openjdk.java.net/jdk/pull/364 From minqi at openjdk.java.net Wed Oct 14 16:31:12 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 14 Oct 2020 16:31:12 GMT Subject: RFR: 8254012: NMT: MetaspaceSnapshot::snapshot uses wrong enum In-Reply-To: References: <50Fn_rh3YZYdguQIjfn48V74SB6lLRj0N_24u9cksHc=.33b1b9d0-26a1-4a30-883f-341b85b40845@github.com> Message-ID: On Wed, 14 Oct 2020 10:49:10 GMT, Thomas Stuefe wrote: >> The change looks good // not Reviewer though. >> Thanks for fixing! > >> > > I wonder why this bug has not been discovered until now. It seems like the old code would not work at all when >> > > compressed class space is disabled. Do we have any test cases for it? Or, is this feature actually used? >> > >> > >> > MetaspaceSnapshot predefine the _reserved_in_bytes (and other two, _commited_in_byte, _used_in_bytes) with dimension of >> > MetadataTypeCount, the array of index ClassType is a valid slot. In this bug, if CCP is disabled, the snapshot for >> > ClassType gets updated with zero, but non class type data is not update in snapshot. There is no output for class type >> > data when CCP is disabled. While the original data recording is correct (at allocation) the snapshot did not get it. I >> > will do some tests. >> >> This is confusing to be sure. The part that is broken by this bug is using the basline..diff functionality if >> compressed class space is off. All other metaspace numbers are still okay because they are printed via other code >> paths. Reproduction: >> >> ``` >> >java -XX:-UseCompressedClassPointers -XX:NativeMemoryTracking=summary de.stuefe.repros.metaspace.JustLoadAndLoad & >> > jcmd JustLoadAndLoad VM.native_memory baseline >> 7518: >> Baseline succeeded >> > jcmd JustLoadAndLoad VM.native_memory summary.diff >> 7518: >> >> Native Memory Tracking: >> >> Total: reserved=5015640KB +163200KB, committed=543088KB +161924KB >> >> - Class (reserved=427146KB +161234KB, committed=425458KB +159954KB) >> (classes #6011 +1185) >> ( instance classes #5706 +1185, array classes #305) >> (malloc=9354KB +3538KB #41433 +14309) >> (mmap: reserved=417792KB +157696KB, committed=416104KB +156416KB) >> ( Metadata: ) << no increase shown >> ( reserved=0KB, committed=0KB) >> ( used=0KB) >> ( free=0KB) >> ( waste=0KB =-nan%) >> ``` >> >> And no, there are no tests for that. This is an old bug. > > Not sure how Oracle handles this usually, but maybe it makes sense to reformulate the JBS issue and describe above > effect? Or, alternatively, open a new one as a duplicate to this bug? > When people look into the JBS for this specific NMT bug they may not notice the harmless test error. @tstuefe @reinrich Thanks for review! I am not sure if JBS issue changed what the PR will react --- Skara requests exact match for the issue. File a new bug with correct description as a dup of this one is OK I think. ------------- PR: https://git.openjdk.java.net/jdk/pull/645 From minqi at openjdk.java.net Wed Oct 14 17:16:12 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 14 Oct 2020 17:16:12 GMT Subject: Integrated: 8254012: NMT: MetaspaceSnapshot::snapshot uses wrong enum In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 23:40:54 GMT, Yumin Qi wrote: > Please review this simple change. > Snapshot should be done first on NonClassType which will include ClassType allocation when > Metaspace::using_class_space() is false. _class_vsm (a VirtualSpaceManager) is set only for class type allocation when > using_class_space is true. The correct order is do snapshot for NonClassType first, then for ClassType if > using_class_space. Tests: mach5 tier1-4 in progress. This pull request has now been integrated. Changeset: fde02e23 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/fde02e23 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8254012: NMT: MetaspaceSnapshot::snapshot uses wrong enum Reviewed-by: stuefe, rrich ------------- PR: https://git.openjdk.java.net/jdk/pull/645 From sspitsyn at openjdk.java.net Wed Oct 14 17:18:16 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 14 Oct 2020 17:18:16 GMT Subject: RFR: 8254777: Remove unimplemented Management::get_loaded_classes In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 15:04:32 GMT, Aleksey Shipilev wrote: > There seems to be no definition of `Management::get_loaded_classes` anywhere in current tip or history prior the > initial load. Can be removed. > Testing: > - [x] Linux x86_64 build > - [x] Text search for `get_loaded_classes` in `src/hotspot` Hi Aleksey, This is good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/660 From dcubed at openjdk.java.net Wed Oct 14 18:49:20 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Oct 2020 18:49:20 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java Message-ID: This is a trivial change to ProblemList compiler/graalunit/HotspotTest.java. ------------- Commit messages: - 8254789: ProblemList compiler/graalunit/HotspotTest.java Changes: https://git.openjdk.java.net/jdk/pull/666/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=666&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254789 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/666.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/666/head:pull/666 PR: https://git.openjdk.java.net/jdk/pull/666 From rriggs at openjdk.java.net Wed Oct 14 18:49:20 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 14 Oct 2020 18:49:20 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java In-Reply-To: References: Message-ID: <2atPIagsa8VCzmwgTjvYylCsDdhWOIAdoNAgel1aXZ4=.bab148e5-4d98-4b76-96fe-05c3d4023999@github.com> On Wed, 14 Oct 2020 18:41:10 GMT, Daniel D. Daugherty wrote: > This is a trivial change to ProblemList compiler/graalunit/HotspotTest.java. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/666 From dcubed at openjdk.java.net Wed Oct 14 18:49:20 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Oct 2020 18:49:20 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java In-Reply-To: References: <2atPIagsa8VCzmwgTjvYylCsDdhWOIAdoNAgel1aXZ4=.bab148e5-4d98-4b76-96fe-05c3d4023999@github.com> Message-ID: <4bqa4Y8QHwDUJ1TBe2P-uzTeA1M6Be7_bI_ZvmGR9Co=.3b99e49d-ca16-4514-a5db-782cfb1c478f@github.com> On Wed, 14 Oct 2020 18:43:44 GMT, Igor Ignatyev wrote: >> Marked as reviewed by rriggs (Reviewer). > > @dcubed-ojdk > graal unit tests can be excluded individually by adding entries to `ProblemList-graal.txt` : > diff --git a/test/hotspot/jtreg/ProblemList-graal.txt b/test/hotspot/jtreg/ProblemList-graal.txt > index f73a4883f42..634f2bc12f6 100644 > --- a/test/hotspot/jtreg/ProblemList-graal.txt > +++ b/test/hotspot/jtreg/ProblemList-graal.txt > @@ -239,3 +239,5 @@ org.graalvm.compiler.replacements.test.classfile.ClassfileBytecodeProviderTest > org.graalvm.compiler.core.test.deopt.CompiledMethodTest 8202955 > > org.graalvm.compiler.hotspot.test.ReservedStackAccessTest 8213567 windows-all > + > +org.graalvm.compiler.hotspot.test.CheckGraalIntrinsics 8254785 @iignatev - I forgot about that file! ------------- PR: https://git.openjdk.java.net/jdk/pull/666 From iignatyev at openjdk.java.net Wed Oct 14 18:49:20 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 14 Oct 2020 18:49:20 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java In-Reply-To: <2atPIagsa8VCzmwgTjvYylCsDdhWOIAdoNAgel1aXZ4=.bab148e5-4d98-4b76-96fe-05c3d4023999@github.com> References: <2atPIagsa8VCzmwgTjvYylCsDdhWOIAdoNAgel1aXZ4=.bab148e5-4d98-4b76-96fe-05c3d4023999@github.com> Message-ID: On Wed, 14 Oct 2020 18:43:19 GMT, Roger Riggs wrote: >> This is a trivial change to ProblemList compiler/graalunit/HotspotTest.java. > > Marked as reviewed by rriggs (Reviewer). @dcubed-ojdk graal unit tests can be excluded individually by adding entries to `ProblemList-graal.txt` : diff --git a/test/hotspot/jtreg/ProblemList-graal.txt b/test/hotspot/jtreg/ProblemList-graal.txt index f73a4883f42..634f2bc12f6 100644 --- a/test/hotspot/jtreg/ProblemList-graal.txt +++ b/test/hotspot/jtreg/ProblemList-graal.txt @@ -239,3 +239,5 @@ org.graalvm.compiler.replacements.test.classfile.ClassfileBytecodeProviderTest org.graalvm.compiler.core.test.deopt.CompiledMethodTest 8202955 org.graalvm.compiler.hotspot.test.ReservedStackAccessTest 8213567 windows-all + +org.graalvm.compiler.hotspot.test.CheckGraalIntrinsics 8254785 ------------- PR: https://git.openjdk.java.net/jdk/pull/666 From dcubed at openjdk.java.net Wed Oct 14 18:54:21 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Oct 2020 18:54:21 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java [v2] In-Reply-To: References: Message-ID: > This is a trivial change to ProblemList compiler/graalunit/HotspotTest.java. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Move ProblemListing of compiler/graalunit/HotspotTest.java from test/hotspot/jtreg/ProblemList.txt to the specific subtest in test/hotspot/jtreg/ProblemList-graal.txt. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/666/files - new: https://git.openjdk.java.net/jdk/pull/666/files/8b01c7c2..4cafa5b7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=666&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=666&range=00-01 Stats: 5 lines in 2 files changed: 2 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/666.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/666/head:pull/666 PR: https://git.openjdk.java.net/jdk/pull/666 From dcubed at openjdk.java.net Wed Oct 14 19:11:25 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Oct 2020 19:11:25 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java [v3] In-Reply-To: References: Message-ID: > This is a trivial change to ProblemList compiler/graalunit/HotspotTest.java. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Add missing platform specification. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/666/files - new: https://git.openjdk.java.net/jdk/pull/666/files/4cafa5b7..869576d2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=666&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=666&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/666.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/666/head:pull/666 PR: https://git.openjdk.java.net/jdk/pull/666 From iignatyev at openjdk.java.net Wed Oct 14 19:11:25 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 14 Oct 2020 19:11:25 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java [v2] In-Reply-To: References: Message-ID: <-Hw9lUUB12UzjLI1ZosOdqpexCJpI-KQBVG2tHS_eOM=.88e8433d-bf47-43fc-a3f3-68bf8466e8c5@github.com> On Wed, 14 Oct 2020 18:54:21 GMT, Daniel D. Daugherty wrote: >> This is a trivial change to ProblemList compiler/graalunit/HotspotTest.java. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Move ProblemListing of compiler/graalunit/HotspotTest.java from test/hotspot/jtreg/ProblemList.txt to the specific > subtest in test/hotspot/jtreg/ProblemList-graal.txt. LGTM. but, in JBS, @vnkozlov said that it's easy to fix the test, and he is working on the fix, so depending on the timing we might want to skip this one. ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/666 From kvn at openjdk.java.net Wed Oct 14 19:11:26 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 14 Oct 2020 19:11:26 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java [v3] In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 19:08:18 GMT, Daniel D. Daugherty wrote: >> This is a trivial change to ProblemList compiler/graalunit/HotspotTest.java. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Add missing platform specification. Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/666 From dcubed at openjdk.java.net Wed Oct 14 19:11:26 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Oct 2020 19:11:26 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java [v3] In-Reply-To: <4bqa4Y8QHwDUJ1TBe2P-uzTeA1M6Be7_bI_ZvmGR9Co=.3b99e49d-ca16-4514-a5db-782cfb1c478f@github.com> References: <2atPIagsa8VCzmwgTjvYylCsDdhWOIAdoNAgel1aXZ4=.bab148e5-4d98-4b76-96fe-05c3d4023999@github.com> <4bqa4Y8QHwDUJ1TBe2P-uzTeA1M6Be7_bI_ZvmGR9Co=.3b99e49d-ca16-4514-a5db-782cfb1c478f@github.com> Message-ID: <65VId5w16rWeIAhkQlO1s6FZK8Qzqqb-1_hizOrCfqU=.95f2e016-32ee-45a4-a836-348069e609a7@github.com> On Wed, 14 Oct 2020 18:44:51 GMT, Daniel D. Daugherty wrote: >> @dcubed-ojdk >> graal unit tests can be excluded individually by adding entries to `ProblemList-graal.txt` : >> diff --git a/test/hotspot/jtreg/ProblemList-graal.txt b/test/hotspot/jtreg/ProblemList-graal.txt >> index f73a4883f42..634f2bc12f6 100644 >> --- a/test/hotspot/jtreg/ProblemList-graal.txt >> +++ b/test/hotspot/jtreg/ProblemList-graal.txt >> @@ -239,3 +239,5 @@ org.graalvm.compiler.replacements.test.classfile.ClassfileBytecodeProviderTest >> org.graalvm.compiler.core.test.deopt.CompiledMethodTest 8202955 >> >> org.graalvm.compiler.hotspot.test.ReservedStackAccessTest 8213567 windows-all >> + >> +org.graalvm.compiler.hotspot.test.CheckGraalIntrinsics 8254785 > > @iignatev - I forgot about that file! @iignatev - should be fixed now. @RogerRiggs - can you also re-review? ------------- PR: https://git.openjdk.java.net/jdk/pull/666 From iignatyev at openjdk.java.net Wed Oct 14 19:11:27 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 14 Oct 2020 19:11:27 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java [v2] In-Reply-To: References: <-Hw9lUUB12UzjLI1ZosOdqpexCJpI-KQBVG2tHS_eOM=.88e8433d-bf47-43fc-a3f3-68bf8466e8c5@github.com> Message-ID: On Wed, 14 Oct 2020 18:58:46 GMT, Daniel D. Daugherty wrote: > Hold on. I somehow lost the platform part of the entry. you don't need it, and IIRC, it's not actually read by `compiler.graalunit.common.GraalUnitTestLauncher` ------------- PR: https://git.openjdk.java.net/jdk/pull/666 From dcubed at openjdk.java.net Wed Oct 14 19:11:27 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Oct 2020 19:11:27 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java [v2] In-Reply-To: <-Hw9lUUB12UzjLI1ZosOdqpexCJpI-KQBVG2tHS_eOM=.88e8433d-bf47-43fc-a3f3-68bf8466e8c5@github.com> References: <-Hw9lUUB12UzjLI1ZosOdqpexCJpI-KQBVG2tHS_eOM=.88e8433d-bf47-43fc-a3f3-68bf8466e8c5@github.com> Message-ID: On Wed, 14 Oct 2020 18:58:42 GMT, Igor Ignatyev wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Move ProblemListing of compiler/graalunit/HotspotTest.java from test/hotspot/jtreg/ProblemList.txt to the specific >> subtest in test/hotspot/jtreg/ProblemList-graal.txt. > > LGTM. but, in JBS, @vnkozlov said that it's easy to fix the test, and he is working on the fix, so depending on the > timing we might want to skip this one. Hold on. I somehow lost the platform part of the entry. ------------- PR: https://git.openjdk.java.net/jdk/pull/666 From dcubed at openjdk.java.net Wed Oct 14 19:11:27 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Oct 2020 19:11:27 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java [v2] In-Reply-To: References: <-Hw9lUUB12UzjLI1ZosOdqpexCJpI-KQBVG2tHS_eOM=.88e8433d-bf47-43fc-a3f3-68bf8466e8c5@github.com> Message-ID: On Wed, 14 Oct 2020 19:00:49 GMT, Daniel D. Daugherty wrote: >>> Hold on. I somehow lost the platform part of the entry. >> >> you don't need it, and IIRC, it's not actually read by `compiler.graalunit.common.GraalUnitTestLauncher` > > Okay. I added it anyway since the previous entry had it... I want to integrate this ProblemListing to get the noise down. ------------- PR: https://git.openjdk.java.net/jdk/pull/666 From dcubed at openjdk.java.net Wed Oct 14 19:11:27 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Oct 2020 19:11:27 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java [v2] In-Reply-To: References: <-Hw9lUUB12UzjLI1ZosOdqpexCJpI-KQBVG2tHS_eOM=.88e8433d-bf47-43fc-a3f3-68bf8466e8c5@github.com> Message-ID: On Wed, 14 Oct 2020 18:59:51 GMT, Igor Ignatyev wrote: >> Hold on. I somehow lost the platform part of the entry. > >> Hold on. I somehow lost the platform part of the entry. > > you don't need it, and IIRC, it's not actually read by `compiler.graalunit.common.GraalUnitTestLauncher` Okay. I added it anyway since the previous entry had it... ------------- PR: https://git.openjdk.java.net/jdk/pull/666 From kvn at openjdk.java.net Wed Oct 14 19:11:28 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 14 Oct 2020 19:11:28 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java [v2] In-Reply-To: <-Hw9lUUB12UzjLI1ZosOdqpexCJpI-KQBVG2tHS_eOM=.88e8433d-bf47-43fc-a3f3-68bf8466e8c5@github.com> References: <-Hw9lUUB12UzjLI1ZosOdqpexCJpI-KQBVG2tHS_eOM=.88e8433d-bf47-43fc-a3f3-68bf8466e8c5@github.com> Message-ID: <2EmgCT55Xu8GSspN2sI9Lwcw7toAjgWrAn2uqKV7DFQ=.57a13fa1-8ad4-4409-bd8b-b9854e6bef9e@github.com> On Wed, 14 Oct 2020 18:58:42 GMT, Igor Ignatyev wrote: > LGTM. but, in JBS, @vnkozlov said that it's easy to fix the test, and he is working on the fix, so depending on the > timing we might want to skip this one. I am fine with problem list the test first. Especially if you can list only CheckGraalIntrinsics. I am also inclining to do it permanently for time in JDK. I am tired to fix it each time people push new intrinsic. It gives us (JPG) nothing. ------------- PR: https://git.openjdk.java.net/jdk/pull/666 From dcubed at openjdk.java.net Wed Oct 14 19:11:28 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Oct 2020 19:11:28 GMT Subject: RFR: 8254789: ProblemList compiler/graalunit/HotspotTest.java [v3] In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 19:03:33 GMT, Vladimir Kozlov wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing platform specification. > > Marked as reviewed by kvn (Reviewer). @RogerRiggs, @iignatev and @vnkozlov - Thanks for the fast reviews and the help with getting this right. ------------- PR: https://git.openjdk.java.net/jdk/pull/666 From dcubed at openjdk.java.net Wed Oct 14 19:11:29 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Oct 2020 19:11:29 GMT Subject: Integrated: 8254789: ProblemList compiler/graalunit/HotspotTest.java In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 18:41:10 GMT, Daniel D. Daugherty wrote: > This is a trivial change to ProblemList compiler/graalunit/HotspotTest.java. This pull request has now been integrated. Changeset: 386e7e8b Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/386e7e8b Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8254789: ProblemList compiler/graalunit/HotspotTest.java Reviewed-by: rriggs, iignatyev, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/666 From ccheung at openjdk.java.net Wed Oct 14 20:45:17 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 14 Oct 2020 20:45:17 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v3] In-Reply-To: References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: On Tue, 13 Oct 2020 06:46:27 GMT, Ioi Lam wrote: >> **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in >> memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each >> of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert >> to fail. >> >> **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to >> access each individual cloned vtable. >> >> **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just >> do the bare minimum to fix the bug, it will be pretty hard to review. >> >> I would suggest that the reviewers look at just the new version of the code and see if it's working as described >> (instead of looking at the diff to understand what the bug was and how it has been fixed). >> This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. >> I plan to change that into templates in a future RFE. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes > the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last > revision: > - Merge branch 'master' of https://github.com/openjdk/jdk into 8254125-cppvtables-assert-on-win32 > - Fixed more cases with align_up(xxx, SharedSpaceObjectAlignment) > - Merge branch 'master' into 8254125-cppvtables-assert-on-win32 > - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/591 From shade at openjdk.java.net Wed Oct 14 21:02:10 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 14 Oct 2020 21:02:10 GMT Subject: Integrated: 8254777: Remove unimplemented Management::get_loaded_classes In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 15:04:32 GMT, Aleksey Shipilev wrote: > There seems to be no definition of `Management::get_loaded_classes` anywhere in current tip or history prior the > initial load. Can be removed. > Testing: > - [x] Linux x86_64 build > - [x] Text search for `get_loaded_classes` in `src/hotspot` This pull request has now been integrated. Changeset: 03fa733e Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/03fa733e Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8254777: Remove unimplemented Management::get_loaded_classes Reviewed-by: sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/660 From iklam at openjdk.java.net Wed Oct 14 21:03:19 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Oct 2020 21:03:19 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v3] In-Reply-To: References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: <9Fbnbx_4a92wcpClyKUiFIUON2Za2LzA4WFbRfKQOuI=.764816a4-0c9f-4168-9b46-f7f4f810eddc@github.com> On Wed, 14 Oct 2020 20:42:44 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes >> the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last >> revision: >> - Merge branch 'master' of https://github.com/openjdk/jdk into 8254125-cppvtables-assert-on-win32 >> - Fixed more cases with align_up(xxx, SharedSpaceObjectAlignment) >> - Merge branch 'master' into 8254125-cppvtables-assert-on-win32 >> - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows > > Marked as reviewed by ccheung (Reviewer). > In the function `ArchiveBuilder::gather_klass_and_symbol(MetaspaceClosure::Ref* ref, bool read_only)` > Instead of `BytesPerWord`, is `BytesPerInt` more appropriate since the `ref->size()` returns an int? Hi Calvin, thanks for the review. For the line `int bytes = ref->size() * BytesPerWord;`, `ref->size()` has the same API as all the `size()` methods of the `MetaspaceObj` classes. I.e., "the number of words needed to hold this object". That's why we need to multiple by `BytesPerWord` to calculate the number of bytes needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/591 From dcubed at openjdk.java.net Wed Oct 14 22:04:19 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Oct 2020 22:04:19 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 21:25:13 GMT, Daniel D. Daugherty wrote: >> 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 > > This sub-task is tracking ObjectMonitor cleanup/minor bug-fix changes > extracted from Erik's and Dan's work on JDK-8253064. This extraction > is done to ease the code review for the JDK-8253064 changes. > > My personal fork includes the commit for: > JDK-8254335: logging/logStream.hpp includes memory/resourceArea.hpp but d? > because the project is currently based on jdk-16+19 and I pushed that commit for jdk-16+20. > Please ignore that commit when reviewing this fix. The changes covered by this bug are: - Redo the "final" ObjectMonitor audit and print stats so that we no longer race between the ServiceThread and a thread generating ObjectMonitors until the end of time. The final audit is now done by the VMThread in the very late stages of VM exit (after other threads have blocked). Because we have two distinict VM exit code paths, we call the final audit hook from both paths. The race was introduced by the following: JDK-8246476 remove AsyncDeflateIdleMonitors option and the safepoint based deflation mechanism - Do some renaming that should have been done by JDK-8246476. - Delete the SharedGlobals::stw_cycle that should have been deleted by JDK-8246476. - Do more "self" cleanup and use of as_Java_thread(). ------------- PR: https://git.openjdk.java.net/jdk/pull/641 From dcubed at openjdk.java.net Wed Oct 14 22:04:20 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Oct 2020 22:04:20 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 21:25:34 GMT, Daniel D. Daugherty wrote: >> This sub-task is tracking ObjectMonitor cleanup/minor bug-fix changes >> extracted from Erik's and Dan's work on JDK-8253064. This extraction >> is done to ease the code review for the JDK-8253064 changes. >> >> My personal fork includes the commit for: >> JDK-8254335: logging/logStream.hpp includes memory/resourceArea.hpp but d? >> because the project is currently based on jdk-16+19 and I pushed that commit for jdk-16+20. >> Please ignore that commit when reviewing this fix. > > The changes covered by this bug are: > > - Redo the "final" ObjectMonitor audit and print stats so that we no longer > race between the ServiceThread and a thread generating ObjectMonitors > until the end of time. The final audit is now done by the VMThread in the > very late stages of VM exit (after other threads have blocked). Because > we have two distinict VM exit code paths, we call the final audit hook > from both paths. > > The race was introduced by the following: > > JDK-8246476 remove AsyncDeflateIdleMonitors option and the safepoint based deflation mechanism > > - Do some renaming that should have been done by JDK-8246476. > > - Delete the SharedGlobals::stw_cycle that should have been deleted > by JDK-8246476. > > - Do more "self" cleanup and use of as_Java_thread(). Mach5 Tier[1-3],4,5,6,7 testing looks good; there are four test failures associated with unrelated, known bugs; there are four other test failures on a machine with bad hardware so those are invalid. Update: Tier8 testing is still in process, but so far the results look good. ------------- PR: https://git.openjdk.java.net/jdk/pull/641 From dcubed at openjdk.java.net Wed Oct 14 22:04:19 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Oct 2020 22:04:19 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 Message-ID: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 ------------- Commit messages: - 8253064.v00.part0 - 8254335: logging/logStream.hpp includes memory/resourceArea.hpp but doesn't need it Changes: https://git.openjdk.java.net/jdk/pull/641/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=641&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254029 Stats: 178 lines in 19 files changed: 58 ins; 38 del; 82 mod Patch: https://git.openjdk.java.net/jdk/pull/641.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/641/head:pull/641 PR: https://git.openjdk.java.net/jdk/pull/641 From dcubed at openjdk.java.net Wed Oct 14 22:04:19 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 14 Oct 2020 22:04:19 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 20:31:16 GMT, Daniel D. Daugherty wrote: > 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 This sub-task is tracking ObjectMonitor cleanup/minor bug-fix changes extracted from Erik's and Dan's work on JDK-8253064. This extraction is done to ease the code review for the JDK-8253064 changes. My personal fork includes the commit for: JDK-8254335: logging/logStream.hpp includes memory/resourceArea.hpp but d? because the project is currently based on jdk-16+19 and I pushed that commit for jdk-16+20. Please ignore that commit when reviewing this fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/641 From minqi at openjdk.java.net Wed Oct 14 22:18:17 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 14 Oct 2020 22:18:17 GMT Subject: RFR: 8254192: ExtraSharedClassListFile contains extra white space at end of line Message-ID: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com> Hi, Please review the simple change. The removing of white spaces from end of line in ClassListParser should be moved to before we add lambda-form-invoker line to array. After made such arrangement, changed CDS.java for trimming line code. Tests: local test on runtime/cds/appcds. Mach5 tier1,4 is in progress. Thanks ------------- Commit messages: - 8254192: ExtraSharedClassListFile contains extra white space at end of line Changes: https://git.openjdk.java.net/jdk/pull/669/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=669&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254192 Stats: 57 lines in 2 files changed: 26 ins; 25 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/669.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/669/head:pull/669 PR: https://git.openjdk.java.net/jdk/pull/669 From pchilanomate at openjdk.java.net Wed Oct 14 22:20:11 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 14 Oct 2020 22:20:11 GMT Subject: Integrated: 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() In-Reply-To: References: Message-ID: On Fri, 9 Oct 2020 14:10:16 GMT, Patricio Chilano Mateo wrote: > Hi all, > > Please review the following patch that removes the call to handle_special_runtime_exit_condition() in > ~ThreadInVMForHandshake(). This check was added by 8223572 to prevent a JavaThread that was suspended while trying to > process a handshake to transition back to java without noticing it was suspended. Since 8238761, a JavaThread executing > HandshakeState::process_by_self() will never become safe. It comes from an unsafe state and remains unsafe, so it > cannot be suspended during that time. Removing this check also removes one of the reasons > SafepointMechanism::process_if_requested() is recursive (the other one remains SafepointSynchronize::block()). Tested > in mach5, tiers 1-7. Thanks, Patricio This pull request has now been integrated. Changeset: 55d760d4 Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/55d760d4 Stats: 43 lines in 4 files changed: 8 ins; 20 del; 15 mod 8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake() Reviewed-by: rrich, dholmes, dcubed, rehn ------------- PR: https://git.openjdk.java.net/jdk/pull/577 From jiefu at openjdk.java.net Wed Oct 14 23:52:17 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 14 Oct 2020 23:52:17 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs Message-ID: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is develop and is available only in debug version of VM. -XX:+IgnoreUnrecognizedVMOptions is added to fix it. ------------- Commit messages: - 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs Changes: https://git.openjdk.java.net/jdk/pull/673/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=673&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254799 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/673.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/673/head:pull/673 PR: https://git.openjdk.java.net/jdk/pull/673 From minqi at openjdk.java.net Thu Oct 15 00:16:11 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 15 Oct 2020 00:16:11 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: On Wed, 14 Oct 2020 23:45:52 GMT, Jie Fu wrote: > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is > develop and is available only in debug version of VM. > -XX:+IgnoreUnrecognizedVMOptions is added to fix it. For test using debug version, please use "@requires vm.debug" in test. ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From dholmes at openjdk.java.net Thu Oct 15 00:19:12 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Oct 2020 00:19:12 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: On Wed, 14 Oct 2020 23:45:52 GMT, Jie Fu wrote: > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is > develop and is available only in debug version of VM. > -XX:+IgnoreUnrecognizedVMOptions is added to fix it. Looks good and trivial. Thanks for fixing. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/673 From david.holmes at oracle.com Thu Oct 15 00:21:43 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Oct 2020 10:21:43 +1000 Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: <5435d301-9c14-c7b8-d7d5-c5ca14f05d34@oracle.com> Hi Yumin, On 15/10/2020 10:16 am, Yumin Qi wrote: > On Wed, 14 Oct 2020 23:45:52 GMT, Jie Fu wrote: > >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is >> develop and is available only in debug version of VM. >> -XX:+IgnoreUnrecognizedVMOptions is added to fix it. > > For test using debug version, please use "@requires vm.debug" in test. I disagree with that approach. The test is run for any release and this is exec'ing the JVM directly so not controlled by an @test directive directly. You would have to have two versions of the Java code to run on release or debug VMs. What Jie has done seems the best solution to me - a logical equivalent of DEBUG_ONLY(-XX:-VerifyDependencies) Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/673 > From minqi at openjdk.java.net Thu Oct 15 00:36:13 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 15 Oct 2020 00:36:13 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: On Thu, 15 Oct 2020 00:16:38 GMT, David Holmes wrote: >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is >> develop and is available only in debug version of VM. >> -XX:+IgnoreUnrecognizedVMOptions is added to fix it. > > Looks good and trivial. > Thanks for fixing. > > 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):_ > Hi Yumin, > > On 15/10/2020 10:16 am, Yumin Qi wrote: > > > On Wed, 14 Oct 2020 23:45:52 GMT, Jie Fu wrote: > > > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and > > > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is > > > develop and is available only in debug version of VM. > > > -XX:+IgnoreUnrecognizedVMOptions is added to fix it. > > > > > > For test using debug version, please use "@requires vm.debug" in test. > > I disagree with that approach. The test is run for any release and this > is exec'ing the JVM directly so not controlled by an @test directive > directly. You would have to have two versions of the Java code to run on > release or debug VMs. > > What Jie has done seems the best solution to me - a logical equivalent of > > DEBUG_ONLY(-XX:-VerifyDependencies) > > Cheers, > David The original fix has problem, don't know how it went through test! Disabling this flag is to reduce run time in debug. I am OK with the workaround though it looks strange. ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From dholmes at openjdk.java.net Thu Oct 15 00:46:15 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Oct 2020 00:46:15 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 20:31:16 GMT, Daniel D. Daugherty wrote: > 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 Hi Dan, Overall this looks good to me. A few minor comments/queries below. Thanks, David src/hotspot/share/runtime/vmOperations.cpp line 458: > 456: // The ObjectMonitor subsystem uses perf counters so do this before > 457: // we call exit_globals() so we don't run afoul of perfMemory_exit(). > 458: ObjectSynchronizer::do_final_audit_and_print_stats(); Given this used to be done in the prolog, is there anything above this line that might interfere with it somehow? Or more simply put, why not do this first so that it is as close as possible to where it used to be? src/hotspot/share/runtime/synchronizer.cpp line 2949: > 2947: assert(Thread::current()->is_VM_thread(), "sanity check"); > 2948: > 2949: if (is_final_audit()) { // Only do the audit once. It seems impossible that you could ever call this twice. A simple file static flag for a debug build would be simpler if you just wanted to assert that. src/hotspot/share/runtime/vmThread.cpp line 194: > 192: // we signal that the VM thread is gone. We don't want to run afoul > 193: // of perfMemory_exit() in exit_globals(). > 194: ObjectSynchronizer::do_final_audit_and_print_stats(); Again I wonder why this was moved so far from the original call to deflate? It makes sense to do the final deflation once the final safepoint has been reached, but should we do it first once the safepoint has been reached? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/641 From dcubed at openjdk.java.net Thu Oct 15 00:48:15 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 15 Oct 2020 00:48:15 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: On Wed, 14 Oct 2020 23:45:52 GMT, Jie Fu wrote: > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is > develop and is available only in debug version of VM. > -XX:+IgnoreUnrecognizedVMOptions is added to fix it. Changes requested by dcubed (Reviewer). test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 82: > 80: "-XX:MaxMetaspaceSize=16m", > 81: "-XX:+IgnoreUnrecognizedVMOptions", > 82: "-XX:-VerifyDependencies", Instead of adding "-XX:+IgnoreUnrecognizedVMOptions", you can check the JDK type like this: String jdkType = System.getProperty("jdk.debug", "release"); boolean addNonReleaseOptions = false; if (!jdkType.equals("release")) { addNonReleaseOptions = true; } and then only include the "-XX:-VerifyDependencies" option when `addNonReleaseOptions` is true... I'm not sure how to do optional parameters with ProcessTools.createJavaProcessBuilder(). ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From minqi at openjdk.java.net Thu Oct 15 00:48:15 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 15 Oct 2020 00:48:15 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: On Thu, 15 Oct 2020 00:33:27 GMT, Yumin Qi wrote: >> Looks good and trivial. >> Thanks for fixing. >> >> 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):_ >> Hi Yumin, >> >> On 15/10/2020 10:16 am, Yumin Qi wrote: >> >> > On Wed, 14 Oct 2020 23:45:52 GMT, Jie Fu wrote: >> > > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and >> > > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is >> > > develop and is available only in debug version of VM. >> > > -XX:+IgnoreUnrecognizedVMOptions is added to fix it. >> > >> > >> > For test using debug version, please use "@requires vm.debug" in test. >> >> I disagree with that approach. The test is run for any release and this >> is exec'ing the JVM directly so not controlled by an @test directive >> directly. You would have to have two versions of the Java code to run on >> release or debug VMs. >> >> What Jie has done seems the best solution to me - a logical equivalent of >> >> DEBUG_ONLY(-XX:-VerifyDependencies) >> >> Cheers, >> David > > The original fix has problem, don't know how it went through test! Disabling this flag is to reduce run time in debug. > I am OK with the workaround though it looks strange. > > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on > > [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_ Hi Yumin, > > On 15/10/2020 10:16 am, Yumin Qi wrote: > > > On Wed, 14 Oct 2020 23:45:52 GMT, Jie Fu wrote: > > > > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and > > > > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is > > > > develop and is available only in debug version of VM. > > > > -XX:+IgnoreUnrecognizedVMOptions is added to fix it. > > > > > > > > > For test using debug version, please use "@requires vm.debug" in test. > > > > > > I disagree with that approach. The test is run for any release and this > > is exec'ing the JVM directly so not controlled by an @test directive > > directly. You would have to have two versions of the Java code to run on > > release or debug VMs. > > What Jie has done seems the best solution to me - a logical equivalent of > > DEBUG_ONLY(-XX:-VerifyDependencies) > > Cheers, > > David > > The original fix has problem, don't know how it went through test! Disabling this flag is to reduce run time in debug. > I am OK with the workaround though it looks strange. Maybe use Platform.isDebugBuild()? Anyway up to Jie's choice. ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From dcubed at openjdk.java.net Thu Oct 15 00:51:11 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 15 Oct 2020 00:51:11 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: On Thu, 15 Oct 2020 00:41:33 GMT, Daniel D. Daugherty wrote: >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is >> develop and is available only in debug version of VM. >> -XX:+IgnoreUnrecognizedVMOptions is added to fix it. > > test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 82: > >> 80: "-XX:MaxMetaspaceSize=16m", >> 81: "-XX:+IgnoreUnrecognizedVMOptions", >> 82: "-XX:-VerifyDependencies", > > Instead of adding "-XX:+IgnoreUnrecognizedVMOptions", you can > check the JDK type like this: > > String jdkType = System.getProperty("jdk.debug", "release"); > boolean addNonReleaseOptions = false; > if (!jdkType.equals("release")) { > addNonReleaseOptions = true; > } > > and then only include the "-XX:-VerifyDependencies" option > when `addNonReleaseOptions` is true... I'm not sure how to > do optional parameters with ProcessTools.createJavaProcessBuilder(). I didn't know about `Platform.isDebugBuild()`... ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From david.holmes at oracle.com Thu Oct 15 00:59:11 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Oct 2020 10:59:11 +1000 Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: On 15/10/2020 10:48 am, Daniel D.Daugherty wrote: > On Wed, 14 Oct 2020 23:45:52 GMT, Jie Fu wrote: > >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is >> develop and is available only in debug version of VM. >> -XX:+IgnoreUnrecognizedVMOptions is added to fix it. > > Changes requested by dcubed (Reviewer). > > test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 82: > >> 80: "-XX:MaxMetaspaceSize=16m", >> 81: "-XX:+IgnoreUnrecognizedVMOptions", >> 82: "-XX:-VerifyDependencies", > > Instead of adding "-XX:+IgnoreUnrecognizedVMOptions", you can > check the JDK type like this: > > String jdkType = System.getProperty("jdk.debug", "release"); > boolean addNonReleaseOptions = false; > if (!jdkType.equals("release")) { > addNonReleaseOptions = true; > } > > and then only include the "-XX:-VerifyDependencies" option > when `addNonReleaseOptions` is true... I'm not sure how to > do optional parameters with ProcessTools.createJavaProcessBuilder(). I think this is a trivial issue being over engineered. :) We run many tests with -XX:+IgnoreUnrecognizedVMOptions at the jtreg level or the @run level, and this is no different. Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/673 > From daniel.daugherty at oracle.com Thu Oct 15 01:01:13 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 14 Oct 2020 21:01:13 -0400 Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: <061b3859-0187-0669-82f7-5968e321d4dd@oracle.com> On 10/14/20 8:59 PM, David Holmes wrote: > On 15/10/2020 10:48 am, Daniel D.Daugherty wrote: >> On Wed, 14 Oct 2020 23:45:52 GMT, Jie Fu wrote: >> >>> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and >>> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java >>> fail with release VMs due to VerifyDependencies is >>> develop and is available only in debug version of VM. >>> -XX:+IgnoreUnrecognizedVMOptions is added to fix it. >> >> Changes requested by dcubed (Reviewer). >> >> test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java >> line 82: >> >>> 80: "-XX:MaxMetaspaceSize=16m", >>> 81:???????????????? "-XX:+IgnoreUnrecognizedVMOptions", >>> 82:???????????????? "-XX:-VerifyDependencies", >> >> Instead of adding "-XX:+IgnoreUnrecognizedVMOptions", you can >> check the JDK type like this: >> >> String jdkType = System.getProperty("jdk.debug", "release"); >> boolean addNonReleaseOptions = false; >> if (!jdkType.equals("release")) { >> ???? addNonReleaseOptions = true; >> } >> >> and then only include the "-XX:-VerifyDependencies" option >> when `addNonReleaseOptions` is true... I'm not sure how to >> do optional parameters with ProcessTools.createJavaProcessBuilder(). > > I think this is a trivial issue being over engineered. :) We run many > tests with -XX:+IgnoreUnrecognizedVMOptions at the jtreg level or the > @run level, and this is no different. My understanding is that we are trying to stop using -XX:+IgnoreUnrecognizedVMOptions because it has unexpected side effects. Dan > > Cheers, > David > ----- > >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/673 >> From minqi at openjdk.java.net Thu Oct 15 01:04:25 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 15 Oct 2020 01:04:25 GMT Subject: RFR: 8254192: ExtraSharedClassListFile contains extra white space at end of line [v2] In-Reply-To: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com> References: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com> Message-ID: > Hi, Please review the simple change. > > The removing of white spaces from end of line in ClassListParser should be moved to before we add lambda-form-invoker > line to array. After made such arrangement, changed CDS.java for trimming line code. > > Tests: local test on runtime/cds/appcds. Mach5 tier1,4 is in progress. > > Thanks Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fix comment adding \f for Replace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/669/files - new: https://git.openjdk.java.net/jdk/pull/669/files/2086b3d8..f2984a4b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=669&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=669&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/669.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/669/head:pull/669 PR: https://git.openjdk.java.net/jdk/pull/669 From iklam at openjdk.java.net Thu Oct 15 01:09:12 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 15 Oct 2020 01:09:12 GMT Subject: RFR: 8254192: ExtraSharedClassListFile contains extra white space at end of line [v2] In-Reply-To: References: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com> Message-ID: On Thu, 15 Oct 2020 01:04:25 GMT, Yumin Qi wrote: >> Hi, Please review the simple change. >> >> The removing of white spaces from end of line in ClassListParser should be moved to before we add lambda-form-invoker >> line to array. After made such arrangement, changed CDS.java for trimming line code. >> >> Tests: local test on runtime/cds/appcds. Mach5 tier1,4 is in progress. >> >> Thanks > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment adding \f for Replace Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/669 From david.holmes at oracle.com Thu Oct 15 01:15:35 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Oct 2020 11:15:35 +1000 Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: <061b3859-0187-0669-82f7-5968e321d4dd@oracle.com> References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> <061b3859-0187-0669-82f7-5968e321d4dd@oracle.com> Message-ID: <1c62be52-36a1-a918-b27a-052cb660c9f9@oracle.com> On 15/10/2020 11:01 am, Daniel D. Daugherty wrote: > On 10/14/20 8:59 PM, David Holmes wrote: >> On 15/10/2020 10:48 am, Daniel D.Daugherty wrote: >>> On Wed, 14 Oct 2020 23:45:52 GMT, Jie Fu wrote: >>> >>>> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and >>>> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java >>>> fail with release VMs due to VerifyDependencies is >>>> develop and is available only in debug version of VM. >>>> -XX:+IgnoreUnrecognizedVMOptions is added to fix it. >>> >>> Changes requested by dcubed (Reviewer). >>> >>> test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java >>> line 82: >>> >>>> 80: "-XX:MaxMetaspaceSize=16m", >>>> 81:???????????????? "-XX:+IgnoreUnrecognizedVMOptions", >>>> 82:???????????????? "-XX:-VerifyDependencies", >>> >>> Instead of adding "-XX:+IgnoreUnrecognizedVMOptions", you can >>> check the JDK type like this: >>> >>> String jdkType = System.getProperty("jdk.debug", "release"); >>> boolean addNonReleaseOptions = false; >>> if (!jdkType.equals("release")) { >>> ???? addNonReleaseOptions = true; >>> } >>> >>> and then only include the "-XX:-VerifyDependencies" option >>> when `addNonReleaseOptions` is true... I'm not sure how to >>> do optional parameters with ProcessTools.createJavaProcessBuilder(). >> >> I think this is a trivial issue being over engineered. :) We run many >> tests with -XX:+IgnoreUnrecognizedVMOptions at the jtreg level or the >> @run level, and this is no different. > > > My understanding is that we are trying to stop using > -XX:+IgnoreUnrecognizedVMOptions because it has unexpected > side effects. I don't recall that. But in this case it is not an issue at all. We are using ProcessTools.createJavaProcessBuilder to pass the specific set of flags listed in the test itself. There are no incoming flags from jtreg etc, so nothing that can be affected. Further, even if using createTestJVM, the explicit flags are placed last on the command-line so still cannot interfere with anything coming in from jtreg. I suppose a trivial change for Jie would be: - "-XX:-VerifyDependencies", + Platform.isDebugBuild() ? "-XX:-VerifyDependencies" : "", Cheers, David > Dan > > >> >> Cheers, >> David >> ----- >> >>> ------------- >>> >>> PR: https://git.openjdk.java.net/jdk/pull/673 >>> > From jiefu at openjdk.java.net Thu Oct 15 01:27:10 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 15 Oct 2020 01:27:10 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: On Thu, 15 Oct 2020 00:45:57 GMT, Daniel D. Daugherty wrote: >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is >> develop and is available only in debug version of VM. >> -XX:+IgnoreUnrecognizedVMOptions is added to fix it. > > Changes requested by dcubed (Reviewer). I like @dholmes-ora 's solution and will update the PR soon. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From jiefu at openjdk.java.net Thu Oct 15 02:06:13 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 15 Oct 2020 02:06:13 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: <6IJTuysWGfnDpnHjLNoRY_1LI_2f_83GJQfjZAAEzDU=.6de76fa5-270b-464e-bdcb-9be2fe6f12d0@github.com> On Thu, 15 Oct 2020 01:24:21 GMT, Jie Fu wrote: >> Changes requested by dcubed (Reviewer). > > I like @dholmes-ora 's solution and will update the PR soon. > Thanks. Unfortunately, the following fix doesn't work. Platform.isDebugBuild() ? "-XX:-VerifyDependencies" : "", It seems that ProcessTools.createJavaProcessBuilder doesn't allow empty string as an arg. Would you mind something like: Platform.isDebugBuild() ? "-XX:-VerifyDependencies" : "-XX:MaxMetaspaceSize=16m", If you don't like it, I still prefer -XX:+IgnoreUnrecognizedVMOptions. I've grepped under jdk/test finding that there are about 700+ tests using -XX:+IgnoreUnrecognizedVMOptions. I didn't get the point why -XX:+IgnoreUnrecognizedVMOptions should be avoided for this case. ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From david.holmes at oracle.com Thu Oct 15 02:33:02 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Oct 2020 12:33:02 +1000 Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: <6IJTuysWGfnDpnHjLNoRY_1LI_2f_83GJQfjZAAEzDU=.6de76fa5-270b-464e-bdcb-9be2fe6f12d0@github.com> References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> <6IJTuysWGfnDpnHjLNoRY_1LI_2f_83GJQfjZAAEzDU=.6de76fa5-270b-464e-bdcb-9be2fe6f12d0@github.com> Message-ID: <4f8590bb-691b-8798-aaf4-539f7a2e1257@oracle.com> On 15/10/2020 12:06 pm, Jie Fu wrote: > On Thu, 15 Oct 2020 01:24:21 GMT, Jie Fu wrote: > >>> Changes requested by dcubed (Reviewer). >> >> I like @dholmes-ora 's solution and will update the PR soon. >> Thanks. > > Unfortunately, the following fix doesn't work. > Platform.isDebugBuild() ? "-XX:-VerifyDependencies" : "", > It seems that ProcessTools.createJavaProcessBuilder doesn't allow empty string as an arg. Well that is annoying - not quite sure how that arises but anyway ... > Would you mind something like: > Platform.isDebugBuild() ? "-XX:-VerifyDependencies" : "-XX:MaxMetaspaceSize=16m", Just use "-Dx" as the dummy argument. Thanks, David > If you don't like it, I still prefer -XX:+IgnoreUnrecognizedVMOptions. > I've grepped under jdk/test finding that there are about 700+ tests using -XX:+IgnoreUnrecognizedVMOptions. > I didn't get the point why -XX:+IgnoreUnrecognizedVMOptions should be avoided for this case. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/673 > From minqi at openjdk.java.net Thu Oct 15 02:56:14 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 15 Oct 2020 02:56:14 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: <6IJTuysWGfnDpnHjLNoRY_1LI_2f_83GJQfjZAAEzDU=.6de76fa5-270b-464e-bdcb-9be2fe6f12d0@github.com> References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> <6IJTuysWGfnDpnHjLNoRY_1LI_2f_83GJQfjZAAEzDU=.6de76fa5-270b-464e-bdcb-9be2fe6f12d0@github.com> Message-ID: On Thu, 15 Oct 2020 02:03:19 GMT, Jie Fu wrote: >> I like @dholmes-ora 's solution and will update the PR soon. >> Thanks. > > Unfortunately, the following fix doesn't work. > Platform.isDebugBuild() ? "-XX:-VerifyDependencies" : "", > It seems that ProcessTools.createJavaProcessBuilder doesn't allow empty string as an arg. > > Would you mind something like: > Platform.isDebugBuild() ? "-XX:-VerifyDependencies" : "-XX:MaxMetaspaceSize=16m", > If you don't like it, I still prefer -XX:+IgnoreUnrecognizedVMOptions. > I've grepped under jdk/test finding that there are about 700+ tests using -XX:+IgnoreUnrecognizedVMOptions. > I didn't get the point why -XX:+IgnoreUnrecognizedVMOptions should be avoided for this case. Hi, Jie, David and Dan, I would like to reorg the code a little bit: `index a889ae11ed1..596ca348c30 100644 --- a/test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java +++ b/test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java @@ -31,10 +31,12 @@ import jdk.test.lib.Asserts; import jdk.test.lib.classloader.GeneratingClassLoader; import jdk.test.lib.hprof.HprofParser; +import jdk.test.lib.Platform; import jdk.test.lib.process.ProcessTools; import jdk.test.lib.process.OutputAnalyzer; import java.io.File; +import java.util.ArrayList; public class TestHeapDumpOnOutOfMemoryError { @@ -64,22 +66,29 @@ public class TestHeapDumpOnOutOfMemoryError { } static void test(String type) throws Exception { + ArrayList args = new ArrayList(); + String heapdumpFilename = type + ".hprof"; - ProcessBuilder pb = ProcessTools.createJavaProcessBuilder("-XX:+HeapDumpOnOutOfMemoryError", - "-XX:HeapDumpPath=" + heapdumpFilename, - // Note: When trying to provoke a metaspace OOM we may generate a lot of classes. In debug VMs this - // can cause considerable wait times since: - // - Compiler Dependencies verification iterates the class tree - // - Before exit, the CLDG is checked. - // Both verifications show quadratic time or worse wrt to number of loaded classes. Therefore it - // makes sense to switch one or both off and limit the metaspace size to something sensible. - // Example numbers on a slow ppc64 machine: - // MaxMetaspaceSize=64M - ~60-70K classes - ~20min runtime with all verifications - // MaxMetaspaceSize=16M - ~12-15K classes - ~12sec runtime with all verifications - // MaxMetaspaceSize=16M - ~12-15K classes - VerifyDependencies off - ~3seconds on ppc - "-XX:MaxMetaspaceSize=16m", - "-XX:-VerifyDependencies", - TestHeapDumpOnOutOfMemoryError.class.getName(), type); + // Note: When trying to provoke a metaspace OOM we may generate a lot of classes. In debug VMs this + // can cause considerable wait times since: + // - Compiler Dependencies verification iterates the class tree + // - Before exit, the CLDG is checked. + // Both verifications show quadratic time or worse wrt to number of loaded classes. Therefore it + // makes sense to switch one or both off and limit the metaspace size to something sensible. + // Example numbers on a slow ppc64 machine: + // MaxMetaspaceSize=64M - ~60-70K classes - ~20min runtime with all verifications + // MaxMetaspaceSize=16M - ~12-15K classes - ~12sec runtime with all verifications + // MaxMetaspaceSize=16M - ~12-15K classes - VerifyDependencies off - ~3seconds on ppc + args.add("-XX:+HeapDumpOnOutOfMemoryError"); + args.add("-XX:HeapDumpPath=" + heapdumpFilename); + args.add("-XX:MaxMetaspaceSize=16m"); + if (Platform.isDebugBuild()) { + args.add("-XX:-VerifyDependencies"); + } + args.add(TestHeapDumpOnOutOfMemoryError.class.getName()); + args.add(type); + + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(args); OutputAnalyzer output = new OutputAnalyzer(pb.start()); output.stdoutShouldNotBeEmpty();` What do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From minqi at openjdk.java.net Thu Oct 15 03:01:09 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 15 Oct 2020 03:01:09 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> <6IJTuysWGfnDpnHjLNoRY_1LI_2f_83GJQfjZAAEzDU=.6de76fa5-270b-464e-bdcb-9be2fe6f12d0@github.com> Message-ID: On Thu, 15 Oct 2020 02:52:18 GMT, Yumin Qi wrote: >> Unfortunately, the following fix doesn't work. >> Platform.isDebugBuild() ? "-XX:-VerifyDependencies" : "", >> It seems that ProcessTools.createJavaProcessBuilder doesn't allow empty string as an arg. >> >> Would you mind something like: >> Platform.isDebugBuild() ? "-XX:-VerifyDependencies" : "-XX:MaxMetaspaceSize=16m", >> If you don't like it, I still prefer -XX:+IgnoreUnrecognizedVMOptions. >> I've grepped under jdk/test finding that there are about 700+ tests using -XX:+IgnoreUnrecognizedVMOptions. >> I didn't get the point why -XX:+IgnoreUnrecognizedVMOptions should be avoided for this case. > > Hi, Jie, David and Dan, I would like to reorg the code a little bit: > > `index a889ae11ed1..596ca348c30 100644 > --- a/test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java > +++ b/test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java > @@ -31,10 +31,12 @@ > import jdk.test.lib.Asserts; > import jdk.test.lib.classloader.GeneratingClassLoader; > import jdk.test.lib.hprof.HprofParser; > +import jdk.test.lib.Platform; > import jdk.test.lib.process.ProcessTools; > import jdk.test.lib.process.OutputAnalyzer; > > import java.io.File; > +import java.util.ArrayList; > > public class TestHeapDumpOnOutOfMemoryError { > > @@ -64,22 +66,29 @@ public class TestHeapDumpOnOutOfMemoryError { > } > > static void test(String type) throws Exception { > + ArrayList args = new ArrayList(); > + > String heapdumpFilename = type + ".hprof"; > - ProcessBuilder pb = ProcessTools.createJavaProcessBuilder("-XX:+HeapDumpOnOutOfMemoryError", > - "-XX:HeapDumpPath=" + heapdumpFilename, > - // Note: When trying to provoke a metaspace OOM we may generate a lot of classes. In debug VMs this > - // can cause considerable wait times since: > - // - Compiler Dependencies verification iterates the class tree > - // - Before exit, the CLDG is checked. > - // Both verifications show quadratic time or worse wrt to number of loaded classes. Therefore it > - // makes sense to switch one or both off and limit the metaspace size to something sensible. > - // Example numbers on a slow ppc64 machine: > - // MaxMetaspaceSize=64M - ~60-70K classes - ~20min runtime with all verifications > - // MaxMetaspaceSize=16M - ~12-15K classes - ~12sec runtime with all verifications > - // MaxMetaspaceSize=16M - ~12-15K classes - VerifyDependencies off - ~3seconds on ppc > - "-XX:MaxMetaspaceSize=16m", > - "-XX:-VerifyDependencies", > - TestHeapDumpOnOutOfMemoryError.class.getName(), type); > + // Note: When trying to provoke a metaspace OOM we may generate a lot of classes. In debug VMs this > + // can cause considerable wait times since: > + // - Compiler Dependencies verification iterates the class tree > + // - Before exit, the CLDG is checked. > + // Both verifications show quadratic time or worse wrt to number of loaded classes. Therefore it > + // makes sense to switch one or both off and limit the metaspace size to something sensible. > + // Example numbers on a slow ppc64 machine: > + // MaxMetaspaceSize=64M - ~60-70K classes - ~20min runtime with all verifications > + // MaxMetaspaceSize=16M - ~12-15K classes - ~12sec runtime with all verifications > + // MaxMetaspaceSize=16M - ~12-15K classes - VerifyDependencies off - ~3seconds on ppc > + args.add("-XX:+HeapDumpOnOutOfMemoryError"); > + args.add("-XX:HeapDumpPath=" + heapdumpFilename); > + args.add("-XX:MaxMetaspaceSize=16m"); > + if (Platform.isDebugBuild()) { > + args.add("-XX:-VerifyDependencies"); > + } > + args.add(TestHeapDumpOnOutOfMemoryError.class.getName()); > + args.add(type); > + > + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(args); > > OutputAnalyzer output = new OutputAnalyzer(pb.start()); > output.stdoutShouldNotBeEmpty();` > > > > What do you think? Aha, the diff looks ugly. Basically ProcessTools.createJavaProcessBuilder(List) so you can manage the code there. ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From jiefu at openjdk.java.net Thu Oct 15 03:18:16 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 15 Oct 2020 03:18:16 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> <6IJTuysWGfnDpnHjLNoRY_1LI_2f_83GJQfjZAAEzDU=.6de76fa5-270b-464e-bdcb-9be2fe6f12d0@github.com> Message-ID: On Thu, 15 Oct 2020 02:58:46 GMT, Yumin Qi wrote: >> Hi, Jie, David and Dan, I would like to reorg the code a little bit: >> >> `index a889ae11ed1..596ca348c30 100644 >> --- a/test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java >> +++ b/test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java >> @@ -31,10 +31,12 @@ >> import jdk.test.lib.Asserts; >> import jdk.test.lib.classloader.GeneratingClassLoader; >> import jdk.test.lib.hprof.HprofParser; >> +import jdk.test.lib.Platform; >> import jdk.test.lib.process.ProcessTools; >> import jdk.test.lib.process.OutputAnalyzer; >> >> import java.io.File; >> +import java.util.ArrayList; >> >> public class TestHeapDumpOnOutOfMemoryError { >> >> @@ -64,22 +66,29 @@ public class TestHeapDumpOnOutOfMemoryError { >> } >> >> static void test(String type) throws Exception { >> + ArrayList args = new ArrayList(); >> + >> String heapdumpFilename = type + ".hprof"; >> - ProcessBuilder pb = ProcessTools.createJavaProcessBuilder("-XX:+HeapDumpOnOutOfMemoryError", >> - "-XX:HeapDumpPath=" + heapdumpFilename, >> - // Note: When trying to provoke a metaspace OOM we may generate a lot of classes. In debug VMs this >> - // can cause considerable wait times since: >> - // - Compiler Dependencies verification iterates the class tree >> - // - Before exit, the CLDG is checked. >> - // Both verifications show quadratic time or worse wrt to number of loaded classes. Therefore it >> - // makes sense to switch one or both off and limit the metaspace size to something sensible. >> - // Example numbers on a slow ppc64 machine: >> - // MaxMetaspaceSize=64M - ~60-70K classes - ~20min runtime with all verifications >> - // MaxMetaspaceSize=16M - ~12-15K classes - ~12sec runtime with all verifications >> - // MaxMetaspaceSize=16M - ~12-15K classes - VerifyDependencies off - ~3seconds on ppc >> - "-XX:MaxMetaspaceSize=16m", >> - "-XX:-VerifyDependencies", >> - TestHeapDumpOnOutOfMemoryError.class.getName(), type); >> + // Note: When trying to provoke a metaspace OOM we may generate a lot of classes. In debug VMs this >> + // can cause considerable wait times since: >> + // - Compiler Dependencies verification iterates the class tree >> + // - Before exit, the CLDG is checked. >> + // Both verifications show quadratic time or worse wrt to number of loaded classes. Therefore it >> + // makes sense to switch one or both off and limit the metaspace size to something sensible. >> + // Example numbers on a slow ppc64 machine: >> + // MaxMetaspaceSize=64M - ~60-70K classes - ~20min runtime with all verifications >> + // MaxMetaspaceSize=16M - ~12-15K classes - ~12sec runtime with all verifications >> + // MaxMetaspaceSize=16M - ~12-15K classes - VerifyDependencies off - ~3seconds on ppc >> + args.add("-XX:+HeapDumpOnOutOfMemoryError"); >> + args.add("-XX:HeapDumpPath=" + heapdumpFilename); >> + args.add("-XX:MaxMetaspaceSize=16m"); >> + if (Platform.isDebugBuild()) { >> + args.add("-XX:-VerifyDependencies"); >> + } >> + args.add(TestHeapDumpOnOutOfMemoryError.class.getName()); >> + args.add(type); >> + >> + ProcessBuilder pb = ProcessTools.createJavaProcessBuilder(args); >> >> OutputAnalyzer output = new OutputAnalyzer(pb.start()); >> output.stdoutShouldNotBeEmpty();` >> >> >> >> What do you think? > > Aha, the diff looks ugly. Basically ProcessTools.createJavaProcessBuilder(List) so you can manage the code there. Hi @yminqi To fix this bug, I prefer David's suggestion, which seems simple and elegant. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From kbarrett at openjdk.java.net Thu Oct 15 03:23:15 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 15 Oct 2020 03:23:15 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) [v3] In-Reply-To: References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> Message-ID: On Wed, 14 Oct 2020 12:52:35 GMT, Jie Fu wrote: >> __sync_val_compare_and_swap shouldn't call with narrowOop* for clang after JDK-8247912. >> Before passing type T to __sync_val_compare_and_swap, the fix converts T to uint32_t* if sizeof(T) == 4. >> >> Testing: >> - Zero VM build on Linux and MacOS with clang >> - Zero VM build on Linux with gcc > > Jie Fu 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-8253970 > - Add FULL_MEM_BARRIER > - Merge branch 'master' into JDK-8253970 > - Revert changes > - Replace __sync_val_compare_and_swap whith __atomic_compare_exchange > - Merge branch 'master' into JDK-8253970 > - Revert changes > - 8253970 Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' > invalid) Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/496 From jiefu at openjdk.java.net Thu Oct 15 03:25:21 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 15 Oct 2020 03:25:21 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs [v2] In-Reply-To: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is > develop and is available only in debug version of VM. > -XX:+IgnoreUnrecognizedVMOptions is added to fix it. Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Remove -XX:+IgnoreUnrecognizedVMOptions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/673/files - new: https://git.openjdk.java.net/jdk/pull/673/files/a36a93b6..b08c8828 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=673&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=673&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/673.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/673/head:pull/673 PR: https://git.openjdk.java.net/jdk/pull/673 From jiefu at openjdk.java.net Thu Oct 15 03:28:11 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 15 Oct 2020 03:28:11 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs [v2] In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> <6IJTuysWGfnDpnHjLNoRY_1LI_2f_83GJQfjZAAEzDU=.6de76fa5-270b-464e-bdcb-9be2fe6f12d0@github.com> Message-ID: On Thu, 15 Oct 2020 03:15:27 GMT, Jie Fu wrote: >> Aha, the diff looks ugly. Basically ProcessTools.createJavaProcessBuilder(List) so you can manage the code there. > > Hi @yminqi > To fix this bug, I prefer David's suggestion, which seems simple and elegant. > Thanks. Hi all, I prefer David's solution because I think it's a good idea to avoid -XX:+IgnoreUnrecognizedVMOptions without the effort to reorg the code. I like this approach if -XX:+IgnoreUnrecognizedVMOptions is not allowed. I've updated the PR. Please review it. Thanks. Best regards, Jie ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From dholmes at openjdk.java.net Thu Oct 15 04:13:12 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Oct 2020 04:13:12 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs [v2] In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: On Thu, 15 Oct 2020 03:25:21 GMT, Jie Fu wrote: >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is >> develop and is available only in debug version of VM. >> -XX:+IgnoreUnrecognizedVMOptions is added to fix it. > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Remove -XX:+IgnoreUnrecognizedVMOptions Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From stuefe at openjdk.java.net Thu Oct 15 05:14:13 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 15 Oct 2020 05:14:13 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs [v2] In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: On Thu, 15 Oct 2020 03:25:21 GMT, Jie Fu wrote: >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is >> develop and is available only in debug version of VM. >> -XX:+IgnoreUnrecognizedVMOptions is added to fix it. > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Remove -XX:+IgnoreUnrecognizedVMOptions Sorry for the trouble my change caused. :( It would have been fine also to just run this test on debug only, or even just to remove the option; the speedup that the reduced MaxMetaspaceSize brought would have been enough. Thanks a lot for fixing this. I wondered how it got past gatekeeper tests but I see now that it was excluded from tier1, probably exactly because the slow runtime. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/673 From rehn at openjdk.java.net Thu Oct 15 06:25:09 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 15 Oct 2020 06:25:09 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 14:25:14 GMT, Patricio Chilano Mateo wrote: > Hi all, > > Please review the following patch that removes some uneeded uses of cross_modify_fence() in common code, in particular > from ~ThreadBlockInVM(), ~ThreadBlockInVMWithDeadlockCheck() and java_suspend_self_with_safepoint_check(). These fences > were added before each JavaThread had to disarm itself (8230594). After a safepoint/handshake each JavaThread will > always call SafepointMechanism::process_if_requested_slow() when transitioning out of the safe state and will execute a > cross_modify_fence(). Tested with mach5 tiers1-7. Thanks, Patricio Thanks! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/655 From jiefu at openjdk.java.net Thu Oct 15 06:30:17 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 15 Oct 2020 06:30:17 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) [v3] In-Reply-To: References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> Message-ID: On Thu, 15 Oct 2020 03:20:40 GMT, Kim Barrett wrote: >> Jie Fu 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-8253970 >> - Add FULL_MEM_BARRIER >> - Merge branch 'master' into JDK-8253970 >> - Revert changes >> - Replace __sync_val_compare_and_swap whith __atomic_compare_exchange >> - Merge branch 'master' into JDK-8253970 >> - Revert changes >> - 8253970 Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' >> invalid) > > Looks good. Thanks @kimbarrett for your review. Will push it tomorrow if there is no objection. ------------- PR: https://git.openjdk.java.net/jdk/pull/496 From jiefu at openjdk.java.net Thu Oct 15 06:38:15 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 15 Oct 2020 06:38:15 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs [v2] In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: On Thu, 15 Oct 2020 05:11:39 GMT, Thomas Stuefe wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove -XX:+IgnoreUnrecognizedVMOptions > > Sorry for the trouble my change caused. :( > > It would have been fine also to just run this test on debug only, or even just to remove the option; the speedup that > the reduced MaxMetaspaceSize brought would have been enough. > Thanks a lot for fixing this. > > I wondered how it got past gatekeeper tests but I see now that it was excluded from tier1, probably exactly because the > slow runtime. Hi @dcubed-ojdk , Hope you have no objection to the latest fix. And then I can push it ASAP. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From david.holmes at oracle.com Thu Oct 15 08:22:38 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Oct 2020 18:22:38 +1000 Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: Message-ID: <8786e8a2-00ce-74f6-7a4b-eef708b6e848@oracle.com> Hi Patricio, On 15/10/2020 1:20 am, Patricio Chilano Mateo wrote: > Hi all, > > Please review the following patch that removes some uneeded uses of cross_modify_fence() in common code, in particular > from ~ThreadBlockInVM(), ~ThreadBlockInVMWithDeadlockCheck() and java_suspend_self_with_safepoint_check(). These fences > were added before each JavaThread had to disarm itself (8230594). After a safepoint/handshake each JavaThread will > always call SafepointMechanism::process_if_requested_slow() when transitioning out of the safe state and will execute a > cross_modify_fence(). Tested with mach5 tiers1-7. As you have already done the analysis, could you show the exact call sequences that allow for the removal of the code as described? I'm trying to verify what you've stated but trying to reverse engineer the calling sequences is painful. :) Thanks, David > Thanks, > Patricio > > ------------- > > Commit messages: > - v1 > > Changes: https://git.openjdk.java.net/jdk/pull/655/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=655&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8254264 > Stats: 5 lines in 2 files changed: 0 ins; 5 del; 0 mod > Patch: https://git.openjdk.java.net/jdk/pull/655.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/655/head:pull/655 > > PR: https://git.openjdk.java.net/jdk/pull/655 > From rehn at openjdk.java.net Thu Oct 15 08:54:15 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 15 Oct 2020 08:54:15 GMT Subject: RFR: 8254824: SignalHandlerMark have no purpose Message-ID: SignalHandlerMark increase and decrease _num_nested_signal, but it is never read. We have no caller to is_inside_signal_handler(). Testing T1. ------------- Commit messages: - SignalHandlerMark removed Changes: https://git.openjdk.java.net/jdk/pull/677/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=677&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254824 Stats: 49 lines in 11 files changed: 0 ins; 49 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/677.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/677/head:pull/677 PR: https://git.openjdk.java.net/jdk/pull/677 From martin.doerr at sap.com Thu Oct 15 09:05:48 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 15 Oct 2020 09:05:48 +0000 Subject: guarantee(object->mark() == markWord::INFLATING()) failed: invariant In-Reply-To: <7edeb04f-7a6f-ed8d-da5b-a51b5ebfa32f@oracle.com> References: <7edeb04f-7a6f-ed8d-da5b-a51b5ebfa32f@oracle.com> Message-ID: Hi Thomas, thanks for your hints. I had replied in the bug only and attached the hs_err file (not sure if you have seen it): https://bugs.openjdk.java.net/browse/JDK-8253927 I'm glad https://bugs.openjdk.java.net/browse/JDK-8254164 is fixed, but it's very unclear to me if the crash was caused by that. To me, it looks more like another thread has deflated the monitor which is not allowed. I don't know if this could be caused by the GC issue. Best regards, Martin > -----Original Message----- > From: hotspot-runtime-dev > On Behalf Of Thomas Schatzl > Sent: Donnerstag, 8. Oktober 2020 10:31 > To: hotspot-runtime-dev at openjdk.java.net > Subject: Re: guarantee(object->mark() == markWord::INFLATING()) failed: > invariant > > Hi Martin, > > On 01.10.20 20:52, Doerr, Martin wrote: > > Hi, > > > > we have seen a crash when running Spec JVM 2008 on a Power9 machine. > > It occurred only once so I can't tell if it is a PPC64 specific or weak memory > model specific issue. > > Locking code has worked very solid for many years on this platform. > > > > # Internal Error (synchronizer.cpp:1953), pid=18455, tid=19363 > > # guarantee(object->mark() == markWord::INFLATING()) failed: invariant > > > > V [libjvm.so+0xe463cc] ObjectSynchronizer::inflate(Thread*, oopDesc*, > ObjectSynchronizer::InflateCause)+0x76c > > V [libjvm.so+0xe467ac] ObjectSynchronizer::exit(oopDesc*, BasicLock*, > Thread*)+0x4c > > V [libjvm.so+0xda18a0] > SharedRuntime::complete_monitor_unlocking_C(oopDesc*, BasicLock*, > JavaThread*)+0xc0 > > J 5765 c2 sun.nio.cs.StreamEncoder.flushBuffer()V java.base at 16.0.0.1- > internal (42 bytes) @ 0x00007fff95e1d84c > [0x00007fff95e1d400+0x000000000000044c] > > J 6249 c2 java.io.PrintStream.println(Ljava/lang/String;)V > java.base at 16.0.0.1-internal (44 bytes) @ 0x00007fff95f1f1a0 > [0x00007fff95f1ea80+0x0000000000000720] > > J 6534 c1 > spec.benchmarks.crypto.aes.Main.runEncryptDecrypt(Ljavax/crypto/SecretK > ey;Ljava/lang/String;Ljava/lang/String;)V (93 bytes) @ 0x00007fff8e575794 > [0x00007fff8e574e00+0x0000000000000994] > > j spec.benchmarks.crypto.aes.Main.harnessMain()V+69 > > ... > > > > object->_mark points to a stack lock: > > 0x00007ffe67dfdbc8 is pointing into the stack for thread: > 0x00007ffeec10d5e0 > > content of stack slot 0x7ffe67dfdbc8: 0x0000000000000009 > > which belongs to the crashing thread: > > Current thread (0x00007ffeec10d5e0): JavaThread "BenchmarkThread > crypto.aes 5" [_thread_in_Java, id=19363, > stack(0x00007ffe67c00000,0x00007ffe67e00000)] > > > > I wonder how this can happen. Can it be related to asynchronous lock > deflation? > > Any ideas are welcome. > > > > This reminds me a bit of JDK-8248438 because of the stack trace. This > will be fixed by JDK-8254164. > > You can you check whether its the same issue using the following keys: > > Using g1 (the snippet does not show even that) > - the markword contains a self-forwarded pointer > AND/OR > - the most recent gc has been a mixed gc with an optional evacuation > phase and an evacuation failure (can be seen in a gc log) > > If you can manage to verify the first, this is a duplicate of > JDK-8254164 (note that that bug is there since JDK 13). If you can only > verify the latter, there is very high probability that this is the issue. > > Thanks, > Thomas From stuefe at openjdk.java.net Thu Oct 15 09:08:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 15 Oct 2020 09:08:11 GMT Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 08:46:01 GMT, Robbin Ehn wrote: > SignalHandlerMark increase and decrease _num_nested_signal, but it is never read. > We have no caller to is_inside_signal_handler(). > > Testing T1. Looks good. Seems like a leftover from Solaris. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/677 From shade at openjdk.java.net Thu Oct 15 09:14:09 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 15 Oct 2020 09:14:09 GMT Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 08:46:01 GMT, Robbin Ehn wrote: > SignalHandlerMark increase and decrease _num_nested_signal, but it is never read. > We have no caller to is_inside_signal_handler(). > > Testing T1. Looks fine to me. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/677 From rehn at openjdk.java.net Thu Oct 15 09:18:18 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 15 Oct 2020 09:18:18 GMT Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 09:11:15 GMT, Aleksey Shipilev wrote: >> SignalHandlerMark increase and decrease _num_nested_signal, but it is never read. >> We have no caller to is_inside_signal_handler(). >> >> Testing T1. > > Looks fine to me. Thanks @tstuefe and @shipilev! ------------- PR: https://git.openjdk.java.net/jdk/pull/677 From thomas.schatzl at oracle.com Thu Oct 15 10:09:19 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 15 Oct 2020 12:09:19 +0200 Subject: guarantee(object->mark() == markWord::INFLATING()) failed: invariant In-Reply-To: References: <7edeb04f-7a6f-ed8d-da5b-a51b5ebfa32f@oracle.com> Message-ID: <84bf1127-1abf-25a5-e3a6-615acc48dd0a@oracle.com> Hi Martin, On 15.10.20 11:05, Doerr, Martin wrote: > Hi Thomas, > > thanks for your hints. I had replied in the bug only and attached the hs_err file (not sure if you have seen it): > https://bugs.openjdk.java.net/browse/JDK-8253927 No, I hadn't subscribed to the CR. > > I'm glad https://bugs.openjdk.java.net/browse/JDK-8254164 is fixed, but it's very unclear to me if the crash was caused by that. > To me, it looks more like another thread has deflated the monitor which is not allowed. I don't know if this could be caused by the GC issue. This looks like something different, the mark is valid, and there is no particular heap pressure that would cause evacuation failures. Thanks, Thomas > > Best regards, > Martin > > >> -----Original Message----- >> From: hotspot-runtime-dev >> On Behalf Of Thomas Schatzl >> Sent: Donnerstag, 8. Oktober 2020 10:31 >> To: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: guarantee(object->mark() == markWord::INFLATING()) failed: >> invariant >> >> Hi Martin, >> >> On 01.10.20 20:52, Doerr, Martin wrote: >>> Hi, >>> >>> we have seen a crash when running Spec JVM 2008 on a Power9 machine. >>> It occurred only once so I can't tell if it is a PPC64 specific or weak memory >> model specific issue. >>> Locking code has worked very solid for many years on this platform. >>> >>> # Internal Error (synchronizer.cpp:1953), pid=18455, tid=19363 >>> # guarantee(object->mark() == markWord::INFLATING()) failed: invariant >>> >>> V [libjvm.so+0xe463cc] ObjectSynchronizer::inflate(Thread*, oopDesc*, >> ObjectSynchronizer::InflateCause)+0x76c >>> V [libjvm.so+0xe467ac] ObjectSynchronizer::exit(oopDesc*, BasicLock*, >> Thread*)+0x4c >>> V [libjvm.so+0xda18a0] >> SharedRuntime::complete_monitor_unlocking_C(oopDesc*, BasicLock*, >> JavaThread*)+0xc0 >>> J 5765 c2 sun.nio.cs.StreamEncoder.flushBuffer()V java.base at 16.0.0.1- >> internal (42 bytes) @ 0x00007fff95e1d84c >> [0x00007fff95e1d400+0x000000000000044c] >>> J 6249 c2 java.io.PrintStream.println(Ljava/lang/String;)V >> java.base at 16.0.0.1-internal (44 bytes) @ 0x00007fff95f1f1a0 >> [0x00007fff95f1ea80+0x0000000000000720] >>> J 6534 c1 >> spec.benchmarks.crypto.aes.Main.runEncryptDecrypt(Ljavax/crypto/SecretK >> ey;Ljava/lang/String;Ljava/lang/String;)V (93 bytes) @ 0x00007fff8e575794 >> [0x00007fff8e574e00+0x0000000000000994] >>> j spec.benchmarks.crypto.aes.Main.harnessMain()V+69 >>> ... >>> >>> object->_mark points to a stack lock: >>> 0x00007ffe67dfdbc8 is pointing into the stack for thread: >> 0x00007ffeec10d5e0 >>> content of stack slot 0x7ffe67dfdbc8: 0x0000000000000009 >>> which belongs to the crashing thread: >>> Current thread (0x00007ffeec10d5e0): JavaThread "BenchmarkThread >> crypto.aes 5" [_thread_in_Java, id=19363, >> stack(0x00007ffe67c00000,0x00007ffe67e00000)] >>> >>> I wonder how this can happen. Can it be related to asynchronous lock >> deflation? >>> Any ideas are welcome. >>> >> >> This reminds me a bit of JDK-8248438 because of the stack trace. This >> will be fixed by JDK-8254164. >> >> You can you check whether its the same issue using the following keys: >> >> Using g1 (the snippet does not show even that) >> - the markword contains a self-forwarded pointer >> AND/OR >> - the most recent gc has been a mixed gc with an optional evacuation >> phase and an evacuation failure (can be seen in a gc log) >> >> If you can manage to verify the first, this is a duplicate of >> JDK-8254164 (note that that bug is there since JDK 13). If you can only >> verify the latter, there is very high probability that this is the issue. >> >> Thanks, >> Thomas From david.holmes at oracle.com Thu Oct 15 11:35:41 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Oct 2020 21:35:41 +1000 Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: <3e952620-8040-4447-de80-7856405d142b@oracle.com> On 15/10/2020 7:08 pm, Thomas Stuefe wrote: > On Thu, 15 Oct 2020 08:46:01 GMT, Robbin Ehn wrote: > >> SignalHandlerMark increase and decrease _num_nested_signal, but it is never read. >> We have no caller to is_inside_signal_handler(). >> >> Testing T1. > > Looks good. Seems like a leftover from Solaris. Yes (for os::fork_and_exec), and also the old Thread::current() code: inline Thread* Thread::current() { #ifdef ASSERT // This function is very high traffic. Define PARANOID to enable expensive // asserts. #ifdef PARANOID // Signal handler should call ThreadLocalStorage::get_thread_slow() Thread* t = ThreadLocalStorage::get_thread_slow(); assert(t != NULL && !t->is_inside_signal_handler(), "Don't use Thread::current() inside signal handler"); #endif #endif Thread* thread = ThreadLocalStorage::thread(); assert(thread != NULL, "just checking"); return thread; } Arguably we should be checking that a lot of code is never executed in a signal handling context, but crash reporting will likely invalidate any attempt to do (unless we have an escape clause for when doing error reporting). David ----- > ------------- > > Marked as reviewed by stuefe (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/677 > From mdoerr at openjdk.java.net Thu Oct 15 12:09:19 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 15 Oct 2020 12:09:19 GMT Subject: RFR: 8254811: JDK-8254158 broke ppc64, s390 builds Message-ID: "frame::interpreter_frame_initial_sp_offset" is currently used in shared POSIX code, but doesn't exist on ppc64 and s390. These platforms use frame pointers instead of initial sp for reserved zone checks. See comments in InterpreterMacroAssembler::remove_activation on these platforms. So we must not add any offset. ------------- Commit messages: - 8254811: JDK-8254158 broke ppc64, s390 builds Changes: https://git.openjdk.java.net/jdk/pull/680/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=680&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254811 Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/680.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/680/head:pull/680 PR: https://git.openjdk.java.net/jdk/pull/680 From stuefe at openjdk.java.net Thu Oct 15 12:27:09 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 15 Oct 2020 12:27:09 GMT Subject: RFR: 8254811: JDK-8254158 broke ppc64, s390 builds In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 12:01:10 GMT, Martin Doerr wrote: > "frame::interpreter_frame_initial_sp_offset" is currently used in shared POSIX code, but doesn't exist on ppc64 and > s390. These platforms use frame pointers instead of initial sp for reserved zone checks. See comments in > InterpreterMacroAssembler::remove_activation on these platforms. So we must not add any offset. LGTM. Thanks for fixing this! ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/680 From goetz at openjdk.java.net Thu Oct 15 12:27:10 2020 From: goetz at openjdk.java.net (Goetz Lindenmaier) Date: Thu, 15 Oct 2020 12:27:10 GMT Subject: RFR: 8254811: JDK-8254158 broke ppc64, s390 builds In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 12:01:10 GMT, Martin Doerr wrote: > "frame::interpreter_frame_initial_sp_offset" is currently used in shared POSIX code, but doesn't exist on ppc64 and > s390. These platforms use frame pointers instead of initial sp for reserved zone checks. See comments in > InterpreterMacroAssembler::remove_activation on these platforms. So we must not add any offset. A pitty we need a #define now. But looks good. Thanks for fixing this. ------------- Marked as reviewed by goetz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/680 From rehn at openjdk.java.net Thu Oct 15 13:23:16 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 15 Oct 2020 13:23:16 GMT Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 11:43:02 GMT, David Holmes wrote: >> SignalHandlerMark increase and decrease _num_nested_signal, but it is never read. >> We have no caller to is_inside_signal_handler(). >> >> Testing T1. > > src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp line 404: > >> 402: Thread* t = Thread::current_or_null_safe(); >> 403: >> 404: // Must do this before SignalHandlerMark, if crash protection installed we will longjmp away > > Should we keep a comment (and add to other files) to the effect that: > > // If crash protection is installed we will longjmp away and no destructors from any RAII utility > // object would be run. So don't use any RAII utilities here. > > ? // If crash protection is installed we may longjmp away and no destructors // for objects in this scope will be run. // So don't use any RAII utilities before crash protection is checked. Since even if crash protection is installed it's not certain we will longjmp and you can trust destructors after we checked crash protection. ? > src/hotspot/share/runtime/thread.hpp line 316: > >> 314: DEBUG_ONLY(bool _suspendible_thread;) >> 315: >> 316: public: > > In a product build we will have: > > private: > public: > > is it possible the compiler may warn about this? I don't believe so. ------------- PR: https://git.openjdk.java.net/jdk/pull/677 From dcubed at openjdk.java.net Thu Oct 15 14:17:14 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 15 Oct 2020 14:17:14 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 00:41:08 GMT, David Holmes wrote: >> 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 > > src/hotspot/share/runtime/synchronizer.cpp line 2949: > >> 2947: assert(Thread::current()->is_VM_thread(), "sanity check"); >> 2948: >> 2949: if (is_final_audit()) { // Only do the audit once. > > It seems impossible that you could ever call this twice. A simple file static flag for a debug build would be simpler > if you just wanted to assert that. I modeled the make-sure-this-is-only-called-once logic on exit_globals(). I originally implemented it as a static flag just like exit_globals(). Is it necessary? I don't think so either, but I'm guarding against future changes since the final audit should only be done once. In the changeset that follows this one (JDK-8253064), this is_final_audit() query function is needed to change some of the logic that gets executed in the "final" audit. I backported that bit to this bug fix so there was one less thing to review in JDK-8253064. > src/hotspot/share/runtime/vmOperations.cpp line 458: > >> 456: // The ObjectMonitor subsystem uses perf counters so do this before >> 457: // we call exit_globals() so we don't run afoul of perfMemory_exit(). >> 458: ObjectSynchronizer::do_final_audit_and_print_stats(); > > Given this used to be done in the prolog, is there anything above this line that might interfere with it somehow? Or > more simply put, why not do this first so that it is as close as possible to where it used to be? The async deflation request was made in `doit_prologue()` which meant that the ServiceThread would eventually do the work, but that was in a racy fashion which is what motivated this change. `exit_globals()` below used to make the call to `audit_and_print_stats()` so we're actually doing that part a little bit earlier than before. The only boundary condition that I've ever found in all of my testing was that the audit needed to be done before the `perfMemory_exit()` call that's made in `exit_globals()`. I have not seen any issues caused by the code that's executed in `VM_Exit::doit()` before we get to the final audit. > src/hotspot/share/runtime/vmThread.cpp line 194: > >> 192: // we signal that the VM thread is gone. We don't want to run afoul >> 193: // of perfMemory_exit() in exit_globals(). >> 194: ObjectSynchronizer::do_final_audit_and_print_stats(); > > Again I wonder why this was moved so far from the original call to deflate? It makes sense to do the final deflation > once the final safepoint has been reached, but should we do it first once the safepoint has been reached? Again the old code made an async deflation request which meant that the ServiceThread would eventually do the work, but that was in a racy fashion which is what motivated this change. The `exit_globals()` call is a little less obvious for this code path. That happens over in `src/hotspot/share/runtime/thread.cpp` in the `Threads::destroy_vm()` function. In `destroy_vm()` we wait for the VMThread to exit via a `VMThread::wait_for_vm_thread_exit()` call and a bit later we call `exit_globals()`. In the new code, we're calling `do_final_audit_and_print_stats()` as part of the VMThread's exit path code in the `VMThread::run()` function so, again, we're doing the final audit a little bit earlier than we used to do it before. ------------- PR: https://git.openjdk.java.net/jdk/pull/641 From mdoerr at openjdk.java.net Thu Oct 15 14:21:21 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 15 Oct 2020 14:21:21 GMT Subject: Integrated: 8254811: JDK-8254158 broke ppc64, s390 builds In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 12:01:10 GMT, Martin Doerr wrote: > "frame::interpreter_frame_initial_sp_offset" is currently used in shared POSIX code, but doesn't exist on ppc64 and > s390. These platforms use frame pointers instead of initial sp for reserved zone checks. See comments in > InterpreterMacroAssembler::remove_activation on these platforms. So we must not add any offset. This pull request has now been integrated. Changeset: cda22e36 Author: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/cda22e36 Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod 8254811: JDK-8254158 broke ppc64, s390 builds Reviewed-by: stuefe, goetz ------------- PR: https://git.openjdk.java.net/jdk/pull/680 From dcubed at openjdk.java.net Thu Oct 15 14:22:17 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 15 Oct 2020 14:22:17 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 00:43:42 GMT, David Holmes wrote: >> 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 > > Hi Dan, > > Overall this looks good to me. > > A few minor comments/queries below. > > Thanks, > David @dholmes-ora - Thanks for the review! Please let me know if the above replies answer your questions. ------------- PR: https://git.openjdk.java.net/jdk/pull/641 From dcubed at openjdk.java.net Thu Oct 15 14:30:15 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 15 Oct 2020 14:30:15 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs [v2] In-Reply-To: References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: <8-xKjtPYYJwGSsjL_wbUr7zsRJpeogrsronyYVHdfyc=.f29b72a2-3013-4e1d-8296-d607f50333dd@github.com> On Thu, 15 Oct 2020 03:25:21 GMT, Jie Fu wrote: >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and >> runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is >> develop and is available only in debug version of VM. >> -XX:+IgnoreUnrecognizedVMOptions is added to fix it. > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Remove -XX:+IgnoreUnrecognizedVMOptions Thumbs up on this version. I would have used "-Dignored_option" so it was self documenting, but that's me... "-Dx" works just fine. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/673 From jiefu at openjdk.java.net Thu Oct 15 14:51:13 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 15 Oct 2020 14:51:13 GMT Subject: RFR: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs [v2] In-Reply-To: <8-xKjtPYYJwGSsjL_wbUr7zsRJpeogrsronyYVHdfyc=.f29b72a2-3013-4e1d-8296-d607f50333dd@github.com> References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> <8-xKjtPYYJwGSsjL_wbUr7zsRJpeogrsronyYVHdfyc=.f29b72a2-3013-4e1d-8296-d607f50333dd@github.com> Message-ID: On Thu, 15 Oct 2020 14:27:38 GMT, Daniel D. Daugherty wrote: >> Jie Fu has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove -XX:+IgnoreUnrecognizedVMOptions > > Thumbs up on this version. > I would have used "-Dignored_option" so it was self documenting, > but that's me... "-Dx" works just fine. Thanks @yminqi , @dholmes-ora , @dcubed-ojdk and @tstuefe for your helpful comments and review. ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From jiefu at openjdk.java.net Thu Oct 15 14:51:14 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 15 Oct 2020 14:51:14 GMT Subject: Integrated: 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs In-Reply-To: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> References: <-ZnmG1a_uJfLsU35m00iNk25rrBphqeUPNQVCXFqZbk=.0b4b9ed4-521f-4e1f-84e4-506762b9d514@github.com> Message-ID: <76sXyWSl9OTNkxzt8fHt-gd-n7d-9h1NxDF-k4gtrdA=.155f06c4-a8d7-4451-8f30-175d6bcce777@github.com> On Wed, 14 Oct 2020 23:45:52 GMT, Jie Fu wrote: > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java and > runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java fail with release VMs due to VerifyDependencies is > develop and is available only in debug version of VM. > -XX:+IgnoreUnrecognizedVMOptions is added to fix it. This pull request has now been integrated. Changeset: f3ce45f2 Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/f3ce45f2 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs Reviewed-by: dholmes, dcubed, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/673 From stuefe at openjdk.java.net Thu Oct 15 15:50:32 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 15 Oct 2020 15:50:32 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v16] In-Reply-To: References: Message-ID: > Hi all, > > this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the > delay, had vacation then the entrance of Skara delayed things a bit. > For the delta diff please see [3]. > > This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all > feedback individually in this PR body, but I incorporated almost all into the new revision. > What changed since the last version: > > - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the > group consent. > > - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for > overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth > class loader which made it rather pointless. Now I run it always. > > - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. > > - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) > > Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. > > - In ChunkManager::purge() I improved the comments after discussions with Leo. > > - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due > to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run > every time. > > - Fixed indentation issues as Leo requested > > - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested > > - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes > and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more > flexible since it allows us to have list with purge-able and non-purge-able nodes. > > - and various smaller fixes, mainly on request of Leo. > > @lkorinth: > >> VirtualSpaceNode.hpp >> >>102 // Start pointer of the area. >>103 MetaWord* const _base; >> >>How does this differ from _rs._base? Really needed? >> >>105 // Size, in words, of the whole node >>106 const size_t _word_size; >> >>Can we not calculate this from _rs.size()? > > You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it > is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly > improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at > some point and make those members const - as they should be - then I would rewrite this as you suggest. > Thanks, again, for all your review work! > > ------ > > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html > [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - Merge - Merge - Richard feedback 3 - Add ASCII art to better describe Metachunk relationship to their payload - Fix retrieval from FreeChunkList; add test; update comments - Loosen unnecessarily strict restriction of allowed chunk states on ChunkManager::return_chunk - Assert that in reclaim=none mode new chunks are fully committed - Review Feedback Richard 2 - Fix 32bit build - Review Feedback Richard 1 - ... and 16 more: https://git.openjdk.java.net/jdk/compare/abe51377...df2f81db ------------- Changes: https://git.openjdk.java.net/jdk/pull/336/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=15 Stats: 23023 lines in 174 files changed: 14779 ins; 7020 del; 1224 mod Patch: https://git.openjdk.java.net/jdk/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/336/head:pull/336 PR: https://git.openjdk.java.net/jdk/pull/336 From ccheung at openjdk.java.net Thu Oct 15 15:54:27 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 15 Oct 2020 15:54:27 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v6] In-Reply-To: References: Message-ID: > Following up on archiving lambda proxy classes in dynamic CDS archive > ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of > lambda proxy classes in static CDS archive. > When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved > during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will > be of the following format: > `@lambda-proxy: ` > > e.g. > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` > > When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above > `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool > indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool > entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index > and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. > During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not > found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> > IsCDSDumpingEnabled) is involved in the core-libs code.) > Testing: tiers 1,2,3,4. > > Performance results (javac on HelloWorld on linux-x64): > Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " > 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- > 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- > 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- > 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- > 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- > 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- > 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- > 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- > 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- > 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- > ============================================================ > 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- > instr delta = -161497801 -7.2542% > time delta = -24.722 ms -6.5951% Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: Changes based on Ioi's suggestions: 1. Added the ClassListWriter class to make writing to a classlist file thread safe; 2. Changed API's in CDS.java to be more consistent with CDS.isDumpingClasslist. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/364/files - new: https://git.openjdk.java.net/jdk/pull/364/files/218d4484..fd4f563b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=04-05 Stats: 183 lines in 13 files changed: 112 ins; 50 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364 PR: https://git.openjdk.java.net/jdk/pull/364 From ccheung at openjdk.java.net Thu Oct 15 15:54:31 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 15 Oct 2020 15:54:31 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v5] In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 23:59:38 GMT, Ioi Lam wrote: >> Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains ten commits: >> - fix minimal vm build issues >> - Merge branch 'master' into 8247666 >> - Merge branch 'master' into 8247666 >> - 1. Symbolic encoding of lambda proxy resolution. An example of @lambda-proxy in the classlist: >> @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambdabash ()V ()V >> 2. Removed BadCPIndex.java; added LambdaProxyClassList.java test. >> 3. Mandy's comments. >> - Merge branch 'master' into 8247666 >> - exclude archived lambda proxy classes in the classlist >> - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi >> - fix extraneous whitespace >> - 8247666 (initial commit) > > src/hotspot/share/interpreter/linkResolver.cpp line 34: > >> 32: #include "classfile/symbolTable.hpp" >> 33: #include "classfile/systemDictionary.hpp" >> 34: #include "classfile/systemDictionaryShared.hpp" > > Are all the new includes necessary? Those new includes are not needed. I've removed them. > src/hotspot/share/memory/archiveUtils.cpp line 321: > >> 319: } >> 320: } >> 321: } > > I think if two threads try call ArchiveUtils::log_to_classlist at the same time, the output may be interleaved. > > classlist_file is a fileStream, which uses fwrite to write to the file. In theory, if you write the whole line at once, > the output should be thread safe (at least on POSIX and Windows). But in your case, you would need to first get the > whole line into a buffer, and then write it out at once. I think it would be safer, and more convenient, to use a lock > to ensure thready safety. Maybe we can convert all uses of classlist_file->print() to something like > class ClassListWriter { > static fileStream* _classlist_file; > MutexLocker locker; > public: > outputStream* stream() { > return _classlist_file; > } > static bool is_enabled() { > return _classlist_file != NULL && _classlist_file->is_open(); > } > ClassListWriter() : locker(Thread::current(), ClassListFile_lock) {} > > static void init() { > // classlist_file init code from ostrea.cpp > } > }; > > // WAS if (DumpLoadedClassList != NULL && classlist_file->is_open()) { > if (ClassListWriter::is_enabled()) { > ClassListWriter w; > w->stream()->print("aaaa"); > w->stream()->print("bbbb"); > w->stream()->cr(); > } I've added the ClassListWriter.hpp and changed other classes which operate on the classlist. > src/hotspot/share/oops/instanceKlass.cpp line 4212: > >> 4210: assert(stream == NULL, "shared class with stream"); >> 4211: if (is_hidden()) { >> 4212: // Not including archived lambda proxy class in the classlist. > > I think it's clearer to say `// Don't include archived lambda proxy class in the classlist.` Fixed. > src/java.base/share/classes/jdk/internal/misc/CDS.java line 78: > >> 76: * Check if CDS dumping is enabled via the DynamicDumpSharedSpaces or the DumpSharedSpaces flag. >> 77: */ >> 78: public static native boolean isDumpingEnabled(); > > I think it will be more consistent if we use the same pattern as `CDS::isDumpingClassList()` > > private static final boolean isDumpingArchive; > static { > isDumpingClassList = isDumpingArchive0(); > } > > /** > * Is the VM writing to a (static or dynamic) CDS archive. > */ > public static boolean isDumpingArchive() { > return isDumpingArchive; > } > > Then in LambdaProxyClassArchive.java, there's no need to keep a separate variable of dumpArchive. You can simply call > CDS.isDumpingArchive(). The JIT compiler will automatically inline the call so it will be just as fast. > LambdaProxyClassArchive::sharingEnabled should also be rewritten to use this pattern. I've changed the API's in CDS.java to be consistent with CDS.isDumpingClasslist. ------------- PR: https://git.openjdk.java.net/jdk/pull/364 From kim.barrett at oracle.com Thu Oct 15 15:56:33 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 15 Oct 2020 11:56:33 -0400 Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) [v3] In-Reply-To: References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> Message-ID: <03DD882E-685A-4973-88BF-19569472D126@oracle.com> > On Oct 15, 2020, at 2:30 AM, Jie Fu wrote: > > On Thu, 15 Oct 2020 03:20:40 GMT, Kim Barrett wrote: > >>> Jie Fu 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-8253970 >>> - Add FULL_MEM_BARRIER >>> - Merge branch 'master' into JDK-8253970 >>> - Revert changes >>> - Replace __sync_val_compare_and_swap whith __atomic_compare_exchange >>> - Merge branch 'master' into JDK-8253970 >>> - Revert changes >>> - 8253970 Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' >>> invalid) >> >> Looks good. > > Thanks @kimbarrett for your review. > Will push it tomorrow if there is no objection. There should normally be a second reviewer for HotSpot changes. > PR: https://git.openjdk.java.net/jdk/pull/496 From ccheung at openjdk.java.net Thu Oct 15 16:02:15 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 15 Oct 2020 16:02:15 GMT Subject: RFR: 8254192: ExtraSharedClassListFile contains extra white space at end of line [v2] In-Reply-To: References: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com> Message-ID: <7AQu7SAGozjdhd6SsivW2Bx22pgOK7T5g2PdpkQ6D8c=.4146bd8d-b4d2-4b22-b796-a2e3c9238597@github.com> On Thu, 15 Oct 2020 01:04:25 GMT, Yumin Qi wrote: >> Hi, Please review the simple change. >> >> The removing of white spaces from end of line in ClassListParser should be moved to before we add lambda-form-invoker >> line to array. After made such arrangement, changed CDS.java for trimming line code. >> >> Tests: local test on runtime/cds/appcds. Mach5 tier1,4 is in progress. >> >> Thanks > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment adding \f for Replace Looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/669 From mchung at openjdk.java.net Thu Oct 15 16:51:14 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 15 Oct 2020 16:51:14 GMT Subject: RFR: 8254192: ExtraSharedClassListFile contains extra white space at end of line [v2] In-Reply-To: References: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com> Message-ID: <70iL1k-EDQrm_m9xE6UTJ_gd5hZ0qCsZlN8_kKqfQ2I=.c40d262f-61fc-4e9d-97ae-caee7d114451@github.com> On Thu, 15 Oct 2020 01:04:25 GMT, Yumin Qi wrote: >> Hi, Please review the simple change. >> >> The removing of white spaces from end of line in ClassListParser should be moved to before we add lambda-form-invoker >> line to array. After made such arrangement, changed CDS.java for trimming line code. >> >> Tests: local test on runtime/cds/appcds. Mach5 tier1,4 is in progress. >> >> Thanks > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment adding \f for Replace Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/669 From minqi at openjdk.java.net Thu Oct 15 16:51:18 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 15 Oct 2020 16:51:18 GMT Subject: RFR: 8254192: ExtraSharedClassListFile contains extra white space at end of line [v2] In-Reply-To: <7AQu7SAGozjdhd6SsivW2Bx22pgOK7T5g2PdpkQ6D8c=.4146bd8d-b4d2-4b22-b796-a2e3c9238597@github.com> References: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com> <7AQu7SAGozjdhd6SsivW2Bx22pgOK7T5g2PdpkQ6D8c=.4146bd8d-b4d2-4b22-b796-a2e3c9238597@github.com> Message-ID: On Thu, 15 Oct 2020 15:59:31 GMT, Calvin Cheung wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment adding \f for Replace > > Looks good. Thanks @iklam and @calvinccheung for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/669 From minqi at openjdk.java.net Thu Oct 15 16:51:20 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 15 Oct 2020 16:51:20 GMT Subject: Integrated: 8254192: ExtraSharedClassListFile contains extra white space at end of line In-Reply-To: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com> References: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com> Message-ID: <4-QBKg5Sv7c0q3ZMxoSIHzHgcaBs28fu32ZsDYubOcs=.cd99fe58-f8af-4448-a210-e7c4accc123b@github.com> On Wed, 14 Oct 2020 22:09:50 GMT, Yumin Qi wrote: > Hi, Please review the simple change. > > The removing of white spaces from end of line in ClassListParser should be moved to before we add lambda-form-invoker > line to array. After made such arrangement, changed CDS.java for trimming line code. > > Tests: local test on runtime/cds/appcds. Mach5 tier1,4 is in progress. > > Thanks This pull request has now been integrated. Changeset: 546620bb Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/546620bb Stats: 57 lines in 2 files changed: 26 ins; 25 del; 6 mod 8254192: ExtraSharedClassListFile contains extra white space at end of line Reviewed-by: iklam, ccheung, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/669 From stuefe at openjdk.java.net Thu Oct 15 17:35:15 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 15 Oct 2020 17:35:15 GMT Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 11:45:28 GMT, David Holmes wrote: >> SignalHandlerMark increase and decrease _num_nested_signal, but it is never read. >> We have no caller to is_inside_signal_handler(). >> >> Testing T1. > > Changes requested by dholmes (Reviewer). > As much as I like seeing old code removed, wouldn't this be something that would be useful? Should Mutex::lock with > safepoint check for instance check for this? Maybe. But as it is, beside being unused it is pretty inconsistent: only the main signal hndler uses this, not the SR_handler nor the secondary error handler. So, Thread::_num_nested_signal would only ever be >1 if a second signal happened right inside the signal handling but before fatal error handling kicks in, which as its first step installs the secondary error handler. BTW one thing I wondered about is that all the JVM_handle_xxx_signal() functions return an int; but we return anything out of {true, false, 0, 1.} And the return value is then ignored at the caller. For example, the "abort_if_unrecognized" option does not seem to do anything - can probably be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/677 From patricio.chilano.mateo at oracle.com Thu Oct 15 18:09:43 2020 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Thu, 15 Oct 2020 15:09:43 -0300 Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: <8786e8a2-00ce-74f6-7a4b-eef708b6e848@oracle.com> References: <8786e8a2-00ce-74f6-7a4b-eef708b6e848@oracle.com> Message-ID: <52eb400e-a9cb-3031-c24d-2e07a573cdd6@oracle.com> Hi David, On 10/15/20 5:22 AM, David Holmes wrote: > Hi Patricio, > > On 15/10/2020 1:20 am, Patricio Chilano Mateo wrote: >> Hi all, >> >> Please review the following patch that removes some uneeded uses of >> cross_modify_fence() in common code, in particular >> from ~ThreadBlockInVM(), ~ThreadBlockInVMWithDeadlockCheck() and >> java_suspend_self_with_safepoint_check(). These fences >> were added before each JavaThread had to disarm itself (8230594). >> After a safepoint/handshake each JavaThread will >> always call SafepointMechanism::process_if_requested_slow() when >> transitioning out of the safe state and will execute a >> cross_modify_fence(). Tested with mach5 tiers1-7. > > As you have already done the analysis, could you show the exact call > sequences that allow for the removal of the code as described? I'm > trying to verify what you've stated but trying to reverse engineer the > calling sequences is painful. :) So, before each JavaThread had to disarm itself you could have the following sequence: - JT T creates ThreadBlockInVM object and then blocks (usually in park()/wait()) - VMThread arms T for a safepoint operation. Since T is in _thread_blocked state it's safe so safepoint starts. - Once safepoint operation is done VMThread disarms T - T wakes up and executes ~ThreadBlockInVM(). Since the poll word/page is not armed it just continues execution. If we didn't have that cross_modify_fence() in ~ThreadBlockInVM() we can transition back to java later without executing the fence instruction. Same sequence with ~ThreadBlockInVMWithDeadlockCheck and java_suspend_self_with_safepoint_check(). So when transitioning out of the _thread_blocked state a JT wouldn't know if a safepoint happened so we had that fence there unconditionally. Today disarming of the poll word/page is done by each JT, so if a safepoint happened while the JT was blocked the poll word/page will remain armed. The JT when transitioning out of the _thread_blocked will call SafepointMechanism::process_if_requested() (in ~TBIVM/~TBIVMWDC/java_suspend_self_with_safepoint_check()), will go through process_if_requested_slow() to check if it needs to process some operation and at the end will execute a cross_modify_fence(). Patricio > Thanks, > David > >> Thanks, >> Patricio >> >> ------------- >> >> Commit messages: >> ? - v1 >> >> Changes: https://git.openjdk.java.net/jdk/pull/655/files >> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=655&range=00 >> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8254264 >> ?? Stats: 5 lines in 2 files changed: 0 ins; 5 del; 0 mod >> ?? Patch: https://git.openjdk.java.net/jdk/pull/655.diff >> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >> pull/655/head:pull/655 >> >> PR: https://git.openjdk.java.net/jdk/pull/655 >> From ccheung at openjdk.java.net Thu Oct 15 18:29:20 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 15 Oct 2020 18:29:20 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v7] In-Reply-To: References: Message-ID: > Following up on archiving lambda proxy classes in dynamic CDS archive > ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of > lambda proxy classes in static CDS archive. > When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved > during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will > be of the following format: > `@lambda-proxy: ` > > e.g. > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` > > When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above > `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool > indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool > entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index > and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. > During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not > found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> > IsCDSDumpingEnabled) is involved in the core-libs code.) > Testing: tiers 1,2,3,4. > > Performance results (javac on HelloWorld on linux-x64): > Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " > 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- > 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- > 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- > 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- > 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- > 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- > 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- > 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- > 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- > 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- > ============================================================ > 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- > instr delta = -161497801 -7.2542% > time delta = -24.722 ms -6.5951% Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'master' into 8247666 - Changes based on Ioi's suggestions: 1. Added the ClassListWriter class to make writing to a classlist file thread safe; 2. Changed API's in CDS.java to be more consistent with CDS.isDumpingClasslist. - fix minimal vm build issues - Merge branch 'master' into 8247666 - Merge branch 'master' into 8247666 - 1. Symbolic encoding of lambda proxy resolution. An example of @lambda-proxy in the classlist: @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambdabash ()V ()V 2. Removed BadCPIndex.java; added LambdaProxyClassList.java test. 3. Mandy's comments. - Merge branch 'master' into 8247666 - exclude archived lambda proxy classes in the classlist - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi - fix extraneous whitespace - ... and 1 more: https://git.openjdk.java.net/jdk/compare/546620bb...dfdf12ea ------------- Changes: https://git.openjdk.java.net/jdk/pull/364/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=06 Stats: 2006 lines in 38 files changed: 1876 ins; 66 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364 PR: https://git.openjdk.java.net/jdk/pull/364 From ccheung at openjdk.java.net Thu Oct 15 18:53:16 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 15 Oct 2020 18:53:16 GMT Subject: RFR: 8251325: Miss 'L' for long value in if statement Message-ID: A simple one-liner fix in DCmdStart.java. Testing: - tier1 - all tests under open/test/jdk/jdk/jfr locally on linux-x64 ------------- Commit messages: - 8251325 (initial commit) Changes: https://git.openjdk.java.net/jdk/pull/687/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=687&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251325 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/687.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/687/head:pull/687 PR: https://git.openjdk.java.net/jdk/pull/687 From coleenp at openjdk.java.net Thu Oct 15 19:03:18 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 15 Oct 2020 19:03:18 GMT Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 08:46:01 GMT, Robbin Ehn wrote: > SignalHandlerMark increase and decrease _num_nested_signal, but it is never read. > We have no caller to is_inside_signal_handler(). > > Testing T1. Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/677 From coleenp at openjdk.java.net Thu Oct 15 19:03:18 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 15 Oct 2020 19:03:18 GMT Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: <_fA8HMuQ-xJNHVtvfz_dQamhmNDF_YXdTjdRy_DXWYc=.9f377da4-148d-47c1-9e6f-b9db5040aedb@github.com> On Thu, 15 Oct 2020 17:32:34 GMT, Thomas Stuefe wrote: >> Changes requested by dholmes (Reviewer). > >> As much as I like seeing old code removed, wouldn't this be something that would be useful? Should Mutex::lock with >> safepoint check for instance check for this? > > Maybe. But as it is, beside being unused it is pretty inconsistent: only the main signal hndler uses this, not the > SR_handler nor the secondary error handler. So, Thread::_num_nested_signal would only ever be >1 if a second signal > happened right inside the signal handling but before fatal error handling kicks in, which as its first step installs > the secondary error handler. BTW one thing I wondered about is that all the JVM_handle_xxx_signal() functions return > an int; but we return anything out of {true, false, 0, 1.} And the return value is then ignored at the caller. For > example, the "abort_if_unrecognized" option does not seem to do anything - can probably be removed. So the code I was worried about is the code between JVM_handle_x_signal and calling report_and_die. There's a lot of duplicated code in JVM_handle_x_signal. I moved some of it but if we move more of it far away, it would be nice to know we aren't calling Thread::current() or some Mutex inside of the signal handler. That said, I'm ok with its deletion. ------------- PR: https://git.openjdk.java.net/jdk/pull/677 From iklam at openjdk.java.net Thu Oct 15 19:11:08 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 15 Oct 2020 19:11:08 GMT Subject: RFR: 8251325: Miss 'L' for long value in if statement In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 18:43:48 GMT, Calvin Cheung wrote: > A simple one-liner fix in DCmdStart.java. > > Testing: > > - tier1 > > - all tests under open/test/jdk/jdk/jfr locally on linux-x64 LGTM and a trivial fix. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/687 From ccheung at openjdk.java.net Thu Oct 15 20:05:09 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 15 Oct 2020 20:05:09 GMT Subject: RFR: 8251325: Miss 'L' for long value in if statement In-Reply-To: References: Message-ID: <7XBbU4iuJqdEUkXuGjhOoZTZXqI-c3Rd6T01ghsoiKg=.e951220a-83d8-491b-b370-bcb5c9741941@github.com> On Thu, 15 Oct 2020 19:08:16 GMT, Ioi Lam wrote: >> A simple one-liner fix in DCmdStart.java. >> >> Testing: >> >> - tier1 >> >> - all tests under open/test/jdk/jdk/jfr locally on linux-x64 > > LGTM and a trivial fix. @iklam Thanks for the quick review. ------------- PR: https://git.openjdk.java.net/jdk/pull/687 From ccheung at openjdk.java.net Thu Oct 15 20:08:18 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 15 Oct 2020 20:08:18 GMT Subject: Integrated: 8251325: Miss 'L' for long value in if statement In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 18:43:48 GMT, Calvin Cheung wrote: > A simple one-liner fix in DCmdStart.java. > > Testing: > > - tier1 > > - all tests under open/test/jdk/jdk/jfr locally on linux-x64 This pull request has now been integrated. Changeset: 96bb6e76 Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/96bb6e76 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8251325: Miss 'L' for long value in if statement Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/687 From redestad at openjdk.java.net Thu Oct 15 22:16:15 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 15 Oct 2020 22:16:15 GMT Subject: RFR: 8254855: Clean up and remove unused code in vmIntrinsics Message-ID: - Remove unused code and constants - Guard some code only used for assertions by ASSERT - Adjust log2_FLAG_LIMIT (could have been 3 also before removing F_RNY) Testing: tier1-3 ------------- Commit messages: - Merge branch 'master' into vmintrinsic_cleanup - vmIntrinsics.cpp: intrinsic_info can also be ASSERT-only - explicit endif - Clean-up and remove dead code from vmIntrinsics Changes: https://git.openjdk.java.net/jdk/pull/688/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=688&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254855 Stats: 124 lines in 2 files changed: 2 ins; 119 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/688.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/688/head:pull/688 PR: https://git.openjdk.java.net/jdk/pull/688 From dholmes at openjdk.java.net Thu Oct 15 22:24:14 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Oct 2020 22:24:14 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 13:47:18 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/synchronizer.cpp line 2949: >> >>> 2947: assert(Thread::current()->is_VM_thread(), "sanity check"); >>> 2948: >>> 2949: if (is_final_audit()) { // Only do the audit once. >> >> It seems impossible that you could ever call this twice. A simple file static flag for a debug build would be simpler >> if you just wanted to assert that. > > I modeled the make-sure-this-is-only-called-once logic on > exit_globals(). I originally implemented it as a static flag just > like exit_globals(). Is it necessary? I don't think so either, but > I'm guarding against future changes since the final audit > should only be done once. > > In the changeset that follows this one (JDK-8253064), this > is_final_audit() query function is needed to change some of > the logic that gets executed in the "final" audit. I backported > that bit to this bug fix so there was one less thing to review > in JDK-8253064. The final_audit flag seems overkill. If the audit code needs to know it is the final audit that could be passed as a parameter. The make-sure-this-is-only-called-once logic gives the false impression that it is entirely possible for this to be called more than once when that is not the case. We can only reach this code after the termination safepoint has been reached. A simple assert would be clearer IMO, but I don't insist on any changes here. >> src/hotspot/share/runtime/vmOperations.cpp line 458: >> >>> 456: // The ObjectMonitor subsystem uses perf counters so do this before >>> 457: // we call exit_globals() so we don't run afoul of perfMemory_exit(). >>> 458: ObjectSynchronizer::do_final_audit_and_print_stats(); >> >> Given this used to be done in the prolog, is there anything above this line that might interfere with it somehow? Or >> more simply put, why not do this first so that it is as close as possible to where it used to be? > > The async deflation request was made in `doit_prologue()` which > meant that the ServiceThread would eventually do the work, but > that was in a racy fashion which is what motivated this change. > > `exit_globals()` below used to make the call to `audit_and_print_stats()` > so we're actually doing that part a little bit earlier than before. The only > boundary condition that I've ever found in all of my testing was that the > audit needed to be done before the `perfMemory_exit()` call that's made > in `exit_globals()`. I have not seen any issues caused by the code that's > executed in `VM_Exit::doit()` before we get to the final audit. Thanks. I missed the fact that the old code was only an async deflation request. ------------- PR: https://git.openjdk.java.net/jdk/pull/641 From dholmes at openjdk.java.net Thu Oct 15 22:24:13 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Oct 2020 22:24:13 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: References: Message-ID: <7qbiyP_ohJ_E-ZtW7fbLmr8WtymzYCY9vd8NiEjw6Y4=.0bd7bcb1-8b95-4083-bb9b-29876de4066f@github.com> On Tue, 13 Oct 2020 20:31:16 GMT, Daniel D. Daugherty wrote: > 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/641 From dholmes at openjdk.java.net Thu Oct 15 23:00:15 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Oct 2020 23:00:15 GMT Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 13:18:33 GMT, Robbin Ehn wrote: >> src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp line 404: >> >>> 402: Thread* t = Thread::current_or_null_safe(); >>> 403: >>> 404: // Must do this before SignalHandlerMark, if crash protection installed we will longjmp away >> >> Should we keep a comment (and add to other files) to the effect that: >> >> // If crash protection is installed we will longjmp away and no destructors from any RAII utility >> // object would be run. So don't use any RAII utilities here. >> >> ? > > // If crash protection is installed we may longjmp away and no destructors > // for objects in this scope will be run. > // So don't use any RAII utilities before crash protection is checked. > > Since even if crash protection is installed it's not certain we will longjmp and you can trust destructors after we > checked crash protection. ? I'm not sure if only the call to `check_crash_protection` can trigger the long jump? If so then your version of the comment is better. ------------- PR: https://git.openjdk.java.net/jdk/pull/677 From kbarrett at openjdk.java.net Thu Oct 15 23:02:17 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 15 Oct 2020 23:02:17 GMT Subject: RFR: 8254855: Clean up and remove unused code in vmIntrinsics In-Reply-To: References: Message-ID: <02yBnm7ZUc0hnDtmdhO5oJQIpQEa-BnpB_awjbilvd0=.a62efb29-0b02-4ad8-964c-38ccc91934e1@github.com> On Thu, 15 Oct 2020 22:07:46 GMT, Claes Redestad wrote: > - Remove unused code and constants > - Guard some code only used for assertions by ASSERT > - Adjust log2_FLAG_LIMIT (could have been 3 also before removing F_RNY) > > Testing: tier1-3 Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/688 From dholmes at openjdk.java.net Thu Oct 15 23:06:09 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Oct 2020 23:06:09 GMT Subject: RFR: 8254855: Clean up and remove unused code in vmIntrinsics In-Reply-To: <02yBnm7ZUc0hnDtmdhO5oJQIpQEa-BnpB_awjbilvd0=.a62efb29-0b02-4ad8-964c-38ccc91934e1@github.com> References: <02yBnm7ZUc0hnDtmdhO5oJQIpQEa-BnpB_awjbilvd0=.a62efb29-0b02-4ad8-964c-38ccc91934e1@github.com> Message-ID: On Thu, 15 Oct 2020 22:58:58 GMT, Kim Barrett wrote: >> - Remove unused code and constants >> - Guard some code only used for assertions by ASSERT >> - Adjust log2_FLAG_LIMIT (could have been 3 also before removing F_RNY) >> >> Testing: tier1-3 > > Looks good. I don't agree with removing F_RNY just because we don't currently have intrinisics that match that shape! If someone were to add one then they would now have to repair the infrastructure code needed to support that. ------------- PR: https://git.openjdk.java.net/jdk/pull/688 From redestad at openjdk.java.net Thu Oct 15 23:28:12 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 15 Oct 2020 23:28:12 GMT Subject: RFR: 8254855: Clean up and remove unused code in vmIntrinsics In-Reply-To: References: <02yBnm7ZUc0hnDtmdhO5oJQIpQEa-BnpB_awjbilvd0=.a62efb29-0b02-4ad8-964c-38ccc91934e1@github.com> Message-ID: On Thu, 15 Oct 2020 23:03:07 GMT, David Holmes wrote: > I don't agree with removing F_RNY just because we don't currently have intrinisics that match that shape! If someone > were to add one then they would now have to repair the infrastructure code needed to support that. Several potentially useful permutations of static, native and synchronized are already missing, so I felt that removing a no longer used variant to be in the spirit of the existing code. I think the infrastructure is easy to repair if it's ever needed (at least easier than the act of adding an intrinsics), but if you feel strongly about it I'll add it back. ------------- PR: https://git.openjdk.java.net/jdk/pull/688 From iklam at openjdk.java.net Fri Oct 16 00:15:10 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 16 Oct 2020 00:15:10 GMT Subject: RFR: 8254855: Clean up and remove unused code in vmIntrinsics In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 22:07:46 GMT, Claes Redestad wrote: > - Remove unused code and constants > - Guard some code only used for assertions by ASSERT > - Adjust log2_FLAG_LIMIT (could have been 3 also before removing F_RNY) > > Testing: tier1-3 LGMT. I try to find the last time for_boxing() and verify_method() were used, and they weren't even used in JDK7! So we have been carrying around this junk for quite a while. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/688 From david.holmes at oracle.com Fri Oct 16 01:22:11 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Oct 2020 11:22:11 +1000 Subject: RFR: 8254855: Clean up and remove unused code in vmIntrinsics In-Reply-To: References: <02yBnm7ZUc0hnDtmdhO5oJQIpQEa-BnpB_awjbilvd0=.a62efb29-0b02-4ad8-964c-38ccc91934e1@github.com> Message-ID: On 16/10/2020 9:28 am, Claes Redestad wrote: > On Thu, 15 Oct 2020 23:03:07 GMT, David Holmes wrote: > >> I don't agree with removing F_RNY just because we don't currently have intrinisics that match that shape! If someone >> were to add one then they would now have to repair the infrastructure code needed to support that. > > Several potentially useful permutations of static, native and synchronized are already missing, so I felt that removing > a no longer used variant to be in the spirit of the existing code. I think the infrastructure is easy to repair if it's > ever needed (at least easier than the act of adding an intrinsics), but if you feel strongly about it I'll add it back. The flags do not define a simple set of permutations - that is part of the problem I have with removing one. It is unclear when you actually need to signify native or synchronized. So I think it would be unclear as to when you might need to add this back, and how to actually add it back. But I don't write intrinsics ... so why is this being reviewed by runtime rather the compiler folk who actually use this? :) Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/688 > From jiefu at openjdk.java.net Fri Oct 16 01:25:16 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 16 Oct 2020 01:25:16 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) [v3] In-Reply-To: References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> Message-ID: On Thu, 15 Oct 2020 06:27:29 GMT, Jie Fu wrote: >> Looks good. > > Thanks @kimbarrett for your review. > Will push it tomorrow if there is no objection. OK. May I get a second review for this change? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/496 From kvn at openjdk.java.net Fri Oct 16 01:54:09 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 16 Oct 2020 01:54:09 GMT Subject: RFR: 8254855: Clean up and remove unused code in vmIntrinsics In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 00:12:45 GMT, Ioi Lam wrote: >> - Remove unused code and constants >> - Guard some code only used for assertions by ASSERT >> - Adjust log2_FLAG_LIMIT (could have been 3 also before removing F_RNY) >> >> Testing: tier1-3 > > LGMT. I try to find the last time for_boxing() and verify_method() were used, and they weren't even used in JDK7! So > we have been carrying around this junk for quite a while. vmIntrinsics::verify_method() become unused after next change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/75596850f863 ------------- PR: https://git.openjdk.java.net/jdk/pull/688 From kvn at openjdk.java.net Fri Oct 16 02:16:12 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 16 Oct 2020 02:16:12 GMT Subject: RFR: 8254855: Clean up and remove unused code in vmIntrinsics In-Reply-To: References: Message-ID: <9V7oTBsDvyEv_VFIuS15qOvS9JVTVz8FfkMA-EssYz0=.ff3676eb-1f40-47c2-bc44-de9778391049@github.com> On Thu, 15 Oct 2020 22:07:46 GMT, Claes Redestad wrote: > - Remove unused code and constants > - Guard some code only used for assertions by ASSERT > - Adjust log2_FLAG_LIMIT (could have been 3 also before removing F_RNY) > > Testing: tier1-3 Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/688 From kvn at openjdk.java.net Fri Oct 16 02:16:14 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 16 Oct 2020 02:16:14 GMT Subject: RFR: 8254855: Clean up and remove unused code in vmIntrinsics In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 01:51:35 GMT, Vladimir Kozlov wrote: >> LGMT. I try to find the last time for_boxing() and verify_method() were used, and they weren't even used in JDK7! So >> we have been carrying around this junk for quite a while. > > vmIntrinsics::verify_method() become unused after next change: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/75596850f863 for_boxing() and for_unboxing() were added for JSR 292 reference implementation: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/aa62b9388fce and then removed when JSR 292 was rewritten: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1d7922586cf6?revcount=480 ------------- PR: https://git.openjdk.java.net/jdk/pull/688 From david.holmes at oracle.com Fri Oct 16 04:58:41 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Oct 2020 14:58:41 +1000 Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: <52eb400e-a9cb-3031-c24d-2e07a573cdd6@oracle.com> References: <8786e8a2-00ce-74f6-7a4b-eef708b6e848@oracle.com> <52eb400e-a9cb-3031-c24d-2e07a573cdd6@oracle.com> Message-ID: Hi Patricio, On 16/10/2020 4:09 am, Patricio Chilano wrote: > Hi David, > > On 10/15/20 5:22 AM, David Holmes wrote: >> Hi Patricio, >> >> On 15/10/2020 1:20 am, Patricio Chilano Mateo wrote: >>> Hi all, >>> >>> Please review the following patch that removes some uneeded uses of >>> cross_modify_fence() in common code, in particular >>> from ~ThreadBlockInVM(), ~ThreadBlockInVMWithDeadlockCheck() and >>> java_suspend_self_with_safepoint_check(). These fences >>> were added before each JavaThread had to disarm itself (8230594). >>> After a safepoint/handshake each JavaThread will >>> always call SafepointMechanism::process_if_requested_slow() when >>> transitioning out of the safe state and will execute a >>> cross_modify_fence(). Tested with mach5 tiers1-7. >> >> As you have already done the analysis, could you show the exact call >> sequences that allow for the removal of the code as described? I'm >> trying to verify what you've stated but trying to reverse engineer the >> calling sequences is painful. :) > So, before each JavaThread had to disarm itself you could have the > following sequence: > > - JT T creates ThreadBlockInVM object and then blocks (usually in > park()/wait()) > - VMThread arms T for a safepoint operation. Since T is in > _thread_blocked state it's safe so safepoint starts. > - Once safepoint operation is done VMThread disarms T > - T wakes up and executes ~ThreadBlockInVM(). Since the poll word/page > is not armed it just continues execution. If we didn't have that > cross_modify_fence() in ~ThreadBlockInVM() we can transition back to > java later without executing the fence instruction. And just to be clear any action that changes code such that a cross-modify-fence is needed by other threads, has to perform a global safepoint/handshake? > Same sequence with ~ThreadBlockInVMWithDeadlockCheck and > java_suspend_self_with_safepoint_check(). So when transitioning out of > the _thread_blocked state a JT wouldn't know if a safepoint happened so > we had that fence there unconditionally. > > Today disarming of the poll word/page is done by each JT, so if a > safepoint happened while the JT was blocked the poll word/page will > remain armed. The JT when transitioning out of the _thread_blocked will > call SafepointMechanism::process_if_requested() (in > ~TBIVM/~TBIVMWDC/java_suspend_self_with_safepoint_check()), will go > through process_if_requested_slow() to check if it needs to process some > operation and at the end will execute a cross_modify_fence(). Okay so ... ~ThreadBlockInVM() -> trans(_thread_blocked, _thread_in_vm); --> transition(...); ---> SafepointMechanism::process_if_requested(thread) -----> if (!local_poll_armed(thread)) { // <- It is armed return; } process_if_requested_slow(thread); => OK ~ThreadBlockInVMWithDeadlockCheck() -> if (SafepointMechanism::should_process(_thread)) { // True as poll armed release_mutex(); SafepointMechanism::process_if_requested(_thread); ------> if (!local_poll_armed(thread)) { // <- It is armed return; } process_if_requested_slow(thread); => OK JavaThread::java_suspend_self_with_safepoint_check() -> if (state != _thread_in_native) { SafepointMechanism::process_if_requested(this); => OK } Those cases are all good as you stated. So my only uncertainty now is the _thread_in_native case for suspension. But how can we be _thread_in_native at the time we call java_suspend_self_with_safepoint_check? When we call from check_safepoint_and_suspend_for_native_trans we are in _thread_in_native_trans. So that leaves handle_special_runtime_exit_condition, which is called from: - JavaCallWrapper::JavaCallWrapper - thread must be _thread_in_vm here - SafepointSynchronize::block - can't be _thread_in_native (fatal error) - ~ThreadInVMfromJava() - thread must be _thread_in_Java - ThreadToNativeFromVM - thread must be _thread_in_vm - ~ThreadInVMfromJavaNoAsyncException - thread must be _thread_in_vm So as far as I can see we can never be _thread_in_native when calling JavaThread::java_suspend_self_with_safepoint_check. So it seems I don't have to worry about that case after all :) (and in any case when leaving _thread_in_native we will call check_safepoint_and_suspend_for_native_trans so we'd get to the cross-modify-fence via that route.) So long story short: this all looks good to me. :) Thanks, David ----- > > Patricio >> Thanks, >> David >> >>> Thanks, >>> Patricio >>> >>> ------------- >>> >>> Commit messages: >>> ? - v1 >>> >>> Changes: https://git.openjdk.java.net/jdk/pull/655/files >>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=655&range=00 >>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8254264 >>> ?? Stats: 5 lines in 2 files changed: 0 ins; 5 del; 0 mod >>> ?? Patch: https://git.openjdk.java.net/jdk/pull/655.diff >>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >>> pull/655/head:pull/655 >>> >>> PR: https://git.openjdk.java.net/jdk/pull/655 >>> > From dholmes at openjdk.java.net Fri Oct 16 05:02:12 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 16 Oct 2020 05:02:12 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 14:25:14 GMT, Patricio Chilano Mateo wrote: > Hi all, > > Please review the following patch that removes some uneeded uses of cross_modify_fence() in common code, in particular > from ~ThreadBlockInVM(), ~ThreadBlockInVMWithDeadlockCheck() and java_suspend_self_with_safepoint_check(). These fences > were added before each JavaThread had to disarm itself (8230594). After a safepoint/handshake each JavaThread will > always call SafepointMechanism::process_if_requested_slow() when transitioning out of the safe state and will execute a > cross_modify_fence(). Tested with mach5 tiers1-7. Thanks, Patricio Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/655 From iklam at openjdk.java.net Fri Oct 16 05:18:32 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 16 Oct 2020 05:18:32 GMT Subject: RFR: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows [v4] In-Reply-To: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: > **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in > memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each > of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert > to fail. > > **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to > access each individual cloned vtable. > > **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just > do the bare minimum to fix the bug, it will be pretty hard to review. > > I would suggest that the reviewers look at just the new version of the code and see if it's working as described > (instead of looking at the diff to understand what the bug was and how it has been fixed). > This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. > I plan to change that into templates in a future RFE. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into 8254125-cppvtables-assert-on-win32 - Merge branch 'master' of https://github.com/openjdk/jdk into 8254125-cppvtables-assert-on-win32 - Fixed more cases with align_up(xxx, SharedSpaceObjectAlignment) - Merge branch 'master' into 8254125-cppvtables-assert-on-win32 - 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/591/files - new: https://git.openjdk.java.net/jdk/pull/591/files/5002b820..9261bfb1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=591&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=591&range=02-03 Stats: 302206 lines in 574 files changed: 296331 ins; 3612 del; 2263 mod Patch: https://git.openjdk.java.net/jdk/pull/591.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/591/head:pull/591 PR: https://git.openjdk.java.net/jdk/pull/591 From iklam at openjdk.java.net Fri Oct 16 05:18:33 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 16 Oct 2020 05:18:33 GMT Subject: Integrated: 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows In-Reply-To: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> References: <91M1KEgkLHc8IDjjJHBNWQmBVHqJE84bX1_1yt1sv40=.e2fa767d-aea4-448b-a0db-5df679ce456f@github.com> Message-ID: <8KNbTYSEgII2zIqwF7TKHP6cPq2h-qsva6NfGcqtrv0=.3924d3f7-f5b0-4603-aac2-b4698955b631@github.com> On Sun, 11 Oct 2020 04:04:56 GMT, Ioi Lam wrote: > **Problem:** when iterating over the cloned vtables, the original code assumes that they are laid out consecutively in > memory. However, since [JDK-8224509](https://bugs.openjdk.java.net/browse/JDK-8224509), the memory allocated for each > of the the cloned vtables is now 8-byte aligned. This introduces gaps between the cloned vtables, and causes the assert > to fail. > > **Fix:** the fix is to no longer assume the consecutive memory layout. Instead, use the CppVtables::_index array to > access each individual cloned vtable. > > **Note:** I also cleaned up the code significantly. I feel the original code is pretty hard to understand, so if I just > do the bare minimum to fix the bug, it will be pretty hard to review. > > I would suggest that the reviewers look at just the new version of the code and see if it's working as described > (instead of looking at the diff to understand what the bug was and how it has been fixed). > This version still uses the x-macro CPP_VTABLE_TYPES_DO to enumerate over the classes whose vtables need to be cloned. > I plan to change that into templates in a future RFE. This pull request has now been integrated. Changeset: 5145bed0 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/5145bed0 Stats: 172 lines in 11 files changed: 33 ins; 63 del; 76 mod 8254125: Assertion in cppVtables.cpp during builds on 32bit Windows Reviewed-by: shade, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/591 From rehn at openjdk.java.net Fri Oct 16 07:01:18 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 16 Oct 2020 07:01:18 GMT Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 22:54:15 GMT, David Holmes wrote: >> // If crash protection is installed we may longjmp away and no destructors >> // for objects in this scope will be run. >> // So don't use any RAII utilities before crash protection is checked. >> >> Since even if crash protection is installed it's not certain we will longjmp and you can trust destructors after we >> checked crash protection. ? > > I'm not sure if only the call to `check_crash_protection` can trigger the long jump? If so then your version of the > comment is better. Yes only check_crash_protection() do the longjmp and only if it's the protected thread and on SIGSEGV/SIGBUS. ------------- PR: https://git.openjdk.java.net/jdk/pull/677 From stuefe at openjdk.java.net Fri Oct 16 07:11:14 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 16 Oct 2020 07:11:14 GMT Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 19:00:03 GMT, Coleen Phillimore wrote: >> SignalHandlerMark increase and decrease _num_nested_signal, but it is never read. >> We have no caller to is_inside_signal_handler(). >> >> Testing T1. > > Marked as reviewed by coleenp (Reviewer). > So the code I was worried about is the code between JVM_handle_x_signal and calling report_and_die. There's a lot of > duplicated code in JVM_handle_x_signal. I moved some of it but if we move more of it far away, it would be nice to know > we aren't calling Thread::current() or some Mutex inside of the signal handler. That said, I'm ok with its deletion. I see your point now, I agree with you that it could be useful information. But its very easy to re-introduce if we want. We don't even need a RAII object, we could just increase the signal nesting level in javaSignalHandler() directly. ------------- PR: https://git.openjdk.java.net/jdk/pull/677 From rehn at openjdk.java.net Fri Oct 16 08:05:16 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 16 Oct 2020 08:05:16 GMT Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 07:08:20 GMT, Thomas Stuefe wrote: > > So the code I was worried about is the code between JVM_handle_x_signal and calling report_and_die. There's a lot of > > duplicated code in JVM_handle_x_signal. I moved some of it but if we move more of it far away, it would be nice to know > > we aren't calling Thread::current() or some Mutex inside of the signal handler. That said, I'm ok with its deletion. > > I see your point now, I agree with you that it could be useful information. But its very easy to re-introduce if we > want. We don't even need a RAII object, we could just increase the signal nesting level in javaSignalHandler() directly. If you execute any code which takes a Mutex you risk deadlocking, since they are not recursive and pthread_mutex is not signal safe. (if they were you risk that the data they are protecting are inconsistent when reading it from signal handler any ways) Any code path not carefully review should be considered unsafe to potentially re-enter from signal handler. We also on purpose call code which is not signal safe, e.g. vfprintf is not signal safe, thus any code that can log is not safe AFAICT. So just one check in one specific case is not that useful and since we do call unsafe code intentionally the rules are very fuzzy. ------------- PR: https://git.openjdk.java.net/jdk/pull/677 From rehn at openjdk.java.net Fri Oct 16 08:13:28 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 16 Oct 2020 08:13:28 GMT Subject: RFR: 8254824: SignalHandlerMark have no purpose [v2] In-Reply-To: References: Message-ID: > SignalHandlerMark increase and decrease _num_nested_signal, but it is never read. > We have no caller to is_inside_signal_handler(). > > Testing T1. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Added comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/677/files - new: https://git.openjdk.java.net/jdk/pull/677/files/b1151e83..54a11043 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=677&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=677&range=00-01 Stats: 15 lines in 5 files changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/677.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/677/head:pull/677 PR: https://git.openjdk.java.net/jdk/pull/677 From redestad at openjdk.java.net Fri Oct 16 11:42:08 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 16 Oct 2020 11:42:08 GMT Subject: RFR: 8254855: Clean up and remove unused code in vmIntrinsics In-Reply-To: <9V7oTBsDvyEv_VFIuS15qOvS9JVTVz8FfkMA-EssYz0=.ff3676eb-1f40-47c2-bc44-de9778391049@github.com> References: <9V7oTBsDvyEv_VFIuS15qOvS9JVTVz8FfkMA-EssYz0=.ff3676eb-1f40-47c2-bc44-de9778391049@github.com> Message-ID: <8Z3HcXkqsU67-i3kls7Wet9r8TJWcr-MHee8tWIfezM=.6f6379a4-0633-4f58-96f6-3b264db8da22@github.com> On Fri, 16 Oct 2020 02:13:37 GMT, Vladimir Kozlov wrote: >> - Remove unused code and constants >> - Guard some code only used for assertions by ASSERT >> - Adjust log2_FLAG_LIMIT (could have been 3 also before removing F_RNY) >> >> Testing: tier1-3 > > Marked as reviewed by kvn (Reviewer). Thanks for reviewing - and digging up the history on when these went out of fashion. The JSR 292 rewrite also removed the concept of ricochetStubs. Getting rid of some remnants of that is another cleanup I have lined up. ------------- PR: https://git.openjdk.java.net/jdk/pull/688 From redestad at openjdk.java.net Fri Oct 16 11:42:09 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 16 Oct 2020 11:42:09 GMT Subject: Integrated: 8254855: Clean up and remove unused code in vmIntrinsics In-Reply-To: References: Message-ID: On Thu, 15 Oct 2020 22:07:46 GMT, Claes Redestad wrote: > - Remove unused code and constants > - Guard some code only used for assertions by ASSERT > - Adjust log2_FLAG_LIMIT (could have been 3 also before removing F_RNY) > > Testing: tier1-3 This pull request has now been integrated. Changeset: 0570cc10 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/0570cc10 Stats: 124 lines in 2 files changed: 2 ins; 119 del; 3 mod 8254855: Clean up and remove unused code in vmIntrinsics Reviewed-by: kbarrett, iklam, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/688 From dcubed at openjdk.java.net Fri Oct 16 15:05:09 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 16 Oct 2020 15:05:09 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: <7qbiyP_ohJ_E-ZtW7fbLmr8WtymzYCY9vd8NiEjw6Y4=.0bd7bcb1-8b95-4083-bb9b-29876de4066f@github.com> References: <7qbiyP_ohJ_E-ZtW7fbLmr8WtymzYCY9vd8NiEjw6Y4=.0bd7bcb1-8b95-4083-bb9b-29876de4066f@github.com> Message-ID: On Thu, 15 Oct 2020 22:21:52 GMT, David Holmes wrote: >> 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 > > Marked as reviewed by dholmes (Reviewer). @dholmes-ora - Thanks for the review and thanks for not insisting on changes to the final_audit flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/641 From dcubed at openjdk.java.net Fri Oct 16 15:19:19 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 16 Oct 2020 15:19:19 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: References: <7qbiyP_ohJ_E-ZtW7fbLmr8WtymzYCY9vd8NiEjw6Y4=.0bd7bcb1-8b95-4083-bb9b-29876de4066f@github.com> Message-ID: On Fri, 16 Oct 2020 15:02:37 GMT, Daniel D. Daugherty wrote: >> Marked as reviewed by dholmes (Reviewer). > > @dholmes-ora - Thanks for the review and thanks for not > insisting on changes to the final_audit flag. @fisk - Please review this when you get a chance since this is an extraction for your ObjectMonitor list cleanup and TSM removal work (https://bugs.openjdk.java.net/browse/JDK-8253064). ------------- PR: https://git.openjdk.java.net/jdk/pull/641 From patricio.chilano.mateo at oracle.com Fri Oct 16 18:33:17 2020 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Fri, 16 Oct 2020 15:33:17 -0300 Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: <8786e8a2-00ce-74f6-7a4b-eef708b6e848@oracle.com> <52eb400e-a9cb-3031-c24d-2e07a573cdd6@oracle.com> Message-ID: Hi David, On 10/16/20 1:58 AM, David Holmes wrote: > Hi Patricio, > > On 16/10/2020 4:09 am, Patricio Chilano wrote: >> Hi David, >> >> On 10/15/20 5:22 AM, David Holmes wrote: >>> Hi Patricio, >>> >>> On 15/10/2020 1:20 am, Patricio Chilano Mateo wrote: >>>> Hi all, >>>> >>>> Please review the following patch that removes some uneeded uses of >>>> cross_modify_fence() in common code, in particular >>>> from ~ThreadBlockInVM(), ~ThreadBlockInVMWithDeadlockCheck() and >>>> java_suspend_self_with_safepoint_check(). These fences >>>> were added before each JavaThread had to disarm itself (8230594). >>>> After a safepoint/handshake each JavaThread will >>>> always call SafepointMechanism::process_if_requested_slow() when >>>> transitioning out of the safe state and will execute a >>>> cross_modify_fence(). Tested with mach5 tiers1-7. >>> >>> As you have already done the analysis, could you show the exact call >>> sequences that allow for the removal of the code as described? I'm >>> trying to verify what you've stated but trying to reverse engineer >>> the calling sequences is painful. :) >> So, before each JavaThread had to disarm itself you could have the >> following sequence: >> >> - JT T creates ThreadBlockInVM object and then blocks (usually in >> park()/wait()) >> - VMThread arms T for a safepoint operation. Since T is in >> _thread_blocked state it's safe so safepoint starts. >> - Once safepoint operation is done VMThread disarms T >> - T wakes up and executes ~ThreadBlockInVM(). Since the poll >> word/page is not armed it just continues execution. If we didn't have >> that cross_modify_fence() in ~ThreadBlockInVM() we can transition >> back to java later without executing the fence instruction. > > And just to be clear any action that changes code such that a > cross-modify-fence is needed by other threads, has to perform a global > safepoint/handshake? I'm not sure of that. But we added these fences for the case where the code got patched during a safepoint. Maybe Robbin knows the answer.? : ) >> Same sequence with ~ThreadBlockInVMWithDeadlockCheck and >> java_suspend_self_with_safepoint_check(). So when transitioning out >> of the _thread_blocked state a JT wouldn't know if a safepoint >> happened so we had that fence there unconditionally. >> >> Today disarming of the poll word/page is done by each JT, so if a >> safepoint happened while the JT was blocked the poll word/page will >> remain armed. The JT when transitioning out of the _thread_blocked >> will call SafepointMechanism::process_if_requested() (in >> ~TBIVM/~TBIVMWDC/java_suspend_self_with_safepoint_check()), will go >> through process_if_requested_slow() to check if it needs to process >> some operation and at the end will execute a cross_modify_fence(). > > Okay so ... > > ~ThreadBlockInVM() > -> trans(_thread_blocked, _thread_in_vm); > --> transition(...); > ---> SafepointMechanism::process_if_requested(thread) > -----> if (!local_poll_armed(thread)) { // <- It is armed > ???????? return; > ?????? } > ?????? process_if_requested_slow(thread); => OK > > > ~ThreadBlockInVMWithDeadlockCheck() > -> if (SafepointMechanism::should_process(_thread)) {? // True as poll > armed > ???? release_mutex(); > ???? SafepointMechanism::process_if_requested(_thread); > ------> if (!local_poll_armed(thread)) { // <- It is armed > ????????? return; > ??????? } > ??????? process_if_requested_slow(thread); => OK > > JavaThread::java_suspend_self_with_safepoint_check() > -> if (state != _thread_in_native) { > ??? SafepointMechanism::process_if_requested(this); => OK > ? } > > Those cases are all good as you stated. > > So my only uncertainty now is the _thread_in_native case for > suspension. But how can we be _thread_in_native at the time we call > java_suspend_self_with_safepoint_check? When we call from > check_safepoint_and_suspend_for_native_trans we are in > _thread_in_native_trans. So that leaves > handle_special_runtime_exit_condition, which is called from: > > - JavaCallWrapper::JavaCallWrapper > ? - thread must be _thread_in_vm here > > - SafepointSynchronize::block > ? - can't be _thread_in_native (fatal error) > > - ~ThreadInVMfromJava() > ?- thread must be _thread_in_Java > > - ThreadToNativeFromVM > ? - thread must be _thread_in_vm > > - ~ThreadInVMfromJavaNoAsyncException > ? - thread must be _thread_in_vm > > So as far as I can see we can never be _thread_in_native when calling > JavaThread::java_suspend_self_with_safepoint_check. Only with ThreadToNativeFromVM, because we switch to native and then call has_special_runtime_exit_condition(). Which by the way, I don't see why we need to make that call since we are going from vm->native. We don't deliver async exceptions and we don't need to check for suspend since we are going to native. If we remove that call we can remove that conditional in java_suspend_self_with_safepoint_check() and always call SafepointMechanism::process_if_requested(). > So it seems I don't have to worry about that case after all :) (and in > any case when leaving _thread_in_native we will call > check_safepoint_and_suspend_for_native_trans so we'd get to the > cross-modify-fence via that route.) Exactly. > \So long story short: this all looks good to me. :) Thanks David! Patricio > Thanks, > David > ----- > > > >> >> Patricio >>> Thanks, >>> David >>> >>>> Thanks, >>>> Patricio >>>> >>>> ------------- >>>> >>>> Commit messages: >>>> ? - v1 >>>> >>>> Changes: https://git.openjdk.java.net/jdk/pull/655/files >>>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=655&range=00 >>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8254264 >>>> ?? Stats: 5 lines in 2 files changed: 0 ins; 5 del; 0 mod >>>> ?? Patch: https://git.openjdk.java.net/jdk/pull/655.diff >>>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >>>> pull/655/head:pull/655 >>>> >>>> PR: https://git.openjdk.java.net/jdk/pull/655 >>>> >> From akozlov at openjdk.java.net Fri Oct 16 19:59:22 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 16 Oct 2020 19:59:22 GMT Subject: RFR: 8254940: AArch64: Cleanup non-product thread members Message-ID: <6GrxMCF3U9N1D2QGrZNCYD55Zw8tT24uccZcwnxHxn4=.eb9e0b8d-7976-470a-8e1f-361b2d130d56@github.com> Please review a very small clean up that deletes unused thread members in linux/aarch64 and windows/aarch64 Testing: grep, linux/aarch64 fastdebug build ------------- Commit messages: - Remove usused thread members Changes: https://git.openjdk.java.net/jdk/pull/708/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=708&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254940 Stats: 19 lines in 2 files changed: 0 ins; 19 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/708.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/708/head:pull/708 PR: https://git.openjdk.java.net/jdk/pull/708 From rehn at openjdk.java.net Fri Oct 16 20:13:11 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 16 Oct 2020 20:13:11 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 04:59:08 GMT, David Holmes wrote: >> Hi all, >> >> Please review the following patch that removes some uneeded uses of cross_modify_fence() in common code, in particular >> from ~ThreadBlockInVM(), ~ThreadBlockInVMWithDeadlockCheck() and java_suspend_self_with_safepoint_check(). These fences >> were added before each JavaThread had to disarm itself (8230594). After a safepoint/handshake each JavaThread will >> always call SafepointMechanism::process_if_requested_slow() when transitioning out of the safe state and will execute a >> cross_modify_fence(). Tested with mach5 tiers1-7. Thanks, Patricio > > Marked as reviewed by dholmes (Reviewer). > > And just to be clear any action that changes code such that a > > cross-modify-fence is needed by other threads, has to perform a global > > safepoint/handshake? > > I'm not sure of that. But we added these fences for the case where the > code got patched during a safepoint. Maybe Robbin knows the answer.? : ) On x86 we have two complaint option according to the manual: (* OPTION 1 *) Store modified code (as data) into code segment; Jump to new code or an intermediate location; Execute new code; (* OPTION 2 *) Store modified code (as data) into code segment; Execute a serializing instruction; (* For example, CPUID instruction *) Execute new code; - Code patching that happens outside a safepoint do options 1 and don't need CMF. If CMF is needed on some arch, it must be encoded into the instruction stream while patching. (whether this is really safe, thinking of spectre, is another story :) ) See e.g. NativeGeneralJump::replace_mt_safe() - Code patching that happens inside a safepoint do options 2 and need CMF. We actual only need CMF for safepoints, but since we do not know why we were armed we must emit it. So can be optimize by keeping track of the safepoint id and for which safepoint id we have emitted CMF for per java thread. ------------- PR: https://git.openjdk.java.net/jdk/pull/655 From ccheung at openjdk.java.net Fri Oct 16 21:01:23 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 16 Oct 2020 21:01:23 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v8] In-Reply-To: References: Message-ID: <0tMvEbzMqsT5-oHGdGcPKLX-bWPJwwypq7wmRmIwzE4=.450e762e-ca0e-4227-b3cc-c76cac88b3be@github.com> > Following up on archiving lambda proxy classes in dynamic CDS archive > ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of > lambda proxy classes in static CDS archive. > When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved > during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will > be of the following format: > `@lambda-proxy: ` > > e.g. > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` > > When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above > `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool > indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool > entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index > and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. > During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not > found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> > IsCDSDumpingEnabled) is involved in the core-libs code.) > Testing: tiers 1,2,3,4. > > Performance results (javac on HelloWorld on linux-x64): > Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " > 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- > 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- > 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- > 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- > 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- > 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- > 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- > 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- > 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- > 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- > ============================================================ > 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- > instr delta = -161497801 -7.2542% > time delta = -24.722 ms -6.5951% Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: 1. Add some comment at the beginning of a classlist. 2. Enclose some debug statements with DEBUG_ONLY. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/364/files - new: https://git.openjdk.java.net/jdk/pull/364/files/dfdf12ea..dd6d440b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=06-07 Stats: 26 lines in 2 files changed: 11 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364 PR: https://git.openjdk.java.net/jdk/pull/364 From mchung at openjdk.java.net Fri Oct 16 21:28:10 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 16 Oct 2020 21:28:10 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v5] In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 16:24:47 GMT, Calvin Cheung wrote: >>> `@lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambda$main$0 ()V ()V` >> >> Can you explain the format? > > `@lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V REF_invokeStatic LambHello lambda$main$0 ()V ()V` > means > `@lambda-proxy ? ? > ` > It is a symbolic representation of a invoke dynamic constant pool entry. > public class LambHello { > public static void main(String[] args) { > doit(() -> { > System.out.println("Hello from Lambda"); > }); > } > static void doit(Runnable t) { > t.run(); > } > } > > An invoke dynamic constant pool of the above program is: > ` - 7 : InvokeDynamic : bootstrap_method_index=43 name_and_type_index=8 arguments={50, 51, 50}` > Other constant pool entries related to the above are: > - 8 : NameAndType : name_index=9 signature_index=10 > - 9 : Utf8 : 'run' > - 10 : Utf8 : '()Ljava/lang/Runnable;' > > - 50 : MethodType : signature_index=6 > - 51 : MethodHandle : ref_kind=6 ref_index=52 > - 52 : Method : klass_index=12 name_and_type_index=53 > - 53 : NameAndType : name_index=39 signature_index=6 > > - 6 : Utf8 : '()V' > - 12 : Class : 'LambHello' {0x0000000800c10040} > - 39 : Utf8 : 'lambda$main$0' > The info included in the class list are: > = LambHello > = run > = ()Ljava/lang/Runnable; > = ()V > = REF_invokeStatic > = LambHello > = lambda$main$0 > = ()V > = ()V Since the class list file is not intended for users to edit/modify but rather a configuration file given when -Xshare:dump is used, the format of `@lambda-proxy` entry is internal implementation details and so it's fine. BTW: for the method handle reference kind, does the entry have the value (e.g. 6) or the name ("REF_invokeStatic")? I see both formats are described in your different replies. > @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambda$main$0 ()V ()V or > @lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V REF_invokeStatic LambHello lambda$main$0 ()V ()V ------------- PR: https://git.openjdk.java.net/jdk/pull/364 From dholmes at openjdk.java.net Fri Oct 16 21:33:09 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 16 Oct 2020 21:33:09 GMT Subject: RFR: 8254824: SignalHandlerMark have no purpose [v2] In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 08:13:28 GMT, Robbin Ehn wrote: >> SignalHandlerMark increase and decrease _num_nested_signal, but it is never read. >> We have no caller to is_inside_signal_handler(). >> >> Testing T1. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Added comments Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/677 From ccheung at openjdk.java.net Fri Oct 16 21:36:16 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 16 Oct 2020 21:36:16 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v5] In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 21:25:04 GMT, Mandy Chung wrote: >> `@lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V REF_invokeStatic LambHello lambda$main$0 ()V ()V` >> means >> `@lambda-proxy ? ? >> ` >> It is a symbolic representation of a invoke dynamic constant pool entry. >> public class LambHello { >> public static void main(String[] args) { >> doit(() -> { >> System.out.println("Hello from Lambda"); >> }); >> } >> static void doit(Runnable t) { >> t.run(); >> } >> } >> >> An invoke dynamic constant pool of the above program is: >> ` - 7 : InvokeDynamic : bootstrap_method_index=43 name_and_type_index=8 arguments={50, 51, 50}` >> Other constant pool entries related to the above are: >> - 8 : NameAndType : name_index=9 signature_index=10 >> - 9 : Utf8 : 'run' >> - 10 : Utf8 : '()Ljava/lang/Runnable;' >> >> - 50 : MethodType : signature_index=6 >> - 51 : MethodHandle : ref_kind=6 ref_index=52 >> - 52 : Method : klass_index=12 name_and_type_index=53 >> - 53 : NameAndType : name_index=39 signature_index=6 >> >> - 6 : Utf8 : '()V' >> - 12 : Class : 'LambHello' {0x0000000800c10040} >> - 39 : Utf8 : 'lambda$main$0' >> The info included in the class list are: >> = LambHello >> = run >> = ()Ljava/lang/Runnable; >> = ()V >> = REF_invokeStatic >> = LambHello >> = lambda$main$0 >> = ()V >> = ()V > > Since the class list file is not intended for users to edit/modify but rather a configuration file given > when -Xshare:dump is used, the format of `@lambda-proxy` entry is internal implementation details and so it's fine. > BTW: for the method handle reference kind, does the entry have the value (e.g. 6) or the name ("REF_invokeStatic")? > I see both formats are described in your different replies. >> @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambda$main$0 ()V ()V > or >> @lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V REF_invokeStatic LambHello lambda$main$0 ()V ()V For the reference kind, the first format (with number '6') will be stored in the classlist. ------------- PR: https://git.openjdk.java.net/jdk/pull/364 From andrew at openjdk.java.net Sat Oct 17 02:51:10 2020 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Sat, 17 Oct 2020 02:51:10 GMT Subject: RFR: 8254144: Non-x86 Zero builds fail with return-type warning in os_linux_zero.cpp [v3] In-Reply-To: References: Message-ID: On Wed, 7 Oct 2020 11:38:51 GMT, Zhengyu Gu wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since >> the last revision: >> - Merge branch 'master' into JDK-8254144-zero-non-x86-return >> - Use the common style for compiler silencing comments >> - 8254144: Non-x86 Zero builds fail with return-type warning in os_linux_zero.cpp > > Looks good and trivial This is JDK-8199973. https://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/ce3abb5889fb Your patch misses the same case in *BSD. ------------- PR: https://git.openjdk.java.net/jdk/pull/539 From aph at openjdk.java.net Sat Oct 17 10:42:09 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Sat, 17 Oct 2020 10:42:09 GMT Subject: RFR: 8254940: AArch64: Cleanup non-product thread members In-Reply-To: <6GrxMCF3U9N1D2QGrZNCYD55Zw8tT24uccZcwnxHxn4=.eb9e0b8d-7976-470a-8e1f-361b2d130d56@github.com> References: <6GrxMCF3U9N1D2QGrZNCYD55Zw8tT24uccZcwnxHxn4=.eb9e0b8d-7976-470a-8e1f-361b2d130d56@github.com> Message-ID: On Fri, 16 Oct 2020 19:49:41 GMT, Anton Kozlov wrote: > Please review a very small clean up that deletes unused thread members in linux/aarch64 and windows/aarch64 > > Testing: grep, linux/aarch64 fastdebug build Removes some left-over debugging code. Change looks good. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/708 From stuefe at openjdk.java.net Sat Oct 17 16:46:27 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 17 Oct 2020 16:46:27 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v17] In-Reply-To: References: Message-ID: > Hi all, > > this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the > delay, had vacation then the entrance of Skara delayed things a bit. > For the delta diff please see [3]. > > This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all > feedback individually in this PR body, but I incorporated almost all into the new revision. > What changed since the last version: > > - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the > group consent. > > - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for > overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth > class loader which made it rather pointless. Now I run it always. > > - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. > > - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) > > Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. > > - In ChunkManager::purge() I improved the comments after discussions with Leo. > > - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due > to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run > every time. > > - Fixed indentation issues as Leo requested > > - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested > > - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes > and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more > flexible since it allows us to have list with purge-able and non-purge-able nodes. > > - and various smaller fixes, mainly on request of Leo. > > @lkorinth: > >> VirtualSpaceNode.hpp >> >>102 // Start pointer of the area. >>103 MetaWord* const _base; >> >>How does this differ from _rs._base? Really needed? >> >>105 // Size, in words, of the whole node >>106 const size_t _word_size; >> >>Can we not calculate this from _rs.size()? > > You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it > is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly > improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at > some point and make those members const - as they should be - then I would rewrite this as you suggest. > Thanks, again, for all your review work! > > ------ > > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html > [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: - Small include file correction - Merge - Merge - Merge - Richard feedback 3 - Add ASCII art to better describe Metachunk relationship to their payload - Fix retrieval from FreeChunkList; add test; update comments - Loosen unnecessarily strict restriction of allowed chunk states on ChunkManager::return_chunk - Assert that in reclaim=none mode new chunks are fully committed - Review Feedback Richard 2 - ... and 18 more: https://git.openjdk.java.net/jdk/compare/0b3e6c51...973e7aae ------------- Changes: https://git.openjdk.java.net/jdk/pull/336/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=16 Stats: 23023 lines in 174 files changed: 14779 ins; 7020 del; 1224 mod Patch: https://git.openjdk.java.net/jdk/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/336/head:pull/336 PR: https://git.openjdk.java.net/jdk/pull/336 From vromero at openjdk.java.net Sun Oct 18 16:12:22 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 18 Oct 2020 16:12:22 GMT Subject: RFR: 8246774: implement Record Classes as a standard feature in Java [v12] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 8246774: implement Record Classes as a standard feature in Java Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'master' into JDK-8246774 - Merge branch 'master' into JDK-8246774 - removing unused jcod file - remove unnecessary jtreg tags from tests, remove othervm etc when applicable - adding missing changes to some tests - modifiying @since from 14 to 16 - Remove preview args from ObjectMethodsTest - Remove preview args from record serialization tests - removing the javax.lang.model related code to be moved to a separate bug - 8246774: Record Classes (final) implementation Co-authored-by: Vicente Romero Co-authored-by: Harold Seigel Co-authored-by: Jonathan Gibbons Co-authored-by: Brian Goetz Co-authored-by: Maurizio Cimadamore Co-authored-by: Joe Darcy Co-authored-by: Chris Hegarty Co-authored-by: Jan Lahoda ------------- Changes: https://git.openjdk.java.net/jdk/pull/290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=11 Stats: 856 lines in 109 files changed: 72 ins; 562 del; 222 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Sun Oct 18 16:40:31 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 18 Oct 2020 16:40:31 GMT Subject: RFR: 8246774: implement Record Classes as a standard feature in Java [v13] In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: > 8246774: implement Record Classes as a standard feature in Java Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: removing reference to unused jcod file from test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/290/files - new: https://git.openjdk.java.net/jdk/pull/290/files/5bfbde59..3e472bc3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=11-12 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290 PR: https://git.openjdk.java.net/jdk/pull/290 From vromero at openjdk.java.net Sun Oct 18 18:58:16 2020 From: vromero at openjdk.java.net (Vicente Romero) Date: Sun, 18 Oct 2020 18:58:16 GMT Subject: Integrated: 8246774: implement Record Classes as a standard feature in Java In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com> Message-ID: On Mon, 21 Sep 2020 21:30:51 GMT, Vicente Romero wrote: > 8246774: implement Record Classes as a standard feature in Java This pull request has now been integrated. Changeset: c17d5851 Author: Vicente Romero URL: https://git.openjdk.java.net/jdk/commit/c17d5851 Stats: 856 lines in 109 files changed: 72 ins; 562 del; 222 mod 8246774: implement Record Classes as a standard feature in Java Co-authored-by: Vicente Romero Co-authored-by: Harold Seigel Co-authored-by: Chris Hegarty Reviewed-by: coleenp, jlahoda, sspitsyn, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/290 From david.holmes at oracle.com Sun Oct 18 22:13:45 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 19 Oct 2020 08:13:45 +1000 Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: <8786e8a2-00ce-74f6-7a4b-eef708b6e848@oracle.com> <52eb400e-a9cb-3031-c24d-2e07a573cdd6@oracle.com> Message-ID: On 17/10/2020 4:33 am, Patricio Chilano wrote: > On 10/16/20 1:58 AM, David Holmes wrote: >> So my only uncertainty now is the _thread_in_native case for >> suspension. But how can we be _thread_in_native at the time we call >> java_suspend_self_with_safepoint_check? When we call from >> check_safepoint_and_suspend_for_native_trans we are in >> _thread_in_native_trans. So that leaves >> handle_special_runtime_exit_condition, which is called from: >> >> - JavaCallWrapper::JavaCallWrapper >> ? - thread must be _thread_in_vm here >> >> - SafepointSynchronize::block >> ? - can't be _thread_in_native (fatal error) >> >> - ~ThreadInVMfromJava() >> ?- thread must be _thread_in_Java >> >> - ThreadToNativeFromVM >> ? - thread must be _thread_in_vm >> >> - ~ThreadInVMfromJavaNoAsyncException >> ? - thread must be _thread_in_vm >> >> So as far as I can see we can never be _thread_in_native when calling >> JavaThread::java_suspend_self_with_safepoint_check. > Only with ThreadToNativeFromVM, because we switch to native and then > call has_special_runtime_exit_condition(). Doh! Yes that was a silly oversight on my part. Thanks, David ----- Which by the way, I don't see > why we need to make that call since we are going from vm->native. We > don't deliver async exceptions and we don't need to check for suspend > since we are going to native. If we remove that call we can remove that > conditional in java_suspend_self_with_safepoint_check() and always call > SafepointMechanism::process_if_requested(). > >> So it seems I don't have to worry about that case after all :) (and in >> any case when leaving _thread_in_native we will call >> check_safepoint_and_suspend_for_native_trans so we'd get to the >> cross-modify-fence via that route.) > Exactly. > >> \So long story short: this all looks good to me. :) > Thanks David! > > > Patricio >> Thanks, >> David >> ----- >> >> >> >>> >>> Patricio >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Patricio >>>>> >>>>> ------------- >>>>> >>>>> Commit messages: >>>>> ? - v1 >>>>> >>>>> Changes: https://git.openjdk.java.net/jdk/pull/655/files >>>>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=655&range=00 >>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8254264 >>>>> ?? Stats: 5 lines in 2 files changed: 0 ins; 5 del; 0 mod >>>>> ?? Patch: https://git.openjdk.java.net/jdk/pull/655.diff >>>>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk >>>>> pull/655/head:pull/655 >>>>> >>>>> PR: https://git.openjdk.java.net/jdk/pull/655 >>>>> >>> > From shade at openjdk.java.net Mon Oct 19 06:23:16 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 19 Oct 2020 06:23:16 GMT Subject: RFR: 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage [v2] In-Reply-To: References: Message-ID: > `LowMemoryDetector::check_memory_usage` seems declared but not implemented. Current history does not show any > definitions since the initial load. Can be removed. > Testing: > - [x] Linux x86_64 build > - [x] Test search for `check_memory_usage` in `src/hotspot` Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage ------------- Changes: https://git.openjdk.java.net/jdk/pull/659/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=659&range=01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/659.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/659/head:pull/659 PR: https://git.openjdk.java.net/jdk/pull/659 From rehn at openjdk.java.net Mon Oct 19 06:32:14 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 19 Oct 2020 06:32:14 GMT Subject: Integrated: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: <3KLRkk_EOu8OLSuThc9YWsdlzoInRX4IxOBJRI9tIBQ=.3532b111-3a37-4185-83c1-00e5f1a98eaa@github.com> On Thu, 15 Oct 2020 08:46:01 GMT, Robbin Ehn wrote: > SignalHandlerMark increase and decrease _num_nested_signal, but it is never read. > We have no caller to is_inside_signal_handler(). > > Testing T1. This pull request has now been integrated. Changeset: 011dd0d8 Author: Robbin Ehn URL: https://git.openjdk.java.net/jdk/commit/011dd0d8 Stats: 54 lines in 11 files changed: 5 ins; 39 del; 10 mod 8254824: SignalHandlerMark have no purpose Reviewed-by: stuefe, shade, dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/677 From akozlov at openjdk.java.net Mon Oct 19 07:56:09 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 19 Oct 2020 07:56:09 GMT Subject: RFR: 8254940: AArch64: Cleanup non-product thread members In-Reply-To: References: <6GrxMCF3U9N1D2QGrZNCYD55Zw8tT24uccZcwnxHxn4=.eb9e0b8d-7976-470a-8e1f-361b2d130d56@github.com> Message-ID: On Sat, 17 Oct 2020 10:38:57 GMT, Andrew Haley wrote: >> Please review a very small clean up that deletes unused thread members in linux/aarch64 and windows/aarch64 >> >> Testing: grep, linux/aarch64 fastdebug build > > Removes some left-over debugging code. Change looks good. Thanks, Andrew! ------------- PR: https://git.openjdk.java.net/jdk/pull/708 From github.com+4146708+a74nh at openjdk.java.net Mon Oct 19 08:13:17 2020 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Mon, 19 Oct 2020 08:13:17 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: Message-ID: On Fri, 16 Oct 2020 20:08:58 GMT, Robbin Ehn wrote: >> Marked as reviewed by dholmes (Reviewer). > >> > And just to be clear any action that changes code such that a >> > cross-modify-fence is needed by other threads, has to perform a global >> > safepoint/handshake? >> >> I'm not sure of that. But we added these fences for the case where the >> code got patched during a safepoint. Maybe Robbin knows the answer.? : ) > > On x86 we have two compliant option according to the manual: > > (* OPTION 1 *) > Store modified code (as data) into code segment; > Jump to new code or an intermediate location; > Execute new code; > > (* OPTION 2 *) > Store modified code (as data) into code segment; > Execute a serializing instruction; (* For example, CPUID instruction *) > Execute new code; > > - Code patching that happens outside a safepoint do options 1 and don't need CMF. > If CMF is needed on some arch, it must be encoded into the instruction stream while patching. > (whether this is really safe, thinking of spectre, is another story :) ) > See e.g. NativeGeneralJump::replace_mt_safe() > - Code patching that happens inside a safepoint do options 2 and need CMF. > We actual only need CMF for safepoints, but since we do not know why we were armed we must emit it. > So can be optimize by keeping track of the safepoint id and for which safepoint id we have emitted CMF for per java > thread. I merged this patch together with https://github.com/openjdk/jdk/pull/428 (which makes AArch64 use cross modify fence) and ran it on AArch64 with the "-XX:+VerifyCrossModifyFence" set. A complete tier1 ran successfully, and I'm waiting on the results of a much wider run. ------------- PR: https://git.openjdk.java.net/jdk/pull/655 From lkorinth at openjdk.java.net Mon Oct 19 09:12:16 2020 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Mon, 19 Oct 2020 09:12:16 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v15] In-Reply-To: References: <4X4ZaiVSAkI3PZYBChk4HTo6X41UOIlidC5dClesGtE=.06d3a0f5-9067-4fac-8dac-251105eb477f@github.com> Message-ID: On Wed, 14 Oct 2020 16:02:30 GMT, Thomas Stuefe wrote: >> Hi Thomas, >> this is a major enhancement and it looks good to me. Congratulations! :) >> Cheers, Richard. > >> Hi Thomas, >> this is a major enhancement and it looks good to me. Congratulations! :) >> Cheers, Richard. > > Thanks a lot Richard! Still looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From jiefu at openjdk.java.net Mon Oct 19 10:10:13 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 19 Oct 2020 10:10:13 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) [v3] In-Reply-To: References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> Message-ID: <1XLNhABhHt0BvRZUvznzBfgphUVjST7Fdn8XM4foUzQ=.b2eea6d7-5fe2-442f-9ac7-66fe6ac5d6cc@github.com> On Fri, 16 Oct 2020 01:22:47 GMT, Jie Fu wrote: >> Thanks @kimbarrett for your review. >> Will push it tomorrow if there is no objection. > > OK. > > May I get a second review for this change? > Thanks. Hi all, May I get a second review to finish this issue? Some of our testing pipelines become red due to this bug. Thanks. Best regards, Jie ------------- PR: https://git.openjdk.java.net/jdk/pull/496 From shade at openjdk.java.net Mon Oct 19 10:53:15 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 19 Oct 2020 10:53:15 GMT Subject: RFR: 8254997: Remove unimplemented OSContainer::read_memory_limit_in_bytes Message-ID: The definition seems to be moved to CgroupSubsystem with JDK-8230305: https://hg.openjdk.java.net/jdk/jdk/rev/931354c6323d#l7.494 The leftover declaration can be cleaned up. ------------- Commit messages: - 8254997: Remove unimplemented OSContainer::read_memory_limit_in_bytes Changes: https://git.openjdk.java.net/jdk/pull/732/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=732&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254997 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/732.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/732/head:pull/732 PR: https://git.openjdk.java.net/jdk/pull/732 From eosterlund at openjdk.java.net Mon Oct 19 11:25:11 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 19 Oct 2020 11:25:11 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 20:31:16 GMT, Daniel D. Daugherty wrote: > 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 Looks great in general. I only have one question regarding when deflation would not be called by a Java thread (which is now checked for). src/hotspot/share/runtime/synchronizer.cpp line 2366: > 2364: GVars.stw_random = os::random(); > 2365: > 2366: if (self->is_Java_thread()) { When would this not be run by a Java thread? ------------- PR: https://git.openjdk.java.net/jdk/pull/641 From akozlov at openjdk.java.net Mon Oct 19 11:46:11 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 19 Oct 2020 11:46:11 GMT Subject: Integrated: 8254940: AArch64: Cleanup non-product thread members In-Reply-To: <6GrxMCF3U9N1D2QGrZNCYD55Zw8tT24uccZcwnxHxn4=.eb9e0b8d-7976-470a-8e1f-361b2d130d56@github.com> References: <6GrxMCF3U9N1D2QGrZNCYD55Zw8tT24uccZcwnxHxn4=.eb9e0b8d-7976-470a-8e1f-361b2d130d56@github.com> Message-ID: On Fri, 16 Oct 2020 19:49:41 GMT, Anton Kozlov wrote: > Please review a very small clean up that deletes unused thread members in linux/aarch64 and windows/aarch64 > > Testing: grep, linux/aarch64 fastdebug build This pull request has now been integrated. Changeset: 4ffed326 Author: Anton Kozlov Committer: Vladimir Kempik URL: https://git.openjdk.java.net/jdk/commit/4ffed326 Stats: 19 lines in 2 files changed: 0 ins; 19 del; 0 mod 8254940: AArch64: Cleanup non-product thread members Reviewed-by: aph ------------- PR: https://git.openjdk.java.net/jdk/pull/708 From sgehwolf at openjdk.java.net Mon Oct 19 12:13:13 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 19 Oct 2020 12:13:13 GMT Subject: RFR: 8254997: Remove unimplemented OSContainer::read_memory_limit_in_bytes In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 10:45:43 GMT, Aleksey Shipilev wrote: > The definition seems to be moved to CgroupSubsystem with JDK-8230305: > https://hg.openjdk.java.net/jdk/jdk/rev/931354c6323d#l7.494 > The leftover declaration can be cleaned up. Looks good. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/732 From dholmes at openjdk.java.net Mon Oct 19 13:15:13 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 19 Oct 2020 13:15:13 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) [v3] In-Reply-To: References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> Message-ID: <7RRvIxzyd90RrVlD-7ifafQf6NHz2TwepoOg-KF31wo=.a8896b4c-ced7-4270-93ce-f6ce4ea1e9e5@github.com> On Wed, 14 Oct 2020 12:52:35 GMT, Jie Fu wrote: >> __sync_val_compare_and_swap shouldn't call with narrowOop* for clang after JDK-8247912. >> Before passing type T to __sync_val_compare_and_swap, the fix converts T to uint32_t* if sizeof(T) == 4. >> >> Testing: >> - Zero VM build on Linux and MacOS with clang >> - Zero VM build on Linux with gcc > > Jie Fu 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-8253970 > - Add FULL_MEM_BARRIER > - Merge branch 'master' into JDK-8253970 > - Revert changes > - Replace __sync_val_compare_and_swap whith __atomic_compare_exchange > - Merge branch 'master' into JDK-8253970 > - Revert changes > - 8253970 Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' > invalid) Seems consistent with the aarch64 code. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/496 From jiefu at openjdk.java.net Mon Oct 19 13:19:24 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 19 Oct 2020 13:19:24 GMT Subject: RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) [v3] In-Reply-To: <7RRvIxzyd90RrVlD-7ifafQf6NHz2TwepoOg-KF31wo=.a8896b4c-ced7-4270-93ce-f6ce4ea1e9e5@github.com> References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> <7RRvIxzyd90RrVlD-7ifafQf6NHz2TwepoOg-KF31wo=.a8896b4c-ced7-4270-93ce-f6ce4ea1e9e5@github.com> Message-ID: <00G0uexSJFpF4j15fomtGggQeRU-uAUoOwxyg1ZtQK8=.fb49bff9-2e30-4388-a090-c6ee64ce24d4@github.com> On Mon, 19 Oct 2020 13:12:14 GMT, David Holmes wrote: >> Jie Fu 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-8253970 >> - Add FULL_MEM_BARRIER >> - Merge branch 'master' into JDK-8253970 >> - Revert changes >> - Replace __sync_val_compare_and_swap whith __atomic_compare_exchange >> - Merge branch 'master' into JDK-8253970 >> - Revert changes >> - 8253970 Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' >> invalid) > > Seems consistent with the aarch64 code. > > Thanks, > David Thanks @dholmes-ora for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/496 From jiefu at openjdk.java.net Mon Oct 19 13:23:11 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 19 Oct 2020 13:23:11 GMT Subject: Integrated: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) In-Reply-To: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> References: <9Kn1qGHqYTqXdtF6g2Pzg_DhJkB-_4EQ_C8hj5A0pUU=.d82283f4-d70b-4631-81b2-2cbb91b3ef62@github.com> Message-ID: <3X4a6kz4uUPu4crx7rWPP8Rk1GbUXJafP5qiWIbJlnA=.66710827-babc-44bd-af61-6d50607d6ad8@github.com> On Sat, 3 Oct 2020 13:29:03 GMT, Jie Fu wrote: > __sync_val_compare_and_swap shouldn't call with narrowOop* for clang after JDK-8247912. > Before passing type T to __sync_val_compare_and_swap, the fix converts T to uint32_t* if sizeof(T) == 4. > > Testing: > - Zero VM build on Linux and MacOS with clang > - Zero VM build on Linux with gcc This pull request has now been integrated. Changeset: cb7701b7 Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/cb7701b7 Stats: 29 lines in 2 files changed: 23 ins; 0 del; 6 mod 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid) Reviewed-by: kbarrett, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/496 From pchilanomate at openjdk.java.net Mon Oct 19 13:56:11 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 19 Oct 2020 13:56:11 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 08:10:25 GMT, Alan Hayward wrote: >>> > And just to be clear any action that changes code such that a >>> > cross-modify-fence is needed by other threads, has to perform a global >>> > safepoint/handshake? >>> >>> I'm not sure of that. But we added these fences for the case where the >>> code got patched during a safepoint. Maybe Robbin knows the answer.? : ) >> >> On x86 we have two compliant option according to the manual: >> >> (* OPTION 1 *) >> Store modified code (as data) into code segment; >> Jump to new code or an intermediate location; >> Execute new code; >> >> (* OPTION 2 *) >> Store modified code (as data) into code segment; >> Execute a serializing instruction; (* For example, CPUID instruction *) >> Execute new code; >> >> - Code patching that happens outside a safepoint do options 1 and don't need CMF. >> If CMF is needed on some arch, it must be encoded into the instruction stream while patching. >> (whether this is really safe, thinking of spectre, is another story :) ) >> See e.g. NativeGeneralJump::replace_mt_safe() >> - Code patching that happens inside a safepoint do options 2 and need CMF. >> We actual only need CMF for safepoints, but since we do not know why we were armed we must emit it. >> So can be optimize by keeping track of the safepoint id and for which safepoint id we have emitted CMF for per java >> thread. > > I merged this patch together with https://github.com/openjdk/jdk/pull/428 (which makes AArch64 use cross modify fence) > and ran it on AArch64 with the "-XX:+VerifyCrossModifyFence" set. A complete tier1 ran successfully, and I'm waiting on > the results of a much wider run. Thanks @robehn and @dholmes-ora for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/655 From pchilanomate at openjdk.java.net Mon Oct 19 14:04:12 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 19 Oct 2020 14:04:12 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: Message-ID: <-kYbdwhYNrI8DGUih4ImqXp1Ovl_gfm50AqpueVJveM=.a69073d5-552d-4385-adcf-e172b506c666@github.com> On Mon, 19 Oct 2020 13:53:50 GMT, Patricio Chilano Mateo wrote: >> I merged this patch together with https://github.com/openjdk/jdk/pull/428 (which makes AArch64 use cross modify fence) >> and ran it on AArch64 with the "-XX:+VerifyCrossModifyFence" set. A complete tier1 ran successfully, and I'm waiting on >> the results of a much wider run. > > Thanks @robehn and @dholmes-ora for the reviews! > I merged this patch together with #428 (which makes AArch64 use cross modify fence) and ran it on AArch64 with the > "-XX:+VerifyCrossModifyFence" set. A complete tier1 ran successfully, and I'm waiting on the results of a much wider > run. Ok, let me know when you are okay and I will integrate. ------------- PR: https://git.openjdk.java.net/jdk/pull/655 From shade at openjdk.java.net Mon Oct 19 14:29:16 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 19 Oct 2020 14:29:16 GMT Subject: RFR: 8197981: Missing return statement in __sync_val_compare_and_swap_8 Message-ID: This is similar to JDK-8254144 (that only did this for `os_linux_zero.cpp`), but a fuller version that also does `os_bsd_zero.cpp`. The patch is already in 7u, and needs forward porting. It takes the shape of JDK-8254144, that is with the comment: https://github.com/openjdk/jdk/commit/8f9e4792 ------------- Commit messages: - Fix the comment in os_linux_zero too - 8197981: Missing return statement in __sync_val_compare_and_swap_8 Changes: https://git.openjdk.java.net/jdk/pull/739/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=739&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8197981 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/739.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/739/head:pull/739 PR: https://git.openjdk.java.net/jdk/pull/739 From stuefe at openjdk.java.net Mon Oct 19 15:20:31 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 19 Oct 2020 15:20:31 GMT Subject: RFR: 8251158: Implementation of JEP 387: Elastic Metaspace [v18] In-Reply-To: References: Message-ID: > Hi all, > > this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the > delay, had vacation then the entrance of Skara delayed things a bit. > For the delta diff please see [3]. > > This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all > feedback individually in this PR body, but I incorporated almost all into the new revision. > What changed since the last version: > > - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the > group consent. > > - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for > overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth > class loader which made it rather pointless. Now I run it always. > > - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. > > - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) > > Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. > > - In ChunkManager::purge() I improved the comments after discussions with Leo. > > - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due > to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run > every time. > > - Fixed indentation issues as Leo requested > > - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested > > - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes > and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more > flexible since it allows us to have list with purge-able and non-purge-able nodes. > > - and various smaller fixes, mainly on request of Leo. > > @lkorinth: > >> VirtualSpaceNode.hpp >> >>102 // Start pointer of the area. >>103 MetaWord* const _base; >> >>How does this differ from _rs._base? Really needed? >> >>105 // Size, in words, of the whole node >>106 const size_t _word_size; >> >>Can we not calculate this from _rs.size()? > > You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it > is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly > improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at > some point and make those members const - as they should be - then I would rewrite this as you suggest. > Thanks, again, for all your review work! > > ------ > > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html > [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Fix Linux 32bit link issue ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/336/files - new: https://git.openjdk.java.net/jdk/pull/336/files/973e7aae..1b521249 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=336&range=16-17 Stats: 8 lines in 2 files changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/336/head:pull/336 PR: https://git.openjdk.java.net/jdk/pull/336 From andrew at openjdk.java.net Mon Oct 19 15:25:09 2020 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Mon, 19 Oct 2020 15:25:09 GMT Subject: RFR: 8197981: Missing return statement in __sync_val_compare_and_swap_8 In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 14:20:04 GMT, Aleksey Shipilev wrote: > This is similar to JDK-8254144 (that only did this for `os_linux_zero.cpp`), but a fuller version that also does > `os_bsd_zero.cpp`. The patch is already in 7u, and needs forward porting. It takes the shape of JDK-8254144, that is > with the comment: https://github.com/openjdk/jdk/commit/8f9e4792 Looks fine (I did the same changes myself in 7u). It would have been nice to have the chance to submit this change myself, so I could try out the new PR system. ------------- Marked as reviewed by andrew (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/739 From ccheung at openjdk.java.net Mon Oct 19 16:04:31 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 19 Oct 2020 16:04:31 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v9] In-Reply-To: References: Message-ID: > Following up on archiving lambda proxy classes in dynamic CDS archive > ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of > lambda proxy classes in static CDS archive. > When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved > during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will > be of the following format: > `@lambda-proxy: ` > > e.g. > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` > > When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above > `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool > indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool > entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index > and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. > During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not > found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> > IsCDSDumpingEnabled) is involved in the core-libs code.) > Testing: tiers 1,2,3,4. > > Performance results (javac on HelloWorld on linux-x64): > Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " > 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- > 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- > 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- > 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- > 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- > 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- > 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- > 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- > 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- > 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- > ============================================================ > 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- > instr delta = -161497801 -7.2542% > time delta = -24.722 ms -6.5951% Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: store symbolic name of ref kind (e.g. REF_invokeStatic) in classlist ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/364/files - new: https://git.openjdk.java.net/jdk/pull/364/files/dd6d440b..dbf3b961 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=07-08 Stats: 14 lines in 1 file changed: 10 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364 PR: https://git.openjdk.java.net/jdk/pull/364 From mchung at openjdk.java.net Mon Oct 19 16:18:13 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 19 Oct 2020 16:18:13 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v9] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 16:04:31 GMT, Calvin Cheung wrote: >> Following up on archiving lambda proxy classes in dynamic CDS archive >> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of >> lambda proxy classes in static CDS archive. >> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved >> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will >> be of the following format: >> `@lambda-proxy: ` >> >> e.g. >> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` >> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` >> >> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above >> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool >> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool >> entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index >> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. >> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not >> found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> >> IsCDSDumpingEnabled) is involved in the core-libs code.) >> Testing: tiers 1,2,3,4. >> >> Performance results (javac on HelloWorld on linux-x64): >> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " >> 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- >> 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- >> 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- >> 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- >> 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- >> 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- >> 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- >> 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- >> 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- >> 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- >> ============================================================ >> 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- >> instr delta = -161497801 -7.2542% >> time delta = -24.722 ms -6.5951% > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > store symbolic name of ref kind (e.g. REF_invokeStatic) in classlist I reviewed the java.base changes and have no additional comment. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/364 From dcubed at openjdk.java.net Mon Oct 19 16:26:16 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 19 Oct 2020 16:26:16 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 11:22:21 GMT, Erik ?sterlund wrote: >> 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 > > Looks great in general. I only have one question regarding when deflation would not be called by a Java thread (which > is now checked for). @fisk - Thanks for the review. Please let me know if I have resolved your question. > src/hotspot/share/runtime/synchronizer.cpp line 2366: > >> 2364: GVars.stw_random = os::random(); >> 2365: >> 2366: if (self->is_Java_thread()) { > > When would this not be run by a Java thread? `ObjectSynchronizer::do_final_audit_and_print_stats()` calls: > L2958: ObjectSynchronizer::deflate_idle_monitors(); and do_final_audit_and_print_stats() is called from two places: - void VM_Exit::doit() - The do_final_audit_and_print_stats() call happens when the VMThread is executing the VM_Exit VM-op. That happens as a result of a vm_exit() call a.k.a. System.exit(). - VMThread::run() - The do_final_audit_and_print_stats() call happens after the VMThread has been terminated and finished processing VM-ops. So this is the jni_DestroyJavaVM() path that happens when the program falls off the end of main() and that thread does an orderly shutdown of the VMThread. A key piece of this changeset is moving the final audit to be executed by the VMThread on one of its two exit code paths. The final audit includes a calls to deflate_idle_monitors() to make sure things are as clean as possible before doing the audit_and_print_stats() call. None of this happens if the right logging is not enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/641 From iklam at openjdk.java.net Mon Oct 19 16:59:14 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 19 Oct 2020 16:59:14 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v9] In-Reply-To: References: Message-ID: <2yXKGk7mfEX6pR2AfBxq4eFs821CVYrxSBe_Wy3i2_A=.d3220e17-317a-4c05-a1e5-300ef460ff23@github.com> On Mon, 19 Oct 2020 16:04:31 GMT, Calvin Cheung wrote: >> Following up on archiving lambda proxy classes in dynamic CDS archive >> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of >> lambda proxy classes in static CDS archive. >> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved >> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will >> be of the following format: >> `@lambda-proxy: ` >> >> e.g. >> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` >> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` >> >> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above >> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool >> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool >> entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index >> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. >> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not >> found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> >> IsCDSDumpingEnabled) is involved in the core-libs code.) >> Testing: tiers 1,2,3,4. >> >> Performance results (javac on HelloWorld on linux-x64): >> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " >> 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- >> 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- >> 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- >> 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- >> 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- >> 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- >> 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- >> 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- >> 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- >> 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- >> ============================================================ >> 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- >> instr delta = -161497801 -7.2542% >> time delta = -24.722 ms -6.5951% > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > store symbolic name of ref kind (e.g. REF_invokeStatic) in classlist LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/364 From sspitsyn at openjdk.java.net Mon Oct 19 17:57:17 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 19 Oct 2020 17:57:17 GMT Subject: RFR: 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage [v2] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 06:23:16 GMT, Aleksey Shipilev wrote: >> `LowMemoryDetector::check_memory_usage` seems declared but not implemented. Current history does not show any >> definitions since the initial load. Can be removed. >> Testing: >> - [x] Linux x86_64 build >> - [x] Test search for `check_memory_usage` in `src/hotspot` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since > the last revision: > 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage This looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/659 From ccheung at openjdk.java.net Mon Oct 19 18:19:31 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 19 Oct 2020 18:19:31 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v10] In-Reply-To: References: Message-ID: > Following up on archiving lambda proxy classes in dynamic CDS archive > ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of > lambda proxy classes in static CDS archive. > When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved > during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will > be of the following format: > `@lambda-proxy: ` > > e.g. > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` > > When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above > `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool > indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool > entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index > and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. > During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not > found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> > IsCDSDumpingEnabled) is involved in the core-libs code.) > Testing: tiers 1,2,3,4. > > Performance results (javac on HelloWorld on linux-x64): > Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " > 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- > 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- > 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- > 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- > 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- > 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- > 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- > 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- > 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- > 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- > ============================================================ > 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- > instr delta = -161497801 -7.2542% > time delta = -24.722 ms -6.5951% Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: correct the classlist in the LambdaProxyClasslist.java test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/364/files - new: https://git.openjdk.java.net/jdk/pull/364/files/dbf3b961..52d7e5fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=08-09 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/364.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364 PR: https://git.openjdk.java.net/jdk/pull/364 From ccheung at openjdk.java.net Mon Oct 19 18:27:20 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 19 Oct 2020 18:27:20 GMT Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v9] In-Reply-To: <2yXKGk7mfEX6pR2AfBxq4eFs821CVYrxSBe_Wy3i2_A=.d3220e17-317a-4c05-a1e5-300ef460ff23@github.com> References: <2yXKGk7mfEX6pR2AfBxq4eFs821CVYrxSBe_Wy3i2_A=.d3220e17-317a-4c05-a1e5-300ef460ff23@github.com> Message-ID: On Mon, 19 Oct 2020 16:56:19 GMT, Ioi Lam wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> store symbolic name of ref kind (e.g. REF_invokeStatic) in classlist > > LGTM @iklam and @mlchung, thanks again for the review and discussions. ------------- PR: https://git.openjdk.java.net/jdk/pull/364 From cjplummer at openjdk.java.net Mon Oct 19 18:33:13 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 19 Oct 2020 18:33:13 GMT Subject: RFR: 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage [v2] In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 06:23:16 GMT, Aleksey Shipilev wrote: >> `LowMemoryDetector::check_memory_usage` seems declared but not implemented. Current history does not show any >> definitions since the initial load. Can be removed. >> Testing: >> - [x] Linux x86_64 build >> - [x] Test search for `check_memory_usage` in `src/hotspot` > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains one commit: > 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/659 From ccheung at openjdk.java.net Mon Oct 19 18:34:15 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 19 Oct 2020 18:34:15 GMT Subject: Integrated: 8247666: Support Lambda proxy classes in static CDS archive In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 17:52:24 GMT, Calvin Cheung wrote: > Following up on archiving lambda proxy classes in dynamic CDS archive > ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of > lambda proxy classes in static CDS archive. > When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved > during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will > be of the following format: > `@lambda-proxy: ` > > e.g. > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233` > `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355` > > When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above > `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool > indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool > entries, and will be cached using a similar mechanism to JDK-8198698. During dumping, there is check on the cp index > and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed. > During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not > found, then lookup from the dynamic archive if one is specified. (Only name change (IsDynamicDumpingEnabled -> > IsCDSDumpingEnabled) is involved in the core-libs code.) > Testing: tiers 1,2,3,4. > > Performance results (javac on HelloWorld on linux-x64): > Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java " > 1: 2228016795 2067752708 (-160264087) ----- 377.760 349.110 (-28.650) ----- > 2: 2223051476 2063016483 (-160034993) ----- 374.580 350.620 (-23.960) ---- > 3: 2225908334 2067673847 (-158234487) ----- 375.220 350.990 (-24.230) ---- > 4: 2225835999 2064596883 (-161239116) ----- 374.670 349.840 (-24.830) ---- > 5: 2226005510 2061694332 (-164311178) ----- 373.512 351.120 (-22.392) ---- > 6: 2225574949 2062657482 (-162917467) ----- 374.710 348.380 (-26.330) ----- > 7: 2224702424 2064634122 (-160068302) ----- 373.670 349.510 (-24.160) ---- > 8: 2226662277 2066301134 (-160361143) ----- 375.350 349.790 (-25.560) ---- > 9: 2226761470 2063162795 (-163598675) ----- 374.260 351.290 (-22.970) ---- > 10: 2230149089 2066203307 (-163945782) ----- 374.760 350.620 (-24.140) ---- > ============================================================ > 2226266109 2064768307 (-161497801) ----- 374.848 350.126 (-24.722) ---- > instr delta = -161497801 -7.2542% > time delta = -24.722 ms -6.5951% This pull request has now been integrated. Changeset: 74ac77e2 Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/74ac77e2 Stats: 2026 lines in 38 files changed: 1896 ins; 66 del; 64 mod 8247666: Support Lambda proxy classes in static CDS archive Reviewed-by: iklam, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/364 From eosterlund at openjdk.java.net Mon Oct 19 20:26:14 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 19 Oct 2020 20:26:14 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 20:31:16 GMT, Daniel D. Daugherty wrote: > 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 Looks good. Thanks for fixing! ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/641 From eosterlund at openjdk.java.net Mon Oct 19 20:26:15 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 19 Oct 2020 20:26:15 GMT Subject: RFR: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: References: Message-ID: <73h9JXzErc3Ck8EiX3gC9ZL2hyAwilcCKWYktV2cwwE=.584f759a-e6d4-42b4-a858-1c68040b95d2@github.com> On Mon, 19 Oct 2020 16:23:24 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/synchronizer.cpp line 2366: >> >>> 2364: GVars.stw_random = os::random(); >>> 2365: >>> 2366: if (self->is_Java_thread()) { >> >> When would this not be run by a Java thread? > > `ObjectSynchronizer::do_final_audit_and_print_stats()` calls: > >> L2958: ObjectSynchronizer::deflate_idle_monitors(); > > and do_final_audit_and_print_stats() is called from two places: > > - void VM_Exit::doit() - The do_final_audit_and_print_stats() call happens > when the VMThread is executing the VM_Exit VM-op. That happens as > a result of a vm_exit() call a.k.a. System.exit(). > > - VMThread::run() - The do_final_audit_and_print_stats() call happens > after the VMThread has been terminated and finished processing > VM-ops. So this is the jni_DestroyJavaVM() path that happens when > the program falls off the end of main() and that thread does an > orderly shutdown of the VMThread. > > A key piece of this changeset is moving the final audit to be executed > by the VMThread on one of its two exit code paths. The final audit > includes a calls to deflate_idle_monitors() to make sure things are as > clean as possible before doing the audit_and_print_stats() call. > > None of this happens if the right logging is not enabled. Okay, that makes sense. Thanks for the explanation. ------------- PR: https://git.openjdk.java.net/jdk/pull/641 From dcubed at openjdk.java.net Mon Oct 19 21:56:11 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 19 Oct 2020 21:56:11 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: <-kYbdwhYNrI8DGUih4ImqXp1Ovl_gfm50AqpueVJveM=.a69073d5-552d-4385-adcf-e172b506c666@github.com> References: <-kYbdwhYNrI8DGUih4ImqXp1Ovl_gfm50AqpueVJveM=.a69073d5-552d-4385-adcf-e172b506c666@github.com> Message-ID: On Mon, 19 Oct 2020 14:01:27 GMT, Patricio Chilano Mateo wrote: >> Thanks @robehn and @dholmes-ora for the reviews! > >> I merged this patch together with #428 (which makes AArch64 use cross modify fence) and ran it on AArch64 with the >> "-XX:+VerifyCrossModifyFence" set. A complete tier1 ran successfully, and I'm waiting on the results of a much wider >> run. > > Ok, let me know when you are okay and I will integrate. Heads-up: The build and test tasks appear to be unhappy. ------------- PR: https://git.openjdk.java.net/jdk/pull/655 From dholmes at openjdk.java.net Mon Oct 19 21:57:13 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 19 Oct 2020 21:57:13 GMT Subject: RFR: 8197981: Missing return statement in __sync_val_compare_and_swap_8 In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 14:20:04 GMT, Aleksey Shipilev wrote: > This is similar to JDK-8254144 (that only did this for `os_linux_zero.cpp`), but a fuller version that also does > `os_bsd_zero.cpp`. The patch is already in 7u, and needs forward porting. It takes the shape of JDK-8254144, that is > with the comment: https://github.com/openjdk/jdk/commit/8f9e4792 Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/739 From dcubed at openjdk.java.net Mon Oct 19 22:07:09 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 19 Oct 2020 22:07:09 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 14:25:14 GMT, Patricio Chilano Mateo wrote: > Hi all, > > Please review the following patch that removes some uneeded uses of cross_modify_fence() in common code, in particular > from ~ThreadBlockInVM(), ~ThreadBlockInVMWithDeadlockCheck() and java_suspend_self_with_safepoint_check(). These fences > were added before each JavaThread had to disarm itself (8230594). After a safepoint/handshake each JavaThread will > always call SafepointMechanism::process_if_requested_slow() when transitioning out of the safe state and will execute a > cross_modify_fence(). Tested with mach5 tiers1-7. Thanks, Patricio Thumbs up! Had to read through the comments a couple of times along with the code before I convinced myself all was okay. Thanks for testing Mach5 Tier[1-7]. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/655 From pchilanomate at openjdk.java.net Mon Oct 19 22:13:25 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 19 Oct 2020 22:13:25 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 22:04:46 GMT, Daniel D. Daugherty wrote: >> Hi all, >> >> Please review the following patch that removes some uneeded uses of cross_modify_fence() in common code, in particular >> from ~ThreadBlockInVM(), ~ThreadBlockInVMWithDeadlockCheck() and java_suspend_self_with_safepoint_check(). These fences >> were added before each JavaThread had to disarm itself (8230594). After a safepoint/handshake each JavaThread will >> always call SafepointMechanism::process_if_requested_slow() when transitioning out of the safe state and will execute a >> cross_modify_fence(). Tested with mach5 tiers1-7. Thanks, Patricio > > Thumbs up! Had to read through the comments a couple of > times along with the code before I convinced myself all was > okay. Thanks for testing Mach5 Tier[1-7]. > Heads-up: The build and test tasks appear to be unhappy. Yes, commit v1 was done after 8173585 was pushed but before the issues introduced by it were fixed. I can merge with master to make it happy. : ) > Thumbs up! Had to read through the comments a couple of > times along with the code before I convinced myself all was > okay. Thanks for testing Mach5 Tier[1-7]. Thanks Dan! ------------- PR: https://git.openjdk.java.net/jdk/pull/655 From dcubed at openjdk.java.net Mon Oct 19 22:19:11 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 19 Oct 2020 22:19:11 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 22:10:49 GMT, Patricio Chilano Mateo wrote: >> Thumbs up! Had to read through the comments a couple of >> times along with the code before I convinced myself all was >> okay. Thanks for testing Mach5 Tier[1-7]. > >> Thumbs up! Had to read through the comments a couple of >> times along with the code before I convinced myself all was >> okay. Thanks for testing Mach5 Tier[1-7]. > > Thanks Dan! Why is the commit history only showing a single commit if there was a merge in the past? (I might be missing something trivial here since I'm still a GitHub newbie.) ------------- PR: https://git.openjdk.java.net/jdk/pull/655 From pchilanomate at openjdk.java.net Mon Oct 19 22:25:13 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 19 Oct 2020 22:25:13 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 22:16:30 GMT, Daniel D. Daugherty wrote: > Why is the commit history only showing a single commit if there was a merge in the past? > (I might be missing something trivial here since I'm still a GitHub newbie.) Not sure, where are you seeing the merge? ------------- PR: https://git.openjdk.java.net/jdk/pull/655 From dcubed at openjdk.java.net Tue Oct 20 01:11:11 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 20 Oct 2020 01:11:11 GMT Subject: Integrated: 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 In-Reply-To: References: Message-ID: On Tue, 13 Oct 2020 20:31:16 GMT, Daniel D. Daugherty wrote: > 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 This pull request has now been integrated. Changeset: c87cdf70 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/c87cdf70 Stats: 162 lines in 8 files changed: 48 ins; 37 del; 77 mod 8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064 Reviewed-by: dholmes, eosterlund ------------- PR: https://git.openjdk.java.net/jdk/pull/641 From dcubed at openjdk.java.net Tue Oct 20 01:28:14 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 20 Oct 2020 01:28:14 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 22:22:53 GMT, Patricio Chilano Mateo wrote: >> Why is the commit history only showing a single commit if there was a merge in the past? >> (I might be missing something trivial here since I'm still a GitHub newbie.) > >> Why is the commit history only showing a single commit if there was a merge in the past? >> (I might be missing something trivial here since I'm still a GitHub newbie.) > > Not sure, where are you seeing the merge? Sorry Patricio. I saw the comment from a74nh above ("I merged this patch together with...") and I just assumed it was you replying to David H. My mistake. ------------- PR: https://git.openjdk.java.net/jdk/pull/655 From shade at openjdk.java.net Tue Oct 20 05:29:19 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 20 Oct 2020 05:29:19 GMT Subject: Integrated: 8254997: Remove unimplemented OSContainer::read_memory_limit_in_bytes In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 10:45:43 GMT, Aleksey Shipilev wrote: > The definition seems to be moved to CgroupSubsystem with JDK-8230305: > https://hg.openjdk.java.net/jdk/jdk/rev/931354c6323d#l7.494 > The leftover declaration can be cleaned up. This pull request has now been integrated. Changeset: 5b51085c Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/5b51085c Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8254997: Remove unimplemented OSContainer::read_memory_limit_in_bytes Reviewed-by: sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/732 From shade at openjdk.java.net Tue Oct 20 05:30:08 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 20 Oct 2020 05:30:08 GMT Subject: Integrated: 8197981: Missing return statement in __sync_val_compare_and_swap_8 In-Reply-To: References: Message-ID: On Mon, 19 Oct 2020 14:20:04 GMT, Aleksey Shipilev wrote: > This is similar to JDK-8254144 (that only did this for `os_linux_zero.cpp`), but a fuller version that also does > `os_bsd_zero.cpp`. The patch is already in 7u, and needs forward porting. It takes the shape of JDK-8254144, that is > with the comment: https://github.com/openjdk/jdk/commit/8f9e4792 This pull request has now been integrated. Changeset: b65dcfa3 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/b65dcfa3 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod 8197981: Missing return statement in __sync_val_compare_and_swap_8 Reviewed-by: andrew, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/739 From shade at openjdk.java.net Tue Oct 20 05:34:14 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 20 Oct 2020 05:34:14 GMT Subject: Integrated: 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage In-Reply-To: References: Message-ID: On Wed, 14 Oct 2020 14:57:20 GMT, Aleksey Shipilev wrote: > `LowMemoryDetector::check_memory_usage` seems declared but not implemented. Current history does not show any > definitions since the initial load. Can be removed. > Testing: > - [x] Linux x86_64 build > - [x] Test search for `check_memory_usage` in `src/hotspot` This pull request has now been integrated. Changeset: 0a75b37f Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/0a75b37f Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8254776: Remove unimplemented LowMemoryDetector::check_memory_usage Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/659 From github.com+4146708+a74nh at openjdk.java.net Tue Oct 20 08:16:23 2020 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Tue, 20 Oct 2020 08:16:23 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 01:25:10 GMT, Daniel D. Daugherty wrote: >>> Why is the commit history only showing a single commit if there was a merge in the past? >>> (I might be missing something trivial here since I'm still a GitHub newbie.) >> >> Not sure, where are you seeing the merge? > > Sorry Patricio. I saw the comment from a74nh above ("I merged this patch together with...") > and I just assumed it was you replying to David H. My mistake. > > I merged this patch together with #428 (which makes AArch64 use cross modify fence) and ran it on AArch64 with the > > "-XX:+VerifyCrossModifyFence" set. A complete tier1 ran successfully, and I'm waiting on the results of a much wider > > run. > > Ok, let me know when you are okay and I will integrate. I've run this across all our tests and machines now, and everything passes ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/655 From stuefe at openjdk.java.net Tue Oct 20 08:22:19 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 20 Oct 2020 08:22:19 GMT Subject: Integrated: 8251158: Implementation of JEP 387: Elastic Metaspace In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 12:16:55 GMT, Thomas Stuefe wrote: > Hi all, > > this is the continuation of the ongoing review for the JEP387 implementation (last rounds see [1] [2]). Sorry for the > delay, had vacation then the entrance of Skara delayed things a bit. > For the delta diff please see [3]. > > This is the first time I do a large PR after Skara, so if something is wrong please bear with me. I cannot answer all > feedback individually in this PR body, but I incorporated almost all into the new revision. > What changed since the last version: > > - I renamed most metaspace files back to the original naming scheme or to something similar, hopefully capturing the > group consent. > > - I changed the way allocation guards are checked if MetaspaceGuardAllocations is enabled. Before, I would test for > overwrites upon CLD destruction, but since that check was subject to VerifyMetaspaceInterval it only ran for every nth > class loader which made it rather pointless. Now I run it always. > > - I also improved the printout on block corruption, and log block corruption unconditionally before asserting. > > - I also fixed up and commented the death test which tests for allocation overwriters (test_allocationGuard.cpp) > > Side note, I find the corruption check very useful but if you guys think it is too much I still can remove the feature. > > - In ChunkManager::purge() I improved the comments after discussions with Leo. > > - I fixed a bug with VerifyMetaspaceInterval: if set to 1 the "SOMETIMES" sections were supposed to fire always, but due > to a one-off error they only fired every second time. Now, if -XX:VerifyMetaspaceInterval=1, the checks really run > every time. > > - Fixed indentation issues as Leo requested > > - Rewrote the condition and the assert in VirtualSpaceList::allocate_root_chunk() as Leo requested > > - I removed the "can_purge" logic from VirtualSpaceList. The list does not need to know. It just should iterate all nodes > and attempt purging, and if a node does not own its ReservedSpace, it refuses to be purged. That is simpler and more > flexible since it allows us to have list with purge-able and non-purge-able nodes. > > - and various smaller fixes, mainly on request of Leo. > > @lkorinth: > >> VirtualSpaceNode.hpp >> >>102 // Start pointer of the area. >>103 MetaWord* const _base; >> >>How does this differ from _rs._base? Really needed? >> >>105 // Size, in words, of the whole node >>106 const size_t _word_size; >> >>Can we not calculate this from _rs.size()? > > You are right, _base and _word_size are directly related to the underlying space. But I'd prefer to leave it the way it > is. Mainly because ReservedSpace::_base and ::_size are nonconst and theoretically can change under me. It is highly > improbable but I'd like to know. Note that VirtualSpaceNode::verify checks that. Should we clean up ReservedSpace at > some point and make those members const - as they should be - then I would rewrite this as you suggest. > Thanks, again, for all your review work! > > ------ > > > [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041162.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041628.html > [3] https://github.com/openjdk/jdk/commit/731f795bc0c1c502dc6cac8f866ff45a15bdd02d This pull request has now been integrated. Changeset: 7ba6a6bf Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/7ba6a6bf Stats: 23026 lines in 174 files changed: 14782 ins; 7020 del; 1224 mod 8251158: Implementation of JEP 387: Elastic Metaspace Reviewed-by: lkorinth, coleenp, iklam, rrich ------------- PR: https://git.openjdk.java.net/jdk/pull/336 From serb at openjdk.java.net Tue Oct 20 08:41:19 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 20 Oct 2020 08:41:19 GMT Subject: RFR: 8255043: Incorrectly styled copyright text Message-ID: In some files, the copyright text is styled as a JavaDoc comment. Most of the affected files are tests, only one product file is affected: src/java.sql/share/classes/javax/sql/package-info.java The chenge is trivial: - /** + /* * Copyright (c) ------------- Commit messages: - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/759/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=759&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255043 Stats: 49 lines in 49 files changed: 0 ins; 0 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/759.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/759/head:pull/759 PR: https://git.openjdk.java.net/jdk/pull/759 From dholmes at openjdk.java.net Tue Oct 20 11:50:12 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 20 Oct 2020 11:50:12 GMT Subject: RFR: 8255043: Incorrectly styled copyright text In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov wrote: > In some files, the copyright text is styled as a JavaDoc comment. > Most of the affected files are tests, only one product file is affected: > src/java.sql/share/classes/javax/sql/package-info.java > > The chenge is trivial: > - /** > + /* > * Copyright (c) Seems trivially fine. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/759 From pchilanomate at openjdk.java.net Tue Oct 20 14:00:45 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 20 Oct 2020 14:00:45 GMT Subject: RFR: 8254264: Remove redundant cross_modify_fence() [v2] In-Reply-To: References: Message-ID: > Hi all, > > Please review the following patch that removes some uneeded uses of cross_modify_fence() in common code, in particular > from ~ThreadBlockInVM(), ~ThreadBlockInVMWithDeadlockCheck() and java_suspend_self_with_safepoint_check(). These fences > were added before each JavaThread had to disarm itself (8230594). After a safepoint/handshake each JavaThread will > always call SafepointMechanism::process_if_requested_slow() when transitioning out of the safe state and will execute a > cross_modify_fence(). Tested with mach5 tiers1-7. Thanks, Patricio Patricio Chilano Mateo 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 8254264-cross_modify_fence - Merge branch 'master' into 8254264-cross_modify_fence - v1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/655/files - new: https://git.openjdk.java.net/jdk/pull/655/files/38fef27a..9f83608f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=655&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=655&range=00-01 Stats: 325776 lines in 788 files changed: 312532 ins; 10055 del; 3189 mod Patch: https://git.openjdk.java.net/jdk/pull/655.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/655/head:pull/655 PR: https://git.openjdk.java.net/jdk/pull/655 From trebari at openjdk.java.net Tue Oct 20 14:36:16 2020 From: trebari at openjdk.java.net (Tejpal Rebari) Date: Tue, 20 Oct 2020 14:36:16 GMT Subject: RFR: 8255043: Incorrectly styled copyright text In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov wrote: > In some files, the copyright text is styled as a JavaDoc comment. > Most of the affected files are tests, only one product file is affected: > src/java.sql/share/classes/javax/sql/package-info.java > > The chenge is trivial: > - /** > + /* > * Copyright (c) Marked as reviewed by trebari (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/759 From pchilanomate at openjdk.java.net Tue Oct 20 15:15:22 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 20 Oct 2020 15:15:22 GMT Subject: Integrated: 8254264: Remove redundant cross_modify_fence() In-Reply-To: References: Message-ID: <43Z1uxPXFyK_kdXSu4tCsWg7dYCcijwNkFRutpoqYkc=.da510dbb-3da9-494b-8c3c-dfe34db93bb9@github.com> On Wed, 14 Oct 2020 14:25:14 GMT, Patricio Chilano Mateo wrote: > Hi all, > > Please review the following patch that removes some uneeded uses of cross_modify_fence() in common code, in particular > from ~ThreadBlockInVM(), ~ThreadBlockInVMWithDeadlockCheck() and java_suspend_self_with_safepoint_check(). These fences > were added before each JavaThread had to disarm itself (8230594). After a safepoint/handshake each JavaThread will > always call SafepointMechanism::process_if_requested_slow() when transitioning out of the safe state and will execute a > cross_modify_fence(). Tested with mach5 tiers1-7. Thanks, Patricio This pull request has now been integrated. Changeset: f167a71f Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/f167a71f Stats: 5 lines in 2 files changed: 0 ins; 5 del; 0 mod 8254264: Remove redundant cross_modify_fence() Reviewed-by: rehn, dholmes, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/655 From jdv at openjdk.java.net Tue Oct 20 15:43:14 2020 From: jdv at openjdk.java.net (Jayathirth D V) Date: Tue, 20 Oct 2020 15:43:14 GMT Subject: RFR: 8255043: Incorrectly styled copyright text In-Reply-To: References: Message-ID: <3HXa_fWqHw4PKAfkD6oo5xKl8gR5ss7yhfl87HdSuGI=.fd3fa01c-a7a1-4e13-ab60-9852ff93162d@github.com> On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov wrote: > In some files, the copyright text is styled as a JavaDoc comment. > Most of the affected files are tests, only one product file is affected: > src/java.sql/share/classes/javax/sql/package-info.java > > The chenge is trivial: > - /** > + /* > * Copyright (c) Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/759 From serb at openjdk.java.net Wed Oct 21 04:59:11 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 21 Oct 2020 04:59:11 GMT Subject: Integrated: 8255043: Incorrectly styled copyright text In-Reply-To: References: Message-ID: On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov wrote: > In some files, the copyright text is styled as a JavaDoc comment. > Most of the affected files are tests, only one product file is affected: > src/java.sql/share/classes/javax/sql/package-info.java > > The chenge is trivial: > - /** > + /* > * Copyright (c) This pull request has now been integrated. Changeset: 2e510e04 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/2e510e04 Stats: 49 lines in 49 files changed: 0 ins; 0 del; 49 mod 8255043: Incorrectly styled copyright text Reviewed-by: dholmes, trebari, jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/759 From dcubed at openjdk.java.net Wed Oct 21 21:16:19 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Oct 2020 21:16:19 GMT Subject: RFR: 8255200: ProblemList com/sun/jdi/EATests.java for ZGC Message-ID: Reduce the noise in the JDK16 CI by ProblemListing com/sun/jdi/EATests.java for ZGC. ------------- Commit messages: - Must learn to not type too fast... - Only the first test case is failing. - 8255200: ProblemList com/sun/jdi/EATests.java for ZGC Changes: https://git.openjdk.java.net/jdk/pull/787/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=787&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255200 Stats: 30 lines in 1 file changed: 30 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/787.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/787/head:pull/787 PR: https://git.openjdk.java.net/jdk/pull/787 From kvn at openjdk.java.net Wed Oct 21 21:27:13 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 21 Oct 2020 21:27:13 GMT Subject: RFR: 8255200: ProblemList com/sun/jdi/EATests.java for ZGC In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 21:04:55 GMT, Daniel D. Daugherty wrote: > Reduce the noise in the JDK16 CI by ProblemListing com/sun/jdi/EATests.java for ZGC. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/787 From iignatyev at openjdk.java.net Wed Oct 21 21:37:15 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 21 Oct 2020 21:37:15 GMT Subject: RFR: 8255200: ProblemList com/sun/jdi/EATests.java for ZGC In-Reply-To: References: Message-ID: <0vi5PXjYPOdQy5wrB72cqJwlGm2BGD7kUGB6s6G1z8Y=.779a3b02-e755-4183-90ea-1ebf836c20ff@github.com> On Wed, 21 Oct 2020 21:04:55 GMT, Daniel D. Daugherty wrote: > Reduce the noise in the JDK16 CI by ProblemListing com/sun/jdi/EATests.java for ZGC. Marked as reviewed by iignatyev (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/787 From dholmes at openjdk.java.net Wed Oct 21 21:37:15 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 21 Oct 2020 21:37:15 GMT Subject: RFR: 8255200: ProblemList com/sun/jdi/EATests.java for ZGC In-Reply-To: References: Message-ID: <5aMRZ_X8Gdo6keu6uADnX4IGe5m5ySl-T6JO5elZeGE=.a1d8e1bb-d616-421b-8ddf-ed04082aa034@github.com> On Wed, 21 Oct 2020 21:04:55 GMT, Daniel D. Daugherty wrote: > Reduce the noise in the JDK16 CI by ProblemListing com/sun/jdi/EATests.java for ZGC. Looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/787 From dcubed at openjdk.java.net Wed Oct 21 21:37:17 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Oct 2020 21:37:17 GMT Subject: Integrated: 8255200: ProblemList com/sun/jdi/EATests.java for ZGC In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 21:04:55 GMT, Daniel D. Daugherty wrote: > Reduce the noise in the JDK16 CI by ProblemListing com/sun/jdi/EATests.java for ZGC. This pull request has now been integrated. Changeset: 34450311 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/34450311 Stats: 30 lines in 1 file changed: 30 ins; 0 del; 0 mod 8255200: ProblemList com/sun/jdi/EATests.java for ZGC Reviewed-by: kvn, iignatyev, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/787 From dcubed at openjdk.java.net Wed Oct 21 21:37:15 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 21 Oct 2020 21:37:15 GMT Subject: RFR: 8255200: ProblemList com/sun/jdi/EATests.java for ZGC In-Reply-To: <5aMRZ_X8Gdo6keu6uADnX4IGe5m5ySl-T6JO5elZeGE=.a1d8e1bb-d616-421b-8ddf-ed04082aa034@github.com> References: <5aMRZ_X8Gdo6keu6uADnX4IGe5m5ySl-T6JO5elZeGE=.a1d8e1bb-d616-421b-8ddf-ed04082aa034@github.com> Message-ID: On Wed, 21 Oct 2020 21:28:45 GMT, David Holmes wrote: >> Reduce the noise in the JDK16 CI by ProblemListing com/sun/jdi/EATests.java for ZGC. > > Looks good. > > Thanks, > David Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/787 From jiefu at openjdk.java.net Thu Oct 22 11:53:18 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 22 Oct 2020 11:53:18 GMT Subject: RFR: 8255040: Replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors with clang Message-ID: Hi all, It's time to replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors. After JDK-8252221, build errors with clang were observed [1] due to the use of __sync_add_and_fetch, which is legacy and will be deprecated in the future. It can be reproduced by building macos-x86-zero or linux-x86-zero with clang. The fix was prepared by learning from aarch64's implementation [2]. Please review it. Thanks Best regards, Jie [1] https://bugs.openjdk.java.net/browse/JDK-8255040 [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp#L39 ------------- Commit messages: - Replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors with clang Changes: https://git.openjdk.java.net/jdk/pull/803/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=803&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255040 Stats: 13 lines in 2 files changed: 9 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/803.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/803/head:pull/803 PR: https://git.openjdk.java.net/jdk/pull/803 From richard.reingruber at sap.com Thu Oct 22 14:22:11 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Thu, 22 Oct 2020 14:22:11 +0000 Subject: Is _thread_in_native safe for handshake/safepoint? Message-ID: Hi, I don't understand the method safepoint_safe_with() in safepoint.cpp Maybe somebody has a quick answer to the questions below... 648 static bool safepoint_safe_with(JavaThread *thread, JavaThreadState state) { 649 switch(state) { 650 case _thread_in_native: 651 // native threads are safe if they have no java stack or have walkable stack 652 return !thread->has_last_Java_frame() || thread->frame_anchor()->walkable(); 653 654 case _thread_blocked: 655 // On wait_barrier or blocked. 656 // Blocked threads should already have walkable stack. 657 assert(!thread->has_last_Java_frame() || thread->frame_anchor()->walkable(), "blocked and not walkable"); 658 return true; 659 660 default: 661 return false; 662 } 663 } I thought _thread_in_native and _thread_blocked are both equally safe for handshakes/safepoints but that method makes a distinction. Looking at line 652 it seems possible that a thread is _thread_in_native without a walkable stack. The thread is then of course considered not safe. Native wrappers, native interpreter entries, ThreadToNativeFromVM change the state to _thread_in_native after making the stack walkable though (I looked also at the old sparc versions). So how can a thread be _thread_in_native without a walkable stack? And why does that state make sense when it blocks handshakes/safepoints? I found JavaThreadInVMAndNative which seems to set the state to _thread_in_native without making the stack walkable. It seems though that from there ThreadInVMfromNative is reachable which can trigger an assertion in JavaThread::check_safepoint_and_suspend_for_native_trans() if the stack isn't walkable. JfrRecorderService::invoke_safepoint_write() : void JfrRecorderService::write() : void JfrRecorderService::finalize_current_chunk() : void JfrRecorderService::chunk_rotation() : void JfrRecorderService::rotate(int) : void JfrEmergencyDump::on_vm_shutdown(bool) : void Thanks, Richard. From stuefe at openjdk.java.net Thu Oct 22 20:43:19 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 22 Oct 2020 20:43:19 GMT Subject: RFR: JDK-8255268: 32-bit failures in runtime/Metaspace/elastic Message-ID: Hi, may I please have reviews for this small test fix? This fixes the elastic metaspace tests on 32bit by increasing the alignment size (which is given in number of words) to a value valid for both 64bit and 32bit. Tested: these tests, on 32bit and 64bit. Thanks. ------------- Commit messages: - JDK-8255268 Changes: https://git.openjdk.java.net/jdk/pull/817/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=817&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255268 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/817.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/817/head:pull/817 PR: https://git.openjdk.java.net/jdk/pull/817 From shade at openjdk.java.net Thu Oct 22 20:59:19 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 22 Oct 2020 20:59:19 GMT Subject: RFR: JDK-8255268: 32-bit failures in runtime/Metaspace/elastic In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 20:34:16 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for this small test fix? This fixes the elastic metaspace tests on 32bit by increasing the alignment size (which is given in number of words) to a value valid for both 64bit and 32bit. > > Tested: these tests, on 32bit and 64bit. > > Thanks. Thanks! Looks good and trivial to me. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/817 From stuefe at openjdk.java.net Fri Oct 23 05:36:09 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 23 Oct 2020 05:36:09 GMT Subject: RFR: JDK-8255268: 32-bit failures in runtime/Metaspace/elastic In-Reply-To: References: Message-ID: <-sTpZdb55zQ2-i2YygNlpsKhRnGETjDUvOPxF4pa_64=.bd19d290-3733-4292-a531-beea74075223@github.com> On Thu, 22 Oct 2020 20:56:06 GMT, Aleksey Shipilev wrote: > Thanks! Looks good and trivial to me. Thanks! Following the trivial rule I will now integrate without waiting. ------------- PR: https://git.openjdk.java.net/jdk/pull/817 From stuefe at openjdk.java.net Fri Oct 23 05:36:09 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 23 Oct 2020 05:36:09 GMT Subject: Integrated: JDK-8255268: 32-bit failures in runtime/Metaspace/elastic In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 20:34:16 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for this small test fix? This fixes the elastic metaspace tests on 32bit by increasing the alignment size (which is given in number of words) to a value valid for both 64bit and 32bit. > > Tested: these tests, on 32bit and 64bit. > > Thanks. This pull request has now been integrated. Changeset: 2ca7a080 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/2ca7a080 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8255268: 32-bit failures in runtime/Metaspace/elastic Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/817 From sgehwolf at openjdk.java.net Fri Oct 23 15:51:47 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 23 Oct 2020 15:51:47 GMT Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code [v3] In-Reply-To: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> Message-ID: <5Jk_4mxRk_8rIaxUY9NhUNhOmjdIuRuV-KWzeSrLkaI=.07c9a141-6335-4e52-8aff-3fcbfce02a17@github.com> > Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). > > When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too. > > Thoughts? Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8253939: [TESTBUG] Increase coverage of the cgroups detection code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/609/files - new: https://git.openjdk.java.net/jdk/pull/609/files/a122958f..44362211 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=609&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=609&range=01-02 Stats: 107 lines in 2 files changed: 107 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/609/head:pull/609 PR: https://git.openjdk.java.net/jdk/pull/609 From shade at openjdk.java.net Fri Oct 23 17:34:47 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 23 Oct 2020 17:34:47 GMT Subject: RFR: 8255330: gtest/MetaspaceGtests.java fail on 32-bit platforms Message-ID: Seems fairly trivial: `UseCompressedKlassPointers` is only available on 64-bit platforms. Attention @tstuefe ;) Testing: - [x] Affected test on Linux x86_64 - [x] Affected test on Linux x86_32 ------------- Commit messages: - 8255330: gtest/MetaspaceGtests.java fail on 32-bit platforms Changes: https://git.openjdk.java.net/jdk/pull/831/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=831&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255330 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/831/head:pull/831 PR: https://git.openjdk.java.net/jdk/pull/831 From stuefe at openjdk.java.net Fri Oct 23 19:25:34 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 23 Oct 2020 19:25:34 GMT Subject: RFR: 8255330: gtest/MetaspaceGtests.java fail on 32-bit platforms In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 10:23:01 GMT, Aleksey Shipilev wrote: > Seems fairly trivial: `UseCompressedKlassPointers` is only available on 64-bit platforms. > > Attention @tstuefe ;) > > Testing: > - [x] Affected test on Linux x86_64 > - [x] Affected test on Linux x86_32 Embarrassingly simple and trivial. Thanks for fixing! ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/831 From stuefe at openjdk.java.net Fri Oct 23 19:30:43 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 23 Oct 2020 19:30:43 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked Message-ID: Hi, may I have reviews please for the following patch which takes care to unblock synchronous error signals at the entrance of our main signal handler (including some minor code cleanups). When a signal happens which cannot be deferred (SIGFPE, SIGILL, SIGSEGV, SIGBUS) but whose delivery is blocked, bad things happen. This is undefined territory, and we have observed the following cases: - on Linux, the default handler is invoked instead of the user handler, which in case of error signals causes the process to core immediately. This is actually one of the better outcomes, we still have a core. - on AIX and PASE both, the process just becomes unresponsive and hangs. - on HPUX - one of our internal platform - the process just vanishes without a trace. I did not test other platforms but would guess similar things happen there. Posix documentation [4] states: _"If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated while they are blocked, the result is undefined, unless the signal was generated by the kill() function, the sigqueue() function, or the raise() function."_ At the moment, undeferrable error signals are unblocked outside the signal handler (see hotspot sigmask) and, since JDK-8065895, inside the error handler (see crash_handler setup). This leaves us with a window where the hotspot signal handler runs but before he has decided to invoke fatal error handling. Inside that window, for any platform but AIX error signals are still blocked. So any crash inside them tears down the VM immediately without giving us a useful hs-err file. On AIX they are not blocked because we added an AIX-only patch a while ago which unblocks them at the entrance of the AIX signal handler. This was before we contributed the port to OpenJDK, so no history in the official repos. But that behavior makes sense for all posix platforms. For more details see discussion from Nov 2014 [2][3]. (Side note, these effects only show for truly synchronous error signals. You cannot artificially create such a scenario e.g. by raising SIGSEGV with kill.) About sa_sigaction.sa_mask vs pthread_sigmask: At the first glance, it would be more elegant to just unblock error signals in the signal mask specified when installing the signal handler. However, the way that mask works is that it is ANDed together with the process signal mask in effect when the signal was raised. So if one or more of the error signals were blocked at that point, they would continue to be blocked in the handler, sa_mask notwithstanding. It seems easier and clearer to just manually unblock those signals at the entrance of our handlers. Changes in detail: - At the entrance of javaSignalHandler() we now unblock error signals for all platforms, not just for AIX. - Nothing changes at the entrance of the secondary error handler (crash_handler()): just better code reuse. - In os::signal(), for AIX only, we used to set the sa_mask for the handler-to-be-installed to unblock error signals. I decided to just remove this section. The reason is: I want to get rid of this AIX specific section, and was torn between leaving it in for all platforms or removing it. os::signal is used to install other signal handlers too, and I do not want to change their behavior with this patch. Therefore I just removed this section. Tests: I tested the change manually by triggering a segfault inside javaSignalHandler. That reliably tore down the process immediately. With this patch, once error signals are unblocked, we continue to run - we get the secondary crash, which then leads to VMError::report_and_die() called since its a real error (I prevented recursion for this test. See my comments about recursion in the JBS issue.) We will put this through our SAP internal tests before pushing. [1] https://bugs.openjdk.java.net/browse/JDK-8065895 [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-November/013346.html [3] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-January/013718.html [4] https://pubs.opengroup.org/onlinepubs/009695399/functions/sigprocmask.html ------------- Commit messages: - Initial patch Changes: https://git.openjdk.java.net/jdk/pull/839/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=839&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252533 Stats: 75 lines in 3 files changed: 13 ins; 53 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/839.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/839/head:pull/839 PR: https://git.openjdk.java.net/jdk/pull/839 From shade at openjdk.java.net Fri Oct 23 19:48:36 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 23 Oct 2020 19:48:36 GMT Subject: Integrated: 8255330: gtest/MetaspaceGtests.java fail on 32-bit platforms In-Reply-To: References: Message-ID: <8JIzAOzVUm8V5KkDD2FMMx9v4ikoCjS3yRI5JtnIHp4=.86679821-dbbf-439f-8dab-a3fa393db9b0@github.com> On Fri, 23 Oct 2020 10:23:01 GMT, Aleksey Shipilev wrote: > Seems fairly trivial: `UseCompressedKlassPointers` is only available on 64-bit platforms. > > Attention @tstuefe ;) > > Testing: > - [x] Affected test on Linux x86_64 > - [x] Affected test on Linux x86_32 This pull request has now been integrated. Changeset: 3f6abd22 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/3f6abd22 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8255330: gtest/MetaspaceGtests.java fail on 32-bit platforms Reviewed-by: stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/831 From hseigel at openjdk.java.net Fri Oct 23 20:34:41 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 23 Oct 2020 20:34:41 GMT Subject: RFR: 8255342: Remove non-specified JVM checks on Classes with Record attributes Message-ID: Please review this fix to remove the checks for non-final and abstract classes containing Record attributes and checks for classes containing Record attributes whose supers are not java.lang.Record. These checks are not specified in the JVM Spec and so should not be done by the JVM. The change removes the checks and updates Record tests as needed. The fix was tested with mach5 tiers 1 and 2 on Linux, Windows, and Mac, and tiers 3-5 on Linux x64 and with JCK lang, vm, and api/java_lang tests. Thanks, Harold ------------- Commit messages: - 8255342: Remove non-specified JVM checks on Classes with Record attributes Changes: https://git.openjdk.java.net/jdk/pull/845/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=845&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255342 Stats: 42 lines in 6 files changed: 0 ins; 22 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/845/head:pull/845 PR: https://git.openjdk.java.net/jdk/pull/845 From dholmes at openjdk.java.net Mon Oct 26 02:26:36 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Oct 2020 02:26:36 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked In-Reply-To: References: Message-ID: <6Qir6UY5T9RhSbYyV4u41W7BdgKO3WBBxwgDAOvPt8o=.f4e4a032-1d5e-42b0-a97b-4be59754c598@github.com> On Fri, 23 Oct 2020 15:44:26 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews please for the following patch which takes care to unblock synchronous error signals at the entrance of our main signal handler (including some minor code cleanups). > > When a signal happens which cannot be deferred (SIGFPE, SIGILL, SIGSEGV, SIGBUS) but whose delivery is blocked, bad things happen. This is undefined territory, and we have observed the following cases: > > - on Linux, the default handler is invoked instead of the user handler, which in case of error signals causes the process to core immediately. This is actually one of the better outcomes, we still have a core. > - on AIX and PASE both, the process just becomes unresponsive and hangs. > - on HPUX - one of our internal platform - the process just vanishes without a trace. > > I did not test other platforms but would guess similar things happen there. Posix documentation [4] states: > _"If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated while they are blocked, the result is undefined, unless the signal was generated by the kill() function, the sigqueue() function, or the raise() function."_ > > At the moment, undeferrable error signals are unblocked outside the signal handler (see hotspot sigmask) and, since JDK-8065895, inside the error handler (see crash_handler setup). This leaves us with a window where the hotspot signal handler runs but before he has decided to invoke fatal error handling. Inside that window, for any platform but AIX error signals are still blocked. So any crash inside them tears down the VM immediately without giving us a useful hs-err file. > > On AIX they are not blocked because we added an AIX-only patch a while ago which unblocks them at the entrance of the AIX signal handler. This was before we contributed the port to OpenJDK, so no history in the official repos. But that behavior makes sense for all posix platforms. > > For more details see discussion from Nov 2014 [2][3]. > > (Side note, these effects only show for truly synchronous error signals. You cannot artificially create such a scenario e.g. by raising SIGSEGV with kill.) > > About sa_sigaction.sa_mask vs pthread_sigmask: At the first glance, it would be more elegant to just unblock error signals in the signal mask specified when installing the signal handler. However, the way that mask works is that it is ANDed together with the process signal mask in effect when the signal was raised. So if one or more of the error signals were blocked at that point, they would continue to be blocked in the handler, sa_mask notwithstanding. > It seems easier and clearer to just manually unblock those signals at the entrance of our handlers. > > Changes in detail: > > - At the entrance of javaSignalHandler() we now unblock error signals for all platforms, not just for AIX. > - Nothing changes at the entrance of the secondary error handler (crash_handler()): just better code reuse. > - In os::signal(), for AIX only, we used to set the sa_mask for the handler-to-be-installed to unblock error signals. I decided to just remove this section. The reason is: I want to get rid of this AIX specific section, and was torn between leaving it in for all platforms or removing it. os::signal is used to install other signal handlers too, and I do not want to change their behavior with this patch. Therefore I just removed this section. > > Tests: > > I tested the change manually by triggering a segfault inside javaSignalHandler. That reliably tore down the process immediately. With this patch, once error signals are unblocked, we continue to run - we get the secondary crash, which then leads to VMError::report_and_die() called since its a real error (I prevented recursion for this test. See my comments about recursion in the JBS issue.) > > We will put this through our SAP internal tests before pushing. > > [1] https://bugs.openjdk.java.net/browse/JDK-8065895 > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-November/013346.html > [3] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-January/013718.html > [4] https://pubs.opengroup.org/onlinepubs/009695399/functions/sigprocmask.html Hi Thomas, I think this has highlighted a number of bugs with our signal handling code in general. It makes no sense to ever block these synchronous signals, so any code that does so seems flawed. You also point out the semantics of sa_sigaction.sa_mask which highlights that call_chained_handler is incorrect as it tries to emulate the conditions under which the original handler would have been called, but it explicitly sets a sigmask from sa_mask instead of combining it with the existing sigmask. Aside: I also noticed the SR_sigset is unused, so unclear if we have a bug lurking in PosixSignals::SR_initialize. There is some commentary about the blocked/unblocked status of SR_signum that also seems wrong. That all said ... AFAICS the synchronous signals are all explicitly unblocked via PosixSignals::hotspot_sigmask which is set when a new thread starts executing, or an existing thread attaches. So from that point we should only need to ensure those signals are not explicitly blocked - which means that in os::signal we unblock them in sa_mask for all platforms. Does that not suffice? Or are you concerned about user native code changing the signal masks arbitrarily? In which case re-setting in each of the VM's signal handlers would be reasonable. Note that SIGTRAP is currently mostly only processed under #if defined(PPC64)and/or defined(AIX). Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/839 From dholmes at openjdk.java.net Mon Oct 26 03:56:35 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Oct 2020 03:56:35 GMT Subject: RFR: 8255342: Remove non-specified JVM checks on Classes with Record attributes In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 20:30:23 GMT, Harold Seigel wrote: > Please review this fix to remove the checks for non-final and abstract classes containing Record attributes and checks for classes containing Record attributes whose supers are not java.lang.Record. These checks are not specified in the JVM Spec and so should not be done by the JVM. > > The change removes the checks and updates Record tests as needed. > > The fix was tested with mach5 tiers 1 and 2 on Linux, Windows, and Mac, and tiers 3-5 on Linux x64 and with JCK lang, vm, and api/java_lang tests. > > Thanks, Harold Hi Harold, Generally looks good, but you need a new test case - see below. Thanks, David test/hotspot/jtreg/runtime/records/recordAttributeTest.java line 76: > 74: // Test that loading a class causes the Record attribute to get parsed > 75: // even if its super class is not java.lang.Record > 76: runTest("superNotJLRecord", "Truncated class file"); This simple "inversion" of the test is not sufficient. The original test was that a bad record attribute is ignored when not a subclass of j.l.Record. The modified test should be that a bad record attribute is never ignored. But in addition there should be a new test that a good record attribute in a class that does not subclass j.l.Record, is also okay. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/845 From jiefu at openjdk.java.net Mon Oct 26 09:01:34 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 26 Oct 2020 09:01:34 GMT Subject: RFR: 8255040: Replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors with clang In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 11:45:18 GMT, Jie Fu wrote: > Hi all, > > It's time to replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors. > > After JDK-8252221, build errors with clang were observed [1] due to the use of __sync_add_and_fetch, which is legacy and will be deprecated in the future. > It can be reproduced by building macos-x86-zero or linux-x86-zero with clang. > > The fix was prepared by learning from aarch64's implementation [2]. > Please review it. > > Thanks > Best regards, > Jie > > [1] https://bugs.openjdk.java.net/browse/JDK-8255040 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp#L39 This bug was exposed after JDK-8252221. Hope the author and reviewers of JDK-8252221 ( @amitdpawar , @tschatzl and @kimbarrett ) can first take a look at this. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/803 From stuefe at openjdk.java.net Mon Oct 26 11:46:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 26 Oct 2020 11:46:11 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked In-Reply-To: <6Qir6UY5T9RhSbYyV4u41W7BdgKO3WBBxwgDAOvPt8o=.f4e4a032-1d5e-42b0-a97b-4be59754c598@github.com> References: <6Qir6UY5T9RhSbYyV4u41W7BdgKO3WBBxwgDAOvPt8o=.f4e4a032-1d5e-42b0-a97b-4be59754c598@github.com> Message-ID: On Mon, 26 Oct 2020 02:23:56 GMT, David Holmes wrote: > Hi Thomas, > > I think this has highlighted a number of bugs with our signal handling code in general. It makes no sense to ever block these synchronous signals, so any code that does so seems flawed. You also point out the semantics of sa_sigaction.sa_mask which highlights that call_chained_handler is incorrect as it tries to emulate the conditions under which the original handler would have been called, but it explicitly sets a sigmask from sa_mask instead of combining it with the existing sigmask. > Yes, this coding may benefit from a bit more grooming (but preferably in another RFE). > Aside: I also noticed the SR_sigset is unused, so unclear if we have a bug lurking in PosixSignals::SR_initialize. There is some commentary about the blocked/unblocked status of SR_signum that also seems wrong. > > That all said ... AFAICS the synchronous signals are all explicitly unblocked via PosixSignals::hotspot_sigmask which is set when a new thread starts executing, or an existing thread attaches. So from that point we should only need to ensure those signals are not explicitly blocked - which means that in os::signal we unblock them in sa_mask for all platforms. Does that not suffice? Or are you concerned about user native code changing the signal masks arbitrarily? In which case re-setting in each of the VM's signal handlers would be reasonable. > You are right. This is what I tried to say with "sa_sigaction.sa_mask vs pthread_sigmask". I chose explicit unblocking over setting the signal mask when establishing the handler because I was concerned about someone changing the thread signal mask after handler is installed and before the signal is triggered. Especially I am not sure what happens if some native code calls sigprocmask() - does that affect all threads, only this thread? Posix says its undefined. Because I did not want to think about all this, and because I found it slightly more obvious, I unblock explicitly. That said, it was a bit of a coin toss, and if you dislike this, we can do it via sigaction.sa_mask instead. The danger of someone blocking synchronous error signals under our nose is probably remote :) > Note that SIGTRAP is currently mostly only processed under #if defined(PPC64)and/or defined(AIX). Yes, we use it for implicit null checks. But this has only meaning outside of signal handling. I unblocked it inside signal handlers because I found vague reports of processes crashing with blocked SIGTRAPs and thought that the same reasoning may apply to this signal wrt to blocking in signal handlers. Blocking SIGTRAP has been handled inconsistently, too. It had been unblocked at the entrance of the secondary error handler for all platforms (see vmError_posix.cpp) but not in general error handling. I think that is an oversight. > > Thanks, > David Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/839 From stuefe at openjdk.java.net Mon Oct 26 15:16:23 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 26 Oct 2020 15:16:23 GMT Subject: RFR: JDK-8254189: Improve comments for StackOverFlow and fix in_xxx() functions Message-ID: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> Hi, may I please have reviews for this small cleanup / fix? While reviewing JDK-8253717 it was found that comments would help with understanding the StackOverFlow class. Especially the fact that the various _base_ are actually pointing outside their respective zone, since the stack grows downward and a zone (and the stack itself) range is [end, base). If you don't look at this code daily it can be surprising. This also fixes some small off-by-one errors in various "in_stack_xxx_zone()" methods which test whether a given address is inside a zone and gave wrong results for address=base since base points outside its zone. This had the effect that an address could be in multiple zones. Finally it adds a small gtest which tests the StackOverFlow methods. ------------- Commit messages: - Remove accidental newline - Initial patch Changes: https://git.openjdk.java.net/jdk/pull/795/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=795&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254189 Stats: 106 lines in 3 files changed: 103 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/795/head:pull/795 PR: https://git.openjdk.java.net/jdk/pull/795 From hseigel at openjdk.java.net Mon Oct 26 15:20:25 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 26 Oct 2020 15:20:25 GMT Subject: RFR: 8255342: Remove non-specified JVM checks on Classes with Record attributes [v2] In-Reply-To: References: Message-ID: > Please review this fix to remove the checks for non-final and abstract classes containing Record attributes and checks for classes containing Record attributes whose supers are not java.lang.Record. These checks are not specified in the JVM Spec and so should not be done by the JVM. > > The change removes the checks and updates Record tests as needed. > > The fix was tested with mach5 tiers 1 and 2 on Linux, Windows, and Mac, and tiers 3-5 on Linux x64 and with JCK lang, vm, and api/java_lang tests. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8255342: Remove non-specified JVM checks on Classes with Record attributes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/845/files - new: https://git.openjdk.java.net/jdk/pull/845/files/6f0e2d23..1379e87f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=845&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=845&range=00-01 Stats: 336 lines in 3 files changed: 332 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/845.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/845/head:pull/845 PR: https://git.openjdk.java.net/jdk/pull/845 From hseigel at openjdk.java.net Mon Oct 26 15:24:16 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 26 Oct 2020 15:24:16 GMT Subject: RFR: 8255342: Remove non-specified JVM checks on Classes with Record attributes [v2] In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 03:54:04 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8255342: Remove non-specified JVM checks on Classes with Record attributes > > Hi Harold, > Generally looks good, but you need a new test case - see below. > Thanks, > David Hi David, Thanks for looking at this change. Please review the updated commit that adds the missing test case. Thanks, Haorld ------------- PR: https://git.openjdk.java.net/jdk/pull/845 From ccheung at openjdk.java.net Mon Oct 26 18:21:22 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 26 Oct 2020 18:21:22 GMT Subject: RFR: 8253920: Share method trampolines in CDS dynamic archive Message-ID: This patch is to allow sharing of the same method trampoline for archived Methods with the same AdapterHandleEntry when using CDS dynamic archive. Running javac on HelloWorld with CDS dynamic archive, the number of calls to SharedRuntime::generate_trampoline() is reduced to 406 times vs 12601 times without the patch. In terms of saving on instructions and time (on linux-x64): instr delta = -2807662 -0.1369% time delta = -6.860 ms -1.8798% It passed tiers 1,2,3,4 testing. ------------- Commit messages: - 8253920: Share method trampolines in CDS dynamic archive Changes: https://git.openjdk.java.net/jdk/pull/868/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=868&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253920 Stats: 225 lines in 8 files changed: 126 ins; 90 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/868/head:pull/868 PR: https://git.openjdk.java.net/jdk/pull/868 From redestad at openjdk.java.net Mon Oct 26 18:44:20 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 26 Oct 2020 18:44:20 GMT Subject: RFR: 8253920: Share method trampolines in CDS dynamic archive In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 18:12:16 GMT, Calvin Cheung wrote: > This patch is to allow sharing of the same method trampoline for archived Methods with the same AdapterHandleEntry when using CDS dynamic archive. > > Running javac on HelloWorld with CDS dynamic archive, the number of calls to SharedRuntime::generate_trampoline() is reduced to 406 times vs 12601 times without the patch. > > In terms of saving on instructions and time (on linux-x64): > instr delta = -2807662 -0.1369% > time delta = -6.860 ms -1.8798% > > It passed tiers 1,2,3,4 testing. LGTM Thanks for ensuring static data-structures only used when dumping are lazily allocated. src/hotspot/share/classfile/systemDictionaryShared.cpp line 1189: > 1187: ResourceObj::C_HEAP> {}; > 1188: > 1189: static LoadedUnregisteredClassesTable* _loaded_unregistered_classes = NULL; Good! ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/868 From minqi at openjdk.java.net Mon Oct 26 18:55:18 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 26 Oct 2020 18:55:18 GMT Subject: RFR: 8253920: Share method trampolines in CDS dynamic archive In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 18:12:16 GMT, Calvin Cheung wrote: > This patch is to allow sharing of the same method trampoline for archived Methods with the same AdapterHandleEntry when using CDS dynamic archive. > > Running javac on HelloWorld with CDS dynamic archive, the number of calls to SharedRuntime::generate_trampoline() is reduced to 406 times vs 12601 times without the patch. > > In terms of saving on instructions and time (on linux-x64): > instr delta = -2807662 -0.1369% > time delta = -6.860 ms -1.8798% > > It passed tiers 1,2,3,4 testing. Looks good. Minor suggestions. src/hotspot/share/memory/archiveBuilder.cpp line 896: > 894: for (int i = 0; i < klasses()->length(); i++) { > 895: Klass* k = klasses()->at(i); > 896: if (!k->is_instance_klass()) { Could you use if (k->is_instance_klass()) { ... } as same style of line 869 src/hotspot/share/oops/method.cpp line 1111: > 1109: > 1110: assert(_from_compiled_entry != NULL, "sanity"); > 1111: if (DumpSharedSpaces) { I think you can remove this if check. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/868 From ccheung at openjdk.java.net Mon Oct 26 20:34:22 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 26 Oct 2020 20:34:22 GMT Subject: RFR: 8253920: Share method trampolines in CDS dynamic archive In-Reply-To: References: Message-ID: <-pcYgGUoy3FCISiLQtxJ9e7vuqv-jo9TroHTMNdL9uI=.f736630d-2073-42a3-8bf7-62984381df14@github.com> On Mon, 26 Oct 2020 18:37:51 GMT, Claes Redestad wrote: >> This patch is to allow sharing of the same method trampoline for archived Methods with the same AdapterHandleEntry when using CDS dynamic archive. >> >> Running javac on HelloWorld with CDS dynamic archive, the number of calls to SharedRuntime::generate_trampoline() is reduced to 406 times vs 12601 times without the patch. >> >> In terms of saving on instructions and time (on linux-x64): >> instr delta = -2807662 -0.1369% >> time delta = -6.860 ms -1.8798% >> >> It passed tiers 1,2,3,4 testing. > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 1189: > >> 1187: ResourceObj::C_HEAP> {}; >> 1188: >> 1189: static LoadedUnregisteredClassesTable* _loaded_unregistered_classes = NULL; > > Good! @cl4es Thanks for your quick review. ------------- PR: https://git.openjdk.java.net/jdk/pull/868 From ccheung at openjdk.java.net Mon Oct 26 20:34:24 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 26 Oct 2020 20:34:24 GMT Subject: RFR: 8253920: Share method trampolines in CDS dynamic archive In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 18:34:48 GMT, Yumin Qi wrote: >> This patch is to allow sharing of the same method trampoline for archived Methods with the same AdapterHandleEntry when using CDS dynamic archive. >> >> Running javac on HelloWorld with CDS dynamic archive, the number of calls to SharedRuntime::generate_trampoline() is reduced to 406 times vs 12601 times without the patch. >> >> In terms of saving on instructions and time (on linux-x64): >> instr delta = -2807662 -0.1369% >> time delta = -6.860 ms -1.8798% >> >> It passed tiers 1,2,3,4 testing. > > src/hotspot/share/memory/archiveBuilder.cpp line 896: > >> 894: for (int i = 0; i < klasses()->length(); i++) { >> 895: Klass* k = klasses()->at(i); >> 896: if (!k->is_instance_klass()) { > > Could you use > if (k->is_instance_klass()) { > ... > } > as same style of line 869 @yminqi Thanks for your review. I've made the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/868 From ccheung at openjdk.java.net Mon Oct 26 20:37:21 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 26 Oct 2020 20:37:21 GMT Subject: RFR: 8253920: Share method trampolines in CDS dynamic archive In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 18:35:30 GMT, Yumin Qi wrote: >> This patch is to allow sharing of the same method trampoline for archived Methods with the same AdapterHandleEntry when using CDS dynamic archive. >> >> Running javac on HelloWorld with CDS dynamic archive, the number of calls to SharedRuntime::generate_trampoline() is reduced to 406 times vs 12601 times without the patch. >> >> In terms of saving on instructions and time (on linux-x64): >> instr delta = -2807662 -0.1369% >> time delta = -6.860 ms -1.8798% >> >> It passed tiers 1,2,3,4 testing. > > src/hotspot/share/oops/method.cpp line 1111: > >> 1109: >> 1110: assert(_from_compiled_entry != NULL, "sanity"); >> 1111: if (DumpSharedSpaces) { > > I think you can remove this if check. No, I can't remove the check. It doesn't work with the DynamicDumpSharedSpaces case. Note that the conditions of the assert statements are the same as the original code. ------------- PR: https://git.openjdk.java.net/jdk/pull/868 From ccheung at openjdk.java.net Mon Oct 26 20:41:29 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 26 Oct 2020 20:41:29 GMT Subject: RFR: 8253920: Share method trampolines in CDS dynamic archive [v2] In-Reply-To: References: Message-ID: <5kF4uTxIzI4rlsLFcFgZ4lOP4yyFgWKEFqSNNZDS9Jc=.9f011605-c084-447e-bea7-a4f1d9e33073@github.com> > This patch is to allow sharing of the same method trampoline for archived Methods with the same AdapterHandleEntry when using CDS dynamic archive. > > Running javac on HelloWorld with CDS dynamic archive, the number of calls to SharedRuntime::generate_trampoline() is reduced to 406 times vs 12601 times without the patch. > > In terms of saving on instructions and time (on linux-x64): > instr delta = -2807662 -0.1369% > time delta = -6.860 ms -1.8798% > > It passed tiers 1,2,3,4 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: update per review comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/868/files - new: https://git.openjdk.java.net/jdk/pull/868/files/af513fb1..213262ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=868&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=868&range=00-01 Stats: 13 lines in 1 file changed: 0 ins; 1 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/868/head:pull/868 PR: https://git.openjdk.java.net/jdk/pull/868 From minqi at openjdk.java.net Mon Oct 26 20:41:29 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 26 Oct 2020 20:41:29 GMT Subject: RFR: 8253920: Share method trampolines in CDS dynamic archive [v2] In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 20:34:49 GMT, Calvin Cheung wrote: >> src/hotspot/share/oops/method.cpp line 1111: >> >>> 1109: >>> 1110: assert(_from_compiled_entry != NULL, "sanity"); >>> 1111: if (DumpSharedSpaces) { >> >> I think you can remove this if check. > > No, I can't remove the check. It doesn't work with the DynamicDumpSharedSpaces case. Note that the conditions of the assert statements are the same as the original code. Yes, I mess up with the two. Then it is OK, thanks for the explain. ------------- PR: https://git.openjdk.java.net/jdk/pull/868 From iklam at openjdk.java.net Mon Oct 26 22:13:20 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 26 Oct 2020 22:13:20 GMT Subject: RFR: 8253920: Share method trampolines in CDS dynamic archive [v2] In-Reply-To: <5kF4uTxIzI4rlsLFcFgZ4lOP4yyFgWKEFqSNNZDS9Jc=.9f011605-c084-447e-bea7-a4f1d9e33073@github.com> References: <5kF4uTxIzI4rlsLFcFgZ4lOP4yyFgWKEFqSNNZDS9Jc=.9f011605-c084-447e-bea7-a4f1d9e33073@github.com> Message-ID: On Mon, 26 Oct 2020 20:41:29 GMT, Calvin Cheung wrote: >> This patch is to allow sharing of the same method trampoline for archived Methods with the same AdapterHandleEntry when using CDS dynamic archive. >> >> Running javac on HelloWorld with CDS dynamic archive, the number of calls to SharedRuntime::generate_trampoline() is reduced to 406 times vs 12601 times without the patch. >> >> In terms of saving on instructions and time (on linux-x64): >> instr delta = -2807662 -0.1369% >> time delta = -6.860 ms -1.8798% >> >> It passed tiers 1,2,3,4 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > update per review comment Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/868 From iklam at openjdk.java.net Mon Oct 26 22:13:21 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 26 Oct 2020 22:13:21 GMT Subject: RFR: 8253920: Share method trampolines in CDS dynamic archive [v2] In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 20:37:37 GMT, Yumin Qi wrote: >> No, I can't remove the check. It doesn't work with the DynamicDumpSharedSpaces case. Note that the conditions of the assert statements are the same as the original code. > > Yes, I mess up with the two. Then it is OK, thanks for the explain. I sent Calvin a patch which will allow the `if (DumpSharedSpaces)` to be removed. The rest of the changes look good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/868 From ccheung at openjdk.java.net Mon Oct 26 22:48:35 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 26 Oct 2020 22:48:35 GMT Subject: RFR: 8253920: Share method trampolines in CDS dynamic archive [v3] In-Reply-To: References: Message-ID: > This patch is to allow sharing of the same method trampoline for archived Methods with the same AdapterHandleEntry when using CDS dynamic archive. > > Running javac on HelloWorld with CDS dynamic archive, the number of calls to SharedRuntime::generate_trampoline() is reduced to 406 times vs 12601 times without the patch. > > In terms of saving on instructions and time (on linux-x64): > instr delta = -2807662 -0.1369% > time delta = -6.860 ms -1.8798% > > It passed tiers 1,2,3,4 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: update with patch from Ioi ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/868/files - new: https://git.openjdk.java.net/jdk/pull/868/files/213262ea..7c745e6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=868&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=868&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/868/head:pull/868 PR: https://git.openjdk.java.net/jdk/pull/868 From dholmes at openjdk.java.net Mon Oct 26 22:49:20 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 26 Oct 2020 22:49:20 GMT Subject: RFR: 8255342: Remove non-specified JVM checks on Classes with Record attributes [v2] In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 15:20:25 GMT, Harold Seigel wrote: >> Please review this fix to remove the checks for non-final and abstract classes containing Record attributes and checks for classes containing Record attributes whose supers are not java.lang.Record. These checks are not specified in the JVM Spec and so should not be done by the JVM. >> >> The change removes the checks and updates Record tests as needed. >> >> The fix was tested with mach5 tiers 1 and 2 on Linux, Windows, and Mac, and tiers 3-5 on Linux x64 and with JCK lang, vm, and api/java_lang tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8255342: Remove non-specified JVM checks on Classes with Record attributes Thanks for adding the additional test. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/845 From iklam at openjdk.java.net Tue Oct 27 00:36:18 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 27 Oct 2020 00:36:18 GMT Subject: RFR: 8253920: Share method trampolines in CDS dynamic archive [v3] In-Reply-To: References: Message-ID: <-POv3g6_4gAP5exRJOMGvW7MD2cO4TkkxCp-VA8KCdw=.b81dae40-1945-492b-9253-535d5685dde7@github.com> On Mon, 26 Oct 2020 22:48:35 GMT, Calvin Cheung wrote: >> This patch is to allow sharing of the same method trampoline for archived Methods with the same AdapterHandleEntry when using CDS dynamic archive. >> >> Running javac on HelloWorld with CDS dynamic archive, the number of calls to SharedRuntime::generate_trampoline() is reduced to 406 times vs 12601 times without the patch. >> >> In terms of saving on instructions and time (on linux-x64): >> instr delta = -2807662 -0.1369% >> time delta = -6.860 ms -1.8798% >> >> It passed tiers 1,2,3,4 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > update with patch from Ioi Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/868 From dholmes at openjdk.java.net Tue Oct 27 01:36:17 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Oct 2020 01:36:17 GMT Subject: RFR: JDK-8254189: Improve comments for StackOverFlow and fix in_xxx() functions In-Reply-To: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> References: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> Message-ID: On Thu, 22 Oct 2020 04:21:30 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for this small cleanup / fix? > > While reviewing JDK-8253717 it was found that comments would help with understanding the StackOverFlow class. Especially the fact that the various _base_ are actually pointing outside their respective zone, since the stack grows downward and a zone (and the stack itself) range is [end, base). If you don't look at this code daily it can be surprising. > > This also fixes some small off-by-one errors in various "in_stack_xxx_zone()" methods which test whether a given address is inside a zone and gave wrong results for address=base since base points outside its zone. This had the effect that an address could be in multiple zones. > > Finally it adds a small gtest which tests the StackOverFlow methods. Hi Thomas, Seems okay. One nit below. Thanks, David src/hotspot/share/runtime/stackOverflow.cpp line 44: > 42: // Note: Zone sizes are given via Stack(Red|Yellow|Reserved|Shadow)Pages > 43: // parameters; these names are misleading since they actually contain > 44: // zone size in units-of-4K-size, regardless the actual platform page size, s/regardless the/regardless of the/ But this is already covered by the following comment: // We need to adapt the configured number of stack protection pages given // in 4K pages to the actual os page size. We must do this before setting ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/795 From dholmes at openjdk.java.net Tue Oct 27 01:40:17 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Oct 2020 01:40:17 GMT Subject: RFR: 8255040: Replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors with clang In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 11:45:18 GMT, Jie Fu wrote: > Hi all, > > It's time to replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors. > > After JDK-8252221, build errors with clang were observed [1] due to the use of __sync_add_and_fetch, which is legacy and will be deprecated in the future. > It can be reproduced by building macos-x86-zero or linux-x86-zero with clang. > > The fix was prepared by learning from aarch64's implementation [2]. > Please review it. > > Thanks > Best regards, > Jie > > [1] https://bugs.openjdk.java.net/browse/JDK-8255040 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp#L39 Hi Jie, LGTM. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/803 From kbarrett at openjdk.java.net Tue Oct 27 04:43:18 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 27 Oct 2020 04:43:18 GMT Subject: RFR: 8255040: Replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors with clang In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 11:45:18 GMT, Jie Fu wrote: > Hi all, > > It's time to replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors. > > After JDK-8252221, build errors with clang were observed [1] due to the use of __sync_add_and_fetch, which is legacy and will be deprecated in the future. > It can be reproduced by building macos-x86-zero or linux-x86-zero with clang. > > The fix was prepared by learning from aarch64's implementation [2]. > Please review it. > > Thanks > Best regards, > Jie > > [1] https://bugs.openjdk.java.net/browse/JDK-8255040 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp#L39 Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/803 From jiefu at openjdk.java.net Tue Oct 27 04:43:19 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 27 Oct 2020 04:43:19 GMT Subject: RFR: 8255040: Replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors with clang In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 01:37:31 GMT, David Holmes wrote: >> Hi all, >> >> It's time to replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors. >> >> After JDK-8252221, build errors with clang were observed [1] due to the use of __sync_add_and_fetch, which is legacy and will be deprecated in the future. >> It can be reproduced by building macos-x86-zero or linux-x86-zero with clang. >> >> The fix was prepared by learning from aarch64's implementation [2]. >> Please review it. >> >> Thanks >> Best regards, >> Jie >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8255040 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp#L39 > > Hi Jie, > > LGTM. > > Thanks, > David Thanks @dholmes-ora and @kimbarrett for your review. Will push it later. ------------- PR: https://git.openjdk.java.net/jdk/pull/803 From stuefe at openjdk.java.net Tue Oct 27 05:39:16 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 27 Oct 2020 05:39:16 GMT Subject: RFR: JDK-8254189: Improve comments for StackOverFlow and fix in_xxx() functions In-Reply-To: References: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> Message-ID: On Tue, 27 Oct 2020 01:27:24 GMT, David Holmes wrote: >> Hi, >> >> may I please have reviews for this small cleanup / fix? >> >> While reviewing JDK-8253717 it was found that comments would help with understanding the StackOverFlow class. Especially the fact that the various _base_ are actually pointing outside their respective zone, since the stack grows downward and a zone (and the stack itself) range is [end, base). If you don't look at this code daily it can be surprising. >> >> This also fixes some small off-by-one errors in various "in_stack_xxx_zone()" methods which test whether a given address is inside a zone and gave wrong results for address=base since base points outside its zone. This had the effect that an address could be in multiple zones. >> >> Finally it adds a small gtest which tests the StackOverFlow methods. > > src/hotspot/share/runtime/stackOverflow.cpp line 44: > >> 42: // Note: Zone sizes are given via Stack(Red|Yellow|Reserved|Shadow)Pages >> 43: // parameters; these names are misleading since they actually contain >> 44: // zone size in units-of-4K-size, regardless the actual platform page size, > > s/regardless the/regardless of the/ > > But this is already covered by the following comment: > > // We need to adapt the configured number of stack protection pages given > // in 4K pages to the actual os page size. We must do this before setting Okay, I'll remove the comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/795 From jiefu at openjdk.java.net Tue Oct 27 05:57:20 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 27 Oct 2020 05:57:20 GMT Subject: Integrated: 8255040: Replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors with clang In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 11:45:18 GMT, Jie Fu wrote: > Hi all, > > It's time to replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors. > > After JDK-8252221, build errors with clang were observed [1] due to the use of __sync_add_and_fetch, which is legacy and will be deprecated in the future. > It can be reproduced by building macos-x86-zero or linux-x86-zero with clang. > > The fix was prepared by learning from aarch64's implementation [2]. > Please review it. > > Thanks > Best regards, > Jie > > [1] https://bugs.openjdk.java.net/browse/JDK-8255040 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp#L39 This pull request has now been integrated. Changeset: d735f919 Author: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/d735f919 Stats: 13 lines in 2 files changed: 9 ins; 0 del; 4 mod 8255040: Replace __sync_add_and_fetch with __atomic_add_fetch to avoid build errors with clang Reviewed-by: dholmes, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/803 From stuefe at openjdk.java.net Tue Oct 27 07:27:33 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 27 Oct 2020 07:27:33 GMT Subject: RFR: JDK-8254189: Improve comments for StackOverFlow and fix in_xxx() functions [v2] In-Reply-To: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> References: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> Message-ID: > Hi, > > may I please have reviews for this small cleanup / fix? > > While reviewing JDK-8253717 it was found that comments would help with understanding the StackOverFlow class. Especially the fact that the various _base_ are actually pointing outside their respective zone, since the stack grows downward and a zone (and the stack itself) range is [end, base). If you don't look at this code daily it can be surprising. > > This also fixes some small off-by-one errors in various "in_stack_xxx_zone()" methods which test whether a given address is inside a zone and gave wrong results for address=base since base points outside its zone. This had the effect that an address could be in multiple zones. > > Finally it adds a small gtest which tests the StackOverFlow methods. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback David ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/795/files - new: https://git.openjdk.java.net/jdk/pull/795/files/8c128823..cc54ef8d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=795&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=795&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/795/head:pull/795 PR: https://git.openjdk.java.net/jdk/pull/795 From dholmes at openjdk.java.net Tue Oct 27 08:07:19 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Oct 2020 08:07:19 GMT Subject: RFR: JDK-8254189: Improve comments for StackOverFlow and fix in_xxx() functions [v2] In-Reply-To: References: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> Message-ID: On Tue, 27 Oct 2020 07:27:33 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for this small cleanup / fix? >> >> While reviewing JDK-8253717 it was found that comments would help with understanding the StackOverFlow class. Especially the fact that the various _base_ are actually pointing outside their respective zone, since the stack grows downward and a zone (and the stack itself) range is [end, base). If you don't look at this code daily it can be surprising. >> >> This also fixes some small off-by-one errors in various "in_stack_xxx_zone()" methods which test whether a given address is inside a zone and gave wrong results for address=base since base points outside its zone. This had the effect that an address could be in multiple zones. >> >> Finally it adds a small gtest which tests the StackOverFlow methods. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback David Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/795 From robbin.ehn at oracle.com Tue Oct 27 08:15:52 2020 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 27 Oct 2020 09:15:52 +0100 Subject: Is _thread_in_native safe for handshake/safepoint? In-Reply-To: References: Message-ID: Hi Richard, I think the main reason for not making the stack walkable is to avoid register flushes. Since we do not have such hardware anymore in mainline I see no reason to skip making the stack walkable. I find two places, JFR and ~ThreadInVMfromNative(). The JavaThreadInVMAndNative should be replaced. In case of ThreadInVMfromNative I guess the idea is that when going from java -> native we already did the stack walkable and then calling e.g. JNI we avoid it. And you are probably going to do many JNI calls. So fixing those two maybe we can simplify to: > 650 case _thread_in_native: > 654 case _thread_blocked: > 657 assert(!thread->has_last_Java_frame() || thread->frame_anchor()->walkable(), "blocked and not walkable"); > 658 return true; Which would be very nice. We are looking into some simplifications of transitions, since after "8203469: Faster safepoints" blocked and native are almost identical. Essential two super-states thread-safe (blocked/native) and thread-unsafe(all other). Having the same 'rules' for walkable stack certainly helps. Does this answer your question(s)? Thanks, Robbin On 2020-10-22 16:22, Reingruber, Richard wrote: > Hi, > > I don't understand the method safepoint_safe_with() in safepoint.cpp > Maybe somebody has a quick answer to the questions below... > > 648 static bool safepoint_safe_with(JavaThread *thread, JavaThreadState state) { > 649 switch(state) { > 650 case _thread_in_native: > 651 // native threads are safe if they have no java stack or have walkable stack > 652 return !thread->has_last_Java_frame() || thread->frame_anchor()->walkable(); > 653 > 654 case _thread_blocked: > 655 // On wait_barrier or blocked. > 656 // Blocked threads should already have walkable stack. > 657 assert(!thread->has_last_Java_frame() || thread->frame_anchor()->walkable(), "blocked and not walkable"); > 658 return true; > 659 > 660 default: > 661 return false; > 662 } > 663 } > > I thought _thread_in_native and _thread_blocked are both equally safe for > handshakes/safepoints but that method makes a distinction. Looking at line 652 > it seems possible that a thread is _thread_in_native without a walkable > stack. The thread is then of course considered not safe. Native wrappers, native > interpreter entries, ThreadToNativeFromVM change the state to _thread_in_native > after making the stack walkable though (I looked also at the old sparc versions). > > So how can a thread be _thread_in_native without a walkable stack? And why does > that state make sense when it blocks handshakes/safepoints? > > I found JavaThreadInVMAndNative which seems to set the state to > _thread_in_native without making the stack walkable. It seems though that from > there ThreadInVMfromNative is reachable which can trigger an assertion in > JavaThread::check_safepoint_and_suspend_for_native_trans() if the stack isn't > walkable. > > JfrRecorderService::invoke_safepoint_write() : void > JfrRecorderService::write() : void > JfrRecorderService::finalize_current_chunk() : void > JfrRecorderService::chunk_rotation() : void > JfrRecorderService::rotate(int) : void > JfrEmergencyDump::on_vm_shutdown(bool) : void > > Thanks, Richard. > From aph at redhat.com Tue Oct 27 08:37:17 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 27 Oct 2020 08:37:17 +0000 Subject: Is _thread_in_native safe for handshake/safepoint? In-Reply-To: References: Message-ID: On 27/10/2020 08:15, Robbin Ehn wrote: > I think the main reason for not making the stack walkable is to avoid > register flushes. Since we do not have such hardware anymore in mainline > I see no reason to skip making the stack walkable. Oh wow, I would not have guessed that. I'm glad we have people around who remember, but sad there isn't a comment in the code that would have provided a clue. Thanks, -- 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 coleenp at openjdk.java.net Tue Oct 27 11:59:19 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 27 Oct 2020 11:59:19 GMT Subject: RFR: 8255342: Remove non-specified JVM checks on Classes with Record attributes [v2] In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 15:20:25 GMT, Harold Seigel wrote: >> Please review this fix to remove the checks for non-final and abstract classes containing Record attributes and checks for classes containing Record attributes whose supers are not java.lang.Record. These checks are not specified in the JVM Spec and so should not be done by the JVM. >> >> The change removes the checks and updates Record tests as needed. >> >> The fix was tested with mach5 tiers 1 and 2 on Linux, Windows, and Mac, and tiers 3-5 on Linux x64 and with JCK lang, vm, and api/java_lang tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8255342: Remove non-specified JVM checks on Classes with Record attributes Looks good, Harold! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/845 From hseigel at openjdk.java.net Tue Oct 27 12:30:23 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 27 Oct 2020 12:30:23 GMT Subject: RFR: 8255342: Remove non-specified JVM checks on Classes with Record attributes [v2] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 11:56:37 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8255342: Remove non-specified JVM checks on Classes with Record attributes > > Looks good, Harold! Thanks David and Coleen for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/845 From hseigel at openjdk.java.net Tue Oct 27 12:30:25 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 27 Oct 2020 12:30:25 GMT Subject: Integrated: 8255342: Remove non-specified JVM checks on Classes with Record attributes In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 20:30:23 GMT, Harold Seigel wrote: > Please review this fix to remove the checks for non-final and abstract classes containing Record attributes and checks for classes containing Record attributes whose supers are not java.lang.Record. These checks are not specified in the JVM Spec and so should not be done by the JVM. > > The change removes the checks and updates Record tests as needed. > > The fix was tested with mach5 tiers 1 and 2 on Linux, Windows, and Mac, and tiers 3-5 on Linux x64 and with JCK lang, vm, and api/java_lang tests. > > Thanks, Harold This pull request has now been integrated. Changeset: 18d9905c Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/18d9905c Stats: 375 lines in 6 files changed: 332 ins; 22 del; 21 mod 8255342: Remove non-specified JVM checks on Classes with Record attributes Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/845 From redestad at openjdk.java.net Tue Oct 27 14:18:31 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 27 Oct 2020 14:18:31 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr Message-ID: The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: [5.428s][debug][heapsampling] log2, 0.0751173 secs [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs I've verified that this refactoring does not affect performance in this naive setup. [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 ------------- Commit messages: - Refactor ThreadHeapSampler::_log_table as constexpr Changes: https://git.openjdk.java.net/jdk/pull/880/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255455 Stats: 23 lines in 2 files changed: 7 ins; 6 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/880/head:pull/880 PR: https://git.openjdk.java.net/jdk/pull/880 From dcubed at openjdk.java.net Tue Oct 27 14:32:23 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 27 Oct 2020 14:32:23 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 14:00:34 GMT, Claes Redestad wrote: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Since the Low Overhead Heap Profiler project is accessible via JVM/TI, you should probably include the Serviceability team in the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Tue Oct 27 14:56:33 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 27 Oct 2020 14:56:33 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v2] In-Reply-To: References: Message-ID: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into threadHeapSampler_constexpr - Remove _log_table_initialized assert - Refactor ThreadHeapSampler::_log_table as constexpr ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/880/files - new: https://git.openjdk.java.net/jdk/pull/880/files/2a66158a..f28b9cc4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=00-01 Stats: 1880 lines in 75 files changed: 1373 ins; 312 del; 195 mod Patch: https://git.openjdk.java.net/jdk/pull/880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/880/head:pull/880 PR: https://git.openjdk.java.net/jdk/pull/880 From ccheung at openjdk.java.net Tue Oct 27 16:22:19 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 27 Oct 2020 16:22:19 GMT Subject: Integrated: 8253920: Share method trampolines in CDS dynamic archive In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 18:12:16 GMT, Calvin Cheung wrote: > This patch is to allow sharing of the same method trampoline for archived Methods with the same AdapterHandleEntry when using CDS dynamic archive. > > Running javac on HelloWorld with CDS dynamic archive, the number of calls to SharedRuntime::generate_trampoline() is reduced to 406 times vs 12601 times without the patch. > > In terms of saving on instructions and time (on linux-x64): > instr delta = -2807662 -0.1369% > time delta = -6.860 ms -1.8798% > > It passed tiers 1,2,3,4 testing. This pull request has now been integrated. Changeset: 84e985da Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/84e985da Stats: 227 lines in 8 files changed: 125 ins; 92 del; 10 mod 8253920: Share method trampolines in CDS dynamic archive Reviewed-by: redestad, minqi, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/868 From richard.reingruber at sap.com Tue Oct 27 16:43:13 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Tue, 27 Oct 2020 16:43:13 +0000 Subject: Is _thread_in_native safe for handshake/safepoint? In-Reply-To: References: Message-ID: Hi Robbin, thanks for picking up the questions. > I think the main reason for not making the stack walkable is to avoid > register flushes. Since we do not have such hardware anymore in mainline > I see no reason to skip making the stack walkable. Yeah, avoiding register flushes would be a reason but practically always the stack is made walkable before changing to _thread_in_native (also in 11u which still supports SPARC). That's why I asked myself if there are code paths which don't do that. > I find two places, JFR and ~ThreadInVMfromNative(). > The JavaThreadInVMAndNative should be replaced. Ok. > In case of ThreadInVMfromNative I guess the idea is that when going from > java -> native we already did the stack walkable and then calling e.g. > JNI we avoid it. And you are probably going to do many JNI calls. > So fixing those two maybe we can simplify to: > > 650 case _thread_in_native: > > 654 case _thread_blocked: > > 657 assert(!thread->has_last_Java_frame() || > thread->frame_anchor()->walkable(), "blocked and not walkable"); > > 658 return true; > Which would be very nice. That would be surely very nice :) But what needs to be fixed in ThreadInVMfromNative? I suppose the (java part of the) stack is walkable when the instance is created or there is no frame on stack. This could be asserted like in line 657 above. Then it is still walkable when the instance is destructed, isn't it? > We are looking into some simplifications of transitions, since after > "8203469: Faster safepoints" blocked and native are almost identical. > Essential two super-states thread-safe (blocked/native) and > thread-unsafe(all other). Having the same 'rules' for walkable stack > certainly helps. I see. > Does this answer your question(s)? To some extent. Unfortunately I haven't understood your answers completely. Anyways thanks! Cheers, Richard. -----Original Message----- From: Robbin Ehn Sent: Dienstag, 27. Oktober 2020 09:16 To: Reingruber, Richard ; Hotspot dev runtime Subject: Re: Is _thread_in_native safe for handshake/safepoint? Hi Richard, I think the main reason for not making the stack walkable is to avoid register flushes. Since we do not have such hardware anymore in mainline I see no reason to skip making the stack walkable. I find two places, JFR and ~ThreadInVMfromNative(). The JavaThreadInVMAndNative should be replaced. In case of ThreadInVMfromNative I guess the idea is that when going from java -> native we already did the stack walkable and then calling e.g. JNI we avoid it. And you are probably going to do many JNI calls. So fixing those two maybe we can simplify to: > 650 case _thread_in_native: > 654 case _thread_blocked: > 657 assert(!thread->has_last_Java_frame() || thread->frame_anchor()->walkable(), "blocked and not walkable"); > 658 return true; Which would be very nice. We are looking into some simplifications of transitions, since after "8203469: Faster safepoints" blocked and native are almost identical. Essential two super-states thread-safe (blocked/native) and thread-unsafe(all other). Having the same 'rules' for walkable stack certainly helps. Does this answer your question(s)? Thanks, Robbin On 2020-10-22 16:22, Reingruber, Richard wrote: > Hi, > > I don't understand the method safepoint_safe_with() in safepoint.cpp > Maybe somebody has a quick answer to the questions below... > > 648 static bool safepoint_safe_with(JavaThread *thread, JavaThreadState state) { > 649 switch(state) { > 650 case _thread_in_native: > 651 // native threads are safe if they have no java stack or have walkable stack > 652 return !thread->has_last_Java_frame() || thread->frame_anchor()->walkable(); > 653 > 654 case _thread_blocked: > 655 // On wait_barrier or blocked. > 656 // Blocked threads should already have walkable stack. > 657 assert(!thread->has_last_Java_frame() || thread->frame_anchor()->walkable(), "blocked and not walkable"); > 658 return true; > 659 > 660 default: > 661 return false; > 662 } > 663 } > > I thought _thread_in_native and _thread_blocked are both equally safe for > handshakes/safepoints but that method makes a distinction. Looking at line 652 > it seems possible that a thread is _thread_in_native without a walkable > stack. The thread is then of course considered not safe. Native wrappers, native > interpreter entries, ThreadToNativeFromVM change the state to _thread_in_native > after making the stack walkable though (I looked also at the old sparc versions). > > So how can a thread be _thread_in_native without a walkable stack? And why does > that state make sense when it blocks handshakes/safepoints? > > I found JavaThreadInVMAndNative which seems to set the state to > _thread_in_native without making the stack walkable. It seems though that from > there ThreadInVMfromNative is reachable which can trigger an assertion in > JavaThread::check_safepoint_and_suspend_for_native_trans() if the stack isn't > walkable. > > JfrRecorderService::invoke_safepoint_write() : void > JfrRecorderService::write() : void > JfrRecorderService::finalize_current_chunk() : void > JfrRecorderService::chunk_rotation() : void > JfrRecorderService::rotate(int) : void > JfrEmergencyDump::on_vm_shutdown(bool) : void > > Thanks, Richard. > From jrose at openjdk.java.net Tue Oct 27 16:47:24 2020 From: jrose at openjdk.java.net (John R Rose) Date: Tue, 27 Oct 2020 16:47:24 GMT Subject: RFR: 8255342: Remove non-specified JVM checks on Classes with Record attributes [v2] In-Reply-To: References: Message-ID: <7DA_SROWspIl17dyMpRD9x4Tnkyjj9e5yLX00KVtQOw=.f44745dd-9d78-4fa9-822f-261685a3e8a3@github.com> On Tue, 27 Oct 2020 12:21:22 GMT, Harold Seigel wrote: >> Looks good, Harold! > > Thanks David and Coleen for the reviews! This was a good example of a VM anti-pattern that's easy to fall into, which I call "The Gratuitous Restriction". There's a wide range of correctness checks the VM *could* do, but deciding which ones it *should* do is surprisingly subtle. When designing a new feature, there's a certain impulse to reject every suspicious input, and even to fish around in the design asking "what can we reject, that doesn't appear to have a meaning?" This impulse is (often) rooted in a legitimate desire to reduce implementation work by constraining inputs (rejecting a class file before trying to interpret something that smells funny). But there are four downsides: 1. The rejected thing might turn out to have a meaning after all, but now we are blocked from discovering what it might be. (This is my favorite. When once we said "value types can't extend abstract classes", I thought, "yeah, that's what we're saying now; just wait a while.") 2. The rejection we threw into the code to save ourselves work has to be rigorously specified in the JVMS and kept there forever. (We may get tired of looking at it, and it may obscure more important material in the JVMS.) 3. The rejection we threw into the code to save ourselves work has to be maintained forever, and if we ever disturb it our own VM will be non-compliant with the JVMS. (We may get tired of maintaining it.) 4. Maybe, if you get into the habit of making them, they can build up as performance debt. Enough extra checks will start to slow down the JVM. ------------- PR: https://git.openjdk.java.net/jdk/pull/845 From forax at univ-mlv.fr Tue Oct 27 17:11:22 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 27 Oct 2020 18:11:22 +0100 (CET) Subject: RFR: 8255342: Remove non-specified JVM checks on Classes with Record attributes [v2] In-Reply-To: <7DA_SROWspIl17dyMpRD9x4Tnkyjj9e5yLX00KVtQOw=.f44745dd-9d78-4fa9-822f-261685a3e8a3@github.com> References: <7DA_SROWspIl17dyMpRD9x4Tnkyjj9e5yLX00KVtQOw=.f44745dd-9d78-4fa9-822f-261685a3e8a3@github.com> Message-ID: <1286200946.905530.1603818682163.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "John R Rose" > ?: "hotspot-runtime-dev" > Envoy?: Mardi 27 Octobre 2020 17:47:24 > Objet: Re: RFR: 8255342: Remove non-specified JVM checks on Classes with Record attributes [v2] > On Tue, 27 Oct 2020 12:21:22 GMT, Harold Seigel wrote: > >>> Looks good, Harold! >> >> Thanks David and Coleen for the reviews! > > This was a good example of a VM anti-pattern that's easy to fall into, which I > call "The Gratuitous Restriction". There's a wide range of correctness checks > the VM *could* do, but deciding which ones it *should* do is surprisingly > subtle. When designing a new feature, there's a certain impulse to reject > every suspicious input, and even to fish around in the design asking "what can > we reject, that doesn't appear to have a meaning?" This impulse is (often) > rooted in a legitimate desire to reduce implementation work by constraining > inputs (rejecting a class file before trying to interpret something that smells > funny). But there are four downsides: > > 1. The rejected thing might turn out to have a meaning after all, but now we are > blocked from discovering what it might be. (This is my favorite. When once we > said "value types can't extend abstract classes", I thought, "yeah, that's what > we're saying now; just wait a while.") by example, in the future an enum may have record components but not inherits from java.lang.Record enum Color(int red, int green, blue) { RED(255, 0, 0), ... } > > 2. The rejection we threw into the code to save ourselves work has to be > rigorously specified in the JVMS and kept there forever. (We may get tired of > looking at it, and it may obscure more important material in the JVMS.) > > 3. The rejection we threw into the code to save ourselves work has to be > maintained forever, and if we ever disturb it our own VM will be non-compliant > with the JVMS. (We may get tired of maintaining it.) > > 4. Maybe, if you get into the habit of making them, they can build up as > performance debt. Enough extra checks will start to slow down the JVM. R?mi From sgehwolf at openjdk.java.net Tue Oct 27 19:06:19 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 27 Oct 2020 19:06:19 GMT Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code In-Reply-To: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> Message-ID: On Mon, 12 Oct 2020 13:24:16 GMT, Severin Gehwolf wrote: > Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). > > When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too. > > Thoughts? @bobvandette Could you please take a look at this when you get a chance? I'd like to get this in before I propose [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) which would enable us to have better tests for all sorts of corner cases irrespective of the system it runs on. ------------- PR: https://git.openjdk.java.net/jdk/pull/609 From hseigel at openjdk.java.net Tue Oct 27 19:56:30 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 27 Oct 2020 19:56:30 GMT Subject: RFR: 8243583: Change 'final' error checks to throw ICCE Message-ID: Please review this small change to throw IncompatibleClassChangeError exceptions instead of VerifyError exceptions for attempts to override Final classes and methods, as described in https://bugs.openjdk.java.net/browse/JDK-8243582. The fix was tested with tiers 1-2 on Linux, Mac OSX, and Windows, tiers 3-5 on Linux x64, and running the JCK lang, vm, and api tests. Thanks, Harold ------------- Commit messages: - 8243583: Change 'final' error checks to throw ICCE Changes: https://git.openjdk.java.net/jdk/pull/885/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=885&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243583 Stats: 29 lines in 4 files changed: 0 ins; 9 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/885.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/885/head:pull/885 PR: https://git.openjdk.java.net/jdk/pull/885 From gziemski at openjdk.java.net Tue Oct 27 20:42:18 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 27 Oct 2020 20:42:18 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked In-Reply-To: References: <6Qir6UY5T9RhSbYyV4u41W7BdgKO3WBBxwgDAOvPt8o=.f4e4a032-1d5e-42b0-a97b-4be59754c598@github.com> Message-ID: On Mon, 26 Oct 2020 11:43:54 GMT, Thomas Stuefe wrote: >> Hi Thomas, >> >> I think this has highlighted a number of bugs with our signal handling code in general. It makes no sense to ever block these synchronous signals, so any code that does so seems flawed. You also point out the semantics of sa_sigaction.sa_mask which highlights that call_chained_handler is incorrect as it tries to emulate the conditions under which the original handler would have been called, but it explicitly sets a sigmask from sa_mask instead of combining it with the existing sigmask. >> >> Aside: I also noticed the SR_sigset is unused, so unclear if we have a bug lurking in PosixSignals::SR_initialize. There is some commentary about the blocked/unblocked status of SR_signum that also seems wrong. >> >> That all said ... AFAICS the synchronous signals are all explicitly unblocked via PosixSignals::hotspot_sigmask which is set when a new thread starts executing, or an existing thread attaches. So from that point we should only need to ensure those signals are not explicitly blocked - which means that in os::signal we unblock them in sa_mask for all platforms. Does that not suffice? Or are you concerned about user native code changing the signal masks arbitrarily? In which case re-setting in each of the VM's signal handlers would be reasonable. >> >> Note that SIGTRAP is currently mostly only processed under #if defined(PPC64)and/or defined(AIX). >> >> Thanks, >> David > >> Hi Thomas, >> >> I think this has highlighted a number of bugs with our signal handling code in general. It makes no sense to ever block these synchronous signals, so any code that does so seems flawed. You also point out the semantics of sa_sigaction.sa_mask which highlights that call_chained_handler is incorrect as it tries to emulate the conditions under which the original handler would have been called, but it explicitly sets a sigmask from sa_mask instead of combining it with the existing sigmask. >> > > Yes, this coding may benefit from a bit more grooming (but preferably in another RFE). > >> Aside: I also noticed the SR_sigset is unused, so unclear if we have a bug lurking in PosixSignals::SR_initialize. There is some commentary about the blocked/unblocked status of SR_signum that also seems wrong. >> >> That all said ... AFAICS the synchronous signals are all explicitly unblocked via PosixSignals::hotspot_sigmask which is set when a new thread starts executing, or an existing thread attaches. So from that point we should only need to ensure those signals are not explicitly blocked - which means that in os::signal we unblock them in sa_mask for all platforms. Does that not suffice? Or are you concerned about user native code changing the signal masks arbitrarily? In which case re-setting in each of the VM's signal handlers would be reasonable. >> > > You are right. This is what I tried to say with "sa_sigaction.sa_mask vs pthread_sigmask". > > I chose explicit unblocking over setting the signal mask when establishing the handler because I was concerned about someone changing the thread signal mask after handler is installed and before the signal is triggered. Especially I am not sure what happens if some native code calls sigprocmask() - does that affect all threads, only this thread? Posix says its undefined. Because I did not want to think about all this, and because I found it slightly more obvious, I unblock explicitly. > > That said, it was a bit of a coin toss, and if you dislike this, we can do it via sigaction.sa_mask instead. The danger of someone blocking synchronous error signals under our nose is probably remote :) > >> Note that SIGTRAP is currently mostly only processed under #if defined(PPC64)and/or defined(AIX). > > Yes, we use it for implicit null checks. But this has only meaning outside of signal handling. I unblocked it inside signal handlers because I found vague reports of processes crashing with blocked SIGTRAPs and thought that the same reasoning may apply to this signal wrt to blocking in signal handlers. > > Blocking SIGTRAP has been handled inconsistently, too. It had been unblocked at the entrance of the secondary error handler for all platforms (see vmError_posix.cpp) but not in general error handling. I think that is an oversight. > >> >> Thanks, >> David > > Thanks, Thomas hi Thomas, Looks good as far as I can tell. I'm still learning the POSIX signal code, so excuse the question, but if our signal handlers are capable of handling the synchronous signals while doing fatal error handling, then why don't we unblock it for all the signals, so that we can handle any kind of a situation inside the fatal error handling? Also, since we're touching the "VMError::reset_signal_handlers()" any chance we can improve on the name here, as you yourself suggested in other review? cheers ------------- PR: https://git.openjdk.java.net/jdk/pull/839 From lfoltan at openjdk.java.net Tue Oct 27 20:45:23 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Tue, 27 Oct 2020 20:45:23 GMT Subject: RFR: 8243583: Change 'final' error checks to throw ICCE In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 19:48:25 GMT, Harold Seigel wrote: > Please review this small change to throw IncompatibleClassChangeError exceptions instead of VerifyError exceptions for attempts to override Final classes and methods, as described in https://bugs.openjdk.java.net/browse/JDK-8243582. > > The fix was tested with tiers 1-2 on Linux, Mac OSX, and Windows, tiers 3-5 on Linux x64, and running the JCK lang, vm, and api tests. > > Thanks, Harold Looks good Harold! Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/885 From iklam at openjdk.java.net Tue Oct 27 23:11:20 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 27 Oct 2020 23:11:20 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v2] In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 14:56:33 GMT, Claes Redestad wrote: >> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. >> >> I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: >> >> [5.428s][debug][heapsampling] log2, 0.0751173 secs >> [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs >> [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs >> >> I've verified that this refactoring does not affect performance in this naive setup. >> >> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into threadHeapSampler_constexpr > - Remove _log_table_initialized assert > - Refactor ThreadHeapSampler::_log_table as constexpr Changes requested by iklam (Reviewer). src/hotspot/share/runtime/threadHeapSampler.cpp line 48: > 46: }; > 47: > 48: const FastLogTable ThreadHeapSampler::_log_table; To guarantee that `_log_table` is evaluated at C++ compile time, it's best to change the code to constexpr FastLogTable _log_table; There are 2 reasons: 1. C++ guarantees compile-time evaluation only if the expression is used in a "constexpr context". You can read more from [here](https://isocpp.org/blog/2013/01/when-does-a-constexpr-function-get-evaluated-at-compile-time-stackoverflow). 2. In the future, if the `FastLogTable` constructor is modified in a way that cannot be evaluated at compile time, (e.g., someone removes `constexpr` from the constructor's declaration by mistake, the C++ compiler will catch that and tell you that `_log_table` cannot be `constexpr`. Unfortunately, you cannot use `constexpr` in forward declarations, so you should either move the definition of `FastLogTable` to the hpp file, or remove the declaration of `_log_table` from the hpp file. ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From stuefe at openjdk.java.net Wed Oct 28 06:39:19 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 28 Oct 2020 06:39:19 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked In-Reply-To: References: <6Qir6UY5T9RhSbYyV4u41W7BdgKO3WBBxwgDAOvPt8o=.f4e4a032-1d5e-42b0-a97b-4be59754c598@github.com> Message-ID: <4Ky44Ag_zqIlhUtoClFuErb1XuWWvxMVCuh1E4hsFTQ=.dc7d0c6d-2b98-4c59-ae26-1ac2e598ae69@github.com> On Tue, 27 Oct 2020 20:39:17 GMT, Gerard Ziemski wrote: > hi Thomas, > > Looks good as far as I can tell. > Thank you! > I'm still learning the POSIX signal code, so excuse the question, but if our signal handlers are capable of handling the synchronous signals while doing fatal error handling, then why don't we unblock it for all the signals, so that we can handle any kind of a situation inside the fatal error handling? Its unnecessary and safer. When signals which can be deferred (lets say, SIGPIPE or SIGCHILD) happen while they are blocked in the receiving thread's signal mask, nothing really happens: they are just added to an internal kernel queue for the time being, until the receiving thread unblocks, eg. by returning from signal handling. Were they unblocked and happen to be delivered to the thread during fatal error handling - so, the reporting thread is somewhere inside VMError::report(), working on one of the error reporting steps - the error reporting step gets interrupted and we execute (in a new call frame): crash_handler(SIGPIPE) -> VMError::report_and_die(SIGPIPE) -> _first_error_tid == our tid -> we print "[Error occurred during error reporting" into the hs-err file -> re-enter VM::report() again. Now call stack looks like this: javaSignalHandler & JVM_handle_xx_signal VMError::report_and_die VMError::report crash_handler VMError::report_and_die VMError::report When re-entering VMError::report(), we skip the error reporting step during which we got the second signal, because we assume it was an error signal. We just continue with the next step. The whole thing is quite ingenious in that it allows us to do all kind of unsafe things for the sake of error reporting. If one step fails, it does not endanger the next step. Also, we never unwind the stack, so when we dump the core after error handling, we have the full stack (plus 0-n incarnations of above frames). Unwinding the stack may also be dangerous since the stack may be corrupted. The only caveat is that we artificially limit the number of recursive error signals that can happen to 30 (not sure why) and of course we may run out of stack after too many recursive errors. Bottomline, that whole mechanism is written with synchronous error signals in mind, and we would have to rethink it if we allow all signals (eg it would not be necessary to skip an error reporting step because we get a SIGPIPE). Since blocking works fine for those signals, there is no need to do this. > > Also, since we're touching the "VMError::reset_signal_handlers()" any chance we can improve on the name here, as you yourself suggested in other review? Sure, but I'd like to do this in a separate patch. I was actually counting on you in that other patch :) but I have some vague cleanup in mind at some point, unless you are faster. Cheers, Thomas > > cheers ------------- PR: https://git.openjdk.java.net/jdk/pull/839 From dholmes at openjdk.java.net Wed Oct 28 06:41:18 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Oct 2020 06:41:18 GMT Subject: RFR: 8243583: Change 'final' error checks to throw ICCE In-Reply-To: References: Message-ID: <-o6Gy_hXEQ81Rcg6cU1p8VraE9um5fReXroPoNIC53s=.3e3d478b-4ed4-4864-a401-ff3fba20d3da@github.com> On Tue, 27 Oct 2020 19:48:25 GMT, Harold Seigel wrote: > Please review this small change to throw IncompatibleClassChangeError exceptions instead of VerifyError exceptions for attempts to override Final classes and methods, as described in https://bugs.openjdk.java.net/browse/JDK-8243582. > > The fix was tested with tiers 1-2 on Linux, Mac OSX, and Windows, tiers 3-5 on Linux x64, and running the JCK lang, vm, and api tests. > > Thanks, Harold Looks good! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/885 From shade at openjdk.java.net Wed Oct 28 09:54:20 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 28 Oct 2020 09:54:20 GMT Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code [v3] In-Reply-To: <5Jk_4mxRk_8rIaxUY9NhUNhOmjdIuRuV-KWzeSrLkaI=.07c9a141-6335-4e52-8aff-3fcbfce02a17@github.com> References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> <5Jk_4mxRk_8rIaxUY9NhUNhOmjdIuRuV-KWzeSrLkaI=.07c9a141-6335-4e52-8aff-3fcbfce02a17@github.com> Message-ID: On Fri, 23 Oct 2020 15:51:47 GMT, Severin Gehwolf wrote: >> Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). >> >> When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too. >> >> Thoughts? > > Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. This looks okay to me. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/609 From stuefe at openjdk.java.net Wed Oct 28 10:25:18 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 28 Oct 2020 10:25:18 GMT Subject: RFR: JDK-8254189: Improve comments for StackOverFlow and fix in_xxx() functions [v2] In-Reply-To: References: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> Message-ID: On Tue, 27 Oct 2020 08:04:41 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback David > > Marked as reviewed by dholmes (Reviewer). Ping... May I have a second review please? Its quite trivial. Patch was tested in our internal systems and no problems surfaced. ------------- PR: https://git.openjdk.java.net/jdk/pull/795 From hseigel at openjdk.java.net Wed Oct 28 12:37:45 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 28 Oct 2020 12:37:45 GMT Subject: RFR: 8243583: Change 'final' error checks to throw ICCE In-Reply-To: <-o6Gy_hXEQ81Rcg6cU1p8VraE9um5fReXroPoNIC53s=.3e3d478b-4ed4-4864-a401-ff3fba20d3da@github.com> References: <-o6Gy_hXEQ81Rcg6cU1p8VraE9um5fReXroPoNIC53s=.3e3d478b-4ed4-4864-a401-ff3fba20d3da@github.com> Message-ID: On Wed, 28 Oct 2020 06:38:07 GMT, David Holmes wrote: >> Please review this small change to throw IncompatibleClassChangeError exceptions instead of VerifyError exceptions for attempts to override Final classes and methods, as described in https://bugs.openjdk.java.net/browse/JDK-8243582. >> >> The fix was tested with tiers 1-2 on Linux, Mac OSX, and Windows, tiers 3-5 on Linux x64, and running the JCK lang, vm, and api tests. >> >> Thanks, Harold > > Looks good! > > Thanks, > David Thanks David and Lois for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/885 From hseigel at openjdk.java.net Wed Oct 28 12:37:46 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 28 Oct 2020 12:37:46 GMT Subject: Integrated: 8243583: Change 'final' error checks to throw ICCE In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 19:48:25 GMT, Harold Seigel wrote: > Please review this small change to throw IncompatibleClassChangeError exceptions instead of VerifyError exceptions for attempts to override Final classes and methods, as described in https://bugs.openjdk.java.net/browse/JDK-8243582. > > The fix was tested with tiers 1-2 on Linux, Mac OSX, and Windows, tiers 3-5 on Linux x64, and running the JCK lang, vm, and api tests. > > Thanks, Harold This pull request has now been integrated. Changeset: 3bd5b807 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/3bd5b807 Stats: 29 lines in 4 files changed: 0 ins; 9 del; 20 mod 8243583: Change 'final' error checks to throw ICCE Reviewed-by: lfoltan, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/885 From sgehwolf at openjdk.java.net Wed Oct 28 13:49:53 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 28 Oct 2020 13:49:53 GMT Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code [v4] In-Reply-To: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> Message-ID: > Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). > > When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too. > > Thoughts? Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8253939: [TESTBUG] Increase coverage of the cgroups detection code ------------- Changes: https://git.openjdk.java.net/jdk/pull/609/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=609&range=03 Stats: 147 lines in 2 files changed: 134 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/609/head:pull/609 PR: https://git.openjdk.java.net/jdk/pull/609 From redestad at openjdk.java.net Wed Oct 28 14:11:04 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 28 Oct 2020 14:11:04 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v3] In-Reply-To: References: Message-ID: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Declare and define log_table as a static constexpr inside threadHeapSampler.cpp - Merge branch 'master' into threadHeapSampler_constexpr - Merge branch 'master' into threadHeapSampler_constexpr - Remove _log_table_initialized assert - Refactor ThreadHeapSampler::_log_table as constexpr ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/880/files - new: https://git.openjdk.java.net/jdk/pull/880/files/f28b9cc4..62148744 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=01-02 Stats: 922 lines in 50 files changed: 556 ins; 221 del; 145 mod Patch: https://git.openjdk.java.net/jdk/pull/880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/880/head:pull/880 PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Wed Oct 28 14:18:51 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 28 Oct 2020 14:18:51 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v2] In-Reply-To: References: Message-ID: <38r92xz8Q0CM1q6V0YFmrO739eO3mz0ZLNSo0wU6_So=.b6155b44-0468-479e-8a89-a6b770f719a9@github.com> On Tue, 27 Oct 2020 23:08:13 GMT, Ioi Lam wrote: >> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into threadHeapSampler_constexpr >> - Remove _log_table_initialized assert >> - Refactor ThreadHeapSampler::_log_table as constexpr > > src/hotspot/share/runtime/threadHeapSampler.cpp line 48: > >> 46: }; >> 47: >> 48: const FastLogTable ThreadHeapSampler::_log_table; > > To guarantee that `_log_table` is evaluated at C++ compile time, it's best to change the code to > > constexpr FastLogTable _log_table; > > There are 2 reasons: > > 1. C++ guarantees compile-time evaluation only if the expression is used in a "constexpr context". You can read more from [here](https://isocpp.org/blog/2013/01/when-does-a-constexpr-function-get-evaluated-at-compile-time-stackoverflow). > 2. In the future, if the `FastLogTable` constructor is modified in a way that cannot be evaluated at compile time, (e.g., someone removes `constexpr` from the constructor's declaration by mistake, the C++ compiler will catch that and tell you that `_log_table` cannot be `constexpr`. > > Unfortunately, you cannot use `constexpr` in forward declarations, so you should either move the definition of `FastLogTable` to the hpp file, or remove the declaration of `_log_table` from the hpp file. Ok, makes sense. I went with removing the `_log_table` declaration from the hpp file. I think things came out a bit cleaner as a result, too. ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Wed Oct 28 14:36:59 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 28 Oct 2020 14:36:59 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v4] In-Reply-To: References: Message-ID: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into threadHeapSampler_constexpr - Declare and define log_table as a static constexpr inside threadHeapSampler.cpp - Merge branch 'master' into threadHeapSampler_constexpr - Merge branch 'master' into threadHeapSampler_constexpr - Remove _log_table_initialized assert - Refactor ThreadHeapSampler::_log_table as constexpr ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/880/files - new: https://git.openjdk.java.net/jdk/pull/880/files/62148744..f796147d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=02-03 Stats: 364 lines in 32 files changed: 294 ins; 21 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/880/head:pull/880 PR: https://git.openjdk.java.net/jdk/pull/880 From gziemski at openjdk.java.net Wed Oct 28 15:30:49 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 28 Oct 2020 15:30:49 GMT Subject: RFR: JDK-8254189: Improve comments for StackOverFlow and fix in_xxx() functions [v2] In-Reply-To: References: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> Message-ID: <1mgAVjauAYD2CYYYwk7A97b_5Pb9AJh9Aazr4bXsIjk=.af64a3e8-a28b-4b6e-ae69-5d3a29ceba9a@github.com> On Tue, 27 Oct 2020 07:27:33 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for this small cleanup / fix? >> >> While reviewing JDK-8253717 it was found that comments would help with understanding the StackOverFlow class. Especially the fact that the various _base_ are actually pointing outside their respective zone, since the stack grows downward and a zone (and the stack itself) range is [end, base). If you don't look at this code daily it can be surprising. >> >> This also fixes some small off-by-one errors in various "in_stack_xxx_zone()" methods which test whether a given address is inside a zone and gave wrong results for address=base since base points outside its zone. This had the effect that an address could be in multiple zones. >> >> Finally it adds a small gtest which tests the StackOverFlow methods. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback David Marked as reviewed by gziemski (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/795 From gziemski at openjdk.java.net Wed Oct 28 15:30:50 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 28 Oct 2020 15:30:50 GMT Subject: RFR: JDK-8254189: Improve comments for StackOverFlow and fix in_xxx() functions [v2] In-Reply-To: References: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> Message-ID: On Wed, 28 Oct 2020 10:22:38 GMT, Thomas Stuefe wrote: >> Marked as reviewed by dholmes (Reviewer). > > Ping... May I have a second review please? Its quite trivial. > Patch was tested in our internal systems and no problems surfaced. Very nice. Personally I'd like to see additional: ASSERT_TRUE(so.in_stack_red_zone(so.stack_end())); ASSERT_TRUE(so.in_stack_yellow_zone(so.stack_red_zone_base())); ASSERT_TRUE(so.in_stack_reserved_zone(so.stack_yellow_zone_base())); in the test, to drive home the point of the inclusion of the ranges, but that's a tiny nick pick. ------------- PR: https://git.openjdk.java.net/jdk/pull/795 From redestad at openjdk.java.net Wed Oct 28 15:36:46 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 28 Oct 2020 15:36:46 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v2] In-Reply-To: References: Message-ID: <4nmtA7n_BrVDrnFAa0ytD4iKBjYTxhTRPtPGV4agWnU=.c44fa156-775b-4d19-948d-efcede4969a0@github.com> On Tue, 27 Oct 2020 23:08:21 GMT, Ioi Lam wrote: >> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into threadHeapSampler_constexpr >> - Remove _log_table_initialized assert >> - Refactor ThreadHeapSampler::_log_table as constexpr > > Changes requested by iklam (Reviewer). The change to declare the log_table as constexpr exposed an issue with the std `log` function not being constexpr, which now cause a build error on Windows and Mac. It works on Linux, but likely not robustly so since I seem to have been stumbling into a non-compliant quirk: https://stackoverflow.com/questions/50477974/constexpr-exp-log-pow ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From bobv at openjdk.java.net Wed Oct 28 15:45:52 2020 From: bobv at openjdk.java.net (Bob Vandette) Date: Wed, 28 Oct 2020 15:45:52 GMT Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code [v4] In-Reply-To: References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> Message-ID: On Wed, 28 Oct 2020 13:49:53 GMT, Severin Gehwolf wrote: >> Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). >> >> When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too. >> >> Thoughts? > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: > > 8253939: [TESTBUG] Increase coverage of the cgroups detection code Looks good. ------------- Marked as reviewed by bobv (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/609 From stuefe at openjdk.java.net Wed Oct 28 16:30:49 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 28 Oct 2020 16:30:49 GMT Subject: RFR: JDK-8254189: Improve comments for StackOverFlow and fix in_xxx() functions [v2] In-Reply-To: <1mgAVjauAYD2CYYYwk7A97b_5Pb9AJh9Aazr4bXsIjk=.af64a3e8-a28b-4b6e-ae69-5d3a29ceba9a@github.com> References: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> <1mgAVjauAYD2CYYYwk7A97b_5Pb9AJh9Aazr4bXsIjk=.af64a3e8-a28b-4b6e-ae69-5d3a29ceba9a@github.com> Message-ID: <9Sj0l5FMyS8wwBluxI3KTzU_ApacFWTGF61eQeXV2EQ=.dc391d65-cc96-4bd1-a6cd-63aaf542c7d8@github.com> On Wed, 28 Oct 2020 15:27:43 GMT, Gerard Ziemski wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback David > > Marked as reviewed by gziemski (Committer). > Very nice. Thank you, Gerard. > > Personally I'd like to see additional: > > ASSERT_TRUE(so.in_stack_red_zone(so.stack_end())); > ASSERT_TRUE(so.in_stack_yellow_zone(so.stack_red_zone_base())); > ASSERT_TRUE(so.in_stack_reserved_zone(so.stack_yellow_zone_base())); > > in the test, to drive home the point of the inclusion of the ranges, but that's a tiny nick pick. I can do this. Will have to reshape those a bit since there is no "in_yellow_zone" (I considered adding one for tests sake but then did not). ...Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/795 From gziemski at openjdk.java.net Wed Oct 28 16:58:50 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 28 Oct 2020 16:58:50 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 15:44:26 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews please for the following patch which takes care to unblock synchronous error signals at the entrance of our main signal handler (including some minor code cleanups). > > When a signal happens which cannot be deferred (SIGFPE, SIGILL, SIGSEGV, SIGBUS) but whose delivery is blocked, bad things happen. This is undefined territory, and we have observed the following cases: > > - on Linux, the default handler is invoked instead of the user handler, which in case of error signals causes the process to core immediately. This is actually one of the better outcomes, we still have a core. > - on AIX and PASE both, the process just becomes unresponsive and hangs. > - on HPUX - one of our internal platform - the process just vanishes without a trace. > > I did not test other platforms but would guess similar things happen there. Posix documentation [4] states: > _"If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated while they are blocked, the result is undefined, unless the signal was generated by the kill() function, the sigqueue() function, or the raise() function."_ > > At the moment, undeferrable error signals are unblocked outside the signal handler (see hotspot sigmask) and, since JDK-8065895, inside the error handler (see crash_handler setup). This leaves us with a window where the hotspot signal handler runs but before he has decided to invoke fatal error handling. Inside that window, for any platform but AIX error signals are still blocked. So any crash inside them tears down the VM immediately without giving us a useful hs-err file. > > On AIX they are not blocked because we added an AIX-only patch a while ago which unblocks them at the entrance of the AIX signal handler. This was before we contributed the port to OpenJDK, so no history in the official repos. But that behavior makes sense for all posix platforms. > > For more details see discussion from Nov 2014 [2][3]. > > (Side note, these effects only show for truly synchronous error signals. You cannot artificially create such a scenario e.g. by raising SIGSEGV with kill.) > > About sa_sigaction.sa_mask vs pthread_sigmask: At the first glance, it would be more elegant to just unblock error signals in the signal mask specified when installing the signal handler. However, the way that mask works is that it is ANDed together with the process signal mask in effect when the signal was raised. So if one or more of the error signals were blocked at that point, they would continue to be blocked in the handler, sa_mask notwithstanding. > It seems easier and clearer to just manually unblock those signals at the entrance of our handlers. > > Changes in detail: > > - At the entrance of javaSignalHandler() we now unblock error signals for all platforms, not just for AIX. > - Nothing changes at the entrance of the secondary error handler (crash_handler()): just better code reuse. > - In os::signal(), for AIX only, we used to set the sa_mask for the handler-to-be-installed to unblock error signals. I decided to just remove this section. The reason is: I want to get rid of this AIX specific section, and was torn between leaving it in for all platforms or removing it. os::signal is used to install other signal handlers too, and I do not want to change their behavior with this patch. Therefore I just removed this section. > > Tests: > > I tested the change manually by triggering a segfault inside javaSignalHandler. That reliably tore down the process immediately. With this patch, once error signals are unblocked, we continue to run - we get the secondary crash, which then leads to VMError::report_and_die() called since its a real error (I prevented recursion for this test. See my comments about recursion in the JBS issue.) > > We will put this through our SAP internal tests before pushing. > > [1] https://bugs.openjdk.java.net/browse/JDK-8065895 > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-November/013346.html > [3] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-January/013718.html > [4] https://pubs.opengroup.org/onlinepubs/009695399/functions/sigprocmask.html Marked as reviewed by gziemski (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/839 From sgehwolf at openjdk.java.net Wed Oct 28 17:19:52 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 28 Oct 2020 17:19:52 GMT Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection code [v4] In-Reply-To: References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> Message-ID: On Wed, 28 Oct 2020 15:42:37 GMT, Bob Vandette wrote: >> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: >> >> 8253939: [TESTBUG] Increase coverage of the cgroups detection code > > Looks good. Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/609 From stuefe at openjdk.java.net Wed Oct 28 17:20:07 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 28 Oct 2020 17:20:07 GMT Subject: RFR: JDK-8254189: Improve comments for StackOverFlow and fix in_xxx() functions [v3] In-Reply-To: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> References: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> Message-ID: > Hi, > > may I please have reviews for this small cleanup / fix? > > While reviewing JDK-8253717 it was found that comments would help with understanding the StackOverFlow class. Especially the fact that the various _base_ are actually pointing outside their respective zone, since the stack grows downward and a zone (and the stack itself) range is [end, base). If you don't look at this code daily it can be surprising. > > This also fixes some small off-by-one errors in various "in_stack_xxx_zone()" methods which test whether a given address is inside a zone and gave wrong results for address=base since base points outside its zone. This had the effect that an address could be in multiple zones. > > Finally it adds a small gtest which tests the StackOverFlow methods. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Gerard ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/795/files - new: https://git.openjdk.java.net/jdk/pull/795/files/cc54ef8d..89f21f1a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=795&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=795&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/795.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/795/head:pull/795 PR: https://git.openjdk.java.net/jdk/pull/795 From stuefe at openjdk.java.net Wed Oct 28 17:20:07 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 28 Oct 2020 17:20:07 GMT Subject: RFR: JDK-8254189: Improve comments for StackOverFlow and fix in_xxx() functions [v2] In-Reply-To: <9Sj0l5FMyS8wwBluxI3KTzU_ApacFWTGF61eQeXV2EQ=.dc391d65-cc96-4bd1-a6cd-63aaf542c7d8@github.com> References: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> <1mgAVjauAYD2CYYYwk7A97b_5Pb9AJh9Aazr4bXsIjk=.af64a3e8-a28b-4b6e-ae69-5d3a29ceba9a@github.com> <9Sj0l5FMyS8wwBluxI3KTzU_ApacFWTGF61eQeXV2EQ=.dc391d65-cc96-4bd1-a6cd-63aaf542c7d8@github.com> Message-ID: On Wed, 28 Oct 2020 16:28:02 GMT, Thomas Stuefe wrote: >> Marked as reviewed by gziemski (Committer). > >> Very nice. > > Thank you, Gerard. > >> >> Personally I'd like to see additional: >> >> ASSERT_TRUE(so.in_stack_red_zone(so.stack_end())); >> ASSERT_TRUE(so.in_stack_yellow_zone(so.stack_red_zone_base())); >> ASSERT_TRUE(so.in_stack_reserved_zone(so.stack_yellow_zone_base())); >> >> in the test, to drive home the point of the inclusion of the ranges, but that's a tiny nick pick. > > I can do this. Will have to reshape those a bit since there is no "in_yellow_zone" (I considered adding one for tests sake but then did not). > > ...Thomas ... and StackOverFlow::stack_end() is private, so I cannot use it in ASSERT either... ------------- PR: https://git.openjdk.java.net/jdk/pull/795 From sgehwolf at openjdk.java.net Wed Oct 28 18:57:46 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 28 Oct 2020 18:57:46 GMT Subject: Integrated: 8253939: [TESTBUG] Increase coverage of the cgroups detection code In-Reply-To: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com> Message-ID: On Mon, 12 Oct 2020 13:24:16 GMT, Severin Gehwolf wrote: > Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). > > When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too. > > Thoughts? This pull request has now been integrated. Changeset: 42fc1589 Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/42fc1589 Stats: 147 lines in 2 files changed: 134 ins; 0 del; 13 mod 8253939: [TESTBUG] Increase coverage of the cgroups detection code Reviewed-by: shade, bobv ------------- PR: https://git.openjdk.java.net/jdk/pull/609 From sspitsyn at openjdk.java.net Wed Oct 28 20:00:55 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 28 Oct 2020 20:00:55 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v4] In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 14:36:59 GMT, Claes Redestad wrote: >> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. >> >> I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: >> >> [5.428s][debug][heapsampling] log2, 0.0751173 secs >> [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs >> [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs >> >> I've verified that this refactoring does not affect performance in this naive setup. >> >> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into threadHeapSampler_constexpr > - Declare and define log_table as a static constexpr inside threadHeapSampler.cpp > - Merge branch 'master' into threadHeapSampler_constexpr > - Merge branch 'master' into threadHeapSampler_constexpr > - Remove _log_table_initialized assert > - Refactor ThreadHeapSampler::_log_table as constexpr Hi Ioi and Claes, This looks nice. One nit: + _values[i] = (log(1.0 + static_cast(i+0.5) / N) / log(2.0)); Need spaces around '+' sign. Also, it can be just one line. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/880 From pchilanomate at openjdk.java.net Wed Oct 28 21:16:49 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 28 Oct 2020 21:16:49 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() Message-ID: Hi all, Please review the following patch that removes the call to handle_special_runtime_exit_condition() from SS::block(). This avoids recursive calls when transitioning and stopping for safepoints and also makes the code simpler to read since it is not trivial to deduce why we need to execute the check for certain states but not others, i.e. what exact scenarios we are trying to guard against. Method handle_special_runtime_exit_condition() checks for external suspends, object deoptimization, async exceptions and JFR suspends. All these need to be checked when transitioning to java and when transitioning out of native (except for async exceptions when transitioning to thread_in_vm). In SS::block() this check is executed for the _thread_new_trans, _thread_in_native_trans and thread_in_Java cases. For _thread_new_trans, we know the JT will have to go through JavaCallWrapper() the first time it transitions to Java and that already has a check for handle_special_runtime_exit_condition(). For _thread_in_native_trans, transitioning out of native already has checks for external suspends, object deoptimization and JFR suspends in check_safepoint_and_suspend_for_native_trans() which is called from ThreadStateTransition::transition_from_native()(called either directly or through the ThreadStateTransition wrappers) and check_special_condition_for_native_trans (for native wrappers case ). So that leaves the thread_in_Java case. Careful analysis shows the handle_special_runtime_exit_condition() call in SS::block() prevents JTs transitioning back to Java from escaping after being externally suspended. This can happen when calling SafepointMechanism::process_if_requested() while transitiong back to java without a later check for external suspend. Looking at the callers of SafepointMechanism::process_if_requested() we see that this can happen from handle_polling_page_exception(), java_suspend_self_with_safepoint_check() and check_safepoint_and_suspend_for_native_trans(). An example of this can be shown for the handle_polling_page_exception() case: - JT hits a poll exception while executing nmethod. - JT calls handle_polling_page_exception() ( which doesn't use ThreadStateTransition wrappers) and calls SafepointMechanism::process_if_requested() - Stops for a safepoint due to a VM_ThreadSuspend request - Upon unblocking from the safepoint, unless we have the check in SS::block() the JT will transition back to java without actually suspending The "escape from suspend" scenarios for the other callers of SafepointMechanism::process_if_requested() are described in the comments of the bug as well as the proper fixes. I have tested the patch several times in mach5 tiers1-7 and saw no issues. Let me know if you think I should run any other special tests. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.java.net/jdk/pull/913/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=913&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255384 Stats: 61 lines in 4 files changed: 7 ins; 37 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/913/head:pull/913 PR: https://git.openjdk.java.net/jdk/pull/913 From dholmes at openjdk.java.net Thu Oct 29 02:46:46 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 29 Oct 2020 02:46:46 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked In-Reply-To: References: Message-ID: On Fri, 23 Oct 2020 15:44:26 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews please for the following patch which takes care to unblock synchronous error signals at the entrance of our main signal handler (including some minor code cleanups). > > When a signal happens which cannot be deferred (SIGFPE, SIGILL, SIGSEGV, SIGBUS) but whose delivery is blocked, bad things happen. This is undefined territory, and we have observed the following cases: > > - on Linux, the default handler is invoked instead of the user handler, which in case of error signals causes the process to core immediately. This is actually one of the better outcomes, we still have a core. > - on AIX and PASE both, the process just becomes unresponsive and hangs. > - on HPUX - one of our internal platform - the process just vanishes without a trace. > > I did not test other platforms but would guess similar things happen there. Posix documentation [4] states: > _"If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated while they are blocked, the result is undefined, unless the signal was generated by the kill() function, the sigqueue() function, or the raise() function."_ > > At the moment, undeferrable error signals are unblocked outside the signal handler (see hotspot sigmask) and, since JDK-8065895, inside the error handler (see crash_handler setup). This leaves us with a window where the hotspot signal handler runs but before he has decided to invoke fatal error handling. Inside that window, for any platform but AIX error signals are still blocked. So any crash inside them tears down the VM immediately without giving us a useful hs-err file. > > On AIX they are not blocked because we added an AIX-only patch a while ago which unblocks them at the entrance of the AIX signal handler. This was before we contributed the port to OpenJDK, so no history in the official repos. But that behavior makes sense for all posix platforms. > > For more details see discussion from Nov 2014 [2][3]. > > (Side note, these effects only show for truly synchronous error signals. You cannot artificially create such a scenario e.g. by raising SIGSEGV with kill.) > > About sa_sigaction.sa_mask vs pthread_sigmask: At the first glance, it would be more elegant to just unblock error signals in the signal mask specified when installing the signal handler. However, the way that mask works is that it is ANDed together with the process signal mask in effect when the signal was raised. So if one or more of the error signals were blocked at that point, they would continue to be blocked in the handler, sa_mask notwithstanding. > It seems easier and clearer to just manually unblock those signals at the entrance of our handlers. > > Changes in detail: > > - At the entrance of javaSignalHandler() we now unblock error signals for all platforms, not just for AIX. > - Nothing changes at the entrance of the secondary error handler (crash_handler()): just better code reuse. > - In os::signal(), for AIX only, we used to set the sa_mask for the handler-to-be-installed to unblock error signals. I decided to just remove this section. The reason is: I want to get rid of this AIX specific section, and was torn between leaving it in for all platforms or removing it. os::signal is used to install other signal handlers too, and I do not want to change their behavior with this patch. Therefore I just removed this section. > > Tests: > > I tested the change manually by triggering a segfault inside javaSignalHandler. That reliably tore down the process immediately. With this patch, once error signals are unblocked, we continue to run - we get the secondary crash, which then leads to VMError::report_and_die() called since its a real error (I prevented recursion for this test. See my comments about recursion in the JBS issue.) > > We will put this through our SAP internal tests before pushing. > > [1] https://bugs.openjdk.java.net/browse/JDK-8065895 > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-November/013346.html > [3] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-January/013718.html > [4] https://pubs.opengroup.org/onlinepubs/009695399/functions/sigprocmask.html Hi Thomas, I still feel that we should never explicitly block these error signals given it leads to undefined behaviour. So I'd like to see a change to os::signal at least in a future RFE. For now I think all the signal handlers should explicitly unblock the error signals, which means the SR_handler also needs updating. Some other minor changes requested below. Thanks, David src/hotspot/os/posix/signals_posix.cpp line 471: > 469: #ifdef ASSERT > 470: if (rc != 0) { > 471: log_warning(os)("pthread_sigmask failed (%d)", errno); pthread_sigmask doesn't set errno, it returns the error code directly. But as there is only one defined error code for pthread_sigmask (EINVAL) this warning seem unnecessary. The usual assert_status would suffice. src/hotspot/os/posix/vmError_posix.cpp line 151: > 149: sigaddset(&newset, SIGNALS[i]); > 150: } > 151: PosixSignals::unblock_thread_signal_mask(&newset); AFAICS newset is now unused with this change. src/hotspot/os/posix/vmError_posix.cpp line 105: > 103: static void crash_handler(int sig, siginfo_t* info, void* ucVoid) { > 104: > 105: PosixSignals::unblock_error_signals(); Just to be clear this crash_handler is only installed for the error signals, so then original code was redundantly processing "sig" twice? ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/839 From dholmes at openjdk.java.net Thu Oct 29 02:49:45 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 29 Oct 2020 02:49:45 GMT Subject: RFR: JDK-8254189: Improve comments for StackOverFlow and fix in_xxx() functions [v3] In-Reply-To: References: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> Message-ID: <4psblrOH5F6HZQnGYYYGu631MiXsb96WRMEj2mLEKIw=.9e7fae19-63cc-46e0-a8a9-95ef2d5ceb05@github.com> On Wed, 28 Oct 2020 17:20:07 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for this small cleanup / fix? >> >> While reviewing JDK-8253717 it was found that comments would help with understanding the StackOverFlow class. Especially the fact that the various _base_ are actually pointing outside their respective zone, since the stack grows downward and a zone (and the stack itself) range is [end, base). If you don't look at this code daily it can be surprising. >> >> This also fixes some small off-by-one errors in various "in_stack_xxx_zone()" methods which test whether a given address is inside a zone and gave wrong results for address=base since base points outside its zone. This had the effect that an address could be in multiple zones. >> >> Finally it adds a small gtest which tests the StackOverFlow methods. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Gerard Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/795 From dholmes at openjdk.java.net Thu Oct 29 05:56:45 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 29 Oct 2020 05:56:45 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 19:54:30 GMT, Patricio Chilano Mateo wrote: > Hi all, > > Please review the following patch that removes the call to handle_special_runtime_exit_condition() from SS::block(). This avoids recursive calls when transitioning and stopping for safepoints and also makes the code simpler to read since it is not trivial to deduce why we need to execute the check for certain states but not others, i.e. what exact scenarios we are trying to guard against. > > Method handle_special_runtime_exit_condition() checks for external suspends, object deoptimization, async exceptions and JFR suspends. All these need to be checked when transitioning to java and when transitioning out of native (except for async exceptions when transitioning to thread_in_vm). In SS::block() this check is executed for the _thread_new_trans, _thread_in_native_trans and thread_in_Java cases. For _thread_new_trans, we know the JT will have to go through JavaCallWrapper() the first time it transitions to Java and that already has a check for handle_special_runtime_exit_condition(). For _thread_in_native_trans, transitioning out of native already has checks for external suspends, object deoptimization and JFR suspends in check_safepoint_and_suspend_for_native_trans() which is called from ThreadStateTransition::transition_from_native()(called either directly or through the ThreadStateTransition wrappers) and check_special_condition_for_native_trans (for native wrappers ca se). So that leaves the thread_in_Java case. > Careful analysis shows the handle_special_runtime_exit_condition() call in SS::block() prevents JTs transitioning back to Java from escaping after being externally suspended. This can happen when calling SafepointMechanism::process_if_requested() while transitiong back to java without a later check for external suspend. Looking at the callers of SafepointMechanism::process_if_requested() we see that this can happen from handle_polling_page_exception(), java_suspend_self_with_safepoint_check() and check_safepoint_and_suspend_for_native_trans(). An example of this can be shown for the handle_polling_page_exception() case: > - JT hits a poll exception while executing nmethod. > - JT calls handle_polling_page_exception() ( which doesn't use ThreadStateTransition wrappers) and calls SafepointMechanism::process_if_requested() > - Stops for a safepoint due to a VM_ThreadSuspend request > - Upon unblocking from the safepoint, unless we have the check in SS::block() the JT will transition back to java without actually suspending > > The "escape from suspend" scenarios for the other callers of SafepointMechanism::process_if_requested() are described in the comments of the bug as well as the proper fixes. > > I have tested the patch several times in mach5 tiers1-7 and saw no issues. Let me know if you think I should run any other special tests. > > Thanks, > Patricio Hi Patricio, Thanks for the detailed analysis on this. I agree with what your are doing in pricniple, but disagree with the means you've chosen to do it. Please see comments below. Thanks, David src/hotspot/share/runtime/safepoint.cpp line 935: > 933: // Process pending operation > 934: { > 935: ThreadInVMfromJava tivm(self); This doesn't look good to me. We are in low-level safepoint/handshake related code, but we call a higher-level abstraction for thread-state transition management, just to get the side-effect of processing the safepoint/handshake correctly. To me this suggests we're missing an appropriate API entry point to do what needs to be done. I would rather see something like: SafepointMechanism::process_if_requested(self); self->handle_special_runtime_exit_condition(true /* check asyncs */); (assuming that is the correct action of course). src/hotspot/share/runtime/safepoint.cpp line 958: > 956: // be delivered. (Polling at a return point is ok though). Sure is > 957: // a lot of bother for a deprecated feature... > 958: ThreadInVMfromJavaNoAsyncException tivm(self); Same comment as above. src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 110: > 108: HandleMarkCleaner __hmc(THREAD); \ > 109: if (SafepointMechanism::should_process(THREAD)) { \ > 110: CALL_VM({ThreadInVMfromJava tiv(THREAD);}, handle_exception); \ I initially thought this was an okay convenience technique to get the desired effects, but seeing it used elsewhere I no longer think that - see comments "above". ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/913 From stuefe at openjdk.java.net Thu Oct 29 06:34:46 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 29 Oct 2020 06:34:46 GMT Subject: Integrated: JDK-8254189: Improve comments for StackOverFlow and fix in_xxx() functions In-Reply-To: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> References: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> Message-ID: On Thu, 22 Oct 2020 04:21:30 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for this small cleanup / fix? > > While reviewing JDK-8253717 it was found that comments would help with understanding the StackOverFlow class. Especially the fact that the various _base_ are actually pointing outside their respective zone, since the stack grows downward and a zone (and the stack itself) range is [end, base). If you don't look at this code daily it can be surprising. > > This also fixes some small off-by-one errors in various "in_stack_xxx_zone()" methods which test whether a given address is inside a zone and gave wrong results for address=base since base points outside its zone. This had the effect that an address could be in multiple zones. > > Finally it adds a small gtest which tests the StackOverFlow methods. This pull request has now been integrated. Changeset: 4031cb41 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/4031cb41 Stats: 102 lines in 2 files changed: 99 ins; 0 del; 3 mod 8254189: Improve comments for StackOverFlow and fix in_xxx() functions Reviewed-by: dholmes, gziemski ------------- PR: https://git.openjdk.java.net/jdk/pull/795 From stuefe at openjdk.java.net Thu Oct 29 06:39:46 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 29 Oct 2020 06:39:46 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 02:21:13 GMT, David Holmes wrote: >> Hi, >> >> may I have reviews please for the following patch which takes care to unblock synchronous error signals at the entrance of our main signal handler (including some minor code cleanups). >> >> When a signal happens which cannot be deferred (SIGFPE, SIGILL, SIGSEGV, SIGBUS) but whose delivery is blocked, bad things happen. This is undefined territory, and we have observed the following cases: >> >> - on Linux, the default handler is invoked instead of the user handler, which in case of error signals causes the process to core immediately. This is actually one of the better outcomes, we still have a core. >> - on AIX and PASE both, the process just becomes unresponsive and hangs. >> - on HPUX - one of our internal platform - the process just vanishes without a trace. >> >> I did not test other platforms but would guess similar things happen there. Posix documentation [4] states: >> _"If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated while they are blocked, the result is undefined, unless the signal was generated by the kill() function, the sigqueue() function, or the raise() function."_ >> >> At the moment, undeferrable error signals are unblocked outside the signal handler (see hotspot sigmask) and, since JDK-8065895, inside the error handler (see crash_handler setup). This leaves us with a window where the hotspot signal handler runs but before he has decided to invoke fatal error handling. Inside that window, for any platform but AIX error signals are still blocked. So any crash inside them tears down the VM immediately without giving us a useful hs-err file. >> >> On AIX they are not blocked because we added an AIX-only patch a while ago which unblocks them at the entrance of the AIX signal handler. This was before we contributed the port to OpenJDK, so no history in the official repos. But that behavior makes sense for all posix platforms. >> >> For more details see discussion from Nov 2014 [2][3]. >> >> (Side note, these effects only show for truly synchronous error signals. You cannot artificially create such a scenario e.g. by raising SIGSEGV with kill.) >> >> About sa_sigaction.sa_mask vs pthread_sigmask: At the first glance, it would be more elegant to just unblock error signals in the signal mask specified when installing the signal handler. However, the way that mask works is that it is ANDed together with the process signal mask in effect when the signal was raised. So if one or more of the error signals were blocked at that point, they would continue to be blocked in the handler, sa_mask notwithstanding. >> It seems easier and clearer to just manually unblock those signals at the entrance of our handlers. >> >> Changes in detail: >> >> - At the entrance of javaSignalHandler() we now unblock error signals for all platforms, not just for AIX. >> - Nothing changes at the entrance of the secondary error handler (crash_handler()): just better code reuse. >> - In os::signal(), for AIX only, we used to set the sa_mask for the handler-to-be-installed to unblock error signals. I decided to just remove this section. The reason is: I want to get rid of this AIX specific section, and was torn between leaving it in for all platforms or removing it. os::signal is used to install other signal handlers too, and I do not want to change their behavior with this patch. Therefore I just removed this section. >> >> Tests: >> >> I tested the change manually by triggering a segfault inside javaSignalHandler. That reliably tore down the process immediately. With this patch, once error signals are unblocked, we continue to run - we get the secondary crash, which then leads to VMError::report_and_die() called since its a real error (I prevented recursion for this test. See my comments about recursion in the JBS issue.) >> >> We will put this through our SAP internal tests before pushing. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8065895 >> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-November/013346.html >> [3] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-January/013718.html >> [4] https://pubs.opengroup.org/onlinepubs/009695399/functions/sigprocmask.html > > src/hotspot/os/posix/signals_posix.cpp line 471: > >> 469: #ifdef ASSERT >> 470: if (rc != 0) { >> 471: log_warning(os)("pthread_sigmask failed (%d)", errno); > > pthread_sigmask doesn't set errno, it returns the error code directly. But as there is only one defined error code for pthread_sigmask (EINVAL) this warning seem unnecessary. The usual assert_status would suffice. Good catch. I thought about assert too. assert is not a good idea, since we would trigger our assertion poison page, and since segv may still be blocked, this would cause exactly the problem I want to prevent. But since the only error is EINVAL, and we know what we feed into this function, I'll just remove the assert. > src/hotspot/os/posix/vmError_posix.cpp line 151: > >> 149: sigaddset(&newset, SIGNALS[i]); >> 150: } >> 151: PosixSignals::unblock_thread_signal_mask(&newset); > > AFAICS newset is now unused with this change. You are right, I can remove more. ------------- PR: https://git.openjdk.java.net/jdk/pull/839 From stuefe at openjdk.java.net Thu Oct 29 06:48:44 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 29 Oct 2020 06:48:44 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked In-Reply-To: References: Message-ID: <7q-JsvgCMH4SvALMOyWXzf0OuBHjSP0XaNgF_L4uRso=.ee685db1-cecb-42cf-93fb-e705afb24468@github.com> On Thu, 29 Oct 2020 02:43:40 GMT, David Holmes wrote: > Hi Thomas, > > I still feel that we should never explicitly block these error signals given it leads to undefined behaviour. So I'd like to see a change to os::signal at least in a future RFE. Not a problem, that is reasonable. No need to make a new RFE. I will prepare a new version which excludes those signals from the sigaction sa_mask too, but leaves the unblocking in place. And I'll add the SR_handler. Since this will probably take some days to get tested again, I'll be happy if you review it after your vacation :) Cheers, Thomas > > For now I think all the signal handlers should explicitly unblock the error signals, which means the SR_handler also needs updating. > > Some other minor changes requested below. > > Thanks, > David > src/hotspot/os/posix/vmError_posix.cpp line 105: > >> 103: static void crash_handler(int sig, siginfo_t* info, void* ucVoid) { >> 104: >> 105: PosixSignals::unblock_error_signals(); > > Just to be clear this crash_handler is only installed for the error signals, so then original code was redundantly processing "sig" twice? I'm unsure what you mean. Do you mean, it had been added twice to newset? > sigaddset(&newset, sig); << > // also unmask other synchronous signals > for (int i = 0; i < NUM_SIGNALS; i++) { > sigaddset(&newset, SIGNALS[i]); << > } > PosixSignals::unblock_thread_signal_mask(&newset); That is true. I believe the original coding was from us too, so I feel responsible :) ------------- PR: https://git.openjdk.java.net/jdk/pull/839 From david.holmes at oracle.com Thu Oct 29 07:01:30 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Oct 2020 17:01:30 +1000 Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked In-Reply-To: <7q-JsvgCMH4SvALMOyWXzf0OuBHjSP0XaNgF_L4uRso=.ee685db1-cecb-42cf-93fb-e705afb24468@github.com> References: <7q-JsvgCMH4SvALMOyWXzf0OuBHjSP0XaNgF_L4uRso=.ee685db1-cecb-42cf-93fb-e705afb24468@github.com> Message-ID: <56e65d23-64db-4d62-3e21-200391d2977a@oracle.com> Hi Thomas, On 29/10/2020 4:48 pm, Thomas Stuefe wrote: > On Thu, 29 Oct 2020 02:43:40 GMT, David Holmes wrote: > >> Hi Thomas, >> >> I still feel that we should never explicitly block these error signals given it leads to undefined behaviour. So I'd like to see a change to os::signal at least in a future RFE. > > Not a problem, that is reasonable. No need to make a new RFE. I will prepare a new version which excludes those signals from the sigaction sa_mask too, but leaves the unblocking in place. And I'll add the SR_handler. Since this will probably take some days to get tested again, I'll be happy if you review it after your vacation :) Okay. > Cheers, Thomas > >> >> For now I think all the signal handlers should explicitly unblock the error signals, which means the SR_handler also needs updating. >> >> Some other minor changes requested below. >> >> Thanks, >> David > >> src/hotspot/os/posix/vmError_posix.cpp line 105: >> >>> 103: static void crash_handler(int sig, siginfo_t* info, void* ucVoid) { >>> 104: >>> 105: PosixSignals::unblock_error_signals(); >> >> Just to be clear this crash_handler is only installed for the error signals, so then original code was redundantly processing "sig" twice? > > I'm unsure what you mean. Do you mean, it had been added twice to newset? > >> sigaddset(&newset, sig); << >> // also unmask other synchronous signals >> for (int i = 0; i < NUM_SIGNALS; i++) { >> sigaddset(&newset, SIGNALS[i]); << >> } >> PosixSignals::unblock_thread_signal_mask(&newset); > > That is true. I believe the original coding was from us too, so I feel responsible :) Right - if the only expected values for sig were in fact one of those defined in SIGNALS then it gets added twice. Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/839 > From stuefe at openjdk.java.net Thu Oct 29 07:40:47 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 29 Oct 2020 07:40:47 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked In-Reply-To: <7q-JsvgCMH4SvALMOyWXzf0OuBHjSP0XaNgF_L4uRso=.ee685db1-cecb-42cf-93fb-e705afb24468@github.com> References: <7q-JsvgCMH4SvALMOyWXzf0OuBHjSP0XaNgF_L4uRso=.ee685db1-cecb-42cf-93fb-e705afb24468@github.com> Message-ID: On Thu, 29 Oct 2020 06:46:12 GMT, Thomas Stuefe wrote: > Hi Thomas, > ..... > > Aside: I also noticed the SR_sigset is unused, so unclear if we have a bug lurking in PosixSignals::SR_initialize. There is some commentary about the blocked/unblocked status of SR_signum that also seems wrong. I find the code in SR_initialize strange and very probably broken. I created https://bugs.openjdk.java.net/browse/JDK-8255577 to keep track of this. Its on my name but if you'd like to take this on be my guest. ------------- PR: https://git.openjdk.java.net/jdk/pull/839 From stuefe at openjdk.java.net Thu Oct 29 08:55:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 29 Oct 2020 08:55:57 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked [v2] In-Reply-To: References: Message-ID: > Hi, > > may I have reviews please for the following patch which takes care to unblock synchronous error signals at the entrance of our main signal handler (including some minor code cleanups). > > When a signal happens which cannot be deferred (SIGFPE, SIGILL, SIGSEGV, SIGBUS) but whose delivery is blocked, bad things happen. This is undefined territory, and we have observed the following cases: > > - on Linux, the default handler is invoked instead of the user handler, which in case of error signals causes the process to core immediately. This is actually one of the better outcomes, we still have a core. > - on AIX and PASE both, the process just becomes unresponsive and hangs. > - on HPUX - one of our internal platform - the process just vanishes without a trace. > > I did not test other platforms but would guess similar things happen there. Posix documentation [4] states: > _"If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated while they are blocked, the result is undefined, unless the signal was generated by the kill() function, the sigqueue() function, or the raise() function."_ > > At the moment, undeferrable error signals are unblocked outside the signal handler (see hotspot sigmask) and, since JDK-8065895, inside the error handler (see crash_handler setup). This leaves us with a window where the hotspot signal handler runs but before he has decided to invoke fatal error handling. Inside that window, for any platform but AIX error signals are still blocked. So any crash inside them tears down the VM immediately without giving us a useful hs-err file. > > On AIX they are not blocked because we added an AIX-only patch a while ago which unblocks them at the entrance of the AIX signal handler. This was before we contributed the port to OpenJDK, so no history in the official repos. But that behavior makes sense for all posix platforms. > > For more details see discussion from Nov 2014 [2][3]. > > (Side note, these effects only show for truly synchronous error signals. You cannot artificially create such a scenario e.g. by raising SIGSEGV with kill.) > > About sa_sigaction.sa_mask vs pthread_sigmask: At the first glance, it would be more elegant to just unblock error signals in the signal mask specified when installing the signal handler. However, the way that mask works is that it is ANDed together with the process signal mask in effect when the signal was raised. So if one or more of the error signals were blocked at that point, they would continue to be blocked in the handler, sa_mask notwithstanding. > It seems easier and clearer to just manually unblock those signals at the entrance of our handlers. > > Changes in detail: > > - At the entrance of javaSignalHandler() we now unblock error signals for all platforms, not just for AIX. > - Nothing changes at the entrance of the secondary error handler (crash_handler()): just better code reuse. > - In os::signal(), for AIX only, we used to set the sa_mask for the handler-to-be-installed to unblock error signals. I decided to just remove this section. The reason is: I want to get rid of this AIX specific section, and was torn between leaving it in for all platforms or removing it. os::signal is used to install other signal handlers too, and I do not want to change their behavior with this patch. Therefore I just removed this section. > > Tests: > > I tested the change manually by triggering a segfault inside javaSignalHandler. That reliably tore down the process immediately. With this patch, once error signals are unblocked, we continue to run - we get the secondary crash, which then leads to VMError::report_and_die() called since its a real error (I prevented recursion for this test. See my comments about recursion in the JBS issue.) > > We will put this through our SAP internal tests before pushing. > > [1] https://bugs.openjdk.java.net/browse/JDK-8065895 > [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-November/013346.html > [3] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-January/013718.html > [4] https://pubs.opengroup.org/onlinepubs/009695399/functions/sigprocmask.html Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback David ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/839/files - new: https://git.openjdk.java.net/jdk/pull/839/files/eabe3e38..8d86e25a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=839&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=839&range=00-01 Stats: 74 lines in 2 files changed: 54 ins; 18 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/839.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/839/head:pull/839 PR: https://git.openjdk.java.net/jdk/pull/839 From lzang at openjdk.java.net Thu Oct 29 08:58:44 2020 From: lzang at openjdk.java.net (Lin Zang) Date: Thu, 29 Oct 2020 08:58:44 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 14:00:34 GMT, Claes Redestad wrote: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Dear @cl4es, I am not a reviewer, just have 1 comment that maybe you need to update the Year info in the headers of touched files. Thanks. Lin ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From robbin.ehn at oracle.com Thu Oct 29 10:12:29 2020 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 29 Oct 2020 11:12:29 +0100 Subject: Is _thread_in_native safe for handshake/safepoint? In-Reply-To: References: Message-ID: Hi Richard, On 2020-10-27 17:43, Reingruber, Richard wrote: > Yeah, avoiding register flushes would be a reason but practically always the > stack is made walkable before changing to _thread_in_native (also in 11u which > still supports SPARC). That's why I asked myself if there are code paths which > don't do that. The check was added 2004 together with: " ... The code and mechanism known as SafepointPolling replaces this method of bringing threads executing in compiled code to a safepoint. Code is generated in the compiled code to poll for whether a safepoint should be reached. ... " It's unclear if this check was needed or added as a safety. > But what needs to be fixed in ThreadInVMfromNative? I suppose the (java part of > the) stack is walkable when the instance is created or there is no frame > on stack. This could be asserted like in line 657 above. Then it is still > walkable when the instance is destructed, isn't it? I was not 100% sure of this, but I cannot find any place where we would return to native and not have it proper set (~ThreadInVMfromNative). Let's fix the JavaThreadInVMAndNative and do some heavy testing. /Robbin > >> We are looking into some simplifications of transitions, since after >> "8203469: Faster safepoints" blocked and native are almost identical. > >> Essential two super-states thread-safe (blocked/native) and >> thread-unsafe(all other). Having the same 'rules' for walkable stack >> certainly helps. > > I see. > >> Does this answer your question(s)? > > To some extent. Unfortunately I haven't understood your answers > completely. Anyways thanks! > > Cheers, Richard. > > -----Original Message----- > From: Robbin Ehn > Sent: Dienstag, 27. Oktober 2020 09:16 > To: Reingruber, Richard ; Hotspot dev runtime > Subject: Re: Is _thread_in_native safe for handshake/safepoint? > > Hi Richard, > > I think the main reason for not making the stack walkable is to avoid > register flushes. Since we do not have such hardware anymore in mainline > I see no reason to skip making the stack walkable. > > I find two places, JFR and ~ThreadInVMfromNative(). > The JavaThreadInVMAndNative should be replaced. > In case of ThreadInVMfromNative I guess the idea is that when going from > java -> native we already did the stack walkable and then calling e.g. > JNI we avoid it. And you are probably going to do many JNI calls. > > So fixing those two maybe we can simplify to: > > 650 case _thread_in_native: > > 654 case _thread_blocked: > > 657 assert(!thread->has_last_Java_frame() || > thread->frame_anchor()->walkable(), "blocked and not walkable"); > > 658 return true; > > Which would be very nice. > > We are looking into some simplifications of transitions, since after > "8203469: Faster safepoints" blocked and native are almost identical. > > Essential two super-states thread-safe (blocked/native) and > thread-unsafe(all other). Having the same 'rules' for walkable stack > certainly helps. > > Does this answer your question(s)? > > Thanks, Robbin > > On 2020-10-22 16:22, Reingruber, Richard wrote: >> Hi, >> >> I don't understand the method safepoint_safe_with() in safepoint.cpp >> Maybe somebody has a quick answer to the questions below... >> >> 648 static bool safepoint_safe_with(JavaThread *thread, JavaThreadState state) { >> 649 switch(state) { >> 650 case _thread_in_native: >> 651 // native threads are safe if they have no java stack or have walkable stack >> 652 return !thread->has_last_Java_frame() || thread->frame_anchor()->walkable(); >> 653 >> 654 case _thread_blocked: >> 655 // On wait_barrier or blocked. >> 656 // Blocked threads should already have walkable stack. >> 657 assert(!thread->has_last_Java_frame() || thread->frame_anchor()->walkable(), "blocked and not walkable"); >> 658 return true; >> 659 >> 660 default: >> 661 return false; >> 662 } >> 663 } >> >> I thought _thread_in_native and _thread_blocked are both equally safe for >> handshakes/safepoints but that method makes a distinction. Looking at line 652 >> it seems possible that a thread is _thread_in_native without a walkable >> stack. The thread is then of course considered not safe. Native wrappers, native >> interpreter entries, ThreadToNativeFromVM change the state to _thread_in_native >> after making the stack walkable though (I looked also at the old sparc versions). >> >> So how can a thread be _thread_in_native without a walkable stack? And why does >> that state make sense when it blocks handshakes/safepoints? >> >> I found JavaThreadInVMAndNative which seems to set the state to >> _thread_in_native without making the stack walkable. It seems though that from >> there ThreadInVMfromNative is reachable which can trigger an assertion in >> JavaThread::check_safepoint_and_suspend_for_native_trans() if the stack isn't >> walkable. >> >> JfrRecorderService::invoke_safepoint_write() : void >> JfrRecorderService::write() : void >> JfrRecorderService::finalize_current_chunk() : void >> JfrRecorderService::chunk_rotation() : void >> JfrRecorderService::rotate(int) : void >> JfrEmergencyDump::on_vm_shutdown(bool) : void >> >> Thanks, Richard. >> From stefank at openjdk.java.net Thu Oct 29 10:26:52 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 29 Oct 2020 10:26:52 GMT Subject: RFR: 8255582: Introduce SemaphoreLock and SemaphoreLocker Message-ID: <_JWavDFnX9LXuj9uXsd6RDwRDrsoVb-tG-CVQ6fMA90=.5d37cc4c-b6cf-4dc8-ac47-0372cf368ead@github.com> Semaphores can be used as low-level locks, but the readability of the code using them could be better. I propose that we introduce two new classes: SemaphoreLock - which provides the operations lock, unlock, try_lock. SemaphoreLocker - Equivalent to MutexLocker. ------------- Commit messages: - 8255582: Introduce SemaphoreLock and SemaphoreLocker Changes: https://git.openjdk.java.net/jdk/pull/927/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=927&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255582 Stats: 59 lines in 2 files changed: 59 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/927.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/927/head:pull/927 PR: https://git.openjdk.java.net/jdk/pull/927 From ayang at openjdk.java.net Thu Oct 29 10:26:52 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 29 Oct 2020 10:26:52 GMT Subject: RFR: 8255582: Introduce SemaphoreLock and SemaphoreLocker In-Reply-To: <_JWavDFnX9LXuj9uXsd6RDwRDrsoVb-tG-CVQ6fMA90=.5d37cc4c-b6cf-4dc8-ac47-0372cf368ead@github.com> References: <_JWavDFnX9LXuj9uXsd6RDwRDrsoVb-tG-CVQ6fMA90=.5d37cc4c-b6cf-4dc8-ac47-0372cf368ead@github.com> Message-ID: <7xyhNYWM9-ZzeiQszzibqDrnZNaCCKLd__6oY4Mtmoo=.b9897b00-fb2e-4c35-ab69-47ad62f9ef66@github.com> On Thu, 29 Oct 2020 10:01:22 GMT, Stefan Karlsson wrote: > Semaphores can be used as low-level locks, but the readability of the code using them could be better. I propose that we introduce two new classes: > > SemaphoreLock - which provides the operations lock, unlock, try_lock. > > SemaphoreLocker - Equivalent to MutexLocker. Marked as reviewed by ayang (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/927 From stefank at openjdk.java.net Thu Oct 29 10:26:53 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 29 Oct 2020 10:26:53 GMT Subject: RFR: 8255582: Introduce SemaphoreLock and SemaphoreLocker In-Reply-To: <_JWavDFnX9LXuj9uXsd6RDwRDrsoVb-tG-CVQ6fMA90=.5d37cc4c-b6cf-4dc8-ac47-0372cf368ead@github.com> References: <_JWavDFnX9LXuj9uXsd6RDwRDrsoVb-tG-CVQ6fMA90=.5d37cc4c-b6cf-4dc8-ac47-0372cf368ead@github.com> Message-ID: On Thu, 29 Oct 2020 10:01:22 GMT, Stefan Karlsson wrote: > Semaphores can be used as low-level locks, but the readability of the code using them could be better. I propose that we introduce two new classes: > > SemaphoreLock - which provides the operations lock, unlock, try_lock. > > SemaphoreLocker - Equivalent to MutexLocker. I intend to use this in https://github.com/openjdk/jdk/pull/903 ------------- PR: https://git.openjdk.java.net/jdk/pull/927 From coleenp at openjdk.java.net Thu Oct 29 11:59:45 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 29 Oct 2020 11:59:45 GMT Subject: RFR: JDK-8254189: Improve comments for StackOverFlow and fix in_xxx() functions [v3] In-Reply-To: <4psblrOH5F6HZQnGYYYGu631MiXsb96WRMEj2mLEKIw=.9e7fae19-63cc-46e0-a8a9-95ef2d5ceb05@github.com> References: <-ifxvzLe2ybjMOLtKta5VdeGvcOgfI7s3CN-876DQgw=.598aef14-c1fb-48d6-8e22-542ec639df9e@github.com> <4psblrOH5F6HZQnGYYYGu631MiXsb96WRMEj2mLEKIw=.9e7fae19-63cc-46e0-a8a9-95ef2d5ceb05@github.com> Message-ID: On Thu, 29 Oct 2020 02:46:57 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Gerard > > Marked as reviewed by dholmes (Reviewer). Sorry for not getting to this review on time. Thank you for doing this and writing the gtest. This is really nice. ------------- PR: https://git.openjdk.java.net/jdk/pull/795 From stuefe at openjdk.java.net Thu Oct 29 12:01:51 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 29 Oct 2020 12:01:51 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked [v2] In-Reply-To: References: <7q-JsvgCMH4SvALMOyWXzf0OuBHjSP0XaNgF_L4uRso=.ee685db1-cecb-42cf-93fb-e705afb24468@github.com> Message-ID: On Thu, 29 Oct 2020 07:38:05 GMT, Thomas Stuefe wrote: >>> Hi Thomas, >>> >>> I still feel that we should never explicitly block these error signals given it leads to undefined behaviour. So I'd like to see a change to os::signal at least in a future RFE. >> >> Not a problem, that is reasonable. No need to make a new RFE. I will prepare a new version which excludes those signals from the sigaction sa_mask too, but leaves the unblocking in place. And I'll add the SR_handler. Since this will probably take some days to get tested again, I'll be happy if you review it after your vacation :) >> >> Cheers, Thomas >> >>> >>> For now I think all the signal handlers should explicitly unblock the error signals, which means the SR_handler also needs updating. >>> >>> Some other minor changes requested below. >>> >>> Thanks, >>> David > >> Hi Thomas, >> > ..... >> >> Aside: I also noticed the SR_sigset is unused, so unclear if we have a bug lurking in PosixSignals::SR_initialize. There is some commentary about the blocked/unblocked status of SR_signum that also seems wrong. > > I find the code in SR_initialize strange and very probably broken. I created https://bugs.openjdk.java.net/browse/JDK-8255577 to keep track of this. Its on my name but if you'd like to take this on be my guest. Changed in the new version: - As David requested, we now exclude synchronous error signals from the signal masks used when registering a signal handler (sa_action.sa_mask). This means that unblocking them explicitly inside the signal handlers is only an additional safety measure now (the signal mask at the entrance of a signal handler is the result of an & operation between sa_action.sa_mask and whatever mask was in effect when the signal happened). - As David requested, now the SR_handler unblocks error signals too, as well as the UserHandler. - I wrote a big comment explaining what I do and why I do it. ------------- PR: https://git.openjdk.java.net/jdk/pull/839 From hseigel at openjdk.java.net Thu Oct 29 13:07:50 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 29 Oct 2020 13:07:50 GMT Subject: RFR: 8255005: Fix indentation levels in classFileParser.cpp Message-ID: Please review this very small change to fix indentation in classFileParser.cpp and move the check for the PermittedSubclasses attribute inside of the "if (major_version >= 16)" block. Fix was tested with tiers 1 and 2 on Linux, Mac OSX, and Windows, and tiers 3-5 on Linux x64. Thanks, Harold ------------- Commit messages: - 8255005: Fix indentation levels in classFileParser.cpp Changes: https://git.openjdk.java.net/jdk/pull/931/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=931&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255005 Stats: 23 lines in 1 file changed: 8 ins; 12 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/931.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/931/head:pull/931 PR: https://git.openjdk.java.net/jdk/pull/931 From redestad at openjdk.java.net Thu Oct 29 14:03:56 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 29 Oct 2020 14:03:56 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v5] In-Reply-To: References: Message-ID: <26xqj78f6sfo9CXjlQAZRTdSeRe0nSU8rnzb1Sb8gJo=.36a30bf2-99e8-46c1-8bae-7efa35cfc989@github.com> > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Desugar constexpr into code generator and output ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/880/files - new: https://git.openjdk.java.net/jdk/pull/880/files/f796147d..61bac3dc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=03-04 Stats: 292 lines in 2 files changed: 281 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/880/head:pull/880 PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Thu Oct 29 14:14:46 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 29 Oct 2020 14:14:46 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 08:56:13 GMT, Lin Zang wrote: >> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. >> >> I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: >> >> [5.428s][debug][heapsampling] log2, 0.0751173 secs >> [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs >> [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs >> >> I've verified that this refactoring does not affect performance in this naive setup. >> >> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 > > Dear @cl4es, > I am not a reviewer, just have 1 comment that maybe you need to update the Year info in the headers of touched files. > > Thanks. > Lin Unfortunately there's currently no portable way to use `std::log` (or any of the other `std` math functions) in a constexpr, so I had to resort to a code generator approach instead. It's either that or withdrawing this PR. Using UL and a debug-only block to implement an adhoc code generator (`-Xlog:heapsampling+generate::none`) might be a bit unorthodox, but I think it turned out OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Thu Oct 29 14:23:04 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 29 Oct 2020 14:23:04 GMT Subject: RFR: 8255455: Refactor ThreadHeapSampler::_log_table as constexpr [v6] In-Reply-To: References: Message-ID: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: - Add explicit include of logging - Add const, fix copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/880/files - new: https://git.openjdk.java.net/jdk/pull/880/files/61bac3dc..a802814f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=04-05 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/880/head:pull/880 PR: https://git.openjdk.java.net/jdk/pull/880 From richard.reingruber at sap.com Thu Oct 29 15:34:34 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Thu, 29 Oct 2020 15:34:34 +0000 Subject: Is _thread_in_native safe for handshake/safepoint? In-Reply-To: References: Message-ID: Hi Robbin, > On 2020-10-27 17:43, Reingruber, Richard wrote: > > Yeah, avoiding register flushes would be a reason but practically always the > > stack is made walkable before changing to _thread_in_native (also in 11u which > > still supports SPARC). That's why I asked myself if there are code paths which > > don't do that. > The check was added 2004 together with: > " > ... > The code and mechanism known as SafepointPolling replaces this method of > bringing threads executing in compiled code to a safepoint. Code is > generated in the compiled code to poll for whether a safepoint should be > reached. > ... > " > It's unclear if this check was needed or added as a safety. That's a while ago... > > But what needs to be fixed in ThreadInVMfromNative? I suppose the (java part of > > the) stack is walkable when the instance is created or there is no frame > > on stack. This could be asserted like in line 657 above. Then it is still > > walkable when the instance is destructed, isn't it? > I was not 100% sure of this, but I cannot find any place where we would > return to native and not have it proper set (~ThreadInVMfromNative). > Let's fix the JavaThreadInVMAndNative and do some heavy testing. Sounds like a plan. Thanks again for looking into this, Richard. -----Original Message----- From: Robbin Ehn Sent: Donnerstag, 29. Oktober 2020 11:12 To: Reingruber, Richard ; Hotspot dev runtime Subject: Re: Is _thread_in_native safe for handshake/safepoint? Hi Richard, On 2020-10-27 17:43, Reingruber, Richard wrote: > Yeah, avoiding register flushes would be a reason but practically always the > stack is made walkable before changing to _thread_in_native (also in 11u which > still supports SPARC). That's why I asked myself if there are code paths which > don't do that. The check was added 2004 together with: " ... The code and mechanism known as SafepointPolling replaces this method of bringing threads executing in compiled code to a safepoint. Code is generated in the compiled code to poll for whether a safepoint should be reached. ... " It's unclear if this check was needed or added as a safety. > But what needs to be fixed in ThreadInVMfromNative? I suppose the (java part of > the) stack is walkable when the instance is created or there is no frame > on stack. This could be asserted like in line 657 above. Then it is still > walkable when the instance is destructed, isn't it? I was not 100% sure of this, but I cannot find any place where we would return to native and not have it proper set (~ThreadInVMfromNative). Let's fix the JavaThreadInVMAndNative and do some heavy testing. /Robbin > >> We are looking into some simplifications of transitions, since after >> "8203469: Faster safepoints" blocked and native are almost identical. > >> Essential two super-states thread-safe (blocked/native) and >> thread-unsafe(all other). Having the same 'rules' for walkable stack >> certainly helps. > > I see. > >> Does this answer your question(s)? > > To some extent. Unfortunately I haven't understood your answers > completely. Anyways thanks! > > Cheers, Richard. > > -----Original Message----- > From: Robbin Ehn > Sent: Dienstag, 27. Oktober 2020 09:16 > To: Reingruber, Richard ; Hotspot dev runtime > Subject: Re: Is _thread_in_native safe for handshake/safepoint? > > Hi Richard, > > I think the main reason for not making the stack walkable is to avoid > register flushes. Since we do not have such hardware anymore in mainline > I see no reason to skip making the stack walkable. > > I find two places, JFR and ~ThreadInVMfromNative(). > The JavaThreadInVMAndNative should be replaced. > In case of ThreadInVMfromNative I guess the idea is that when going from > java -> native we already did the stack walkable and then calling e.g. > JNI we avoid it. And you are probably going to do many JNI calls. > > So fixing those two maybe we can simplify to: > > 650 case _thread_in_native: > > 654 case _thread_blocked: > > 657 assert(!thread->has_last_Java_frame() || > thread->frame_anchor()->walkable(), "blocked and not walkable"); > > 658 return true; > > Which would be very nice. > > We are looking into some simplifications of transitions, since after > "8203469: Faster safepoints" blocked and native are almost identical. > > Essential two super-states thread-safe (blocked/native) and > thread-unsafe(all other). Having the same 'rules' for walkable stack > certainly helps. > > Does this answer your question(s)? > > Thanks, Robbin > > On 2020-10-22 16:22, Reingruber, Richard wrote: >> Hi, >> >> I don't understand the method safepoint_safe_with() in safepoint.cpp >> Maybe somebody has a quick answer to the questions below... >> >> 648 static bool safepoint_safe_with(JavaThread *thread, JavaThreadState state) { >> 649 switch(state) { >> 650 case _thread_in_native: >> 651 // native threads are safe if they have no java stack or have walkable stack >> 652 return !thread->has_last_Java_frame() || thread->frame_anchor()->walkable(); >> 653 >> 654 case _thread_blocked: >> 655 // On wait_barrier or blocked. >> 656 // Blocked threads should already have walkable stack. >> 657 assert(!thread->has_last_Java_frame() || thread->frame_anchor()->walkable(), "blocked and not walkable"); >> 658 return true; >> 659 >> 660 default: >> 661 return false; >> 662 } >> 663 } >> >> I thought _thread_in_native and _thread_blocked are both equally safe for >> handshakes/safepoints but that method makes a distinction. Looking at line 652 >> it seems possible that a thread is _thread_in_native without a walkable >> stack. The thread is then of course considered not safe. Native wrappers, native >> interpreter entries, ThreadToNativeFromVM change the state to _thread_in_native >> after making the stack walkable though (I looked also at the old sparc versions). >> >> So how can a thread be _thread_in_native without a walkable stack? And why does >> that state make sense when it blocks handshakes/safepoints? >> >> I found JavaThreadInVMAndNative which seems to set the state to >> _thread_in_native without making the stack walkable. It seems though that from >> there ThreadInVMfromNative is reachable which can trigger an assertion in >> JavaThread::check_safepoint_and_suspend_for_native_trans() if the stack isn't >> walkable. >> >> JfrRecorderService::invoke_safepoint_write() : void >> JfrRecorderService::write() : void >> JfrRecorderService::finalize_current_chunk() : void >> JfrRecorderService::chunk_rotation() : void >> JfrRecorderService::rotate(int) : void >> JfrEmergencyDump::on_vm_shutdown(bool) : void >> >> Thanks, Richard. >> From thomas.stuefe at gmail.com Thu Oct 29 16:02:02 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 29 Oct 2020 17:02:02 +0100 Subject: Why do we export "JVM_handle_xxx_signal"? Message-ID: Hi, Does anyone know why we explicitly export JVM_handle_bsd_signal and JVM_handle_linux_signal (the latter also accidentally from symbols-aix)? These functions are not even the real signal handler, just an internal function; the signal handler is "javaSignalHandler", but that one is not exported... Thanks, Thomas From lfoltan at openjdk.java.net Thu Oct 29 16:08:43 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Thu, 29 Oct 2020 16:08:43 GMT Subject: RFR: 8255005: Fix indentation levels in classFileParser.cpp In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 13:02:04 GMT, Harold Seigel wrote: > Please review this very small change to fix indentation in classFileParser.cpp and move the check for the PermittedSubclasses attribute inside of the "if (major_version >= 16)" block. > > Fix was tested with tiers 1 and 2 on Linux, Mac OSX, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold One minor nit for you to consider. Overall looks good! src/hotspot/share/classfile/classFileParser.cpp line 3925: > 3923: record_attribute_length = attribute_length; > 3924: } > 3925: cfs->skip_u1(attribute_length, CHECK); Minor nit, since records, permitted subclasses and an unknown attribute type all do a "cfs->skip_u1(attribute_length, CHECK);" as the last action, you could pull that out to the end of the else if (_major_version >= JAVA_16_VERSION) statement. ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/931 From pchilanomate at openjdk.java.net Thu Oct 29 18:40:47 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 29 Oct 2020 18:40:47 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 05:40:49 GMT, David Holmes wrote: >> Hi all, >> >> Please review the following patch that removes the call to handle_special_runtime_exit_condition() from SS::block(). This avoids recursive calls when transitioning and stopping for safepoints and also makes the code simpler to read since it is not trivial to deduce why we need to execute the check for certain states but not others, i.e. what exact scenarios we are trying to guard against. >> >> Method handle_special_runtime_exit_condition() checks for external suspends, object deoptimization, async exceptions and JFR suspends. All these need to be checked when transitioning to java and when transitioning out of native (except for async exceptions when transitioning to thread_in_vm). In SS::block() this check is executed for the _thread_new_trans, _thread_in_native_trans and thread_in_Java cases. For _thread_new_trans, we know the JT will have to go through JavaCallWrapper() the first time it transitions to Java and that already has a check for handle_special_runtime_exit_condition(). For _thread_in_native_trans, transitioning out of native already has checks for external suspends, object deoptimization and JFR suspends in check_safepoint_and_suspend_for_native_trans() which is called from ThreadStateTransition::transition_from_native()(called either directly or through the ThreadStateTransition wrappers) and check_special_condition_for_native_trans (for native wrappers c ase). So that leaves the thread_in_Java case. >> Careful analysis shows the handle_special_runtime_exit_condition() call in SS::block() prevents JTs transitioning back to Java from escaping after being externally suspended. This can happen when calling SafepointMechanism::process_if_requested() while transitiong back to java without a later check for external suspend. Looking at the callers of SafepointMechanism::process_if_requested() we see that this can happen from handle_polling_page_exception(), java_suspend_self_with_safepoint_check() and check_safepoint_and_suspend_for_native_trans(). An example of this can be shown for the handle_polling_page_exception() case: >> - JT hits a poll exception while executing nmethod. >> - JT calls handle_polling_page_exception() ( which doesn't use ThreadStateTransition wrappers) and calls SafepointMechanism::process_if_requested() >> - Stops for a safepoint due to a VM_ThreadSuspend request >> - Upon unblocking from the safepoint, unless we have the check in SS::block() the JT will transition back to java without actually suspending >> >> The "escape from suspend" scenarios for the other callers of SafepointMechanism::process_if_requested() are described in the comments of the bug as well as the proper fixes. >> >> I have tested the patch several times in mach5 tiers1-7 and saw no issues. Let me know if you think I should run any other special tests. >> >> Thanks, >> Patricio > > src/hotspot/share/runtime/safepoint.cpp line 935: > >> 933: // Process pending operation >> 934: { >> 935: ThreadInVMfromJava tivm(self); > > This doesn't look good to me. We are in low-level safepoint/handshake related code, but we call a higher-level abstraction for thread-state transition management, just to get the side-effect of processing the safepoint/handshake correctly. To me this suggests we're missing an appropriate API entry point to do what needs to be done. I would rather see something like: > SafepointMechanism::process_if_requested(self); > self->handle_special_runtime_exit_condition(true /* check asyncs */); > (assuming that is the correct action of course). Ok, initially I thought of doing that but then decided to use transition wrappers. I'll change it. I think ideally we would like to use a transition wrapper in SafepointSynchronize::handle_polling_page_exception() but given the complexity of ThreadSafepointState::handle_polling_page_exception() we have to do things more manual unfortunately. > src/hotspot/share/runtime/safepoint.cpp line 958: > >> 956: // be delivered. (Polling at a return point is ok though). Sure is >> 957: // a lot of bother for a deprecated feature... >> 958: ThreadInVMfromJavaNoAsyncException tivm(self); > > Same comment as above. Ok, I'll change it. > src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 110: > >> 108: HandleMarkCleaner __hmc(THREAD); \ >> 109: if (SafepointMechanism::should_process(THREAD)) { \ >> 110: CALL_VM({ThreadInVMfromJava tiv(THREAD);}, handle_exception); \ > > I initially thought this was an okay convenience technique to get the desired effects, but seeing it used elsewhere I no longer think that - see comments "above". In this case I thought using TIVFJ seemed better because when reading CALL_VM() one would expect a transition from _thread_in_Java to _thread_in_vm and then a call to the appropiate method (like with JRT_ENTRY). It's just that in this case the call that we want to make (SafepointMechanism::process_if_requested()) is already included in the TIVFJ. Anyways, doing it the other way is okay too. ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From ccheung at openjdk.java.net Thu Oct 29 19:18:49 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 29 Oct 2020 19:18:49 GMT Subject: RFR: 8255489: Unify the parsing of @lambda-proxy and @lambda-form-invokers tags in a classlist Message-ID: <5Q_aAV6vaw3uP2HZlknyhFHxJqpq1NuQd2QWJK0n8jI=.acd4f352-047f-4d34-9262-4e9cda73c502@github.com> With this change, the parsing of the `@lambda-proxy` and the `@lambda-form-invokers` tags in a classlist will be performed in the same function - `ClassListParser::parse_at_tags()`. Also removing the `:` of the `@lambda-proxy:` to be consistent with the `@lambda-form-invokers `tag. Ran tiers 1 through 4 tests successfully. ------------- Commit messages: - 8255489 (initial commit) Changes: https://git.openjdk.java.net/jdk/pull/942/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=942&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255489 Stats: 41 lines in 8 files changed: 19 ins; 12 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/942.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/942/head:pull/942 PR: https://git.openjdk.java.net/jdk/pull/942 From iklam at openjdk.java.net Thu Oct 29 20:06:49 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 29 Oct 2020 20:06:49 GMT Subject: RFR: 8255455: Pre-generate ThreadHeapSampler::_log_table [v6] In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 14:23:04 GMT, Claes Redestad wrote: >> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. >> >> I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: >> >> [5.428s][debug][heapsampling] log2, 0.0751173 secs >> [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs >> [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs >> >> I've verified that this refactoring does not affect performance in this naive setup. >> >> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 > > Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: > > - Add explicit include of logging > - Add const, fix copyright Marked as reviewed by iklam (Reviewer). src/hotspot/share/runtime/threadHeapSampler.cpp line 353: > 351: const uint32_t y = x_high >> (20 - FastLogNumBits) & FastLogMask; > 352: const int32_t exponent = ((x_high >> 20) & 0x7FF) - 1023; > 353: return exponent + log_table[y]; The pre-generated values look good to me. Just a small nit. You can decide whether to take this or not: C++ will generate an error if you have too many elements in `log_table[FastLogCount] = { ...`, but won't complain if you have not enough elements. Any uninitialized elements will take up the default value of 0. To prevent cut-and-paste errors in the future, I would suggest adding something like assert(FastLogCount > 0 && log_table[FastLogCount-1] != 0, "table should be full"); ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From minqi at openjdk.java.net Thu Oct 29 20:08:44 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 29 Oct 2020 20:08:44 GMT Subject: RFR: 8255489: Unify the parsing of @lambda-proxy and @lambda-form-invokers tags in a classlist In-Reply-To: <5Q_aAV6vaw3uP2HZlknyhFHxJqpq1NuQd2QWJK0n8jI=.acd4f352-047f-4d34-9262-4e9cda73c502@github.com> References: <5Q_aAV6vaw3uP2HZlknyhFHxJqpq1NuQd2QWJK0n8jI=.acd4f352-047f-4d34-9262-4e9cda73c502@github.com> Message-ID: On Thu, 29 Oct 2020 19:11:32 GMT, Calvin Cheung wrote: > With this change, the parsing of the `@lambda-proxy` and the `@lambda-form-invokers` tags in a classlist will be performed in the same function - `ClassListParser::parse_at_tags()`. > > Also removing the `:` of the `@lambda-proxy:` to be consistent with the `@lambda-form-invokers `tag. > > Ran tiers 1 through 4 tests successfully. Looks good to me. There are two issues in question: 1) _indy_items is specific name, it was designed for indy before and now it includes lambda_form_invokers. I don't know if we should use a more generic name here. 2) This part seems not necessary since we already done this before calling parse_at_tag: 211 } else if (strcmp(_indy_items->at(0), LAMBDA_FORM_TAG) == 0) { 212 for (int i = _line_len; i >= 0; i--) { 213 if (_line[i] == '\0') { 214 _line[i] = ' '; 215 } 216 } ------------- PR: https://git.openjdk.java.net/jdk/pull/942 From mikhailo.seledtsov at oracle.com Thu Oct 29 20:25:03 2020 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Thu, 29 Oct 2020 13:25:03 -0700 Subject: Stack traces for a stuck test in mach5? In-Reply-To: References: <7B084D70-0413-42D1-A837-4ECFCEF19851@oracle.com> Message-ID: <7f51b1c8-c606-3af0-c3a7-70b6b1dbcc51@oracle.com> OK, thanks for clarifying. Then right, file a bug in infrabugs, add subcomponent 'host', add me as a watcher. If you already did, please let me know the bug id. Thanks, Misha On 10/29/20 1:21 PM, Igor Ignatyev wrote: > right, timeout handler uses tools from PATH, but as far as I can tell > the problem here isn't w/ the used lldb, but w/ host security > policies: if DevToolsSecurity isn't enabled, macOS asks you for > login/password every time you try to attach w/ lldb (or any other tools) > > -- Igor > >> On Oct 29, 2020, at 1:13 PM, mikhailo.seledtsov at oracle.com >> wrote: >> >> Adding Leonid, since he worked on similar issue recently. >> >> It was something about timeout handler possibly referencing a wrong >> lldb (platform natively installed vs installed by JIB), IIRC. >> >> >> Misha >> >> On 10/27/20 1:07 PM, Igor Ignatyev wrote: >>> Hi Evgeny, >>> >>> if you look at `DevToolsSecurity` results, you will see that >>> "Developer mode is currently disabled.", meaning this host isn't >>> properly configured and `lldb` can attach to the process. you need >>> to open a bug in infra JIRA -- >>> https://java.se.oracle.com/infrabugs/?(you can always find link to >>> it from 'services' menu on infra landing page >>> https://java.se.oracle.com ?). I >>> *assume* the appropriate project is MACH5 w/ 'host' being the >>> component, Misha (cc'ed) might know better. >>> >>> HTH, >>> -- Igor >>> >>> PS even if the host was properly configured, we wouldn't get any >>> meaningful data in this particular case, as by the time jtreg >>> invoked failure-handler, the test process had already finished and >>> exited. that's why there is no "common" section (which has `jstack`, >>> `jcmd` and other java specific tools) in `processes.html`, and why >>> `pgrep` (in "test_processes") exited w/ 1 and `kill` ("core" >>> subsection) said "No such process". this is by no means to say that >>> we shouldn't fix the hosts. I just don't want to get yours hopes too >>> high: failure-handler is useful and all (mostly b/c it's me who >>> implented it ;) ) but b/c it's run concurrently to a test process, >>> there always will be cases w/ missed data, esp. when a test is >>> having almost enough time to finish. >>> >>> >>>> On Oct 27, 2020, at 12:51 PM, Evgeny Nikitin >>>> > wrote: >>>> >>>> Hi Igor, >>>> >>>> May I ask for your advice with one test stuck failure in mach5? >>>> >>>> Here's the job, it contains only one test failure: >>>> >>>> https://mach5.us.oracle.com/mdash/jobs/mach5-one-jdk-16+22-1219-tier3-20201022-1017-15212551/tasks/mach5-one-jdk-16+22-1219-tier3-20201022-1017-15212551-tier3-comp-open_test_hotspot_jtreg_hotspot_slow_compiler-macosx-x64-debug-40/results?search=status%3Afailed%20AND%20-state%3Ainvalid >>>> >>>> The test hung, jtreg tried to gather stack traces, but with no success. >>>> Output for stack traces: >>>> >>>> ---------------------------------------- >>>> [2020-10-22 10:42:02] [/bin/bash, -c, DevToolsSecurity --status | >>>> grep -q enabled && lldb -o 'attach 23355' -o 'thread backtrace all' >>>> -o 'detach' -o 'quit'] timeout=20000 >>>> ---------------------------------------- >>>> ---------------------------------------- >>>> [2020-10-22 10:42:02] exit code: 1 time: 29 ms >>>> ---------------------------------------- >>>> >>>> Output for spindump: >>>> ---------------------------------------- >>>> [2020-10-22 10:42:02] [/usr/sbin/spindump, 23355, -stdout] >>>> timeout=20000 >>>> ---------------------------------------- >>>> spindump must be run as root >>>> ---------------------------------------- >>>> [2020-10-22 10:42:02] exit code: 77 time: 98 ms >>>> ---------------------------------------- >>>> >>>> There's obviously some problem with stack traces gathering. Is that >>>> expected? If not... how and where can I open a bug about that? I'm >>>> guessing, it is for the Infra team, and not in the openjdk JIRA, right? >>>> >>>> Regards, >>>> // Evgeny. >>>> >>>> >>> > From hseigel at openjdk.java.net Thu Oct 29 20:28:57 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 29 Oct 2020 20:28:57 GMT Subject: RFR: 8255005: Fix indentation levels in classFileParser.cpp [v2] In-Reply-To: References: Message-ID: > Please review this very small change to fix indentation in classFileParser.cpp and move the check for the PermittedSubclasses attribute inside of the "if (major_version >= 16)" block. > > Fix was tested with tiers 1 and 2 on Linux, Mac OSX, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8255005: Fix indentation levels in classFileParser.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/931/files - new: https://git.openjdk.java.net/jdk/pull/931/files/e6873a32..11555765 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=931&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=931&range=00-01 Stats: 7 lines in 1 file changed: 2 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/931.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/931/head:pull/931 PR: https://git.openjdk.java.net/jdk/pull/931 From hseigel at openjdk.java.net Thu Oct 29 20:28:58 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 29 Oct 2020 20:28:58 GMT Subject: RFR: 8255005: Fix indentation levels in classFileParser.cpp [v2] In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 16:05:37 GMT, Lois Foltan wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8255005: Fix indentation levels in classFileParser.cpp > > src/hotspot/share/classfile/classFileParser.cpp line 3925: > >> 3923: record_attribute_length = attribute_length; >> 3924: } >> 3925: cfs->skip_u1(attribute_length, CHECK); > > Minor nit, since records, permitted subclasses and an unknown attribute type all do a "cfs->skip_u1(attribute_length, CHECK);" as the last action, you could pull that out to the end of the else if (_major_version >= JAVA_16_VERSION) statement. Thanks for looking at this. Please see latest commit that contains the changes you suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/931 From leonid.mesnik at oracle.com Thu Oct 29 20:32:36 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 29 Oct 2020 13:32:36 -0700 Subject: Stack traces for a stuck test in mach5? In-Reply-To: <7f51b1c8-c606-3af0-c3a7-70b6b1dbcc51@oracle.com> References: <7B084D70-0413-42D1-A837-4ECFCEF19851@oracle.com> <7f51b1c8-c606-3af0-c3a7-70b6b1dbcc51@oracle.com> Message-ID: I think it is https://java.se.oracle.com/infrabugs/browse/MACH5-510 I believe it is closed by "Not reproduced" only no-one replied. Re-opened it. Leonid On 10/29/20 1:25 PM, mikhailo.seledtsov at oracle.com wrote: > > OK, thanks for clarifying. Then right, file a bug in infrabugs, add > subcomponent 'host', add me as a watcher. If you already did, please > let me know the bug id. > > Thanks, > > Misha > > On 10/29/20 1:21 PM, Igor Ignatyev wrote: >> right, timeout handler uses tools from PATH, but as far as I can tell >> the problem here isn't w/ the used lldb, but w/ host security >> policies: if DevToolsSecurity isn't enabled, macOS asks you for >> login/password every time you try to attach w/ lldb (or any other tools) >> >> -- Igor >> >>> On Oct 29, 2020, at 1:13 PM, mikhailo.seledtsov at oracle.com >>> wrote: >>> >>> Adding Leonid, since he worked on similar issue recently. >>> >>> It was something about timeout handler possibly referencing a wrong >>> lldb (platform natively installed vs installed by JIB), IIRC. >>> >>> >>> Misha >>> >>> On 10/27/20 1:07 PM, Igor Ignatyev wrote: >>>> Hi Evgeny, >>>> >>>> if you look at `DevToolsSecurity` results, you will see that >>>> "Developer mode is currently disabled.", meaning this host isn't >>>> properly configured and `lldb` can attach to the process. you need >>>> to open a bug in infra JIRA -- >>>> https://java.se.oracle.com/infrabugs/?(you can always find link to >>>> it from 'services' menu on infra landing page >>>> https://java.se.oracle.com ?). I >>>> *assume* the appropriate project is MACH5 w/ 'host' being the >>>> component, Misha (cc'ed) might know better. >>>> >>>> HTH, >>>> -- Igor >>>> >>>> PS even if the host was properly configured, we wouldn't get any >>>> meaningful data in this particular case, as by the time jtreg >>>> invoked failure-handler, the test process had already finished and >>>> exited. that's why there is no "common" section (which has >>>> `jstack`, `jcmd` and other java specific tools) in >>>> `processes.html`, and why `pgrep` (in "test_processes") exited w/ 1 >>>> and `kill` ("core" subsection) said "No such process". this is by >>>> no means to say that we shouldn't fix the hosts. I just don't want >>>> to get yours hopes too high: failure-handler is useful and all >>>> (mostly b/c it's me who implented it ;) ) but b/c it's run >>>> concurrently to a test process, there always will be cases w/ >>>> missed data, esp. when a test is having almost enough time to finish. >>>> >>>> >>>>> On Oct 27, 2020, at 12:51 PM, Evgeny Nikitin >>>>> > wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> May I ask for your advice with one test stuck failure in mach5? >>>>> >>>>> Here's the job, it contains only one test failure: >>>>> >>>>> https://mach5.us.oracle.com/mdash/jobs/mach5-one-jdk-16+22-1219-tier3-20201022-1017-15212551/tasks/mach5-one-jdk-16+22-1219-tier3-20201022-1017-15212551-tier3-comp-open_test_hotspot_jtreg_hotspot_slow_compiler-macosx-x64-debug-40/results?search=status%3Afailed%20AND%20-state%3Ainvalid >>>>> >>>>> The test hung, jtreg tried to gather stack traces, but with no >>>>> success. >>>>> Output for stack traces: >>>>> >>>>> ---------------------------------------- >>>>> [2020-10-22 10:42:02] [/bin/bash, -c, DevToolsSecurity --status | >>>>> grep -q enabled && lldb -o 'attach 23355' -o 'thread backtrace >>>>> all' -o 'detach' -o 'quit'] timeout=20000 >>>>> ---------------------------------------- >>>>> ---------------------------------------- >>>>> [2020-10-22 10:42:02] exit code: 1 time: 29 ms >>>>> ---------------------------------------- >>>>> >>>>> Output for spindump: >>>>> ---------------------------------------- >>>>> [2020-10-22 10:42:02] [/usr/sbin/spindump, 23355, -stdout] >>>>> timeout=20000 >>>>> ---------------------------------------- >>>>> spindump must be run as root >>>>> ---------------------------------------- >>>>> [2020-10-22 10:42:02] exit code: 77 time: 98 ms >>>>> ---------------------------------------- >>>>> >>>>> There's obviously some problem with stack traces gathering. Is >>>>> that expected? If not... how and where can I open a bug about >>>>> that? I'm guessing, it is for the Infra team, and not in the >>>>> openjdk JIRA, right? >>>>> >>>>> Regards, >>>>> // Evgeny. >>>>> >>>>> >>>> >> From leonid.mesnik at oracle.com Thu Oct 29 20:44:56 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 29 Oct 2020 13:44:56 -0700 Subject: Stack traces for a stuck test in mach5? In-Reply-To: References: <7B084D70-0413-42D1-A837-4ECFCEF19851@oracle.com> <7f51b1c8-c606-3af0-c3a7-70b6b1dbcc51@oracle.com> Message-ID: Please disregard following thread. The alias was added in CC by mistake. Leonid On 10/29/20 1:32 PM, Leonid Mesnik wrote: > I think it is > > https://java.se.oracle.com/infrabugs/browse/MACH5-510 > > I believe it is closed by "Not reproduced" only no-one replied. > Re-opened it. > > Leonid > > On 10/29/20 1:25 PM, mikhailo.seledtsov at oracle.com wrote: >> >> OK, thanks for clarifying. Then right, file a bug in infrabugs, add >> subcomponent 'host', add me as a watcher. If you already did, please >> let me know the bug id. >> >> Thanks, >> >> Misha >> >> On 10/29/20 1:21 PM, Igor Ignatyev wrote: >>> right, timeout handler uses tools from PATH, but as far as I can >>> tell the problem here isn't w/ the used lldb, but w/ host security >>> policies: if DevToolsSecurity isn't enabled, macOS asks you for >>> login/password every time you try to attach w/ lldb (or any other >>> tools) >>> >>> -- Igor >>> >>>> On Oct 29, 2020, at 1:13 PM, mikhailo.seledtsov at oracle.com >>>> wrote: >>>> >>>> Adding Leonid, since he worked on similar issue recently. >>>> >>>> It was something about timeout handler possibly referencing a wrong >>>> lldb (platform natively installed vs installed by JIB), IIRC. >>>> >>>> >>>> Misha >>>> >>>> On 10/27/20 1:07 PM, Igor Ignatyev wrote: >>>>> Hi Evgeny, >>>>> >>>>> if you look at `DevToolsSecurity` results, you will see that >>>>> "Developer mode is currently disabled.", meaning this host isn't >>>>> properly configured and `lldb` can attach to the process. you need >>>>> to open a bug in infra JIRA -- >>>>> https://java.se.oracle.com/infrabugs/?(you can always find link to >>>>> it from 'services' menu on infra landing page >>>>> https://java.se.oracle.com ?). I >>>>> *assume* the appropriate project is MACH5 w/ 'host' being the >>>>> component, Misha (cc'ed) might know better. >>>>> >>>>> HTH, >>>>> -- Igor >>>>> >>>>> PS even if the host was properly configured, we wouldn't get any >>>>> meaningful data in this particular case, as by the time jtreg >>>>> invoked failure-handler, the test process had already finished and >>>>> exited. that's why there is no "common" section (which has >>>>> `jstack`, `jcmd` and other java specific tools) in >>>>> `processes.html`, and why `pgrep` (in "test_processes") exited w/ >>>>> 1 and `kill` ("core" subsection) said "No such process". this is >>>>> by no means to say that we shouldn't fix the hosts. I just don't >>>>> want to get yours hopes too high: failure-handler is useful and >>>>> all (mostly b/c it's me who implented it ;) ) but b/c it's run >>>>> concurrently to a test process, there always will be cases w/ >>>>> missed data, esp. when a test is having almost enough time to finish. >>>>> >>>>> >>>>>> On Oct 27, 2020, at 12:51 PM, Evgeny Nikitin >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Hi Igor, >>>>>> >>>>>> May I ask for your advice with one test stuck failure in mach5? >>>>>> >>>>>> Here's the job, it contains only one test failure: >>>>>> >>>>>> https://mach5.us.oracle.com/mdash/jobs/mach5-one-jdk-16+22-1219-tier3-20201022-1017-15212551/tasks/mach5-one-jdk-16+22-1219-tier3-20201022-1017-15212551-tier3-comp-open_test_hotspot_jtreg_hotspot_slow_compiler-macosx-x64-debug-40/results?search=status%3Afailed%20AND%20-state%3Ainvalid >>>>>> >>>>>> >>>>>> The test hung, jtreg tried to gather stack traces, but with no >>>>>> success. >>>>>> Output for stack traces: >>>>>> >>>>>> ---------------------------------------- >>>>>> [2020-10-22 10:42:02] [/bin/bash, -c, DevToolsSecurity --status | >>>>>> grep -q enabled && lldb -o 'attach 23355' -o 'thread backtrace >>>>>> all' -o 'detach' -o 'quit'] timeout=20000 >>>>>> ---------------------------------------- >>>>>> ---------------------------------------- >>>>>> [2020-10-22 10:42:02] exit code: 1 time: 29 ms >>>>>> ---------------------------------------- >>>>>> >>>>>> Output for spindump: >>>>>> ---------------------------------------- >>>>>> [2020-10-22 10:42:02] [/usr/sbin/spindump, 23355, -stdout] >>>>>> timeout=20000 >>>>>> ---------------------------------------- >>>>>> spindump must be run as root >>>>>> ---------------------------------------- >>>>>> [2020-10-22 10:42:02] exit code: 77 time: 98 ms >>>>>> ---------------------------------------- >>>>>> >>>>>> There's obviously some problem with stack traces gathering. Is >>>>>> that expected? If not... how and where can I open a bug about >>>>>> that? I'm guessing, it is for the Infra team, and not in the >>>>>> openjdk JIRA, right? >>>>>> >>>>>> Regards, >>>>>> // Evgeny. >>>>>> >>>>>> >>>>> >>> From ccheung at openjdk.java.net Thu Oct 29 20:47:44 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 29 Oct 2020 20:47:44 GMT Subject: RFR: 8255489: Unify the parsing of @lambda-proxy and @lambda-form-invokers tags in a classlist In-Reply-To: References: <5Q_aAV6vaw3uP2HZlknyhFHxJqpq1NuQd2QWJK0n8jI=.acd4f352-047f-4d34-9262-4e9cda73c502@github.com> Message-ID: On Thu, 29 Oct 2020 20:05:42 GMT, Yumin Qi wrote: > Looks good to me. There are two issues in question: > > 1. _indy_items is specific name, it was designed for indy before and now it includes lambda_form_invokers. I don't know if we should use a more generic name here. Maybe name it _lambda_items? I've another idea. Add another function to separate the tag and the rest of the line. Within the `if-else` block, only the rest of the line needs to be processed since the tag is not needed for loading the class and we can avoid code like the following in LambdaFormInvokers::regenerate_holder_classes: `record += strlen(LAMBDA_FORM_TAG) + 1; // skip the @lambda_form_invoker prefix` Also, the _indy_items name doesn't need to be changed since it will be only for the @lambda-proxy tag. > 2. This part seems not necessary since we already done this before calling parse_at_tag: > 211 } else if (strcmp(_indy_items->at(0), LAMBDA_FORM_TAG) == 0) { > 212 for (int i = _line_len; i >= 0; i--) { > 213 if (_line[i] == '\0') { > 214 _line[i] = ' '; > 215 } > 216 } I don't see why the above is not necessary as the following code in classListParser.cpp has been removed with this patch: 118 // Check if the line is output TRACE_RESOLVE 119 if (strncmp(_line, LambdaFormInvokers::lambda_form_invoker_tag(), 120 strlen(LambdaFormInvokers::lambda_form_invoker_tag())) == 0) { 121 LambdaFormInvokers::append(os::strdup((const char*)_line, mtInternal)); 122 continue; 123 } The for loop is also necessary because the call to `split_tokens_by_whitespace()` has replaced some blank spaces with '\0'. ------------- PR: https://git.openjdk.java.net/jdk/pull/942 From lfoltan at openjdk.java.net Thu Oct 29 20:51:46 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Thu, 29 Oct 2020 20:51:46 GMT Subject: RFR: 8255005: Fix indentation levels in classFileParser.cpp [v2] In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 20:28:57 GMT, Harold Seigel wrote: >> Please review this very small change to fix indentation in classFileParser.cpp and move the check for the PermittedSubclasses attribute inside of the "if (major_version >= 16)" block. >> >> Fix was tested with tiers 1 and 2 on Linux, Mac OSX, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8255005: Fix indentation levels in classFileParser.cpp Thanks for making that change. ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/931 From coleenp at openjdk.java.net Thu Oct 29 21:34:45 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 29 Oct 2020 21:34:45 GMT Subject: RFR: 8255005: Fix indentation levels in classFileParser.cpp [v2] In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 20:28:57 GMT, Harold Seigel wrote: >> Please review this very small change to fix indentation in classFileParser.cpp and move the check for the PermittedSubclasses attribute inside of the "if (major_version >= 16)" block. >> >> Fix was tested with tiers 1 and 2 on Linux, Mac OSX, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8255005: Fix indentation levels in classFileParser.cpp Changes requested by coleenp (Reviewer). src/hotspot/share/classfile/classFileParser.cpp line 3896: > 3894: _nest_host = class_info_index; > 3895: > 3896: } else if (_major_version >= JAVA_16_VERSION) { I don't understand why you changed it from >= 15 to >= 16. ------------- PR: https://git.openjdk.java.net/jdk/pull/931 From minqi at openjdk.java.net Thu Oct 29 21:45:44 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 29 Oct 2020 21:45:44 GMT Subject: RFR: 8255489: Unify the parsing of @lambda-proxy and @lambda-form-invokers tags in a classlist In-Reply-To: References: <5Q_aAV6vaw3uP2HZlknyhFHxJqpq1NuQd2QWJK0n8jI=.acd4f352-047f-4d34-9262-4e9cda73c502@github.com> Message-ID: On Thu, 29 Oct 2020 20:44:59 GMT, Calvin Cheung wrote: >> Looks good to me. There are two issues in question: >> 1) _indy_items is specific name, it was designed for indy before and now it includes lambda_form_invokers. I don't know if we should use a more generic name here. >> 2) This part seems not necessary since we already done this before calling parse_at_tag: >> 211 } else if (strcmp(_indy_items->at(0), LAMBDA_FORM_TAG) == 0) { >> 212 for (int i = _line_len; i >= 0; i--) { >> 213 if (_line[i] == '\0') { >> 214 _line[i] = ' '; >> 215 } >> 216 } > >> Looks good to me. There are two issues in question: >> >> 1. _indy_items is specific name, it was designed for indy before and now it includes lambda_form_invokers. I don't know if we should use a more generic name here. > > Maybe name it _lambda_items? > > I've another idea. Add another function to separate the tag and the rest of the line. Within the `if-else` block, only the rest of the line needs to be processed since the tag is not needed for loading the class and we can avoid code like the following in LambdaFormInvokers::regenerate_holder_classes: > `record += strlen(LAMBDA_FORM_TAG) + 1; // skip the @lambda_form_invoker prefix` > Also, the _indy_items name doesn't need to be changed since it will be only for the @lambda-proxy tag. > >> 2. This part seems not necessary since we already done this before calling parse_at_tag: >> 211 } else if (strcmp(_indy_items->at(0), LAMBDA_FORM_TAG) == 0) { >> 212 for (int i = _line_len; i >= 0; i--) { >> 213 if (_line[i] == '\0') { >> 214 _line[i] = ' '; >> 215 } >> 216 } > > I don't see why the above is not necessary as the following code in classListParser.cpp has been removed with this patch: > > 118 // Check if the line is output TRACE_RESOLVE > 119 if (strncmp(_line, LambdaFormInvokers::lambda_form_invoker_tag(), > 120 strlen(LambdaFormInvokers::lambda_form_invoker_tag())) == 0) { > 121 LambdaFormInvokers::append(os::strdup((const char*)_line, mtInternal)); > 122 continue; > 123 } > > The for loop is also necessary because the call to `split_tokens_by_whitespace()` has replaced some blank spaces with '\0'. > > Looks good to me. There are two issues in question: > > > > 1. _indy_items is specific name, it was designed for indy before and now it includes lambda_form_invokers. I don't know if we should use a more generic name here. > > Maybe name it _lambda_items? > > I've another idea. Add another function to separate the tag and the rest of the line. Within the `if-else` block, only the rest of the line needs to be processed since the tag is not needed for loading the class and we can avoid code like the following in LambdaFormInvokers::regenerate_holder_classes: > `record += strlen(LAMBDA_FORM_TAG) + 1; // skip the @lambda_form_invoker prefix` > Also, the _indy_items name doesn't need to be changed since it will be only for the @lambda-proxy tag. > > > 1. This part seems not necessary since we already done this before calling parse_at_tag: > > 211 } else if (strcmp(_indy_items->at(0), LAMBDA_FORM_TAG) == 0) { > > 212 for (int i = _line_len; i >= 0; i--) { > > 213 if (_line[i] == '\0') { > > 214 _line[i] = ' '; > > 215 } > > 216 } > > I don't see why the above is not necessary as the following code in classListParser.cpp has been removed with this patch: > > ``` > 118 // Check if the line is output TRACE_RESOLVE > 119 if (strncmp(_line, LambdaFormInvokers::lambda_form_invoker_tag(), > 120 strlen(LambdaFormInvokers::lambda_form_invoker_tag())) == 0) { > 121 LambdaFormInvokers::append(os::strdup((const char*)_line, mtInternal)); > 122 continue; > 123 } > ``` > > The for loop is also necessary because the call to `split_tokens_by_whitespace()` has replaced some blank spaces with '\0'. Maybe we don't need change name for _indy_items. First in parse_at_tag: if (strcmp(_line, LAMBDA_FORM_TAG, strlen(LAMBDA_FORM_TAG)) ==0) { // this is lambda_form_invoker line // } Then check if it is indy index format. ------------- PR: https://git.openjdk.java.net/jdk/pull/942 From pchilanomate at openjdk.java.net Thu Oct 29 22:10:58 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 29 Oct 2020 22:10:58 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v2] In-Reply-To: References: Message-ID: > Hi all, > > Please review the following patch that removes the call to handle_special_runtime_exit_condition() from SS::block(). This avoids recursive calls when transitioning and stopping for safepoints and also makes the code simpler to read since it is not trivial to deduce why we need to execute the check for certain states but not others, i.e. what exact scenarios we are trying to guard against. > > Method handle_special_runtime_exit_condition() checks for external suspends, object deoptimization, async exceptions and JFR suspends. All these need to be checked when transitioning to java and when transitioning out of native (except for async exceptions when transitioning to thread_in_vm). In SS::block() this check is executed for the _thread_new_trans, _thread_in_native_trans and thread_in_Java cases. For _thread_new_trans, we know the JT will have to go through JavaCallWrapper() the first time it transitions to Java and that already has a check for handle_special_runtime_exit_condition(). For _thread_in_native_trans, transitioning out of native already has checks for external suspends, object deoptimization and JFR suspends in check_safepoint_and_suspend_for_native_trans() which is called from ThreadStateTransition::transition_from_native()(called either directly or through the ThreadStateTransition wrappers) and check_special_condition_for_native_trans (for native wrappers ca se). So that leaves the thread_in_Java case. > Careful analysis shows the handle_special_runtime_exit_condition() call in SS::block() prevents JTs transitioning back to Java from escaping after being externally suspended. This can happen when calling SafepointMechanism::process_if_requested() while transitiong back to java without a later check for external suspend. Looking at the callers of SafepointMechanism::process_if_requested() we see that this can happen from handle_polling_page_exception(), java_suspend_self_with_safepoint_check() and check_safepoint_and_suspend_for_native_trans(). An example of this can be shown for the handle_polling_page_exception() case: > - JT hits a poll exception while executing nmethod. > - JT calls handle_polling_page_exception() ( which doesn't use ThreadStateTransition wrappers) and calls SafepointMechanism::process_if_requested() > - Stops for a safepoint due to a VM_ThreadSuspend request > - Upon unblocking from the safepoint, unless we have the check in SS::block() the JT will transition back to java without actually suspending > > The "escape from suspend" scenarios for the other callers of SafepointMechanism::process_if_requested() are described in the comments of the bug as well as the proper fixes. > > I have tested the patch several times in mach5 tiers1-7 and saw no issues. Let me know if you think I should run any other special tests. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Make direct calls instead of using transition wrappers ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/913/files - new: https://git.openjdk.java.net/jdk/pull/913/files/90c300cd..3f9dfe4c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=913&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=913&range=00-01 Stats: 19 lines in 3 files changed: 6 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/913.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/913/head:pull/913 PR: https://git.openjdk.java.net/jdk/pull/913 From pchilanomate at openjdk.java.net Thu Oct 29 22:24:47 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 29 Oct 2020 22:24:47 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v2] In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 05:53:11 GMT, David Holmes wrote: > Hi Patricio, > > Thanks for the detailed analysis on this. I agree with what your are doing in pricniple, but disagree with the means you've chosen to do it. Please see comments below. > > Thanks, > David Hi David, Please check the updated version. I added also a has_special_runtime_exit_condition() check before actually calling handle_special_runtime_exit_condition(). Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From ccheung at openjdk.java.net Fri Oct 30 00:35:57 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 30 Oct 2020 00:35:57 GMT Subject: RFR: 8255489: Unify the parsing of @lambda-proxy and @lambda-form-invokers tags in a classlist [v2] In-Reply-To: <5Q_aAV6vaw3uP2HZlknyhFHxJqpq1NuQd2QWJK0n8jI=.acd4f352-047f-4d34-9262-4e9cda73c502@github.com> References: <5Q_aAV6vaw3uP2HZlknyhFHxJqpq1NuQd2QWJK0n8jI=.acd4f352-047f-4d34-9262-4e9cda73c502@github.com> Message-ID: > With this change, the parsing of the `@lambda-proxy` and the `@lambda-form-invokers` tags in a classlist will be performed in the same function - `ClassListParser::parse_at_tags()`. > > Also removing the `:` of the `@lambda-proxy:` to be consistent with the `@lambda-form-invokers `tag. > > Ran tiers 1 through 4 tests successfully. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: improve the parsing code in ClassListParser::parse_at_tags() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/942/files - new: https://git.openjdk.java.net/jdk/pull/942/files/6e8a0b2f..a3b75186 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=942&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=942&range=00-01 Stats: 39 lines in 3 files changed: 18 ins; 8 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/942.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/942/head:pull/942 PR: https://git.openjdk.java.net/jdk/pull/942 From ccheung at openjdk.java.net Fri Oct 30 00:40:42 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 30 Oct 2020 00:40:42 GMT Subject: RFR: 8255489: Unify the parsing of @lambda-proxy and @lambda-form-invokers tags in a classlist In-Reply-To: References: <5Q_aAV6vaw3uP2HZlknyhFHxJqpq1NuQd2QWJK0n8jI=.acd4f352-047f-4d34-9262-4e9cda73c502@github.com> Message-ID: On Thu, 29 Oct 2020 21:43:16 GMT, Yumin Qi wrote: > > Maybe we don't need change name for _indy_items. First in parse_at_tag: > if (strcmp(_line, LAMBDA_FORM_TAG, strlen(LAMBDA_FORM_TAG)) ==0) { > // this is lambda_form_invoker line > // > } > > Then check if it is indy index format. The above is similar to the original code which doesn't do an exact match. For example, it will match `@lambda-form-invokers-xxx` which is incorrect. I've uploaded another webrev (v. 01) which implements the idea I mentioned in my previous comment. Thanks, Calvin ------------- PR: https://git.openjdk.java.net/jdk/pull/942 From ioi.lam at oracle.com Fri Oct 30 06:12:34 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 29 Oct 2020 23:12:34 -0700 Subject: Why do we export "JVM_handle_xxx_signal"? In-Reply-To: References: Message-ID: <62cca950-ae1b-2c41-49e3-8eb8ae2879ce@oracle.com> I have no idea, but this symbol has been exported since we moved the HotSpot source code from SCCS to Mercurial in 2008. It's probably vestige from the early days of Java. http://hg.openjdk.java.net/jdk7/modules/hotspot/annotate/9646293b9637/make/linux/makefiles/mapfile-vers-product#l244 I checked all .so files in our JDK build and no one uses JVM_handle_linux_signal. I think it's probably safe to hide it. We should probably drop the JVM_ prefix, since this function is not declared in jvm.h. Thanks - Ioi On 10/29/20 9:02 AM, Thomas St?fe wrote: > Hi, > > Does anyone know why we explicitly export JVM_handle_bsd_signal and > JVM_handle_linux_signal (the latter also accidentally from symbols-aix)? > > These functions are not even the real signal handler, just an internal > function; the signal handler is "javaSignalHandler", but that one is not > exported... > > Thanks, Thomas From thomas.stuefe at gmail.com Fri Oct 30 06:22:00 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 30 Oct 2020 07:22:00 +0100 Subject: Why do we export "JVM_handle_xxx_signal"? In-Reply-To: <62cca950-ae1b-2c41-49e3-8eb8ae2879ce@oracle.com> References: <62cca950-ae1b-2c41-49e3-8eb8ae2879ce@oracle.com> Message-ID: Thanks for checking, Ioi. I think I'll remove the export and rename the functions. Cheers, Thomas On Fri, Oct 30, 2020 at 7:12 AM Ioi Lam wrote: > I have no idea, but this symbol has been exported since we moved the > HotSpot source code from SCCS to Mercurial in 2008. It's probably > vestige from the early days of Java. > > > http://hg.openjdk.java.net/jdk7/modules/hotspot/annotate/9646293b9637/make/linux/makefiles/mapfile-vers-product#l244 > > I checked all .so files in our JDK build and no one uses > JVM_handle_linux_signal. I think it's probably safe to hide it. We > should probably drop the JVM_ prefix, since this function is not > declared in jvm.h. > > Thanks > - Ioi > > On 10/29/20 9:02 AM, Thomas St?fe wrote: > > Hi, > > > > Does anyone know why we explicitly export JVM_handle_bsd_signal and > > JVM_handle_linux_signal (the latter also accidentally from symbols-aix)? > > > > These functions are not even the real signal handler, just an internal > > function; the signal handler is "javaSignalHandler", but that one is not > > exported... > > > > Thanks, Thomas > > From shade at openjdk.java.net Fri Oct 30 06:56:50 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 30 Oct 2020 06:56:50 GMT Subject: RFR: 8255617: Zero: purge the remaining bytecode interpreter profiling support Message-ID: All the stubs in `interpreter/zero/bytecodeInterpreterProfiling.hpp` are empty. History shows the whole thing gradually moved to template interpreter. We can probably simplify Zero code by dropping these empty stubs altogether. Arguably, this makes porting to new architectures a bit harder, but it seems that the proper stepping stone after Zero is implementing template interpreter anyway. On my TR 3970X, this improves: - Linux x86_64 Zero "make images" times from ~18 minutes to ~17.5 minutes I would like to have the opinion of @GoeLin who added this for PPC64 porting back in 8u. And probably @DamonFool who is usually interested in Zero. And @jerboaa, @gnu-andrew who deal with Zero from time to time. ------------- Commit messages: - 8255617: Zero: purge the remaining bytecode interpreter profiling support Changes: https://git.openjdk.java.net/jdk/pull/944/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=944&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255617 Stats: 169 lines in 2 files changed: 3 ins; 161 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/944.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/944/head:pull/944 PR: https://git.openjdk.java.net/jdk/pull/944 From thomas.stuefe at gmail.com Fri Oct 30 07:58:00 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 30 Oct 2020 08:58:00 +0100 Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: On Fri, Oct 16, 2020 at 9:01 AM Robbin Ehn wrote: > On Thu, 15 Oct 2020 22:54:15 GMT, David Holmes > wrote: > > >> // If crash protection is installed we may longjmp away and no > destructors > >> // for objects in this scope will be run. > >> // So don't use any RAII utilities before crash protection is checked. > >> > >> Since even if crash protection is installed it's not certain we will > longjmp and you can trust destructors after we > >> checked crash protection. ? > > > > I'm not sure if only the call to `check_crash_protection` can trigger > the long jump? If so then your version of the > > comment is better. > > Yes only check_crash_protection() do the longjmp and only if it's the > protected thread and on SIGSEGV/SIGBUS. > > I am cleaning up signal handling a bit, and started thinking about this restriction ("do not use RAII objects before check_crash_protection"). I wanted to use an RAII object in javaSignalHandler (so, one frame above). But the point is not RAII, no? The point is that we skip any epilogue code in the handler and in all frames above us up to os::ThreadCrashProtection::call(). Just avoiding RAII and writing out the epilogue code manually at the end does not help. IIUC it should not say "don't use RAII" but "in anything you do in all frames between os::ThreadCrashProtection::call() and os::ThreadCrashProtection::check_crash_protection(), don't rely on any epilogue code". Thanks, Thomas > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/677 > From github.com+58410019+alphahot at openjdk.java.net Fri Oct 30 08:00:42 2020 From: github.com+58410019+alphahot at openjdk.java.net (AlphaHot) Date: Fri, 30 Oct 2020 08:00:42 GMT Subject: RFR: 8255615: Zero: demote ZeroStack::abi_stack_available guarantee to assert In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 19:13:06 GMT, Aleksey Shipilev wrote: > It is currently guarantee(), which slows down release bits unnecessarily: > > inline int ZeroStack::abi_stack_available(Thread *thread) const { > guarantee(Thread::current() == thread, "should run in the same thread"); > > On my TR 3970X, changing that `guarantee` to `assert` improves: > - Zero x86_64 release "make images" times from ~9.5 minutes to ~7.5 minutes > - Zero x86_64 release "make bootcycle-images" times from ~49 minutes to ~44 minutes > > Attention @jerboaa and @gnu-andrew, who have to suffer through the Zero build times occasionally. Marked as reviewed by AlphaHot at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/943 From robbin.ehn at oracle.com Fri Oct 30 08:26:00 2020 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 30 Oct 2020 09:26:00 +0100 Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: References: Message-ID: <9c28e159-fa4e-dd71-9157-832df189419d@oracle.com> Hi Thomas, The comment was specificity just for the signalhandler scope. I assumed that any one changing the signal handler would know what "longjmp away" means any epilogue code will not run. Since a RAII destructor is much more likely to get missed, I agreed with David that a reminder of RAII destructors could be useful. The user of ThreadCrashProtection::call() must take much more precaution, very few pieces of code can be called reliable with it. > IIUC it should not say "don't use RAII" but "in anything you do in all > frames between os::ThreadCrashProtection::call() and > os::ThreadCrashProtection::check_crash_protection(), don't rely on any > epilogue code". So you have this comment in the declaration: /* * Crash protection for the JfrSampler thread. Wrap the callback * with a sigsetjmp and in case of a SIGSEGV/SIGBUS we siglongjmp * back. * To be able to use this - don't take locks, don't rely on destructors, * don't make OS library calls, don't allocate memory, don't print, * don't call code that could leave the heap / memory in an inconsistent state, * or anything else where we are not in control if we suddenly jump out. */ class ThreadCrashProtection : public StackObj { https://github.com/openjdk/jdk/blob/379ba80eb7999f60fb12a08a9d0b2ff16263ab23/src/hotspot/os/posix/os_posix.hpp#L115 If you think you can improve the comments feel free to improve! Thanks, Robbin > > Thanks, Thomas > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/677 > > From thomas.stuefe at gmail.com Fri Oct 30 09:23:12 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 30 Oct 2020 10:23:12 +0100 Subject: RFR: 8254824: SignalHandlerMark have no purpose In-Reply-To: <9c28e159-fa4e-dd71-9157-832df189419d@oracle.com> References: <9c28e159-fa4e-dd71-9157-832df189419d@oracle.com> Message-ID: Hi Robin, Thanks for clarifying! My mail was partly to check if I had overlooked something. I will, as part of the cleanup, move some of the more obvious common sections out of the platform signal handlers up to the shared wrapper function. I will do this for the crash protector too. And then tweak the comment somewhat to my liking :) Thanks, Thomas On Fri, Oct 30, 2020, 09:28 Robbin Ehn wrote: > Hi Thomas, > > The comment was specificity just for the signalhandler scope. > I assumed that any one changing the signal handler would know what > "longjmp away" means any epilogue code will not run. > > Since a RAII destructor is much more likely to get missed, I agreed with > David that a reminder of RAII destructors could be useful. > > The user of ThreadCrashProtection::call() must take much more > precaution, very few pieces of code can be called reliable with it. > > > IIUC it should not say "don't use RAII" but "in anything you do in all > > frames between os::ThreadCrashProtection::call() and > > os::ThreadCrashProtection::check_crash_protection(), don't rely on any > > epilogue code". > > So you have this comment in the declaration: > /* > * Crash protection for the JfrSampler thread. Wrap the callback > * with a sigsetjmp and in case of a SIGSEGV/SIGBUS we siglongjmp > * back. > * To be able to use this - don't take locks, don't rely on > destructors, > * don't make OS library calls, don't allocate memory, don't print, > * don't call code that could leave the heap / memory in an > inconsistent state, > * or anything else where we are not in control if we suddenly jump out. > */ > class ThreadCrashProtection : public StackObj { > > > https://github.com/openjdk/jdk/blob/379ba80eb7999f60fb12a08a9d0b2ff16263ab23/src/hotspot/os/posix/os_posix.hpp#L115 > > If you think you can improve the comments feel free to improve! > > Thanks, Robbin > > > > > Thanks, Thomas > > > > ------------- > > > > PR: https://git.openjdk.java.net/jdk/pull/677 > > > > > From coleenp at openjdk.java.net Fri Oct 30 11:58:43 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 30 Oct 2020 11:58:43 GMT Subject: RFR: 8255617: Zero: purge the remaining bytecode interpreter profiling support In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 19:47:02 GMT, Aleksey Shipilev wrote: > All the stubs in `interpreter/zero/bytecodeInterpreterProfiling.hpp` are empty. History shows the whole thing gradually moved to template interpreter. We can probably simplify Zero code by dropping these empty stubs altogether. Arguably, this makes porting to new architectures a bit harder, but it seems that the proper stepping stone after Zero is implementing template interpreter anyway. > > On my TR 3970X, this improves: > - Linux x86_64 Zero "make images" times from ~18 minutes to ~17.5 minutes > > I would like to have the opinion of @GoeLin who added this for PPC64 porting back in 8u. And probably @DamonFool who is usually interested in Zero. And @jerboaa, @gnu-andrew who deal with Zero from time to time. I left this code from the C++ interpreter because I had a dream that we could someday hook zero up to c1/c2 someday, but if so, there would be a more work than adding these back. I'd be interested to see what these other people with interest in Zero think. But this LGTM. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/944 From coleen.phillimore at oracle.com Fri Oct 30 12:30:05 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 30 Oct 2020 08:30:05 -0400 Subject: Why do we export "JVM_handle_xxx_signal"? In-Reply-To: References: <62cca950-ae1b-2c41-49e3-8eb8ae2879ce@oracle.com> Message-ID: <9f386d5d-fc33-de0a-e1e5-cb8a9a22555f@oracle.com> I looked through the old history and don't see any reason for this naming.? My only guess is that the solaris version was exported to the JDK at one time. It would be nice for these to have new names, and I see on the other thread some of the code might be refactored?? That would be really good. Thanks, Coleen On 10/30/20 2:22 AM, Thomas St?fe wrote: > Thanks for checking, Ioi. I think I'll remove the export and rename the > functions. > > Cheers, Thomas > > On Fri, Oct 30, 2020 at 7:12 AM Ioi Lam wrote: > >> I have no idea, but this symbol has been exported since we moved the >> HotSpot source code from SCCS to Mercurial in 2008. It's probably >> vestige from the early days of Java. >> >> >> http://hg.openjdk.java.net/jdk7/modules/hotspot/annotate/9646293b9637/make/linux/makefiles/mapfile-vers-product#l244 >> >> I checked all .so files in our JDK build and no one uses >> JVM_handle_linux_signal. I think it's probably safe to hide it. We >> should probably drop the JVM_ prefix, since this function is not >> declared in jvm.h. >> >> Thanks >> - Ioi >> >> On 10/29/20 9:02 AM, Thomas St?fe wrote: >>> Hi, >>> >>> Does anyone know why we explicitly export JVM_handle_bsd_signal and >>> JVM_handle_linux_signal (the latter also accidentally from symbols-aix)? >>> >>> These functions are not even the real signal handler, just an internal >>> function; the signal handler is "javaSignalHandler", but that one is not >>> exported... >>> >>> Thanks, Thomas >> From hseigel at openjdk.java.net Fri Oct 30 12:42:57 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 30 Oct 2020 12:42:57 GMT Subject: RFR: 8255005: Fix indentation levels in classFileParser.cpp [v2] In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 21:31:41 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8255005: Fix indentation levels in classFileParser.cpp > > src/hotspot/share/classfile/classFileParser.cpp line 3896: > >> 3894: _nest_host = class_info_index; >> 3895: >> 3896: } else if (_major_version >= JAVA_16_VERSION) { > > I don't understand why you changed it from >= 15 to >= 16. It was changed to 16 because, starting with 16, Records is a new non-preview feature. So, the Record attribute is for class file version 60 or later. 60 is the major class file version for JDK-16. Sealed types are still preview but require class file version 60.65535. Preview features must always have the latest major class file version (and minor version of 655353). ------------- PR: https://git.openjdk.java.net/jdk/pull/931 From coleenp at openjdk.java.net Fri Oct 30 12:53:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 30 Oct 2020 12:53:56 GMT Subject: RFR: 8255005: Fix indentation levels in classFileParser.cpp [v2] In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 20:28:57 GMT, Harold Seigel wrote: >> Please review this very small change to fix indentation in classFileParser.cpp and move the check for the PermittedSubclasses attribute inside of the "if (major_version >= 16)" block. >> >> Fix was tested with tiers 1 and 2 on Linux, Mac OSX, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8255005: Fix indentation levels in classFileParser.cpp Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/931 From coleenp at openjdk.java.net Fri Oct 30 12:53:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 30 Oct 2020 12:53:56 GMT Subject: RFR: 8255005: Fix indentation levels in classFileParser.cpp [v2] In-Reply-To: References: Message-ID: <-Bz4gmyPAt5QcMR8OdGoOlTXM1OkxKZelj1_BJM1S9w=.0b62ecc5-8b1f-4e54-94f2-513008681917@github.com> On Fri, 30 Oct 2020 12:40:08 GMT, Harold Seigel wrote: >> src/hotspot/share/classfile/classFileParser.cpp line 3896: >> >>> 3894: _nest_host = class_info_index; >>> 3895: >>> 3896: } else if (_major_version >= JAVA_16_VERSION) { >> >> I don't understand why you changed it from >= 15 to >= 16. > > It was changed to 16 because, starting with 16, Records is a new non-preview feature. So, the Record attribute is for class file version 60 or later. 60 is the major class file version for JDK-16. > > Sealed types are still preview but require class file version 60.65535. Preview features must always have the latest major class file version (and minor version of 655353). Okay, thank you for the explanation about preview features. Looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/931 From thomas.stuefe at gmail.com Fri Oct 30 12:58:04 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 30 Oct 2020 13:58:04 +0100 Subject: Why do we export "JVM_handle_xxx_signal"? In-Reply-To: <9f386d5d-fc33-de0a-e1e5-cb8a9a22555f@oracle.com> References: <62cca950-ae1b-2c41-49e3-8eb8ae2879ce@oracle.com> <9f386d5d-fc33-de0a-e1e5-cb8a9a22555f@oracle.com> Message-ID: Yes, I have a patch in preparation. Not the whole cleanup, but some of the more obvious things. I need to get JDK-8252533 through first (since I have not yet figured out how to post a PR based on another, still open, PR). Cheers, Thomas On Fri 30. Oct 2020 at 13:30, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > I looked through the old history and don't see any reason for this > naming. My only guess is that the solaris version was exported to the > JDK at one time. > > It would be nice for these to have new names, and I see on the other > thread some of the code might be refactored? That would be really good. > > Thanks, > Coleen > > On 10/30/20 2:22 AM, Thomas St?fe wrote: > > Thanks for checking, Ioi. I think I'll remove the export and rename the > > functions. > > > > Cheers, Thomas > > > > On Fri, Oct 30, 2020 at 7:12 AM Ioi Lam wrote: > > > >> I have no idea, but this symbol has been exported since we moved the > >> HotSpot source code from SCCS to Mercurial in 2008. It's probably > >> vestige from the early days of Java. > >> > >> > >> > http://hg.openjdk.java.net/jdk7/modules/hotspot/annotate/9646293b9637/make/linux/makefiles/mapfile-vers-product#l244 > >> > >> I checked all .so files in our JDK build and no one uses > >> JVM_handle_linux_signal. I think it's probably safe to hide it. We > >> should probably drop the JVM_ prefix, since this function is not > >> declared in jvm.h. > >> > >> Thanks > >> - Ioi > >> > >> On 10/29/20 9:02 AM, Thomas St?fe wrote: > >>> Hi, > >>> > >>> Does anyone know why we explicitly export JVM_handle_bsd_signal and > >>> JVM_handle_linux_signal (the latter also accidentally from > symbols-aix)? > >>> > >>> These functions are not even the real signal handler, just an internal > >>> function; the signal handler is "javaSignalHandler", but that one is > not > >>> exported... > >>> > >>> Thanks, Thomas > >> > > From hseigel at openjdk.java.net Fri Oct 30 13:01:56 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 30 Oct 2020 13:01:56 GMT Subject: Integrated: 8255005: Fix indentation levels in classFileParser.cpp In-Reply-To: References: Message-ID: <8q5FXx2mIevosupOxPbuGPuo0NTpUo6wSo88v3Adrwc=.7bbf8f65-6521-4d72-9799-c18a4d3e2c09@github.com> On Thu, 29 Oct 2020 13:02:04 GMT, Harold Seigel wrote: > Please review this very small change to fix indentation in classFileParser.cpp and move the check for the PermittedSubclasses attribute inside of the "if (major_version >= 16)" block. > > Fix was tested with tiers 1 and 2 on Linux, Mac OSX, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: 8a065ef2 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/8a065ef2 Stats: 28 lines in 1 file changed: 9 ins; 16 del; 3 mod 8255005: Fix indentation levels in classFileParser.cpp Reviewed-by: lfoltan, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/931 From shade at openjdk.java.net Fri Oct 30 13:22:54 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 30 Oct 2020 13:22:54 GMT Subject: RFR: 8255617: Zero: purge the remaining bytecode interpreter profiling support In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 11:56:07 GMT, Coleen Phillimore wrote: > I left this code from the C++ interpreter because I had a dream that we could someday hook zero up to c1/c2 someday, but if so, there would be a more work than adding these back. I'd be interested to see what these other people with interest in Zero think. But this LGTM. It is my understanding that Zero had basically backed off to be the "pure" interpreter without any support for compilers, and thus the most portable thing, for example for architectures that have no compiler ports whatsoever. Template interpreter seems to be the thing that hooks up in C1/C2. So, porting is basically: a) get Zero buildable and executable, work out class library problems; b) get template interpreter working; c) get C1 working; d) get C2 working. So in this sense, getting compiler hooks (like this interpreter profile support) penalizes Zero execution for nothing. If that continues, I'd say we can also purge deopt support from Zero. Need more thoughts about this, so: ------------- PR: https://git.openjdk.java.net/jdk/pull/944 From coleen.phillimore at oracle.com Fri Oct 30 13:58:10 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 30 Oct 2020 09:58:10 -0400 Subject: Why do we export "JVM_handle_xxx_signal"? In-Reply-To: References: <62cca950-ae1b-2c41-49e3-8eb8ae2879ce@oracle.com> <9f386d5d-fc33-de0a-e1e5-cb8a9a22555f@oracle.com> Message-ID: On 10/30/20 8:58 AM, Thomas St?fe wrote: > Yes, I have a patch in preparation. Not the whole cleanup, but some of > the more obvious things. I need to get JDK-8252533 through first > (since I have not yet figured out how to post a PR based on another, > still open, PR). I don't know how to do this yet either.? Thank you from the reviewers for doing one at a time. Coleen > > Cheers, Thomas > > On Fri 30. Oct 2020 at 13:30, Coleen Phillimore > > > wrote: > > > I looked through the old history and don't see any reason for this > naming.? My only guess is that the solaris version was exported to > the > JDK at one time. > > It would be nice for these to have new names, and I see on the other > thread some of the code might be refactored?? That would be really > good. > > Thanks, > Coleen > > On 10/30/20 2:22 AM, Thomas St?fe wrote: > > Thanks for checking, Ioi. I think I'll remove the export and > rename the > > functions. > > > > Cheers, Thomas > > > > On Fri, Oct 30, 2020 at 7:12 AM Ioi Lam > wrote: > > > >> I have no idea, but this symbol has been exported since we > moved the > >> HotSpot source code from SCCS to Mercurial in 2008. It's probably > >> vestige from the early days of Java. > >> > >> > >> > http://hg.openjdk.java.net/jdk7/modules/hotspot/annotate/9646293b9637/make/linux/makefiles/mapfile-vers-product#l244 > > >> > >> I checked all .so files in our JDK build and no one uses > >> JVM_handle_linux_signal. I think it's probably safe to hide it. We > >> should probably drop the JVM_ prefix, since this function is not > >> declared in jvm.h. > >> > >> Thanks > >> - Ioi > >> > >> On 10/29/20 9:02 AM, Thomas St?fe wrote: > >>> Hi, > >>> > >>> Does anyone know why we explicitly export > JVM_handle_bsd_signal and > >>> JVM_handle_linux_signal (the latter also accidentally from > symbols-aix)? > >>> > >>> These functions are not even the real signal handler, just an > internal > >>> function; the signal handler is "javaSignalHandler", but that > one is not > >>> exported... > >>> > >>> Thanks, Thomas > >> > From redestad at openjdk.java.net Fri Oct 30 15:24:17 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 30 Oct 2020 15:24:17 GMT Subject: RFR: 8255455: Pre-generate ThreadHeapSampler::_log_table [v7] In-Reply-To: References: Message-ID: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'master' into threadHeapSampler_constexpr - Check log_table on startup in debug builds - Add explicit include of logging - Add const, fix copyright - Desugar constexpr into code generator and output - Merge branch 'master' into threadHeapSampler_constexpr - Declare and define log_table as a static constexpr inside threadHeapSampler.cpp - Merge branch 'master' into threadHeapSampler_constexpr - Merge branch 'master' into threadHeapSampler_constexpr - Remove _log_table_initialized assert - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b5bd0028...0eebe57c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/880/files - new: https://git.openjdk.java.net/jdk/pull/880/files/a802814f..0eebe57c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=880&range=05-06 Stats: 11692 lines in 331 files changed: 6229 ins; 3920 del; 1543 mod Patch: https://git.openjdk.java.net/jdk/pull/880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/880/head:pull/880 PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Fri Oct 30 15:27:58 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 30 Oct 2020 15:27:58 GMT Subject: RFR: 8255455: Pre-generate ThreadHeapSampler::_log_table [v6] In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 20:04:11 GMT, Ioi Lam wrote: >> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add explicit include of logging >> - Add const, fix copyright > > Marked as reviewed by iklam (Reviewer). @iklam: I added a runtime verification pass that the values in the log_table are reasonably accurate. This adds around 100k instructions on startup on a debug build, which is in the noise there (currently hello world takes 470M on fastdebug builds). The checking is disabled in a code gen run to not put up tripwires when resizing the table. ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From sgehwolf at openjdk.java.net Fri Oct 30 17:15:55 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 30 Oct 2020 17:15:55 GMT Subject: RFR: 8255617: Zero: purge the remaining bytecode interpreter profiling support In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 19:47:02 GMT, Aleksey Shipilev wrote: > All the stubs in `interpreter/zero/bytecodeInterpreterProfiling.hpp` are empty. History shows the whole thing gradually moved to template interpreter. We can probably simplify Zero code by dropping these empty stubs altogether. Arguably, this makes porting to new architectures a bit harder, but it seems that the proper stepping stone after Zero is implementing template interpreter anyway. > > On my TR 3970X, this improves: > - Linux x86_64 Zero "make images" times from ~18 minutes to ~17.5 minutes > > I would like to have the opinion of @GoeLin who added this for PPC64 porting back in 8u. And probably @DamonFool who is usually interested in Zero. And @jerboaa, @gnu-andrew who deal with Zero from time to time. Marked as reviewed by sgehwolf (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/944 From sgehwolf at openjdk.java.net Fri Oct 30 17:15:56 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 30 Oct 2020 17:15:56 GMT Subject: RFR: 8255617: Zero: purge the remaining bytecode interpreter profiling support In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 13:20:19 GMT, Aleksey Shipilev wrote: >> I left this code from the C++ interpreter because I had a dream that we could someday hook zero up to c1/c2 someday, but if so, there would be a more work than adding these back. I'd be interested to see what these other people with interest in Zero think. But this LGTM. > >> I left this code from the C++ interpreter because I had a dream that we could someday hook zero up to c1/c2 someday, but if so, there would be a more work than adding these back. I'd be interested to see what these other people with interest in Zero think. But this LGTM. > > It is my understanding that Zero had basically backed off to be the "pure" interpreter without any support for compilers, and thus the most portable thing, for example for architectures that have no compiler ports whatsoever. Template interpreter seems to be the thing that hooks up in C1/C2. So, porting is basically: a) get Zero buildable and executable, work out class library problems; b) get template interpreter working; c) get C1 working; d) get C2 working. > > So in this sense, getting compiler hooks (like this interpreter profile support) penalizes Zero execution for nothing. If that continues, I'd say we can also purge deopt support from Zero. > > Need more thoughts about this, so: IIRC the original idea of Zero's compiler support was for shark (via LLVM). That got removed with [JDK-8171853](https://bugs.openjdk.java.net/browse/JDK-8171853). It seems fine to remove profiling support too. So what @shipilev said above makes sense to me. Zero is mostly a porter's tool. Keeping it as simple as possible seems the better approach. +1 ------------- PR: https://git.openjdk.java.net/jdk/pull/944 From iklam at openjdk.java.net Fri Oct 30 17:36:06 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 30 Oct 2020 17:36:06 GMT Subject: RFR: 8255489: Unify the parsing of @lambda-proxy and @lambda-form-invokers tags in a classlist [v2] In-Reply-To: References: <5Q_aAV6vaw3uP2HZlknyhFHxJqpq1NuQd2QWJK0n8jI=.acd4f352-047f-4d34-9262-4e9cda73c502@github.com> Message-ID: On Fri, 30 Oct 2020 00:35:57 GMT, Calvin Cheung wrote: >> With this change, the parsing of the `@lambda-proxy` and the `@lambda-form-invokers` tags in a classlist will be performed in the same function - `ClassListParser::parse_at_tags()`. >> >> Also removing the `:` of the `@lambda-proxy:` to be consistent with the `@lambda-form-invokers `tag. >> >> Ran tiers 1 through 4 tests successfully. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > improve the parsing code in ClassListParser::parse_at_tags() Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/942 From iklam at openjdk.java.net Fri Oct 30 17:42:01 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 30 Oct 2020 17:42:01 GMT Subject: RFR: 8255455: Pre-generate ThreadHeapSampler::_log_table [v7] In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 15:24:17 GMT, Claes Redestad wrote: >> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. >> >> I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: >> >> [5.428s][debug][heapsampling] log2, 0.0751173 secs >> [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs >> [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs >> >> I've verified that this refactoring does not affect performance in this naive setup. >> >> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' into threadHeapSampler_constexpr > - Check log_table on startup in debug builds > - Add explicit include of logging > - Add const, fix copyright > - Desugar constexpr into code generator and output > - Merge branch 'master' into threadHeapSampler_constexpr > - Declare and define log_table as a static constexpr inside threadHeapSampler.cpp > - Merge branch 'master' into threadHeapSampler_constexpr > - Merge branch 'master' into threadHeapSampler_constexpr > - Remove _log_table_initialized assert > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/63c0fc2d...0eebe57c LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Fri Oct 30 18:18:58 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 30 Oct 2020 18:18:58 GMT Subject: RFR: 8255455: Pre-generate ThreadHeapSampler::_log_table [v7] In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 17:39:05 GMT, Ioi Lam wrote: >> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Merge branch 'master' into threadHeapSampler_constexpr >> - Check log_table on startup in debug builds >> - Add explicit include of logging >> - Add const, fix copyright >> - Desugar constexpr into code generator and output >> - Merge branch 'master' into threadHeapSampler_constexpr >> - Declare and define log_table as a static constexpr inside threadHeapSampler.cpp >> - Merge branch 'master' into threadHeapSampler_constexpr >> - Merge branch 'master' into threadHeapSampler_constexpr >> - Remove _log_table_initialized assert >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/7a199d94...0eebe57c > > LGTM @iklam: thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From redestad at openjdk.java.net Fri Oct 30 18:18:59 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 30 Oct 2020 18:18:59 GMT Subject: Integrated: 8255455: Pre-generate ThreadHeapSampler::_log_table In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 14:00:34 GMT, Claes Redestad wrote: > The static `ThreadHeapSampler::_log_table` is currently initialized on JVM bootstrap to an overhead of ~67k instructions (linux-x64). By turning the initialization into a constexpr, we can precalculate the helper table at compile time, which trades a runtime overhead for a small, 8kb, static footprint increase. > > I compared `fast_log2` with the `log2` builtin with a naive benchmarking experiment[1] (not included in this PR) and show that the `fast_log2` is ~2.5x faster than `log2` on my system. And that without the lookup table we'd be much worse. So I think it makes sense to preserve this optimization, but get rid of the startup overhead: > > [5.428s][debug][heapsampling] log2, 0.0751173 secs > [5.457s][debug][heapsampling] fast_log2, 0.0298244 secs > [5.622s][debug][heapsampling] fast_log2_uncached, 0.1645569 secs > > I've verified that this refactoring does not affect performance in this naive setup. > > [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1 This pull request has now been integrated. Changeset: 4158567f Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/4158567f Stats: 317 lines in 3 files changed: 296 ins; 10 del; 11 mod 8255455: Pre-generate ThreadHeapSampler::_log_table Reviewed-by: iklam, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/880 From ccheung at openjdk.java.net Fri Oct 30 20:27:09 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 30 Oct 2020 20:27:09 GMT Subject: RFR: 8255489: Unify the parsing of @lambda-proxy and @lambda-form-invokers tags in a classlist [v3] In-Reply-To: <5Q_aAV6vaw3uP2HZlknyhFHxJqpq1NuQd2QWJK0n8jI=.acd4f352-047f-4d34-9262-4e9cda73c502@github.com> References: <5Q_aAV6vaw3uP2HZlknyhFHxJqpq1NuQd2QWJK0n8jI=.acd4f352-047f-4d34-9262-4e9cda73c502@github.com> Message-ID: <0YaVX0zP0ExnApVRZU0Q8QYqQ6F7yYcfQnow35iPgZ0=.87e0bc83-daeb-4dfc-a921-a06dafc8c4f0@github.com> > With this change, the parsing of the `@lambda-proxy` and the `@lambda-form-invokers` tags in a classlist will be performed in the same function - `ClassListParser::parse_at_tags()`. > > Also removing the `:` of the `@lambda-proxy:` to be consistent with the `@lambda-form-invokers `tag. > > Ran tiers 1 through 4 tests successfully. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: add invalid @ tag tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/942/files - new: https://git.openjdk.java.net/jdk/pull/942/files/a3b75186..63f1201a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=942&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=942&range=01-02 Stats: 14 lines in 2 files changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/942.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/942/head:pull/942 PR: https://git.openjdk.java.net/jdk/pull/942 From minqi at openjdk.java.net Fri Oct 30 20:37:00 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 30 Oct 2020 20:37:00 GMT Subject: RFR: 8255489: Unify the parsing of @lambda-proxy and @lambda-form-invokers tags in a classlist [v3] In-Reply-To: <0YaVX0zP0ExnApVRZU0Q8QYqQ6F7yYcfQnow35iPgZ0=.87e0bc83-daeb-4dfc-a921-a06dafc8c4f0@github.com> References: <5Q_aAV6vaw3uP2HZlknyhFHxJqpq1NuQd2QWJK0n8jI=.acd4f352-047f-4d34-9262-4e9cda73c502@github.com> <0YaVX0zP0ExnApVRZU0Q8QYqQ6F7yYcfQnow35iPgZ0=.87e0bc83-daeb-4dfc-a921-a06dafc8c4f0@github.com> Message-ID: <6oh3xfiIAQgy5xUs7pe0TSCbhBdjgZjg8kPpuXezdiQ=.e1d3f47a-1a3f-420a-8268-add88da0bb69@github.com> On Fri, 30 Oct 2020 20:27:09 GMT, Calvin Cheung wrote: >> With this change, the parsing of the `@lambda-proxy` and the `@lambda-form-invokers` tags in a classlist will be performed in the same function - `ClassListParser::parse_at_tags()`. >> >> Also removing the `:` of the `@lambda-proxy:` to be consistent with the `@lambda-form-invokers `tag. >> >> Ran tiers 1 through 4 tests successfully. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > add invalid @ tag tests LGTM. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/942 From ccheung at openjdk.java.net Fri Oct 30 22:05:55 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 30 Oct 2020 22:05:55 GMT Subject: Integrated: 8255489: Unify the parsing of @lambda-proxy and @lambda-form-invokers tags in a classlist In-Reply-To: <5Q_aAV6vaw3uP2HZlknyhFHxJqpq1NuQd2QWJK0n8jI=.acd4f352-047f-4d34-9262-4e9cda73c502@github.com> References: <5Q_aAV6vaw3uP2HZlknyhFHxJqpq1NuQd2QWJK0n8jI=.acd4f352-047f-4d34-9262-4e9cda73c502@github.com> Message-ID: On Thu, 29 Oct 2020 19:11:32 GMT, Calvin Cheung wrote: > With this change, the parsing of the `@lambda-proxy` and the `@lambda-form-invokers` tags in a classlist will be performed in the same function - `ClassListParser::parse_at_tags()`. > > Also removing the `:` of the `@lambda-proxy:` to be consistent with the `@lambda-form-invokers `tag. > > Ran tiers 1 through 4 tests successfully. This pull request has now been integrated. Changeset: 36c150b1 Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/36c150b1 Stats: 79 lines in 9 files changed: 45 ins; 14 del; 20 mod 8255489: Unify the parsing of @lambda-proxy and @lambda-form-invokers tags in a classlist Reviewed-by: iklam, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/942 From thomas.stuefe at gmail.com Sat Oct 31 07:05:45 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 31 Oct 2020 08:05:45 +0100 Subject: Why do we export "JVM_handle_xxx_signal"? In-Reply-To: <9f386d5d-fc33-de0a-e1e5-cb8a9a22555f@oracle.com> References: <62cca950-ae1b-2c41-49e3-8eb8ae2879ce@oracle.com> <9f386d5d-fc33-de0a-e1e5-cb8a9a22555f@oracle.com> Message-ID: I found old bugs from Sun about this: JDK-4864136 : JVM_handle_linux_signal is private in 1.4.2-beta JDK-4408646 : JVM_handle_solaris_signal must be a global function seems that the ability to call the hotspot signal handler from outside was a possibility for third party signal handlers to co-exist with the hotspot signal handler. However, nowadays we have signal chaining: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html So, I wonder whether that advice to invoke the hotspot signal handler manually (which I only inferred from the bug, did not find an official guide) from a third party user handler preceded signal chaining. Since with signal chaining and the libjsig, I do not see a need for manually invoking us: - if user installs a signal handler after we had one established, libjsig should be preloaded, which will take care of chaining. - if we install a signal handler over a user handler, we preserve it and chain signals to it. So. For backward compatibility we would have to preserve these exports (in the current form too, which is annoying). But this would really hamper cleanup :( I really would like to clean this up and unify some coding, among other things to ease porting work for us on AIX. This stuff is twenty years old though. I am hoping for some Sun archeological knowledge :) ..Thomas On Fri, Oct 30, 2020 at 1:30 PM Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > I looked through the old history and don't see any reason for this > naming. My only guess is that the solaris version was exported to the > JDK at one time. > > It would be nice for these to have new names, and I see on the other > thread some of the code might be refactored? That would be really good. > > Thanks, > Coleen > > On 10/30/20 2:22 AM, Thomas St?fe wrote: > > Thanks for checking, Ioi. I think I'll remove the export and rename the > > functions. > > > > Cheers, Thomas > > > > On Fri, Oct 30, 2020 at 7:12 AM Ioi Lam wrote: > > > >> I have no idea, but this symbol has been exported since we moved the > >> HotSpot source code from SCCS to Mercurial in 2008. It's probably > >> vestige from the early days of Java. > >> > >> > >> > http://hg.openjdk.java.net/jdk7/modules/hotspot/annotate/9646293b9637/make/linux/makefiles/mapfile-vers-product#l244 > >> > >> I checked all .so files in our JDK build and no one uses > >> JVM_handle_linux_signal. I think it's probably safe to hide it. We > >> should probably drop the JVM_ prefix, since this function is not > >> declared in jvm.h. > >> > >> Thanks > >> - Ioi > >> > >> On 10/29/20 9:02 AM, Thomas St?fe wrote: > >>> Hi, > >>> > >>> Does anyone know why we explicitly export JVM_handle_bsd_signal and > >>> JVM_handle_linux_signal (the latter also accidentally from > symbols-aix)? > >>> > >>> These functions are not even the real signal handler, just an internal > >>> function; the signal handler is "javaSignalHandler", but that one is > not > >>> exported... > >>> > >>> Thanks, Thomas > >> > >