From qpzhang at openjdk.java.net Sun Nov 1 12:37:03 2020 From: qpzhang at openjdk.java.net (Patrick Zhang) Date: Sun, 1 Nov 2020 12:37:03 GMT Subject: RFR: 8255716: AArch64: Regression: JVM crashes if manually offline a core Message-ID: Please review this change that removed the unnecessary check **cpu_lines == os::processor_count()** from VM_Version::get_os_cpu_info inside src/hotspot/os_cpu/linux_aarch64/vm_version_linux_aarch64.cpp. This **assertion** is practically not needed. While a test system with some cores intentionally turned off, e.g. via echo 0 > /sys/devices/system/cpu/cpu1/online, **java -version** would crash, building openjdk on this system would fail too. This regression issue was introduced by https://github.com/openjdk/jdk/commit/ec9bee68 Testing: - java -version, building openjdk as smoke tests - jtreg tier1 as sanity check ------------- Commit messages: - AArch64: Remove unnecessary check cpu_lines == os::processor_count() Changes: https://git.openjdk.java.net/jdk/pull/983/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=983&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255716 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/983.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/983/head:pull/983 PR: https://git.openjdk.java.net/jdk/pull/983 From shade at openjdk.java.net Sun Nov 1 17:31:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 1 Nov 2020 17:31:59 GMT Subject: RFR: 8255718: Zero: VM should know it runs in interpreter-only mode Message-ID: There are many tests in tier1 that fail with Zero, because they supply -XX:+TieredCompilation, and that makes VM code believe it runs in "mixed" mode. Can be reproduced trivially by running anything with -XX:+TieredCompilation. Then Zero fails when runtime asks it to produce a native wrapper for MH intrinsics. That code is normally protected by Arguments::is_interpreter_only. Method* SystemDictionary::find_method_handle_intrinsic(vmIntrinsics::ID iid, Symbol* signature, TRAPS) { ... if (!Arguments::is_interpreter_only()) { // <--- checks here // Generate a compiled form of the MH intrinsic. AdapterHandlerLibrary::create_native_wrapper(m); // <--- fails through here } Then in `sharedRuntime_zero.cpp`: nmethod *SharedRuntime::generate_native_wrapper(MacroAssembler *masm, const methodHandle& method, int compile_id, BasicType *sig_bt, VMRegPair *regs, BasicType ret_type, address critical_entry) { ShouldNotCallThis(); // <--- crashes here return NULL; } ...so: $ build/linux-x86_64-zero-fastdebug/images/jdk/bin/java -XX:+TieredCompilation OpenJDK 64-Bit Zero VM warning: -XX:+TieredCompilation not supported in this VM # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/sharedRuntime_zero.cpp:80 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/zero/sharedRuntime_zero.cpp:80), pid=404967, tid=404968 # Error: ShouldNotCall() Additional testing: - [x] ad-hoc Hello World runs with Linux x86_64 Zero - [x] re-run some failed `tier1` tests with Linux x86_64 Zero, now passing ------------- Commit messages: - 8255718: Zero: VM should know it runs in interpreter-only mode Changes: https://git.openjdk.java.net/jdk/pull/985/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=985&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255718 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/985.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/985/head:pull/985 PR: https://git.openjdk.java.net/jdk/pull/985 From shade at openjdk.java.net Sun Nov 1 17:40:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 1 Nov 2020 17:40:59 GMT Subject: RFR: 8255719: Zero: on return path, check for pending exception before attempting to clear it Message-ID: Profiling shows we spend a lot of time trying to clear the pending exception at _return path, whereas it seldom is pending. The additional problem with calling into `clear_pending_exception` is that inlining budget is depleted completely at that point in the compilation unit, and so we do the full outbound call. There are other places where we clear pending exception unconditionally, but those places do seem to expect the exceptions to be there. ------------- Commit messages: - 8255719: Zero: on return path, check for pending exception before attempting to clear it Changes: https://git.openjdk.java.net/jdk/pull/986/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=986&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255719 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/986.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/986/head:pull/986 PR: https://git.openjdk.java.net/jdk/pull/986 From redestad at openjdk.java.net Sun Nov 1 23:43:00 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Sun, 1 Nov 2020 23:43:00 GMT Subject: RFR: 8255720: Optimize bci_to_dp/-data by enabling iteration over raw DataLayouts Message-ID: MethodData::bci_to_dp and ciMethodData::bci_to_data show up in startup/warmup profiles - much of the overhead allocating resource objects when iterating over ProfileData objects (next_data) Providing a means to iterate over the raw DataLayout objects allow us to avoid explicitly allocating resource objects for purposes of calculating the next DataLayout address for the most common types. This patch reduces overhead of MethodData::bci_to_dp and ciMethodData::bci_to_data by 80% or more in profiles and has a measurable impact on simple startup tests, e.g. ~250k instruction (~0.2% of total) reduction on Hello World. Testing: tier1-3 passed ------------- Commit messages: - Merge branch 'master' into bci_to_dp_opt - Optimize bci_to_data in ciMethodData - Optimize bci_to_data similarly, remove dead code - Optimize bci_to_dp by enabling iteration over DataLayouts with as few allocations as possible Changes: https://git.openjdk.java.net/jdk/pull/988/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=988&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255720 Stats: 95 lines in 4 files changed: 67 ins; 1 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/988.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/988/head:pull/988 PR: https://git.openjdk.java.net/jdk/pull/988 From redestad at openjdk.java.net Sun Nov 1 23:43:59 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Sun, 1 Nov 2020 23:43:59 GMT Subject: RFR: 8255697: LogTargetHandle::print should check if log level is enabled Message-ID: <6IKvz2i-qnmU4MYyWBh5dHInqxJvXa_APdrnos-NW5I=.3c779a06-37da-4f11-be38-1bac4f8aa25a@github.com> An early check in LogTargetHandle::print like this can reduce overhead by not dropping into code that initialize LogDecorations et.c. This saves around 100k instructions on VM bootstrap, and can reduce cost of not logging in a few places. ------------- Commit messages: - Merge branch 'master' into print_check_enabled - Add early check if logStreamHandle is enabled Changes: https://git.openjdk.java.net/jdk/pull/964/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=964&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255697 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/964.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/964/head:pull/964 PR: https://git.openjdk.java.net/jdk/pull/964 From redestad at openjdk.java.net Sun Nov 1 23:48:02 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Sun, 1 Nov 2020 23:48:02 GMT Subject: RFR: 8255721: Remove no-op clean_weak_method_links methods Message-ID: <8DMw8Uh95wEVAR3n7glM67s8w8Hp3htB2JqbkyfPSIA=.c875a1d1-7958-4c83-aa1c-05955a3e4ca3@github.com> ProfileData:: and DataLayout::clean_weak_method_links are both virtual but empty methods with no overrides, so removing them and simplifying MethodData::clean_weak_method_links should be a minor clean-up and possibly speed-up redefinition a notch. ------------- Commit messages: - Clean-up no-op clean_weak_method_links Changes: https://git.openjdk.java.net/jdk/pull/990/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=990&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255721 Stats: 28 lines in 2 files changed: 0 ins; 28 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/990.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/990/head:pull/990 PR: https://git.openjdk.java.net/jdk/pull/990 From kvn at openjdk.java.net Mon Nov 2 01:53:55 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 2 Nov 2020 01:53:55 GMT Subject: RFR: 8255720: Optimize bci_to_dp/-data by enabling iteration over raw DataLayouts In-Reply-To: References: Message-ID: On Sun, 1 Nov 2020 22:50:39 GMT, Claes Redestad wrote: > MethodData::bci_to_dp and ciMethodData::bci_to_data show up in startup/warmup profiles - much of the overhead allocating resource objects when iterating over ProfileData objects (next_data) > > Providing a means to iterate over the raw DataLayout objects allow us to avoid explicitly allocating resource objects for purposes of calculating the next DataLayout address for the most common types. > > This patch reduces overhead of MethodData::bci_to_dp and ciMethodData::bci_to_data by 80% or more in profiles and has a measurable impact on simple startup tests, e.g. ~250k instruction (~0.2% of total) reduction on Hello World. > > Testing: tier1-3 passed Nice! ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/988 From kvn at openjdk.java.net Mon Nov 2 02:04:54 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 2 Nov 2020 02:04:54 GMT Subject: RFR: 8255721: Remove no-op clean_weak_method_links methods In-Reply-To: <8DMw8Uh95wEVAR3n7glM67s8w8Hp3htB2JqbkyfPSIA=.c875a1d1-7958-4c83-aa1c-05955a3e4ca3@github.com> References: <8DMw8Uh95wEVAR3n7glM67s8w8Hp3htB2JqbkyfPSIA=.c875a1d1-7958-4c83-aa1c-05955a3e4ca3@github.com> Message-ID: On Sun, 1 Nov 2020 23:32:29 GMT, Claes Redestad wrote: > ProfileData:: and DataLayout::clean_weak_method_links are both virtual but empty methods with no overrides, so removing them and simplifying MethodData::clean_weak_method_links should be a minor clean-up and possibly speed-up redefinition a notch. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/990 From thartmann at openjdk.java.net Mon Nov 2 07:31:56 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 2 Nov 2020 07:31:56 GMT Subject: RFR: 8255721: Remove no-op clean_weak_method_links methods In-Reply-To: <8DMw8Uh95wEVAR3n7glM67s8w8Hp3htB2JqbkyfPSIA=.c875a1d1-7958-4c83-aa1c-05955a3e4ca3@github.com> References: <8DMw8Uh95wEVAR3n7glM67s8w8Hp3htB2JqbkyfPSIA=.c875a1d1-7958-4c83-aa1c-05955a3e4ca3@github.com> Message-ID: On Sun, 1 Nov 2020 23:32:29 GMT, Claes Redestad wrote: > ProfileData:: and DataLayout::clean_weak_method_links are both virtual but empty methods with no overrides, so removing them and simplifying MethodData::clean_weak_method_links should be a minor clean-up and possibly speed-up redefinition a notch. Looks good. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/990 From stefank at openjdk.java.net Mon Nov 2 07:33:56 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 2 Nov 2020 07:33:56 GMT Subject: RFR: 8255697: LogTargetHandle::print should check if log level is enabled In-Reply-To: <6IKvz2i-qnmU4MYyWBh5dHInqxJvXa_APdrnos-NW5I=.3c779a06-37da-4f11-be38-1bac4f8aa25a@github.com> References: <6IKvz2i-qnmU4MYyWBh5dHInqxJvXa_APdrnos-NW5I=.3c779a06-37da-4f11-be38-1bac4f8aa25a@github.com> Message-ID: <2_H0BlO3bWz3SK7nXYkJpb_cvkAa7wF6e1f3zDX4zm4=.2a8f9318-5d44-4a07-9daf-ca0f322a7a8f@github.com> On Fri, 30 Oct 2020 19:40:04 GMT, Claes Redestad wrote: > An early check in LogTargetHandle::print like this can reduce overhead by not dropping into code that initialize LogDecorations et.c. This saves around 100k instructions on VM bootstrap, and can reduce cost of not logging in a few places. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/964 From tschatzl at openjdk.java.net Mon Nov 2 07:39:55 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 2 Nov 2020 07:39:55 GMT Subject: RFR: 8255697: LogTargetHandle::print should check if log level is enabled In-Reply-To: <6IKvz2i-qnmU4MYyWBh5dHInqxJvXa_APdrnos-NW5I=.3c779a06-37da-4f11-be38-1bac4f8aa25a@github.com> References: <6IKvz2i-qnmU4MYyWBh5dHInqxJvXa_APdrnos-NW5I=.3c779a06-37da-4f11-be38-1bac4f8aa25a@github.com> Message-ID: On Fri, 30 Oct 2020 19:40:04 GMT, Claes Redestad wrote: > An early check in LogTargetHandle::print like this can reduce overhead by not dropping into code that initialize LogDecorations et.c. This saves around 100k instructions on VM bootstrap, and can reduce cost of not logging in a few places. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/964 From thomas.stuefe at gmail.com Mon Nov 2 07:41:24 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 2 Nov 2020 08:41:24 +0100 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: (redirected this question to jdk-dev: https://mail.openjdk.java.net/pipermail/jdk-dev/2020-November/004887.html) Cheers, Thomas On Sat, Oct 31, 2020 at 8:05 AM Thomas St?fe wrote: > 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 >> >> >> >> From thartmann at openjdk.java.net Mon Nov 2 07:43:56 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 2 Nov 2020 07:43:56 GMT Subject: RFR: 8255720: Optimize bci_to_dp/-data by enabling iteration over raw DataLayouts In-Reply-To: References: Message-ID: On Sun, 1 Nov 2020 22:50:39 GMT, Claes Redestad wrote: > MethodData::bci_to_dp and ciMethodData::bci_to_data show up in startup/warmup profiles - much of the overhead allocating resource objects when iterating over ProfileData objects (next_data) > > Providing a means to iterate over the raw DataLayout objects allow us to avoid explicitly allocating resource objects for purposes of calculating the next DataLayout address for the most common types. > > This patch reduces overhead of MethodData::bci_to_dp and ciMethodData::bci_to_data by 80% or more in profiles and has a measurable impact on simple startup tests, e.g. ~250k instruction (~0.2% of total) reduction on Hello World. > > Testing: tier1-3 passed Looks good to! Some of the code formatting could be improved though (missing new lines between method definitions). ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/988 From stuefe at openjdk.java.net Mon Nov 2 07:48:54 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 2 Nov 2020 07:48:54 GMT Subject: RFR: 8255697: LogTargetHandle::print should check if log level is enabled In-Reply-To: <6IKvz2i-qnmU4MYyWBh5dHInqxJvXa_APdrnos-NW5I=.3c779a06-37da-4f11-be38-1bac4f8aa25a@github.com> References: <6IKvz2i-qnmU4MYyWBh5dHInqxJvXa_APdrnos-NW5I=.3c779a06-37da-4f11-be38-1bac4f8aa25a@github.com> Message-ID: <6jmSZUcu_3SzNXNkiKrM9VWIaSgMwo96XK-pSQuDfCw=.ef5a2693-709e-437a-9205-8386ff50651e@github.com> On Fri, 30 Oct 2020 19:40:04 GMT, Claes Redestad wrote: > An early check in LogTargetHandle::print like this can reduce overhead by not dropping into code that initialize LogDecorations et.c. This saves around 100k instructions on VM bootstrap, and can reduce cost of not logging in a few places. Makes sense. Callers should test this but it gets often overlooked. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/964 From stuefe at openjdk.java.net Mon Nov 2 08:54:03 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 2 Nov 2020 08:54:03 GMT Subject: RFR: JDK-8255734: VM should ignore SIGXFSZ on ppc64, s390 too Message-ID: Hi, may I have reviews please for this small fix. We willfully ignore SIGPIPE and SIGXFSZ, since their default action is to terminate the VM. However, SIGXFSZ handling was missing for linux ppc64, s390 and AIX. Note that this is a minimal patch, with the explicit aim of making backporting simple. This whole coding will change a lot with JDK-8255711, so I did refrain from changing much more code. Thanks, Thomas ------------- Commit messages: - Initial patch Changes: https://git.openjdk.java.net/jdk/pull/996/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=996&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255734 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/996/head:pull/996 PR: https://git.openjdk.java.net/jdk/pull/996 From shade at openjdk.java.net Mon Nov 2 09:06:07 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 2 Nov 2020 09:06:07 GMT Subject: RFR: 8255737: Zero: DO_UPDATE_INSTRUCTION_COUNT should only update when relevant VM flags are set Message-ID: <0rTV2XCqJXx-PVUlcJdxjg30iG2fueUwnxMHe6dFM1M=.2e8fcc35-8dbb-482e-b1ab-d5c377d79c14@github.com> Everywhere else in VM code we effectively do: if (CountBytecodes || TraceBytecodes || StopInterpreterAt) BytecodeCounter::... if (PrintBytecodeHistogram) BytecodeHistogram::... But not in `DO_UPDATE_INSTRUCTION_COUNT` macro. Adding these flags avoid the writes to statistics what would never be used (and those writes can even contend, afaics). This change drops the Linux x86_64 Zero fastdebug build time from ~18m to ~17.5m. Testing: - [x] Ad-hoc runs with Zero and affected flags ------------- Commit messages: - 8255737: Zero: DO_UPDATE_INSTRUCTION_COUNT should only update when relevant VM flags are set Changes: https://git.openjdk.java.net/jdk/pull/997/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=997&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255737 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/997.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/997/head:pull/997 PR: https://git.openjdk.java.net/jdk/pull/997 From adinn at openjdk.java.net Mon Nov 2 10:10:53 2020 From: adinn at openjdk.java.net (Andrew Dinn) Date: Mon, 2 Nov 2020 10:10:53 GMT Subject: RFR: 8255716: AArch64: Regression: JVM crashes if manually offline a core In-Reply-To: References: Message-ID: On Sun, 1 Nov 2020 12:26:15 GMT, Patrick Zhang wrote: > This assertion is practically not needed. While a test system with some cores intentionally turned off, e.g. via echo 0 > /sys/devices/system/cpu/cpu1/online, java -version would crash, building openjdk on this system would fail too. I don't follow this comment. I am not saying the check is redundant but the rationale provided above does not really cut it. Sure, a build might also fail. But that misses several possibilities. The image could be built on a different machine which didn't have the cpu switched off. The cpu switch off could happen on the same machine between building and running. If there is a good reason for not including this check the one cited above is not it. Can you just state in simple terms why it is ok to continue when the info retrieved from /proc/cpuinfo and os::processor_count() do not match up? ------------- PR: https://git.openjdk.java.net/jdk/pull/983 From redestad at openjdk.java.net Mon Nov 2 10:12:09 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Nov 2020 10:12:09 GMT Subject: RFR: 8255721: Remove no-op clean_weak_method_links methods [v2] In-Reply-To: <8DMw8Uh95wEVAR3n7glM67s8w8Hp3htB2JqbkyfPSIA=.c875a1d1-7958-4c83-aa1c-05955a3e4ca3@github.com> References: <8DMw8Uh95wEVAR3n7glM67s8w8Hp3htB2JqbkyfPSIA=.c875a1d1-7958-4c83-aa1c-05955a3e4ca3@github.com> Message-ID: > ProfileData:: and DataLayout::clean_weak_method_links are both virtual but empty methods with no overrides, so removing them and simplifying MethodData::clean_weak_method_links should be a minor clean-up and possibly speed-up redefinition a notch. 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 methoddata_cleanup - Remove undefined declaration - Clean-up no-op clean_weak_method_links ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/990/files - new: https://git.openjdk.java.net/jdk/pull/990/files/4d5c18f4..653a325f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=990&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=990&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/990.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/990/head:pull/990 PR: https://git.openjdk.java.net/jdk/pull/990 From stuefe at openjdk.java.net Mon Nov 2 10:16:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 2 Nov 2020 10:16:56 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 11:59:04 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. > > 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. Tests ran in our nightlies on all platforms successfully, including ppc, s390, aarch64. ------------- PR: https://git.openjdk.java.net/jdk/pull/839 From shade at openjdk.java.net Mon Nov 2 10:24:00 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 2 Nov 2020 10:24:00 GMT Subject: RFR: 8255741: Zero: print signal name in unhandled signal handler Message-ID: At least one test -- `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` -- fails on Zero with: # Internal Error (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:250), pid=560280, tid=560281 # fatal error: caught unhandled signal 4 The test expects "SIGKILL (sent by kill)" in the test output. Additional testing: - [x] `TestAbortVMOnSafepointTimeout.java` now passes on Linux x86_64 Zero. ------------- Commit messages: - 8255741: Zero: print signal name in unhandled signal handler Changes: https://git.openjdk.java.net/jdk/pull/1001/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1001&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255741 Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1001/head:pull/1001 PR: https://git.openjdk.java.net/jdk/pull/1001 From mdoerr at openjdk.java.net Mon Nov 2 10:32:54 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 2 Nov 2020 10:32:54 GMT Subject: RFR: JDK-8255734: VM should ignore SIGXFSZ on ppc64, s390 too In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 08:46:03 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews please for this small fix. > > We willfully ignore SIGPIPE and SIGXFSZ, since their default action is to terminate the VM. However, SIGXFSZ handling was missing for linux ppc64, s390 and AIX. > > Note that this is a minimal patch, with the explicit aim of making backporting simple. This whole coding will change a lot with JDK-8255711, so I did refrain from changing much more code. > > Thanks, Thomas Thanks for fixing it! ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/996 From shade at openjdk.java.net Mon Nov 2 10:44:09 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 2 Nov 2020 10:44:09 GMT Subject: RFR: 8255743: Relax SIGFPE match in in runtime/ErrorHandling/SecondaryErrorTest.java Message-ID: After JDK-8255741, Zero prints the message below for the affected test: # Internal Error (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:257), pid=903938, tid=903939 # fatal error: caught unhandled signal: SIGFPE Unfortunately, that still does not match the regexp in the test. Seems simple to relax the regexp a bit. @tstuefe, what do you think? Additional testing: - [x] Affected test on Linux x86_64 Zero (together with JDK-8255741 fix) - [x] Affected test on Linux x86_64 server ------------- Commit messages: - 8255743: Relax SIGFPE match in in runtime/ErrorHandling/SecondaryErrorTest.java Changes: https://git.openjdk.java.net/jdk/pull/1002/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1002&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255743 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1002.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1002/head:pull/1002 PR: https://git.openjdk.java.net/jdk/pull/1002 From stuefe at openjdk.java.net Mon Nov 2 10:49:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 2 Nov 2020 10:49:56 GMT Subject: RFR: 8255741: Zero: print signal name in unhandled signal handler In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 10:15:24 GMT, Aleksey Shipilev wrote: > At least one test -- `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` -- fails on Zero with: > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:250), pid=560280, tid=560281 > # fatal error: caught unhandled signal 4 > > The test expects "SIGKILL (sent by kill)" in the test output. > > Additional testing: > - [x] `TestAbortVMOnSafepointTimeout.java` now passes on Linux x86_64 Zero. Okay I guess, but note that I am currently rewriting all that coding for https://bugs.openjdk.java.net/browse/JDK-8255711 . Which would, as a side effect, fix this bug too. (The real bug here is that we invoke fatal() instead of calling VMError::report_and_die(), which means we won't see the real register content from the fault point in the hs-err file). See current draft: https://github.com/openjdk/jdk/pull/982 Part of the change will be to heave fatal error handler invocation out of platform dependent up to shared code (and note how I took explicit care to preserve robot and cat on zero :) . Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1001 From stuefe at openjdk.java.net Mon Nov 2 10:53:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 2 Nov 2020 10:53:55 GMT Subject: RFR: 8255743: Relax SIGFPE match in in runtime/ErrorHandling/SecondaryErrorTest.java In-Reply-To: References: Message-ID: <90gBdRL-U5Ew_Rjr3NncbaexF8CfjY8f2bD5oF3igH8=.447e2de5-a021-4eac-baa9-d4cba9832cd7@github.com> On Mon, 2 Nov 2020 10:35:41 GMT, Aleksey Shipilev wrote: > After JDK-8255741, Zero prints the message below for the affected test: > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:257), pid=903938, tid=903939 > # fatal error: caught unhandled signal: SIGFPE > > Unfortunately, that still does not match the regexp in the test. Seems simple to relax the regexp a bit. @tstuefe, what do you think? > > Additional testing: > - [x] Affected test on Linux x86_64 Zero (together with JDK-8255741 fix) > - [x] Affected test on Linux x86_64 server Same as for https://git.openjdk.java.net/jdk/pull/1001. Code will be fixed as a side effect of https://bugs.openjdk.java.net/browse/JDK-8255711. But this is fine if it fixes the test for you; plus, probably easier to downport that way. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1002 From stuefe at openjdk.java.net Mon Nov 2 10:58:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 2 Nov 2020 10:58:55 GMT Subject: RFR: 8255741: Zero: print signal name in unhandled signal handler In-Reply-To: References: Message-ID: <9fCI-E7e-v0-9FaqLn9_5YbOAw7TytgAddPg-iTajLk=.ab66309e-39f1-4069-a20f-fa82dddc589b@github.com> On Mon, 2 Nov 2020 10:15:24 GMT, Aleksey Shipilev wrote: > At least one test -- `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` -- fails on Zero with: > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:250), pid=560280, tid=560281 > # fatal error: caught unhandled signal 4 > > The test expects "SIGKILL (sent by kill)" in the test output. > > Additional testing: > - [x] `TestAbortVMOnSafepointTimeout.java` now passes on Linux x86_64 Zero. LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1001 From shade at openjdk.java.net Mon Nov 2 10:58:56 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 2 Nov 2020 10:58:56 GMT Subject: RFR: 8255741: Zero: print signal name in unhandled signal handler In-Reply-To: <9fCI-E7e-v0-9FaqLn9_5YbOAw7TytgAddPg-iTajLk=.ab66309e-39f1-4069-a20f-fa82dddc589b@github.com> References: <9fCI-E7e-v0-9FaqLn9_5YbOAw7TytgAddPg-iTajLk=.ab66309e-39f1-4069-a20f-fa82dddc589b@github.com> Message-ID: On Mon, 2 Nov 2020 10:56:13 GMT, Thomas Stuefe wrote: >> At least one test -- `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` -- fails on Zero with: >> >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:250), pid=560280, tid=560281 >> # fatal error: caught unhandled signal 4 >> >> The test expects "SIGKILL (sent by kill)" in the test output. >> >> Additional testing: >> - [x] `TestAbortVMOnSafepointTimeout.java` now passes on Linux x86_64 Zero. > > LGTM Thanks! I was not aware of #982 -- that would be very good to have. Maybe push this simple patch to ease backporting? Making Zero pass tier1 in 11u would be nice. I suspect #982 would not be backportable? ------------- PR: https://git.openjdk.java.net/jdk/pull/1001 From lucy at openjdk.java.net Mon Nov 2 11:00:01 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 2 Nov 2020 11:00:01 GMT Subject: RFR: JDK-8255734: VM should ignore SIGXFSZ on ppc64, s390 too In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 08:46:03 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews please for this small fix. > > We willfully ignore SIGPIPE and SIGXFSZ, since their default action is to terminate the VM. However, SIGXFSZ handling was missing for linux ppc64, s390 and AIX. > > Note that this is a minimal patch, with the explicit aim of making backporting simple. This whole coding will change a lot with JDK-8255711, so I did refrain from changing much more code. > > Thanks, Thomas Change looks good. It really is pointless to handle this signal in the VM. What should we do? ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/996 From redestad at openjdk.java.net Mon Nov 2 11:03:56 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Nov 2020 11:03:56 GMT Subject: RFR: 8255697: LogTargetHandle::print should check if log level is enabled In-Reply-To: References: <6IKvz2i-qnmU4MYyWBh5dHInqxJvXa_APdrnos-NW5I=.3c779a06-37da-4f11-be38-1bac4f8aa25a@github.com> Message-ID: On Mon, 2 Nov 2020 07:37:03 GMT, Thomas Schatzl wrote: >> An early check in LogTargetHandle::print like this can reduce overhead by not dropping into code that initialize LogDecorations et.c. This saves around 100k instructions on VM bootstrap, and can reduce cost of not logging in a few places. > > Marked as reviewed by tschatzl (Reviewer). @tschatzl @stefank @tstuefe - thank you for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/964 From redestad at openjdk.java.net Mon Nov 2 11:03:58 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Nov 2020 11:03:58 GMT Subject: Integrated: 8255697: LogTargetHandle::print should check if log level is enabled In-Reply-To: <6IKvz2i-qnmU4MYyWBh5dHInqxJvXa_APdrnos-NW5I=.3c779a06-37da-4f11-be38-1bac4f8aa25a@github.com> References: <6IKvz2i-qnmU4MYyWBh5dHInqxJvXa_APdrnos-NW5I=.3c779a06-37da-4f11-be38-1bac4f8aa25a@github.com> Message-ID: On Fri, 30 Oct 2020 19:40:04 GMT, Claes Redestad wrote: > An early check in LogTargetHandle::print like this can reduce overhead by not dropping into code that initialize LogDecorations et.c. This saves around 100k instructions on VM bootstrap, and can reduce cost of not logging in a few places. This pull request has now been integrated. Changeset: 79a010f7 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/79a010f7 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8255697: LogTargetHandle::print should check if log level is enabled Reviewed-by: stefank, tschatzl, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/964 From suenaga at oss.nttdata.com Mon Nov 2 11:20:36 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Mon, 2 Nov 2020 20:20:36 +0900 Subject: Unified Logging for network Message-ID: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> Hi all, We need to out UL to stdout and/or file. If we can out it to TCP socket, I think it is useful. For example, some system gather all logs to document oriented databases (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. CloudWatch). If HotSpot can out UL to TCP socket, we can send all logs to them via TCP input plugin (Fluentd, Logstash). I think it is useful for container platform. What do you think? If it is worth to work, I will add CSR and JBS ticket, and also will create patch. From shade at openjdk.java.net Mon Nov 2 11:53:01 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 2 Nov 2020 11:53:01 GMT Subject: RFR: 8255744: Zero: handle JVM_CONSTANT_DynamicInError Message-ID: JDK-8186211 introduced a few negative tests for Condy, and Zero seem to fail them: $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=java/lang/invoke/condy/CondyRepeatFailedResolution.java # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp:2289), pid=574573, tid=581749 # Error: ShouldNotReachHere() After some debugging, I think Zero misses to handle `JVM_CONSTANT_DynamicInError`. I believe we can just do the same thing as `JVM_CONSTANT_Dynamic`, and then let `CALL_VM` to go to `handle_exception` on another resolution failure. Additional testing: - [x] `CondyRepeatFailedResolution` test now passes on Linux x86_64 Zero ------------- Commit messages: - 8255744: Zero: handle JVM_CONSTANT_DynamicInError Changes: https://git.openjdk.java.net/jdk/pull/1004/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1004&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255744 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1004.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1004/head:pull/1004 PR: https://git.openjdk.java.net/jdk/pull/1004 From stuefe at openjdk.java.net Mon Nov 2 12:14:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 2 Nov 2020 12:14:59 GMT Subject: RFR: JDK-8255734: VM should ignore SIGXFSZ on ppc64, s390 too In-Reply-To: References: Message-ID: <4HipnXSqeCv8FVMWHTa_iAIvm5xV3SjmHxW5BjpX5G8=.25882950-279b-4d18-b3e6-28c5f38c28d9@github.com> On Mon, 2 Nov 2020 10:57:28 GMT, Lutz Schmidt wrote: > Change looks good. > It really is pointless to handle this signal in the VM. What should we do? This is more complicated than it looks :) Standard procedure for normal applications is to set those signals to SIG_IGN. We cannot do this, since we need to take care of third party signal handler (eg if a signal handler was in place for SIG_PIPE, we cannot just remove it by setting it to SIG_IGN. We may be able to do this too, but I have to think this through. For now, lets do as the Romans do. ------------- PR: https://git.openjdk.java.net/jdk/pull/996 From thomas.stuefe at gmail.com Mon Nov 2 12:26:45 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 2 Nov 2020 13:26:45 +0100 Subject: Unified Logging for network In-Reply-To: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> Message-ID: Hi Yasumasa, one problem I see is that this could introduce a surprising amount of lag into log() calls which do look inconspicuous, thereby distorting timing behavior or even create timeout effects. We already have that problem now to some degree when logging to network shares. Another thing, log output can be very fine granular, which would create a lot of network traffic. Such an addition may also open some security questions. >From a more philosophical standpoint, I like the "do one thing and do it right" Unix way and this seems more like something an outside tool should be doing. Which could also aggregate log output better. But I admit that argument is weak. Cheers, Thomas On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga wrote: > Hi all, > > We need to out UL to stdout and/or file. If we can out it to TCP socket, I > think it is useful. > > For example, some system gather all logs to document oriented databases > (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. CloudWatch). If > HotSpot can out UL to TCP socket, we can send all logs to them via TCP > input plugin (Fluentd, Logstash). > > I think it is useful for container platform. What do you think? > If it is worth to work, I will add CSR and JBS ticket, and also will > create patch. > From thomas.stuefe at gmail.com Mon Nov 2 12:28:17 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 2 Nov 2020 13:28:17 +0100 Subject: RFR: 8255741: Zero: print signal name in unhandled signal handler In-Reply-To: References: <9fCI-E7e-v0-9FaqLn9_5YbOAw7TytgAddPg-iTajLk=.ab66309e-39f1-4069-a20f-fa82dddc589b@github.com> Message-ID: Sure, push away, I approved both fixes. #982 would be backportable too but require much more work. Thanks, Thomas On Mon, Nov 2, 2020 at 12:01 PM Aleksey Shipilev wrote: > On Mon, 2 Nov 2020 10:56:13 GMT, Thomas Stuefe wrote: > > >> At least one test -- > `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` -- fails on Zero > with: > >> > >> # Internal Error > (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:250), > pid=560280, tid=560281 > >> # fatal error: caught unhandled signal 4 > >> > >> The test expects "SIGKILL (sent by kill)" in the test output. > >> > >> Additional testing: > >> - [x] `TestAbortVMOnSafepointTimeout.java` now passes on Linux x86_64 > Zero. > > > > LGTM > > Thanks! I was not aware of #982 -- that would be very good to have. Maybe > push this simple patch to ease backporting? Making Zero pass tier1 in 11u > would be nice. I suspect #982 would not be backportable? > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1001 > From leo.korinth at oracle.com Mon Nov 2 12:39:31 2020 From: leo.korinth at oracle.com (Leo Korinth) Date: Mon, 2 Nov 2020 13:39:31 +0100 Subject: Unified Logging for network In-Reply-To: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> Message-ID: <5c5e812f-9730-4358-b79e-efd4875153f3@oracle.com> I think it is a mistake. Making UL easy to use over network will make people use it (over network). It will have bad latency and will transfer an unstable log format. If some important data is missing from JFR, would it not be better to add new JFR events? If you need it for debug reasons, you could just pipe stdout through netcat (I guess). Thanks, Leo On 02/11/2020 12:20, Yasumasa Suenaga wrote: > Hi all, > > We need to out UL to stdout and/or file. If we can out it to TCP socket, I think it is useful. > > For example, some system gather all logs to document oriented databases (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. CloudWatch). If HotSpot can out UL to TCP socket, we can send all logs to them via TCP input plugin (Fluentd, Logstash). > > I think it is useful for container platform. What do you think? > If it is worth to work, I will add CSR and JBS ticket, and also will create patch. From akozlov at openjdk.java.net Mon Nov 2 12:39:59 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 2 Nov 2020 12:39:59 GMT Subject: RFR: 8255716: AArch64: Regression: JVM crashes if manually offline a core In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 10:08:25 GMT, Andrew Dinn wrote: >> Please review this change that removed the unnecessary check **cpu_lines == os::processor_count()** from VM_Version::get_os_cpu_info inside src/hotspot/os_cpu/linux_aarch64/vm_version_linux_aarch64.cpp. >> >> This **assertion** is practically not needed. While a test system with some cores intentionally turned off, e.g. via echo 0 > /sys/devices/system/cpu/cpu1/online, **java -version** would crash, building openjdk on this system would fail too. >> >> This regression issue was introduced by https://github.com/openjdk/jdk/commit/ec9bee68 >> >> Testing: >> - java -version, building openjdk as smoke tests >> - jtreg tier1 as sanity check > >> This assertion is practically not needed. While a test system with some cores intentionally turned off, e.g. via echo 0 > /sys/devices/system/cpu/cpu1/online, java -version would crash, building openjdk on this system would fail too. > > I don't follow this comment. I am not saying the check is redundant but the rationale provided above does not really cut it. Sure, a build might also fail. But that misses several possibilities. The image could be built on a different machine which didn't have the cpu switched off. The cpu switch off could happen on the same machine between building and running. If there is a good reason for not including this check the one cited above is not it. > > Can you just state in simple terms why it is ok to continue when the info retrieved from /proc/cpuinfo and os::processor_count() do not match up? Hi, I've introduced this check, so I feel responsible. The number of cores reported in /proc/cpuinfo was used to decide CPU_A53MAC feature https://github.com/openjdk/jdk/commit/ec9bee68660acd6abf0b4dd4023ae69514542256#diff-a87e260510f34ca7d9b0feb089ad982be8268c5c8aa5a71221f6738b051ea488R184. After the change, os::processor_count is used instead and the guarantee checks the meaning of the CPU_A53MAC has not changed. processor_count is initialized with sysconf https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp#L364, which now I see may be affected by disabling cores https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getsysstats.c;h=6d4c9c06e8a5de1b97da448909aa0874df5f6c88;hb=6d4c9c06e8a5de1b97da448909aa0874df5f6c88#l113. So processor_count can be actually not equal to number of CPUs in /proc/cpuinfo. Assert can be relaxed (`<=` should be correct). But even after that, it's incorrect to set the feature with only one active core. It does not look critical (the feature should be harmless), but does not look right as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/983 From stuefe at openjdk.java.net Mon Nov 2 12:52:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 2 Nov 2020 12:52:58 GMT Subject: Integrated: JDK-8255734: VM should ignore SIGXFSZ on ppc64, s390 too In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 08:46:03 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews please for this small fix. > > We willfully ignore SIGPIPE and SIGXFSZ, since their default action is to terminate the VM. However, SIGXFSZ handling was missing for linux ppc64, s390 and AIX. > > Note that this is a minimal patch, with the explicit aim of making backporting simple. This whole coding will change a lot with JDK-8255711, so I did refrain from changing much more code. > > Thanks, Thomas This pull request has now been integrated. Changeset: 54c88132 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/54c88132 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8255734: VM should ignore SIGXFSZ on ppc64, s390 too Reviewed-by: mdoerr, lucy ------------- PR: https://git.openjdk.java.net/jdk/pull/996 From qpzhang at openjdk.java.net Mon Nov 2 13:05:54 2020 From: qpzhang at openjdk.java.net (Patrick Zhang) Date: Mon, 2 Nov 2020 13:05:54 GMT Subject: RFR: 8255716: AArch64: Regression: JVM crashes if manually offline a core In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 10:08:25 GMT, Andrew Dinn wrote: > > This assertion is practically not needed. While a test system with some cores intentionally turned off, e.g. via echo 0 > /sys/devices/system/cpu/cpu1/online, java -version would crash, building openjdk on this system would fail too. > > I don't follow this comment. I am not saying the check is redundant but the rationale provided above does not really cut it. Sure, a build might also fail. But that misses several possibilities. The image could be built on a different machine which didn't have the cpu switched off. The cpu switch off could happen on the same machine between building and running. If there is a good reason for not including this check the one cited above is not it. > > Can you just state in simple terms why it is ok to continue when the info retrieved from /proc/cpuinfo and os::processor_count() do not match up? JVM can work well with the number of enabled cores, which is equivalent to the value of os::processor_count(), e.g. decide the number of threads for parallel gc. While counting the lines from /proc/cpuinfo is a static number. ------------- PR: https://git.openjdk.java.net/jdk/pull/983 From redestad at openjdk.java.net Mon Nov 2 13:09:08 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Nov 2020 13:09:08 GMT Subject: RFR: 8255720: Optimize bci_to_dp/-data by enabling iteration over raw DataLayouts [v2] In-Reply-To: References: Message-ID: > MethodData::bci_to_dp and ciMethodData::bci_to_data show up in startup/warmup profiles - much of the overhead allocating resource objects when iterating over ProfileData objects (next_data) > > Providing a means to iterate over the raw DataLayout objects allow us to avoid explicitly allocating resource objects for purposes of calculating the next DataLayout address for the most common types. > > This patch reduces overhead of MethodData::bci_to_dp and ciMethodData::bci_to_data by 80% or more in profiles and has a measurable impact on simple startup tests, e.g. ~250k instruction (~0.2% of total) reduction on Hello World. > > Testing: tier1-3 passed 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: - More lines - Merge branch 'master' into bci_to_dp_opt - Merge branch 'master' into bci_to_dp_opt - Optimize bci_to_data in ciMethodData - Optimize bci_to_data similarly, remove dead code - Optimize bci_to_dp by enabling iteration over DataLayouts with as few allocations as possible ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/988/files - new: https://git.openjdk.java.net/jdk/pull/988/files/0d8e8f04..b12ff3b3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=988&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=988&range=00-01 Stats: 682 lines in 21 files changed: 593 ins; 37 del; 52 mod Patch: https://git.openjdk.java.net/jdk/pull/988.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/988/head:pull/988 PR: https://git.openjdk.java.net/jdk/pull/988 From qpzhang at openjdk.java.net Mon Nov 2 13:14:58 2020 From: qpzhang at openjdk.java.net (Patrick Zhang) Date: Mon, 2 Nov 2020 13:14:58 GMT Subject: RFR: 8255716: AArch64: Regression: JVM crashes if manually offline a core In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 13:03:01 GMT, Patrick Zhang wrote: >>> This assertion is practically not needed. While a test system with some cores intentionally turned off, e.g. via echo 0 > /sys/devices/system/cpu/cpu1/online, java -version would crash, building openjdk on this system would fail too. >> >> I don't follow this comment. I am not saying the check is redundant but the rationale provided above does not really cut it. Sure, a build might also fail. But that misses several possibilities. The image could be built on a different machine which didn't have the cpu switched off. The cpu switch off could happen on the same machine between building and running. If there is a good reason for not including this check the one cited above is not it. >> >> Can you just state in simple terms why it is ok to continue when the info retrieved from /proc/cpuinfo and os::processor_count() do not match up? > >> > This assertion is practically not needed. While a test system with some cores intentionally turned off, e.g. via echo 0 > /sys/devices/system/cpu/cpu1/online, java -version would crash, building openjdk on this system would fail too. >> >> I don't follow this comment. I am not saying the check is redundant but the rationale provided above does not really cut it. Sure, a build might also fail. But that misses several possibilities. The image could be built on a different machine which didn't have the cpu switched off. The cpu switch off could happen on the same machine between building and running. If there is a good reason for not including this check the one cited above is not it. >> >> Can you just state in simple terms why it is ok to continue when the info retrieved from /proc/cpuinfo and os::processor_count() do not match up? > > JVM can work well with the number of enabled cores, which is equivalent to the value of os::processor_count(), e.g. decide the number of threads for parallel gc. While counting the lines from /proc/cpuinfo is a static number. > /proc/cpuinfo was used to decide CPU_A53MAC feature [ec9bee6#diff-a87e260510f34ca7d9b0feb089ad982be8268c5c8aa5a71221f6738b051ea488R184](https://github.com/openjdk/jdk/commit/ec9bee68660acd6abf0b4dd4023ae69514542256#diff-a87e260510f34ca7d9b0feb089ad982be8268c5c8aa5a71221f6738b051ea488R184). Thanks for your comment. Yes, I noticed this part as well. One possible of solving that could be having a duplicated but simpler '_counting /proc/cpuinfo lines_' logic here. I want to solve the [guarantee call](https://github.com/openjdk/jdk/pull/983/files#diff-7e6fa90a7bcdbe41687eb8d39c6c6232e6518b019937a87aab75284166ef67bdL171) issue firstly, as it is breaking my daily build & test (where I have only half of cores online). ------------- PR: https://git.openjdk.java.net/jdk/pull/983 From thartmann at openjdk.java.net Mon Nov 2 13:14:59 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 2 Nov 2020 13:14:59 GMT Subject: RFR: 8255721: Remove no-op clean_weak_method_links methods [v2] In-Reply-To: References: <8DMw8Uh95wEVAR3n7glM67s8w8Hp3htB2JqbkyfPSIA=.c875a1d1-7958-4c83-aa1c-05955a3e4ca3@github.com> Message-ID: On Mon, 2 Nov 2020 10:12:09 GMT, Claes Redestad wrote: >> ProfileData:: and DataLayout::clean_weak_method_links are both virtual but empty methods with no overrides, so removing them and simplifying MethodData::clean_weak_method_links should be a minor clean-up and possibly speed-up redefinition a notch. > > 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 methoddata_cleanup > - Remove undefined declaration > - Clean-up no-op clean_weak_method_links Marked as reviewed by thartmann (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/990 From thartmann at openjdk.java.net Mon Nov 2 13:16:02 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 2 Nov 2020 13:16:02 GMT Subject: RFR: 8255720: Optimize bci_to_dp/-data by enabling iteration over raw DataLayouts [v2] In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 13:09:08 GMT, Claes Redestad wrote: >> MethodData::bci_to_dp and ciMethodData::bci_to_data show up in startup/warmup profiles - much of the overhead allocating resource objects when iterating over ProfileData objects (next_data) >> >> Providing a means to iterate over the raw DataLayout objects allow us to avoid explicitly allocating resource objects for purposes of calculating the next DataLayout address for the most common types. >> >> This patch reduces overhead of MethodData::bci_to_dp and ciMethodData::bci_to_data by 80% or more in profiles and has a measurable impact on simple startup tests, e.g. ~250k instruction (~0.2% of total) reduction on Hello World. >> >> Testing: tier1-3 passed > > 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: > > - More lines > - Merge branch 'master' into bci_to_dp_opt > - Merge branch 'master' into bci_to_dp_opt > - Optimize bci_to_data in ciMethodData > - Optimize bci_to_data similarly, remove dead code > - Optimize bci_to_dp by enabling iteration over DataLayouts with as few allocations as possible Looks good, thanks for making these changes. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/988 From redestad at openjdk.java.net Mon Nov 2 13:23:57 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Nov 2020 13:23:57 GMT Subject: RFR: 8255720: Optimize bci_to_dp/-data by enabling iteration over raw DataLayouts [v2] In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 01:50:52 GMT, Vladimir Kozlov 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 six additional commits since the last revision: >> >> - More lines >> - Merge branch 'master' into bci_to_dp_opt >> - Merge branch 'master' into bci_to_dp_opt >> - Optimize bci_to_data in ciMethodData >> - Optimize bci_to_data similarly, remove dead code >> - Optimize bci_to_dp by enabling iteration over DataLayouts with as few allocations as possible > > Nice! @vnkozlov @TobiHartmann - thank you for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/988 From redestad at openjdk.java.net Mon Nov 2 13:25:01 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Nov 2020 13:25:01 GMT Subject: RFR: 8255721: Remove no-op clean_weak_method_links methods [v2] In-Reply-To: References: <8DMw8Uh95wEVAR3n7glM67s8w8Hp3htB2JqbkyfPSIA=.c875a1d1-7958-4c83-aa1c-05955a3e4ca3@github.com> Message-ID: On Mon, 2 Nov 2020 02:02:17 GMT, Vladimir Kozlov 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 methoddata_cleanup >> - Remove undefined declaration >> - Clean-up no-op clean_weak_method_links > > Good. @vnkozlov @TobiHartmann - thank you for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/990 From redestad at openjdk.java.net Mon Nov 2 13:28:10 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Nov 2020 13:28:10 GMT Subject: RFR: 8255756: Disabling logging does unnecessary work Message-ID: When disabling UL outputs - for example when shutting down the JVM - we are doing some unnecessary work: - we always disable all outputs in bulk, but the routine searches up outputs one by one in the LogTagSet output lists - instead we could just drop all nodes in these lists in one quick pass. - when finalizing for a JVM shutdown, it's unnecessary to update decorators While not technically startup this gets rid of some noise on JVM exit (~45k instructions) that show up when using full JVM executions as a proxy for startup testing (or when running many shortlived JVMs back-to-back). ------------- Commit messages: - Improve wording - Remove extra lines - Clean up and fix clear - Shortcut clearing of all outputs from tagsets - Shortcut clearing of all outputs from tagsets - Fix loop - Merge branch 'master' into disable_logging - Disabling logging outputs on exit does unnecessary work Changes: https://git.openjdk.java.net/jdk/pull/1005/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1005&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255756 Stats: 48 lines in 5 files changed: 30 ins; 4 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1005.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1005/head:pull/1005 PR: https://git.openjdk.java.net/jdk/pull/1005 From redestad at openjdk.java.net Mon Nov 2 13:31:57 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Nov 2020 13:31:57 GMT Subject: Integrated: 8255720: Optimize bci_to_dp/-data by enabling iteration over raw DataLayouts In-Reply-To: References: Message-ID: On Sun, 1 Nov 2020 22:50:39 GMT, Claes Redestad wrote: > MethodData::bci_to_dp and ciMethodData::bci_to_data show up in startup/warmup profiles - much of the overhead allocating resource objects when iterating over ProfileData objects (next_data) > > Providing a means to iterate over the raw DataLayout objects allow us to avoid explicitly allocating resource objects for purposes of calculating the next DataLayout address for the most common types. > > This patch reduces overhead of MethodData::bci_to_dp and ciMethodData::bci_to_data by 80% or more in profiles and has a measurable impact on simple startup tests, e.g. ~250k instruction (~0.2% of total) reduction on Hello World. > > Testing: tier1-3 passed This pull request has now been integrated. Changeset: 120aec70 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/120aec70 Stats: 99 lines in 4 files changed: 71 ins; 1 del; 27 mod 8255720: Optimize bci_to_dp/-data by enabling iteration over raw DataLayouts Reviewed-by: kvn, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/988 From aph at openjdk.java.net Mon Nov 2 13:31:57 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 2 Nov 2020 13:31:57 GMT Subject: RFR: 8255716: AArch64: Regression: JVM crashes if manually offline a core In-Reply-To: References: Message-ID: On Sun, 1 Nov 2020 12:26:15 GMT, Patrick Zhang wrote: > Please review this change that removed the unnecessary check **cpu_lines == os::processor_count()** from VM_Version::get_os_cpu_info inside src/hotspot/os_cpu/linux_aarch64/vm_version_linux_aarch64.cpp. > > This **assertion** is practically not needed. While a test system with some cores intentionally turned off, e.g. via echo 0 > /sys/devices/system/cpu/cpu1/online, **java -version** would crash, building openjdk on this system would fail too. > > This regression issue was introduced by https://github.com/openjdk/jdk/commit/ec9bee68 > > Testing: > - java -version, building openjdk as smoke tests > - jtreg tier1 as sanity check Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/983 From redestad at openjdk.java.net Mon Nov 2 13:31:58 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 2 Nov 2020 13:31:58 GMT Subject: Integrated: 8255721: Remove no-op clean_weak_method_links methods In-Reply-To: <8DMw8Uh95wEVAR3n7glM67s8w8Hp3htB2JqbkyfPSIA=.c875a1d1-7958-4c83-aa1c-05955a3e4ca3@github.com> References: <8DMw8Uh95wEVAR3n7glM67s8w8Hp3htB2JqbkyfPSIA=.c875a1d1-7958-4c83-aa1c-05955a3e4ca3@github.com> Message-ID: On Sun, 1 Nov 2020 23:32:29 GMT, Claes Redestad wrote: > ProfileData:: and DataLayout::clean_weak_method_links are both virtual but empty methods with no overrides, so removing them and simplifying MethodData::clean_weak_method_links should be a minor clean-up and possibly speed-up redefinition a notch. This pull request has now been integrated. Changeset: 4b775e64 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/4b775e64 Stats: 29 lines in 2 files changed: 0 ins; 29 del; 0 mod 8255721: Remove no-op clean_weak_method_links methods Reviewed-by: kvn, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/990 From adinn at openjdk.java.net Mon Nov 2 13:48:01 2020 From: adinn at openjdk.java.net (Andrew Dinn) Date: Mon, 2 Nov 2020 13:48:01 GMT Subject: RFR: 8255716: AArch64: Regression: JVM crashes if manually offline a core In-Reply-To: References: Message-ID: <0rLudl3g60pNgAiWtp3iqX-u4la33OicQFxaKN031Js=.a44775c5-a8c1-430a-b92b-c11a84096c97@github.com> On Sun, 1 Nov 2020 12:26:15 GMT, Patrick Zhang wrote: > Please review this change that removed the unnecessary check **cpu_lines == os::processor_count()** from VM_Version::get_os_cpu_info inside src/hotspot/os_cpu/linux_aarch64/vm_version_linux_aarch64.cpp. > > This **assertion** is practically not needed. While a test system with some cores intentionally turned off, e.g. via echo 0 > /sys/devices/system/cpu/cpu1/online, **java -version** would crash, building openjdk on this system would fail too. > > This regression issue was introduced by https://github.com/openjdk/jdk/commit/ec9bee68 > > Testing: > - java -version, building openjdk as smoke tests > - jtreg tier1 as sanity check Marked as reviewed by adinn (Reviewer). @cnqpzhang I agree this guarantee needs removing as it breaks a valid case. @AntonKozlov If the code that sets the A53MAC property really needs to be based on the cpu count obtained from /proc/cpuinfo then you need to rework things so that the OS-specific code can communicate the requisite info to the os agnostic vm_version code. Could you raise a new JIRA for that and propose a fix? ------------- PR: https://git.openjdk.java.net/jdk/pull/983 From qpzhang at openjdk.java.net Mon Nov 2 13:56:54 2020 From: qpzhang at openjdk.java.net (Patrick Zhang) Date: Mon, 2 Nov 2020 13:56:54 GMT Subject: RFR: 8255716: AArch64: Regression: JVM crashes if manually offline a core In-Reply-To: <0rLudl3g60pNgAiWtp3iqX-u4la33OicQFxaKN031Js=.a44775c5-a8c1-430a-b92b-c11a84096c97@github.com> References: <0rLudl3g60pNgAiWtp3iqX-u4la33OicQFxaKN031Js=.a44775c5-a8c1-430a-b92b-c11a84096c97@github.com> Message-ID: On Mon, 2 Nov 2020 13:45:00 GMT, Andrew Dinn wrote: >> Please review this change that removed the unnecessary check **cpu_lines == os::processor_count()** from VM_Version::get_os_cpu_info inside src/hotspot/os_cpu/linux_aarch64/vm_version_linux_aarch64.cpp. >> >> This **assertion** is practically not needed. While a test system with some cores intentionally turned off, e.g. via echo 0 > /sys/devices/system/cpu/cpu1/online, **java -version** would crash, building openjdk on this system would fail too. >> >> This regression issue was introduced by https://github.com/openjdk/jdk/commit/ec9bee68 >> >> Testing: >> - java -version, building openjdk as smoke tests >> - jtreg tier1 as sanity check > > Marked as reviewed by adinn (Reviewer). Thanks for your review and comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/983 From akozlov at openjdk.java.net Mon Nov 2 15:12:54 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 2 Nov 2020 15:12:54 GMT Subject: RFR: 8255716: AArch64: Regression: JVM crashes if manually offline a core In-Reply-To: References: <0rLudl3g60pNgAiWtp3iqX-u4la33OicQFxaKN031Js=.a44775c5-a8c1-430a-b92b-c11a84096c97@github.com> Message-ID: <1oOiQohoWLHbEx0VgKlzWpNZwxzE7H0ZcodOVuiBX60=.0046e475-00d9-4763-b057-dfab48623796@github.com> On Mon, 2 Nov 2020 13:54:09 GMT, Patrick Zhang wrote: >> Marked as reviewed by adinn (Reviewer). > > Thanks for your review and comments. > @AntonKozlov If the code that sets the A53MAC property really needs to be based on the cpu count obtained from /proc/cpuinfo I would like to know that for sure. The code was introduced in http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6e2422a230fd#l6.48, unfortunately I don't know reasoning behind. > Could you raise a new JIRA for that and propose a fix? Ok, I'll do this, just to make sure we set the feature just as it was before. @cnqpzhang I will likely re-introduce cpu_line counting in the follow-up patch. It would be handy if you just relax the assert (like `cpu_lines >= os::processor_count()`, btw, does this work for you, is the guess is correct?) instead of removing it completely. But this is not very important. Also, I'm not a reviewer in the jdk project, not sure if I can be credited for review. ------------- PR: https://git.openjdk.java.net/jdk/pull/983 From adinn at openjdk.java.net Mon Nov 2 15:46:55 2020 From: adinn at openjdk.java.net (Andrew Dinn) Date: Mon, 2 Nov 2020 15:46:55 GMT Subject: RFR: 8255716: AArch64: Regression: JVM crashes if manually offline a core In-Reply-To: <1oOiQohoWLHbEx0VgKlzWpNZwxzE7H0ZcodOVuiBX60=.0046e475-00d9-4763-b057-dfab48623796@github.com> References: <0rLudl3g60pNgAiWtp3iqX-u4la33OicQFxaKN031Js=.a44775c5-a8c1-430a-b92b-c11a84096c97@github.com> <1oOiQohoWLHbEx0VgKlzWpNZwxzE7H0ZcodOVuiBX60=.0046e475-00d9-4763-b057-dfab48623796@github.com> Message-ID: On Mon, 2 Nov 2020 15:10:26 GMT, Anton Kozlov wrote: > Also, I'm not a reviewer in the jdk project, not sure if I can be credited for review. Anyone can offer a review, not just big 'R' Reviewers. Small 'r' reviewers don't count towards official sign-off but they *do* count as far as getting it right is concerned. So, thanks for chipping in. ------------- PR: https://git.openjdk.java.net/jdk/pull/983 From shade at openjdk.java.net Mon Nov 2 18:04:08 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 2 Nov 2020 18:04:08 GMT Subject: RFR: 8255741: Zero: print signal name in unhandled signal handler [v2] In-Reply-To: References: Message-ID: > At least one test -- `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` -- fails on Zero with: > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:250), pid=560280, tid=560281 > # fatal error: caught unhandled signal 4 > > The test expects "SIGKILL (sent by kill)" in the test output. > > Additional testing: > - [x] `TestAbortVMOnSafepointTimeout.java` now passes on Linux x86_64 Zero. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Minor stylistic change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1001/files - new: https://git.openjdk.java.net/jdk/pull/1001/files/89de8c27..3356bd3f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1001&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1001&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1001/head:pull/1001 PR: https://git.openjdk.java.net/jdk/pull/1001 From kirk at kodewerk.com Mon Nov 2 19:10:45 2020 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Mon, 2 Nov 2020 11:10:45 -0800 Subject: Unified Logging for network In-Reply-To: References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> Message-ID: <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> Hi Thomas, I appreciate Yasumasa?s desire to be able to redirect UL output to somewhere other than? I also appreciate that the highly granular nature of how UL messages are currently structure can be and indeed are an issue. That said, I?d also like the ability to push the data to some where other than a file on disk. To the point of granularity, UL might benefit from some message coarsening. This might also help in with other logging related performance issues that I?ve noted here and there. Quite frankly dealing with logs in containers isn?t a wonderful experience. And while I firmly believe that there is more that containers can do to ease this, being able to redirect output to something other than a log file does feel like it would be helpful. That said, I?m also concerned about the potential performance impacts but I think for this things that one would generally log, this should be minimal. Kind regards, Kirk Pepperdine > On Nov 2, 2020, at 4:26 AM, Thomas St?fe wrote: > > Hi Yasumasa, > > one problem I see is that this could introduce a surprising amount of lag > into log() calls which do look inconspicuous, thereby distorting timing > behavior or even create timeout effects. We already have that problem now > to some degree when logging to network shares. > > Another thing, log output can be very fine granular, which would create a > lot of network traffic. > > Such an addition may also open some security questions. > > From a more philosophical standpoint, I like the "do one thing and do it > right" Unix way and this seems more like something an outside tool should > be doing. Which could also aggregate log output better. But I admit that > argument is weak. > > Cheers, Thomas > > > > On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga > wrote: > >> Hi all, >> >> We need to out UL to stdout and/or file. If we can out it to TCP socket, I >> think it is useful. >> >> For example, some system gather all logs to document oriented databases >> (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. CloudWatch). If >> HotSpot can out UL to TCP socket, we can send all logs to them via TCP >> input plugin (Fluentd, Logstash). >> >> I think it is useful for container platform. What do you think? >> If it is worth to work, I will add CSR and JBS ticket, and also will >> create patch. >> From ioi.lam at oracle.com Mon Nov 2 21:16:05 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 2 Nov 2020 13:16:05 -0800 Subject: Unified Logging for network In-Reply-To: <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> Message-ID: <41f33608-63de-c7cb-e135-13a6fcc39b05@oracle.com> For performance, maybe the implementation can log into a memory buffer, and use a worker thread to send the output over the network? That way we can minimize the overhead per log_xxx() call. I agree that using "-Xlog:foo=debug:network=xyz.com:1234" would be quite handy when you have lots of containers. You don't need to enable remote access to the container's file system just to get to the log file. Thanks - Ioi On 11/2/20 11:10 AM, Kirk Pepperdine wrote: > Hi Thomas, > > I appreciate Yasumasa?s desire to be able to redirect UL output to somewhere other than? I also appreciate that the highly granular nature of how UL messages are currently structure can be and indeed are an issue. That said, I?d also like the ability to push the data to some where other than a file on disk. > > To the point of granularity, UL might benefit from some message coarsening. This might also help in with other logging related performance issues that I?ve noted here and there. Quite frankly dealing with logs in containers isn?t a wonderful experience. And while I firmly believe that there is more that containers can do to ease this, being able to redirect output to something other than a log file does feel like it would be helpful. That said, I?m also concerned about the potential performance impacts but I think for this things that one would generally log, this should be minimal. > > Kind regards, > Kirk Pepperdine > > >> On Nov 2, 2020, at 4:26 AM, Thomas St?fe wrote: >> >> Hi Yasumasa, >> >> one problem I see is that this could introduce a surprising amount of lag >> into log() calls which do look inconspicuous, thereby distorting timing >> behavior or even create timeout effects. We already have that problem now >> to some degree when logging to network shares. >> >> Another thing, log output can be very fine granular, which would create a >> lot of network traffic. >> >> Such an addition may also open some security questions. >> >> From a more philosophical standpoint, I like the "do one thing and do it >> right" Unix way and this seems more like something an outside tool should >> be doing. Which could also aggregate log output better. But I admit that >> argument is weak. >> >> Cheers, Thomas >> >> >> >> On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga >> wrote: >> >>> Hi all, >>> >>> We need to out UL to stdout and/or file. If we can out it to TCP socket, I >>> think it is useful. >>> >>> For example, some system gather all logs to document oriented databases >>> (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. CloudWatch). If >>> HotSpot can out UL to TCP socket, we can send all logs to them via TCP >>> input plugin (Fluentd, Logstash). >>> >>> I think it is useful for container platform. What do you think? >>> If it is worth to work, I will add CSR and JBS ticket, and also will >>> create patch. >>> From andrew at openjdk.java.net Mon Nov 2 21:22:00 2020 From: andrew at openjdk.java.net (Andrew John Hughes) Date: Mon, 2 Nov 2020 21:22:00 GMT Subject: RFR: 8255718: Zero: VM should know it runs in interpreter-only mode In-Reply-To: References: Message-ID: On Sun, 1 Nov 2020 17:24:44 GMT, Aleksey Shipilev wrote: > There are many tests in tier1 that fail with Zero, because they supply -XX:+TieredCompilation, and that makes VM code believe it runs in "mixed" mode. > > Can be reproduced trivially by running anything with -XX:+TieredCompilation. Then Zero fails when runtime asks it to produce a native wrapper for MH intrinsics. That code is normally protected by Arguments::is_interpreter_only. > > Method* SystemDictionary::find_method_handle_intrinsic(vmIntrinsics::ID iid, > Symbol* signature, > TRAPS) { > ... > if (!Arguments::is_interpreter_only()) { // <--- checks here > // Generate a compiled form of the MH intrinsic. > AdapterHandlerLibrary::create_native_wrapper(m); // <--- fails through here > } > > Then in `sharedRuntime_zero.cpp`: > > nmethod *SharedRuntime::generate_native_wrapper(MacroAssembler *masm, > const methodHandle& method, > int compile_id, > BasicType *sig_bt, > VMRegPair *regs, > BasicType ret_type, > address critical_entry) { > ShouldNotCallThis(); // <--- crashes here > return NULL; > } > > ...so: > > $ build/linux-x86_64-zero-fastdebug/images/jdk/bin/java -XX:+TieredCompilation > OpenJDK 64-Bit Zero VM warning: -XX:+TieredCompilation not supported in this VM > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/sharedRuntime_zero.cpp:80 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/zero/sharedRuntime_zero.cpp:80), pid=404967, tid=404968 > # Error: ShouldNotCall() > > Additional testing: > - [x] ad-hoc Hello World runs with Linux x86_64 Zero > - [x] re-run some failed `tier1` tests with Linux x86_64 Zero, now passing Seems sensible to me. ------------- Marked as reviewed by andrew (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/985 From thomas.stuefe at gmail.com Mon Nov 2 21:31:26 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 2 Nov 2020 22:31:26 +0100 Subject: Unified Logging for network In-Reply-To: <41f33608-63de-c7cb-e135-13a6fcc39b05@oracle.com> References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> <41f33608-63de-c7cb-e135-13a6fcc39b05@oracle.com> Message-ID: Hi Ioi, I dimly remember proposals like this from the past. Main problem I see is how large would you dimension the buffer, and what do you do if the buffer cannot be drained rapidly enough. Discard log output? Hold? The former sounds bad, the latter negates the advantages of such a buffer. Then, access to such a buffer would probably have to be synchronized, whereas today AFAIK the log calls do not have to be. Cheers, Thomas On Mon 2. Nov 2020 at 22:18, Ioi Lam wrote: > For performance, maybe the implementation can log into a memory buffer, > and use a worker thread to send the output over the network? That way we > can minimize the overhead per log_xxx() call. > > I agree that using "-Xlog:foo=debug:network=xyz.com:1234" would be quite > handy when you have lots of containers. You don't need to enable remote > access to the container's file system just to get to the log file. > > Thanks > - Ioi > > On 11/2/20 11:10 AM, Kirk Pepperdine wrote: > > Hi Thomas, > > > > I appreciate Yasumasa?s desire to be able to redirect UL output to > somewhere other than? I also appreciate that the highly granular nature of > how UL messages are currently structure can be and indeed are an issue. > That said, I?d also like the ability to push the data to some where other > than a file on disk. > > > > To the point of granularity, UL might benefit from some message > coarsening. This might also help in with other logging related performance > issues that I?ve noted here and there. Quite frankly dealing with logs in > containers isn?t a wonderful experience. And while I firmly believe that > there is more that containers can do to ease this, being able to redirect > output to something other than a log file does feel like it would be > helpful. That said, I?m also concerned about the potential performance > impacts but I think for this things that one would generally log, this > should be minimal. > > > > Kind regards, > > Kirk Pepperdine > > > > > >> On Nov 2, 2020, at 4:26 AM, Thomas St?fe > wrote: > >> > >> Hi Yasumasa, > >> > >> one problem I see is that this could introduce a surprising amount of > lag > >> into log() calls which do look inconspicuous, thereby distorting timing > >> behavior or even create timeout effects. We already have that problem > now > >> to some degree when logging to network shares. > >> > >> Another thing, log output can be very fine granular, which would create > a > >> lot of network traffic. > >> > >> Such an addition may also open some security questions. > >> > >> From a more philosophical standpoint, I like the "do one thing and do > it > >> right" Unix way and this seems more like something an outside tool > should > >> be doing. Which could also aggregate log output better. But I admit that > >> argument is weak. > >> > >> Cheers, Thomas > >> > >> > >> > >> On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga < > suenaga at oss.nttdata.com> > >> wrote: > >> > >>> Hi all, > >>> > >>> We need to out UL to stdout and/or file. If we can out it to TCP > socket, I > >>> think it is useful. > >>> > >>> For example, some system gather all logs to document oriented databases > >>> (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. > CloudWatch). If > >>> HotSpot can out UL to TCP socket, we can send all logs to them via TCP > >>> input plugin (Fluentd, Logstash). > >>> > >>> I think it is useful for container platform. What do you think? > >>> If it is worth to work, I will add CSR and JBS ticket, and also will > >>> create patch. > >>> > > From coleenp at openjdk.java.net Mon Nov 2 23:05:53 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 2 Nov 2020 23:05:53 GMT Subject: RFR: 8255718: Zero: VM should know it runs in interpreter-only mode In-Reply-To: References: Message-ID: <9CDwd7hyKzTFmHx44cxYHi6bVDlSB0MO_9U8Ao6cVfc=.782bd12f-ecfb-47a2-8bec-1c7b01b88683@github.com> On Sun, 1 Nov 2020 17:24:44 GMT, Aleksey Shipilev wrote: > There are many tests in tier1 that fail with Zero, because they supply -XX:+TieredCompilation, and that makes VM code believe it runs in "mixed" mode. > > Can be reproduced trivially by running anything with -XX:+TieredCompilation. Then Zero fails when runtime asks it to produce a native wrapper for MH intrinsics. That code is normally protected by Arguments::is_interpreter_only. > > Method* SystemDictionary::find_method_handle_intrinsic(vmIntrinsics::ID iid, > Symbol* signature, > TRAPS) { > ... > if (!Arguments::is_interpreter_only()) { // <--- checks here > // Generate a compiled form of the MH intrinsic. > AdapterHandlerLibrary::create_native_wrapper(m); // <--- fails through here > } > > Then in `sharedRuntime_zero.cpp`: > > nmethod *SharedRuntime::generate_native_wrapper(MacroAssembler *masm, > const methodHandle& method, > int compile_id, > BasicType *sig_bt, > VMRegPair *regs, > BasicType ret_type, > address critical_entry) { > ShouldNotCallThis(); // <--- crashes here > return NULL; > } > > ...so: > > $ build/linux-x86_64-zero-fastdebug/images/jdk/bin/java -XX:+TieredCompilation > OpenJDK 64-Bit Zero VM warning: -XX:+TieredCompilation not supported in this VM > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/sharedRuntime_zero.cpp:80 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/zero/sharedRuntime_zero.cpp:80), pid=404967, tid=404968 > # Error: ShouldNotCall() > > Additional testing: > - [x] ad-hoc Hello World runs with Linux x86_64 Zero > - [x] re-run some failed `tier1` tests with Linux x86_64 Zero, now passing Looks good. Thank you for taking care of Zero. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/985 From ccheung at openjdk.java.net Tue Nov 3 00:07:01 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 3 Nov 2020 00:07:01 GMT Subject: RFR: 8255239: The timezone of the hs_err_pid log file is corrupted in Japanese locale Message-ID: Please review this simple fix by using the wide char version of strftime, i.e. wcsftime, to convert the timezone into a wide character string. After that, converting the wide character string back to multi-byte string before printing out the time and timezone. Testing: ran the test case in the bug report manually on: - Windows with ja, zh-tw, and en locales; - Linux and Mac OS with en locale. ------------- Commit messages: - 8255239 (initial commit) Changes: https://git.openjdk.java.net/jdk/pull/1023/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1023&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255239 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1023.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1023/head:pull/1023 PR: https://git.openjdk.java.net/jdk/pull/1023 From suenaga at oss.nttdata.com Tue Nov 3 02:13:54 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Tue, 3 Nov 2020 11:13:54 +0900 Subject: Unified Logging for network In-Reply-To: References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> <41f33608-63de-c7cb-e135-13a6fcc39b05@oracle.com> Message-ID: Hi, I agree this proposal might occur performance issue. However I think it is the responsibility of the user. If this proposal is implemented, I think it would be transferred to local log shipper process (fluentd, logstash on 127.0.0.1) in most case because HotSpot does not send log with JSON. And also log shipper may support message buffering and message queue persistence. We can avoid (in part of) performance/reliability issues with log shipper. Even if current implementation, performance issues is occurs when the disk is very slow (e.g. storage is broken). Cheers, Yasumasa On 2020/11/03 6:31, Thomas St?fe wrote: > Hi Ioi, > > I dimly remember proposals like this from the past. Main problem I see is > how large would you dimension the buffer, and what do you do if the buffer > cannot be drained rapidly enough. Discard log output? Hold? The former > sounds bad, the latter negates the advantages of such a buffer. > > Then, access to such a buffer would probably have to be synchronized, > whereas today AFAIK the log calls do not have to be. > > Cheers, Thomas > > On Mon 2. Nov 2020 at 22:18, Ioi Lam wrote: > >> For performance, maybe the implementation can log into a memory buffer, >> and use a worker thread to send the output over the network? That way we >> can minimize the overhead per log_xxx() call. >> >> I agree that using "-Xlog:foo=debug:network=xyz.com:1234" would be quite >> handy when you have lots of containers. You don't need to enable remote >> access to the container's file system just to get to the log file. >> >> Thanks >> - Ioi >> >> On 11/2/20 11:10 AM, Kirk Pepperdine wrote: >>> Hi Thomas, >>> >>> I appreciate Yasumasa?s desire to be able to redirect UL output to >> somewhere other than? I also appreciate that the highly granular nature of >> how UL messages are currently structure can be and indeed are an issue. >> That said, I?d also like the ability to push the data to some where other >> than a file on disk. >>> >>> To the point of granularity, UL might benefit from some message >> coarsening. This might also help in with other logging related performance >> issues that I?ve noted here and there. Quite frankly dealing with logs in >> containers isn?t a wonderful experience. And while I firmly believe that >> there is more that containers can do to ease this, being able to redirect >> output to something other than a log file does feel like it would be >> helpful. That said, I?m also concerned about the potential performance >> impacts but I think for this things that one would generally log, this >> should be minimal. >>> >>> Kind regards, >>> Kirk Pepperdine >>> >>> >>>> On Nov 2, 2020, at 4:26 AM, Thomas St?fe >> wrote: >>>> >>>> Hi Yasumasa, >>>> >>>> one problem I see is that this could introduce a surprising amount of >> lag >>>> into log() calls which do look inconspicuous, thereby distorting timing >>>> behavior or even create timeout effects. We already have that problem >> now >>>> to some degree when logging to network shares. >>>> >>>> Another thing, log output can be very fine granular, which would create >> a >>>> lot of network traffic. >>>> >>>> Such an addition may also open some security questions. >>>> >>>> From a more philosophical standpoint, I like the "do one thing and do >> it >>>> right" Unix way and this seems more like something an outside tool >> should >>>> be doing. Which could also aggregate log output better. But I admit that >>>> argument is weak. >>>> >>>> Cheers, Thomas >>>> >>>> >>>> >>>> On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga < >> suenaga at oss.nttdata.com> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> We need to out UL to stdout and/or file. If we can out it to TCP >> socket, I >>>>> think it is useful. >>>>> >>>>> For example, some system gather all logs to document oriented databases >>>>> (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. >> CloudWatch). If >>>>> HotSpot can out UL to TCP socket, we can send all logs to them via TCP >>>>> input plugin (Fluentd, Logstash). >>>>> >>>>> I think it is useful for container platform. What do you think? >>>>> If it is worth to work, I will add CSR and JBS ticket, and also will >>>>> create patch. >>>>> >> >> From dholmes at openjdk.java.net Tue Nov 3 02:35:07 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 Nov 2020 02:35:07 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 22:10:58 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 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 > > 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 This seems functionally fine, but it still seems to me that we are missing a Safepoint or SafepointMechanism API helper method that does: SafepointMechanism::process_if_requested(THREAD); if (THREAD->has_special_runtime_exit_condition()) { THREAD->handle_special_runtime_exit_condition(checkAsyncs); } Lets see if others have an opinion. Thanks. src/hotspot/share/runtime/safepoint.cpp line 936: > 934: SafepointMechanism::process_if_requested(self); > 935: if (self->has_special_runtime_exit_condition()) { > 936: self->handle_special_runtime_exit_condition(); Please add explicit arg: "(true /* check asyncs */)" src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 112: > 110: CALL_VM(SafepointMechanism::process_if_requested(THREAD); \ > 111: if (THREAD->has_special_runtime_exit_condition()) { \ > 112: THREAD->handle_special_runtime_exit_condition(); \ Please add explicit arg: "(true /* check asyncs */)" Using a multi-statement code block for the CALL_VM macro looks odd to me, but I find these zero macros unpleasant to begin with. ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From qpzhang at openjdk.java.net Tue Nov 3 03:44:54 2020 From: qpzhang at openjdk.java.net (Patrick Zhang) Date: Tue, 3 Nov 2020 03:44:54 GMT Subject: RFR: 8255716: AArch64: Regression: JVM crashes if manually offline a core In-Reply-To: <1oOiQohoWLHbEx0VgKlzWpNZwxzE7H0ZcodOVuiBX60=.0046e475-00d9-4763-b057-dfab48623796@github.com> References: <0rLudl3g60pNgAiWtp3iqX-u4la33OicQFxaKN031Js=.a44775c5-a8c1-430a-b92b-c11a84096c97@github.com> <1oOiQohoWLHbEx0VgKlzWpNZwxzE7H0ZcodOVuiBX60=.0046e475-00d9-4763-b057-dfab48623796@github.com> Message-ID: On Mon, 2 Nov 2020 15:10:26 GMT, Anton Kozlov wrote: > relax the assert (like `cpu_lines >= os::processor_count()`, btw, does this work for you Looks fine to me, but I cannot think out a negative case, or any practical scenario this assertion could help guarantee. So, I would leave this to you, in the follow-up patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/983 From qpzhang at openjdk.java.net Tue Nov 3 03:44:55 2020 From: qpzhang at openjdk.java.net (Patrick Zhang) Date: Tue, 3 Nov 2020 03:44:55 GMT Subject: RFR: 8255716: AArch64: Regression: JVM crashes if manually offline a core In-Reply-To: References: <0rLudl3g60pNgAiWtp3iqX-u4la33OicQFxaKN031Js=.a44775c5-a8c1-430a-b92b-c11a84096c97@github.com> <1oOiQohoWLHbEx0VgKlzWpNZwxzE7H0ZcodOVuiBX60=.0046e475-00d9-4763-b057-dfab48623796@github.com> Message-ID: <0Jp67eWeTmIQkgdweyuP-10ZYP-OgYR_tcp6NaD5mYc=.5231d7ee-84de-4fee-b859-7db57f743b25@github.com> On Mon, 2 Nov 2020 15:43:50 GMT, Andrew Dinn wrote: >>> @AntonKozlov If the code that sets the A53MAC property really needs to be based on the cpu count obtained from /proc/cpuinfo >> >> I would like to know that for sure. The code was introduced in http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6e2422a230fd#l6.48, unfortunately I don't know reasoning behind. >> >>> Could you raise a new JIRA for that and propose a fix? >> >> Ok, I'll do this, just to make sure we set the feature just as it was before. >> >> @cnqpzhang I will likely re-introduce cpu_line counting in the follow-up patch. It would be handy if you just relax the assert (like `cpu_lines >= os::processor_count()`, btw, does this work for you, is the guess is correct?) instead of removing it completely. But this is not very important. >> Also, I'm not a reviewer in the jdk project, not sure if I can be credited for review. > >> Also, I'm not a reviewer in the jdk project, not sure if I can be credited for review. > > Anyone can offer a review, not just big 'R' Reviewers. Small 'r' reviewers don't count towards official sign-off but they *do* count as far as getting it right is concerned. So, thanks for chipping in. @adinn Could you please do me a favor and help intergrade this PR? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/983 From david.holmes at oracle.com Tue Nov 3 06:01:33 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 Nov 2020 16:01:33 +1000 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: <40c072ae-af00-beec-aca4-3db7f6b792bc@oracle.com> Responded on jdk-dev. David On 2/11/2020 5:41 pm, Thomas St?fe wrote: > (redirected this question to jdk-dev: > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-November/004887.html) > > Cheers, Thomas > > On Sat, Oct 31, 2020 at 8:05 AM Thomas St?fe > wrote: > >> 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 >>>>> >>> >>> From dholmes at openjdk.java.net Tue Nov 3 06:21:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 Nov 2020 06:21:56 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked [v2] In-Reply-To: References: Message-ID: On Thu, 29 Oct 2020 08:55:57 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 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback David Hi Thomas, A couple of minor nits but otherwise seems good to go. We should share these error signals between signals_posix and vmError_posix at some stage. Thanks, David src/hotspot/os/posix/signals_posix.cpp line 464: > 462: // > 463: // Relevant Posix quote: > 464: // This line and `` are not needed src/hotspot/os/posix/signals_posix.cpp line 471: > 469: // > 470: // We also include SIGTRAP in that list of never-to-block-signals. While not > 471: // mentioned by the Posix documentation, in our (SAPs) experience blocking it Seems to be an extra space after // on this and next couple of line. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/839 From stuefe at openjdk.java.net Tue Nov 3 06:43:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 3 Nov 2020 06:43:56 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked [v2] In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 06:19:26 GMT, David Holmes wrote: > Hi Thomas, > > A couple of minor nits but otherwise seems good to go. > > We should share these error signals between signals_posix and vmError_posix at some stage. > I agree. > Thanks, > David Thanks a lot, David! I'll fix those last nits and then I'll push. ------------- PR: https://git.openjdk.java.net/jdk/pull/839 From stuefe at openjdk.java.net Tue Nov 3 06:48:12 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 3 Nov 2020 06:48:12 GMT Subject: RFR: JDK-8252533: Signal handlers should run with synchronous error signals unblocked [v3] 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: last nits (comments only) ironed out ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/839/files - new: https://git.openjdk.java.net/jdk/pull/839/files/8d86e25a..d9cbdb60 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=839&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=839&range=01-02 Stats: 13 lines in 1 file changed: 0 ins; 2 del; 11 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 Tue Nov 3 07:04:54 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 07:04:54 GMT Subject: RFR: 8255718: Zero: VM should know it runs in interpreter-only mode In-Reply-To: <9CDwd7hyKzTFmHx44cxYHi6bVDlSB0MO_9U8Ao6cVfc=.782bd12f-ecfb-47a2-8bec-1c7b01b88683@github.com> References: <9CDwd7hyKzTFmHx44cxYHi6bVDlSB0MO_9U8Ao6cVfc=.782bd12f-ecfb-47a2-8bec-1c7b01b88683@github.com> Message-ID: On Mon, 2 Nov 2020 23:03:09 GMT, Coleen Phillimore wrote: >> There are many tests in tier1 that fail with Zero, because they supply -XX:+TieredCompilation, and that makes VM code believe it runs in "mixed" mode. >> >> Can be reproduced trivially by running anything with -XX:+TieredCompilation. Then Zero fails when runtime asks it to produce a native wrapper for MH intrinsics. That code is normally protected by Arguments::is_interpreter_only. >> >> Method* SystemDictionary::find_method_handle_intrinsic(vmIntrinsics::ID iid, >> Symbol* signature, >> TRAPS) { >> ... >> if (!Arguments::is_interpreter_only()) { // <--- checks here >> // Generate a compiled form of the MH intrinsic. >> AdapterHandlerLibrary::create_native_wrapper(m); // <--- fails through here >> } >> >> Then in `sharedRuntime_zero.cpp`: >> >> nmethod *SharedRuntime::generate_native_wrapper(MacroAssembler *masm, >> const methodHandle& method, >> int compile_id, >> BasicType *sig_bt, >> VMRegPair *regs, >> BasicType ret_type, >> address critical_entry) { >> ShouldNotCallThis(); // <--- crashes here >> return NULL; >> } >> >> ...so: >> >> $ build/linux-x86_64-zero-fastdebug/images/jdk/bin/java -XX:+TieredCompilation >> OpenJDK 64-Bit Zero VM warning: -XX:+TieredCompilation not supported in this VM >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: SuppressErrorAt=/sharedRuntime_zero.cpp:80 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/zero/sharedRuntime_zero.cpp:80), pid=404967, tid=404968 >> # Error: ShouldNotCall() >> >> Additional testing: >> - [x] ad-hoc Hello World runs with Linux x86_64 Zero >> - [x] re-run some failed `tier1` tests with Linux x86_64 Zero, now passing > > Looks good. Thank you for taking care of Zero. Thank you for reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/985 From shade at openjdk.java.net Tue Nov 3 07:09:55 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 07:09:55 GMT Subject: Integrated: 8255718: Zero: VM should know it runs in interpreter-only mode In-Reply-To: References: Message-ID: On Sun, 1 Nov 2020 17:24:44 GMT, Aleksey Shipilev wrote: > There are many tests in tier1 that fail with Zero, because they supply -XX:+TieredCompilation, and that makes VM code believe it runs in "mixed" mode. > > Can be reproduced trivially by running anything with -XX:+TieredCompilation. Then Zero fails when runtime asks it to produce a native wrapper for MH intrinsics. That code is normally protected by Arguments::is_interpreter_only. > > Method* SystemDictionary::find_method_handle_intrinsic(vmIntrinsics::ID iid, > Symbol* signature, > TRAPS) { > ... > if (!Arguments::is_interpreter_only()) { // <--- checks here > // Generate a compiled form of the MH intrinsic. > AdapterHandlerLibrary::create_native_wrapper(m); // <--- fails through here > } > > Then in `sharedRuntime_zero.cpp`: > > nmethod *SharedRuntime::generate_native_wrapper(MacroAssembler *masm, > const methodHandle& method, > int compile_id, > BasicType *sig_bt, > VMRegPair *regs, > BasicType ret_type, > address critical_entry) { > ShouldNotCallThis(); // <--- crashes here > return NULL; > } > > ...so: > > $ build/linux-x86_64-zero-fastdebug/images/jdk/bin/java -XX:+TieredCompilation > OpenJDK 64-Bit Zero VM warning: -XX:+TieredCompilation not supported in this VM > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/sharedRuntime_zero.cpp:80 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/shade/trunks/jdk/src/hotspot/cpu/zero/sharedRuntime_zero.cpp:80), pid=404967, tid=404968 > # Error: ShouldNotCall() > > Additional testing: > - [x] ad-hoc Hello World runs with Linux x86_64 Zero > - [x] re-run some failed `tier1` tests with Linux x86_64 Zero, now passing This pull request has now been integrated. Changeset: f0eeca90 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/f0eeca90 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8255718: Zero: VM should know it runs in interpreter-only mode Reviewed-by: andrew, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/985 From shade at openjdk.java.net Tue Nov 3 07:11:55 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 07:11:55 GMT Subject: Integrated: 8255743: Relax SIGFPE match in in runtime/ErrorHandling/SecondaryErrorTest.java In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 10:35:41 GMT, Aleksey Shipilev wrote: > After JDK-8255741, Zero prints the message below for the affected test: > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:257), pid=903938, tid=903939 > # fatal error: caught unhandled signal: SIGFPE > > Unfortunately, that still does not match the regexp in the test. Seems simple to relax the regexp a bit. @tstuefe, what do you think? > > Additional testing: > - [x] Affected test on Linux x86_64 Zero (together with JDK-8255741 fix) > - [x] Affected test on Linux x86_64 server This pull request has now been integrated. Changeset: 6d36b4bb Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/6d36b4bb Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8255743: Relax SIGFPE match in in runtime/ErrorHandling/SecondaryErrorTest.java Reviewed-by: stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1002 From stuefe at openjdk.java.net Tue Nov 3 07:23:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 3 Nov 2020 07:23:00 GMT Subject: Integrated: 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 This pull request has now been integrated. Changeset: e7a2d5c8 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/e7a2d5c8 Stats: 109 lines in 3 files changed: 42 ins; 48 del; 19 mod 8252533: Signal handlers should run with synchronous error signals unblocked Reviewed-by: gziemski, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/839 From shade at openjdk.java.net Tue Nov 3 07:32:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 07:32:57 GMT Subject: Integrated: 8255741: Zero: print signal name in unhandled signal handler In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 10:15:24 GMT, Aleksey Shipilev wrote: > At least one test -- `runtime/Safepoint/TestAbortVMOnSafepointTimeout.java` -- fails on Zero with: > > # Internal Error (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:250), pid=560280, tid=560281 > # fatal error: caught unhandled signal 4 > > The test expects "SIGKILL (sent by kill)" in the test output. > > Additional testing: > - [x] `TestAbortVMOnSafepointTimeout.java` now passes on Linux x86_64 Zero. This pull request has now been integrated. Changeset: aa2862ad Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/aa2862ad Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod 8255741: Zero: print signal name in unhandled signal handler Reviewed-by: stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1001 From shade at openjdk.java.net Tue Nov 3 07:36:55 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 07:36:55 GMT Subject: RFR: 8255617: Zero: purge the remaining bytecode interpreter profiling support In-Reply-To: References: Message-ID: On Fri, 30 Oct 2020 17:12:59 GMT, Severin Gehwolf 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). @DamonFool, @GoeLin, do you have an opinion here? ------------- PR: https://git.openjdk.java.net/jdk/pull/944 From jiefu at openjdk.java.net Tue Nov 3 07:52:55 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 3 Nov 2020 07:52:55 GMT Subject: RFR: 8255617: Zero: purge the remaining bytecode interpreter profiling support In-Reply-To: References: Message-ID: <7PqRfnmIHgpu2Q4sAsk_iUhcdn87QjBtoBA1X-ib0n0=.ca7bb5b6-f992-41e0-8fba-dabb49b4475d@github.com> On Tue, 3 Nov 2020 07:33:44 GMT, Aleksey Shipilev wrote: > @DamonFool, @GoeLin, do you have an opinion here? Hi @shipilev ? Sorry, I missed this PR before. I'll have a look and do some experiments and will let you know soon. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/944 From thomas.stuefe at gmail.com Tue Nov 3 08:09:47 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 3 Nov 2020 09:09:47 +0100 Subject: Unified Logging for network In-Reply-To: References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> <41f33608-63de-c7cb-e135-13a6fcc39b05@oracle.com> Message-ID: Hi Yasumasa, I don't argue that such a feature would not be useful. Of course it would! But as with any other added feature, it will come at the cost of complexity. It will have to be maintained, tests will have to be written and run. That increases technical debt for us all. That is not a reason not to do it, but to think before doing it and exploring alternatives. -- To me, the fact that a logging call now could possibly do Network IO fills me with deep unease. It violates the principle of least surprise. Logging should be as basic as possible, in order to be usable anywhere in code. - as had been said before, it would introduce unpredictable timing behavior. The fact that we have this already today is not a big consolation :( - similar to "the User should know what he does" argument - unfortunately many don't, so a balance has to be found to limit support from these cases - AFAICS we do not do network IO anywhere in the hotspot today. That coding would have to be written and tested. Reusing some other code - e.g. from the corelibs - is out of question for such a low level API, since you don't want to risk circularities. - But now we have a complete network stack below the innocuous logging call. This imposes further restrictions on where we can log - eg even if it were possible before, logging from signal handling is impossible now. Without these restrictions documented and tested anywhere. To me this makes UL more and more questionable, and I already tend to shun it when possible in favour of plain tty printing. I argued yesterday against Ioi's concurrent-log-draining, but that is actually more attractive the more I think about it. Only, could the same not be achieved with piping stdout/err to a separate tool like netcat, as Leo suggested? That solution exists today. If netcat does not do it for you, this could also be a separate utility - could be even part of the jdk. Conceptually this would be much the same as a separate thread printing out UL, with the pipe size being the buffer size. Or, communication could happen via shared memory... This would have two distinct advantages over doing network IO in UL: - we see the whole stderr output (e.g. output from the libc, or any third party tools) - we see output also from a VM which crashed and burned. E.g. any last words from hs-err reporting. Cheers, Thomas On Tue, Nov 3, 2020 at 3:12 AM Yasumasa Suenaga wrote: > Hi, > > I agree this proposal might occur performance issue. However I think it is > the responsibility of the user. > If this proposal is implemented, I think it would be transferred to local > log shipper process (fluentd, logstash on 127.0.0.1) in most case because > HotSpot does not send log with JSON. And also log shipper may support > message buffering and message queue persistence. > We can avoid (in part of) performance/reliability issues with log shipper. > > Even if current implementation, performance issues is occurs when the disk > is very slow (e.g. storage is broken). > > > Cheers, > > Yasumasa > > > On 2020/11/03 6:31, Thomas St?fe wrote: > > Hi Ioi, > > > > I dimly remember proposals like this from the past. Main problem I see is > > how large would you dimension the buffer, and what do you do if the > buffer > > cannot be drained rapidly enough. Discard log output? Hold? The former > > sounds bad, the latter negates the advantages of such a buffer. > > > > Then, access to such a buffer would probably have to be synchronized, > > whereas today AFAIK the log calls do not have to be. > > > > Cheers, Thomas > > > > On Mon 2. Nov 2020 at 22:18, Ioi Lam wrote: > > > >> For performance, maybe the implementation can log into a memory buffer, > >> and use a worker thread to send the output over the network? That way we > >> can minimize the overhead per log_xxx() call. > >> > >> I agree that using "-Xlog:foo=debug:network=xyz.com:1234" would be > quite > >> handy when you have lots of containers. You don't need to enable remote > >> access to the container's file system just to get to the log file. > >> > >> Thanks > >> - Ioi > >> > >> On 11/2/20 11:10 AM, Kirk Pepperdine wrote: > >>> Hi Thomas, > >>> > >>> I appreciate Yasumasa?s desire to be able to redirect UL output to > >> somewhere other than? I also appreciate that the highly granular nature > of > >> how UL messages are currently structure can be and indeed are an issue. > >> That said, I?d also like the ability to push the data to some where > other > >> than a file on disk. > >>> > >>> To the point of granularity, UL might benefit from some message > >> coarsening. This might also help in with other logging related > performance > >> issues that I?ve noted here and there. Quite frankly dealing with logs > in > >> containers isn?t a wonderful experience. And while I firmly believe that > >> there is more that containers can do to ease this, being able to > redirect > >> output to something other than a log file does feel like it would be > >> helpful. That said, I?m also concerned about the potential performance > >> impacts but I think for this things that one would generally log, this > >> should be minimal. > >>> > >>> Kind regards, > >>> Kirk Pepperdine > >>> > >>> > >>>> On Nov 2, 2020, at 4:26 AM, Thomas St?fe > >> wrote: > >>>> > >>>> Hi Yasumasa, > >>>> > >>>> one problem I see is that this could introduce a surprising amount of > >> lag > >>>> into log() calls which do look inconspicuous, thereby distorting > timing > >>>> behavior or even create timeout effects. We already have that problem > >> now > >>>> to some degree when logging to network shares. > >>>> > >>>> Another thing, log output can be very fine granular, which would > create > >> a > >>>> lot of network traffic. > >>>> > >>>> Such an addition may also open some security questions. > >>>> > >>>> From a more philosophical standpoint, I like the "do one thing and > do > >> it > >>>> right" Unix way and this seems more like something an outside tool > >> should > >>>> be doing. Which could also aggregate log output better. But I admit > that > >>>> argument is weak. > >>>> > >>>> Cheers, Thomas > >>>> > >>>> > >>>> > >>>> On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga < > >> suenaga at oss.nttdata.com> > >>>> wrote: > >>>> > >>>>> Hi all, > >>>>> > >>>>> We need to out UL to stdout and/or file. If we can out it to TCP > >> socket, I > >>>>> think it is useful. > >>>>> > >>>>> For example, some system gather all logs to document oriented > databases > >>>>> (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. > >> CloudWatch). If > >>>>> HotSpot can out UL to TCP socket, we can send all logs to them via > TCP > >>>>> input plugin (Fluentd, Logstash). > >>>>> > >>>>> I think it is useful for container platform. What do you think? > >>>>> If it is worth to work, I will add CSR and JBS ticket, and also will > >>>>> create patch. > >>>>> > >> > >> > From thomas.stuefe at gmail.com Tue Nov 3 08:12:29 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 3 Nov 2020 09:12:29 +0100 Subject: Unified Logging for network In-Reply-To: <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> Message-ID: Hi Kirk, On Mon, Nov 2, 2020 at 8:10 PM Kirk Pepperdine wrote: > Hi Thomas, > > I appreciate Yasumasa?s desire to be able to redirect UL output to > somewhere other than? I also appreciate that the highly granular nature of > how UL messages are currently structure can be and indeed are an issue. > That said, I?d also like the ability to push the data to some where other > than a file on disk. > > To the point of granularity, UL might benefit from some message > coarsening. This might also help in with other logging related performance > issues that I?ve noted here and there. Quite frankly dealing with logs in > containers isn?t a wonderful experience. And while I firmly believe that > there is more that containers can do to ease this, being able to redirect > output to something other than a log file does feel like it would be > helpful. That said, I?m also concerned about the potential performance > impacts but I think for this things that one would generally log, this > should be minimal. > About this proposal, see my answer to Yasumasa. About UL granularity: feel free to raise concrete examples in JBS or on the mailing lists! This is often not that difficult to fix. Kind Regards, Thomas > > Kind regards, > Kirk Pepperdine > > > > On Nov 2, 2020, at 4:26 AM, Thomas St?fe > wrote: > > > > Hi Yasumasa, > > > > one problem I see is that this could introduce a surprising amount of lag > > into log() calls which do look inconspicuous, thereby distorting timing > > behavior or even create timeout effects. We already have that problem now > > to some degree when logging to network shares. > > > > Another thing, log output can be very fine granular, which would create a > > lot of network traffic. > > > > Such an addition may also open some security questions. > > > > From a more philosophical standpoint, I like the "do one thing and do it > > right" Unix way and this seems more like something an outside tool should > > be doing. Which could also aggregate log output better. But I admit that > > argument is weak. > > > > Cheers, Thomas > > > > > > > > On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga < > suenaga at oss.nttdata.com> > > wrote: > > > >> Hi all, > >> > >> We need to out UL to stdout and/or file. If we can out it to TCP > socket, I > >> think it is useful. > >> > >> For example, some system gather all logs to document oriented databases > >> (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. > CloudWatch). If > >> HotSpot can out UL to TCP socket, we can send all logs to them via TCP > >> input plugin (Fluentd, Logstash). > >> > >> I think it is useful for container platform. What do you think? > >> If it is worth to work, I will add CSR and JBS ticket, and also will > >> create patch. > >> > > From shade at openjdk.java.net Tue Nov 3 08:14:02 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 08:14:02 GMT Subject: RFR: 8255796: Zero: CASE(_new) should replenish TLABs properly Message-ID: If you look at how current `CASE(_new)` is structured, then you will notice an odd thing: if (ik->is_initialized() && ik->can_be_fastpath_allocated() ) { size_t obj_size = ik->size_helper(); oop result = NULL; if (UseTLAB) { result = (oop) THREAD->tlab().allocate(obj_size); } if (result == NULL) { // allocate from inline contiguous alloc } if (result != NULL) { // initialize the object and return } } // Slow case allocation CALL_VM(InterpreterRuntime::_new(THREAD, METHOD->constants(), index), handle_exception); // return The oddity here is: when TLAB is depleted and rejects the allocation, we fall through to inline contiguous alloc block that allocates the object in shared eden. That allocation is likely to succeed, and then we return from this path. But TLAB would never get replenished! Because to do that, we need to hit the slowpath allocation in `Interpreter::_new`, let in enter the runtime, and ask GC for a new TLAB! So in the end, when +UseTLAB is enabled for Zero, the code only uses the very first issued TLAB, and then always falls through to inline contiguous allocation, until eden is completely depleted. Inline contiguous block makes the shared CAS increment that could be heavily contended under allocations. I have observed this with supplying +UseTLAB to my adhoc Zero runs -- it was still slow. I think we can just remove the inline contiguous allocation block, and let the whole thing slide to slowpath on failure. This would also resolve the issue of enabling Zero for GCs that do not support inline contiguous allocs (anything beyond Serial and Parallel). I think giving up that block and make use +UseTLAB is enabled (JDK-8255782) would give us sensible improvements: | | Original | Original +UseTLAB | Patched +UseTLAB | | --- | ----- | ----- | ----- | | Simple alloc, ns/op | 302 +- 5 | 291 +- 5 | 233 +- 3 | | Linux x86_64 Zero release `make images` | 9m35s | ----- | 9m10s | ------------- Commit messages: - 8255796: Zero: CASE(_new) should replenish TLABs properly Changes: https://git.openjdk.java.net/jdk/pull/1029/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1029&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255796 Stats: 21 lines in 1 file changed: 1 ins; 18 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1029.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1029/head:pull/1029 PR: https://git.openjdk.java.net/jdk/pull/1029 From jiefu at openjdk.java.net Tue Nov 3 08:51:56 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 3 Nov 2020 08:51:56 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 jiefu (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/944 From jiefu at openjdk.java.net Tue Nov 3 08:51:57 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 3 Nov 2020 08:51:57 GMT Subject: RFR: 8255617: Zero: purge the remaining bytecode interpreter profiling support In-Reply-To: <7PqRfnmIHgpu2Q4sAsk_iUhcdn87QjBtoBA1X-ib0n0=.ca7bb5b6-f992-41e0-8fba-dabb49b4475d@github.com> References: <7PqRfnmIHgpu2Q4sAsk_iUhcdn87QjBtoBA1X-ib0n0=.ca7bb5b6-f992-41e0-8fba-dabb49b4475d@github.com> Message-ID: <5Wrv6fiw607c4wnPABYmEDncyducvAYUsBGJ_aC2_LY=.c53624a8-491e-4339-baf2-0a30997e4edf@github.com> On Tue, 3 Nov 2020 07:50:11 GMT, Jie Fu wrote: >> @DamonFool, @GoeLin, do you have an opinion here? > >> @DamonFool, @GoeLin, do you have an opinion here? > > Hi @shipilev ? > > Sorry, I missed this PR before. > I'll have a look and do some experiments and will let you know soon. > > Thanks. > > 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 stepped back to be the "pure" interpreter without any support for compilers, and thus becoming the most portable thing, for example for architectures that have no arch-specific code implemented whatsoever. When one needs an interpreter that hooks into C1/C2, they have to go to template interpreter and start implementing arch-specific stuff. So, porting is basically: a) get Zero working; b) get template interpreter working; c) get C1 working; d) get C2 working. On each of these steps you have something that works, with every step much harder to get it right, but better for performance. > > So in this sense, having compiler hooks (like this interpreter profile support) penalizes Zero execution for nothing. If we continue it further, I'd say we can also purge deopt support from Zero too. > > Need more thoughts about this, so: > > /reviewers 3 +1 All tests for Zero VM passed in our CI/CD. And the build time for zero-release vm reduced 20s ~ 30s on our platforms. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/944 From qpzhang at openjdk.java.net Tue Nov 3 09:30:58 2020 From: qpzhang at openjdk.java.net (Patrick Zhang) Date: Tue, 3 Nov 2020 09:30:58 GMT Subject: Integrated: 8255716: AArch64: Regression: JVM crashes if manually offline a core In-Reply-To: References: Message-ID: On Sun, 1 Nov 2020 12:26:15 GMT, Patrick Zhang wrote: > Please review this change that removed the unnecessary check **cpu_lines == os::processor_count()** from VM_Version::get_os_cpu_info inside src/hotspot/os_cpu/linux_aarch64/vm_version_linux_aarch64.cpp. > > This **assertion** is practically not needed. While a test system with some cores intentionally turned off, e.g. via echo 0 > /sys/devices/system/cpu/cpu1/online, **java -version** would crash, building openjdk on this system would fail too. > > This regression issue was introduced by https://github.com/openjdk/jdk/commit/ec9bee68 > > Testing: > - java -version, building openjdk as smoke tests > - jtreg tier1 as sanity check This pull request has now been integrated. Changeset: 36998b00 Author: Patrick Zhang URL: https://git.openjdk.java.net/jdk/commit/36998b00 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8255716: AArch64: Regression: JVM crashes if manually offline a core Reviewed-by: aph, adinn, akozlov ------------- PR: https://git.openjdk.java.net/jdk/pull/983 From sgehwolf at openjdk.java.net Tue Nov 3 10:24:04 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 3 Nov 2020 10:24:04 GMT Subject: RFR: 8255744: Zero: handle JVM_CONSTANT_DynamicInError In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 11:44:35 GMT, Aleksey Shipilev wrote: > JDK-8186211 introduced a few negative tests for Condy, and Zero seem to fail them: > > $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=java/lang/invoke/condy/CondyRepeatFailedResolution.java > # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp:2289), pid=574573, tid=581749 > # Error: ShouldNotReachHere() > > After some debugging, I think Zero misses to handle `JVM_CONSTANT_DynamicInError`. I believe we can just do the same thing as `JVM_CONSTANT_Dynamic`, and then let `CALL_VM` to go to `handle_exception` on another resolution failure. > > Additional testing: > - [x] `CondyRepeatFailedResolution` test now passes on Linux x86_64 Zero Looks OK. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1004 From shade at openjdk.java.net Tue Nov 3 10:43:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 10:43:58 GMT Subject: RFR: 8255744: Zero: handle JVM_CONSTANT_DynamicInError In-Reply-To: References: Message-ID: <_Z-AAo1DIMLTwNmXyfctFRg56MD7hslGzdUp64rYLcc=.36a0c7df-1675-4789-b51a-00d4ccb46ebb@github.com> On Tue, 3 Nov 2020 10:21:26 GMT, Severin Gehwolf wrote: >> JDK-8186211 introduced a few negative tests for Condy, and Zero seem to fail them: >> >> $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=java/lang/invoke/condy/CondyRepeatFailedResolution.java >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp:2289), pid=574573, tid=581749 >> # Error: ShouldNotReachHere() >> >> After some debugging, I think Zero misses to handle `JVM_CONSTANT_DynamicInError`. I believe we can just do the same thing as `JVM_CONSTANT_Dynamic`, and then let `CALL_VM` to go to `handle_exception` on another resolution failure. >> >> Additional testing: >> - [x] `CondyRepeatFailedResolution` test now passes on Linux x86_64 Zero > > Looks OK. Thanks @jerboaa! ------------- PR: https://git.openjdk.java.net/jdk/pull/1004 From shade at openjdk.java.net Tue Nov 3 10:44:01 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 10:44:01 GMT Subject: Integrated: 8255744: Zero: handle JVM_CONSTANT_DynamicInError In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 11:44:35 GMT, Aleksey Shipilev wrote: > JDK-8186211 introduced a few negative tests for Condy, and Zero seem to fail them: > > $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=java/lang/invoke/condy/CondyRepeatFailedResolution.java > # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp:2289), pid=574573, tid=581749 > # Error: ShouldNotReachHere() > > After some debugging, I think Zero misses to handle `JVM_CONSTANT_DynamicInError`. I believe we can just do the same thing as `JVM_CONSTANT_Dynamic`, and then let `CALL_VM` to go to `handle_exception` on another resolution failure. > > Additional testing: > - [x] `CondyRepeatFailedResolution` test now passes on Linux x86_64 Zero This pull request has now been integrated. Changeset: 9bd836e0 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/9bd836e0 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8255744: Zero: handle JVM_CONSTANT_DynamicInError Reviewed-by: sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/1004 From sgehwolf at openjdk.java.net Tue Nov 3 10:49:54 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 3 Nov 2020 10:49:54 GMT Subject: RFR: 8255719: Zero: on return path, check for pending exception before attempting to clear it In-Reply-To: References: Message-ID: On Sun, 1 Nov 2020 17:33:04 GMT, Aleksey Shipilev wrote: > Profiling shows we spend a lot of time trying to clear the pending exception at _return path, whereas it seldom is pending. > > The additional problem with calling into `clear_pending_exception` is that inlining budget is depleted completely at that point in the compilation unit, and so we do the full outbound call. > > There are other places where we clear pending exception unconditionally, but those places do seem to expect the exceptions to be there. Seems reasonable. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/986 From shade at openjdk.java.net Tue Nov 3 11:07:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 11:07:59 GMT Subject: RFR: 8255719: Zero: on return path, check for pending exception before attempting to clear it In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 10:47:24 GMT, Severin Gehwolf wrote: >> Profiling shows we spend a lot of time trying to clear the pending exception at _return path, whereas it seldom is pending. >> >> The additional problem with calling into `clear_pending_exception` is that inlining budget is depleted completely at that point in the compilation unit, and so we do the full outbound call. >> >> There are other places where we clear pending exception unconditionally, but those places do seem to expect the exceptions to be there. > > Seems reasonable. Thanks @jerboaa! ------------- PR: https://git.openjdk.java.net/jdk/pull/986 From shade at openjdk.java.net Tue Nov 3 11:08:00 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 11:08:00 GMT Subject: Integrated: 8255719: Zero: on return path, check for pending exception before attempting to clear it In-Reply-To: References: Message-ID: On Sun, 1 Nov 2020 17:33:04 GMT, Aleksey Shipilev wrote: > Profiling shows we spend a lot of time trying to clear the pending exception at _return path, whereas it seldom is pending. > > The additional problem with calling into `clear_pending_exception` is that inlining budget is depleted completely at that point in the compilation unit, and so we do the full outbound call. > > There are other places where we clear pending exception unconditionally, but those places do seem to expect the exceptions to be there. This pull request has now been integrated. Changeset: 904561eb Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/904561eb Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8255719: Zero: on return path, check for pending exception before attempting to clear it Reviewed-by: sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/986 From sgehwolf at openjdk.java.net Tue Nov 3 11:09:56 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 3 Nov 2020 11:09:56 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. The affected method is private, and so what that `assert` really does is checks that no internal Zero code calls it with a wrong `thread` -- something that should be caught by `fastdebug` builds. > > 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. LGTM ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/943 From shade at openjdk.java.net Tue Nov 3 11:09:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 11:09:58 GMT Subject: RFR: 8255615: Zero: demote ZeroStack::abi_stack_available guarantee to assert In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 11:01:27 GMT, Severin Gehwolf wrote: >> It is currently `guarantee`, which slows down release bits unnecessarily. The affected method is private, and so what that `assert` really does is checks that no internal Zero code calls it with a wrong `thread` -- something that should be caught by `fastdebug` builds. >> >> 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. > > LGTM Thanks @jerboaa! Thanks @AlphaHot (even though you are not the official reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/943 From shade at openjdk.java.net Tue Nov 3 11:09:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 11:09:59 GMT Subject: Integrated: 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. The affected method is private, and so what that `assert` really does is checks that no internal Zero code calls it with a wrong `thread` -- something that should be caught by `fastdebug` builds. > > 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. This pull request has now been integrated. Changeset: 9a0cf587 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/9a0cf587 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8255615: Zero: demote ZeroStack::abi_stack_available guarantee to assert Reviewed-by: sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/943 From sgehwolf at openjdk.java.net Tue Nov 3 11:22:55 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 3 Nov 2020 11:22:55 GMT Subject: RFR: 8255737: Zero: DO_UPDATE_INSTRUCTION_COUNT should only update when relevant VM flags are set In-Reply-To: <0rTV2XCqJXx-PVUlcJdxjg30iG2fueUwnxMHe6dFM1M=.2e8fcc35-8dbb-482e-b1ab-d5c377d79c14@github.com> References: <0rTV2XCqJXx-PVUlcJdxjg30iG2fueUwnxMHe6dFM1M=.2e8fcc35-8dbb-482e-b1ab-d5c377d79c14@github.com> Message-ID: <67LKUJ6Gi6JfVbgTLlN9Sa0GO5kG9k1nA0LvirvZJQs=.6a527790-ed6a-4fbc-aa82-60c9278adb72@github.com> On Mon, 2 Nov 2020 08:58:56 GMT, Aleksey Shipilev wrote: > Everywhere else in VM code we effectively do: > > if (CountBytecodes || TraceBytecodes || StopInterpreterAt) BytecodeCounter::... > if (PrintBytecodeHistogram) BytecodeHistogram::... > > But not in `DO_UPDATE_INSTRUCTION_COUNT` macro. > Adding these flags avoid the writes to statistics what would never be used (and those writes can even contend, afaics). > This change drops the Linux x86_64 Zero fastdebug build time from ~18m to ~17.5m. > > Testing: > - [x] Ad-hoc runs with Zero and affected flags One nit. Good to go otherwise. src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 138: > 136: #define DO_UPDATE_INSTRUCTION_COUNT(opcode) \ > 137: { \ > 138: if (CountBytecodes || TraceBytecodes || StopInterpreterAt) BytecodeCounter::_counter_value++; \ Elsewhere we do `[...] || StopInterpreterAt > 0` which is clearer as it's a flag expecting an int value. Perhaps you could use that instead of the implicit boolean conversion? Yes, this doesn't seem consistent throughout the code, but while at it... ------------- PR: https://git.openjdk.java.net/jdk/pull/997 From shade at openjdk.java.net Tue Nov 3 11:30:00 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 11:30:00 GMT Subject: RFR: 8255810: Zero: build fails without JVMTI Message-ID: Zero interpreter has two modes: with JVMTI built-in, and without. But we cannot test it properly, because the build fails without JVMTI in shared code. Mostly due to JDK-8147388. Additional testing: - [x] Linux x86_64 Zero fastdebug builds `--with-jvm-features=-jvmti` ------------- Commit messages: - Invert the order of end comments - 8255810: Zero: build fails without JVMTI Changes: https://git.openjdk.java.net/jdk/pull/1036/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1036&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255810 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1036.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1036/head:pull/1036 PR: https://git.openjdk.java.net/jdk/pull/1036 From martin.doerr at sap.com Tue Nov 3 11:46:23 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 3 Nov 2020 11:46:23 +0000 Subject: New assertion in CompressedOops::decode restricts usability Message-ID: Hi, I'd like to raise awareness of the following issue. [1] introduced "assert(Universe::heap()->is_in..." check in CompressedOops::decode functions. This strong assertion may help to find bugs earlier. However, this assertion is so strong that it restricts the usability of the decode functions because it introduces heap management dependencies in the more generic CompressedOops functionality. There are periods of time (during GC) at which we can't use " Universe::heap()->is_in" because the pointer gets switched between old and new location, but "Universe::heap()->is_in" is not yet accurate. Seems like there's currently one affected place in PPC64 code [2]. We can easily fix that by using decode_raw in PPC64 code. So if we expect that nobody else will ever call CompressedOops::decode function during such a phase, I can live with just adding the workaround to PPC64 code as recently discussed in [2]. But I can imagine other people running into such a problem, too, sooner or later. Opinions? Best regards, Martin [1] "8237363: Remove automatic is in heap verification in OopIterateClosure" https://bugs.openjdk.java.net/browse/JDK-8237363 [2] "8255598: assert(Universe::heap()->is_in(result)) failed: object not in heap" https://bugs.openjdk.java.net/browse/JDK-8255598 From shade at openjdk.java.net Tue Nov 3 12:20:15 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 12:20:15 GMT Subject: RFR: 8255737: Zero: DO_UPDATE_INSTRUCTION_COUNT should only update when relevant VM flags are set [v2] In-Reply-To: <0rTV2XCqJXx-PVUlcJdxjg30iG2fueUwnxMHe6dFM1M=.2e8fcc35-8dbb-482e-b1ab-d5c377d79c14@github.com> References: <0rTV2XCqJXx-PVUlcJdxjg30iG2fueUwnxMHe6dFM1M=.2e8fcc35-8dbb-482e-b1ab-d5c377d79c14@github.com> Message-ID: <2SVUpoNyz1wu-GgLpF_wlxWoAFGeYIncu5pIYOSc95Y=.c4efbc2c-7486-4ad3-adb3-672d448b1cd0@github.com> > Everywhere else in VM code we effectively do: > > if (CountBytecodes || TraceBytecodes || StopInterpreterAt) BytecodeCounter::... > if (PrintBytecodeHistogram) BytecodeHistogram::... > > But not in `DO_UPDATE_INSTRUCTION_COUNT` macro. > Adding these flags avoid the writes to statistics what would never be used (and those writes can even contend, afaics). > This change drops the Linux x86_64 Zero fastdebug build time from ~18m to ~17.5m. > > Testing: > - [x] Ad-hoc runs with Zero and affected flags 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: - Rewrite the block to hide flags under major check - Merge branch 'master' into JDK-8255737-zero-do-update-flags - 8255737: Zero: DO_UPDATE_INSTRUCTION_COUNT should only update when relevant VM flags are set ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/997/files - new: https://git.openjdk.java.net/jdk/pull/997/files/e2aaf25a..d75d182f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=997&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=997&range=00-01 Stats: 6104 lines in 271 files changed: 3549 ins; 1109 del; 1446 mod Patch: https://git.openjdk.java.net/jdk/pull/997.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/997/head:pull/997 PR: https://git.openjdk.java.net/jdk/pull/997 From shade at openjdk.java.net Tue Nov 3 12:20:18 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 12:20:18 GMT Subject: RFR: 8255737: Zero: DO_UPDATE_INSTRUCTION_COUNT should only update when relevant VM flags are set [v2] In-Reply-To: <67LKUJ6Gi6JfVbgTLlN9Sa0GO5kG9k1nA0LvirvZJQs=.6a527790-ed6a-4fbc-aa82-60c9278adb72@github.com> References: <0rTV2XCqJXx-PVUlcJdxjg30iG2fueUwnxMHe6dFM1M=.2e8fcc35-8dbb-482e-b1ab-d5c377d79c14@github.com> <67LKUJ6Gi6JfVbgTLlN9Sa0GO5kG9k1nA0LvirvZJQs=.6a527790-ed6a-4fbc-aa82-60c9278adb72@github.com> Message-ID: On Tue, 3 Nov 2020 11:19:16 GMT, Severin Gehwolf 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: >> >> - Rewrite the block to hide flags under major check >> - Merge branch 'master' into JDK-8255737-zero-do-update-flags >> - 8255737: Zero: DO_UPDATE_INSTRUCTION_COUNT should only update when relevant VM flags are set > > src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 138: > >> 136: #define DO_UPDATE_INSTRUCTION_COUNT(opcode) \ >> 137: { \ >> 138: if (CountBytecodes || TraceBytecodes || StopInterpreterAt) BytecodeCounter::_counter_value++; \ > > Elsewhere we do `[...] || StopInterpreterAt > 0` which is clearer as it's a flag expecting an int value. Perhaps you could use that instead of the implicit boolean conversion? > > Yes, this doesn't seem consistent throughout the code, but while at it... Right on. I went on fixing the uses of `StopInterpreterAt` in this macro. I thought we can just check it against `_counter_value` without implicitly checking for `0` in the line below. But then Zero fastdebug build times exploded on me! So I thought to rewrite the block to hide most of the branches under the big one. See the update. This also clusters the uses of `BytecodeCounter::_counter_value`. ------------- PR: https://git.openjdk.java.net/jdk/pull/997 From coleenp at openjdk.java.net Tue Nov 3 13:06:53 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 3 Nov 2020 13:06:53 GMT Subject: RFR: 8255810: Zero: build fails without JVMTI In-Reply-To: References: Message-ID: <8RuFCVYY-9hEzt8yw9K_PUuMLx74KRXeihjGMPZnKtA=.8da9b0de-e209-4f10-807e-5388680dd3c1@github.com> On Tue, 3 Nov 2020 11:22:50 GMT, Aleksey Shipilev wrote: > Zero interpreter has two modes: with JVMTI built-in, and without. But we cannot test it properly, because the build fails without JVMTI in shared code. Mostly due to JDK-8147388. > > Additional testing: > - [x] Linux x86_64 Zero fastdebug builds `--with-jvm-features=-jvmti` Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1036 From sgehwolf at openjdk.java.net Tue Nov 3 13:34:03 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 3 Nov 2020 13:34:03 GMT Subject: RFR: 8255737: Zero: DO_UPDATE_INSTRUCTION_COUNT should only update when relevant VM flags are set [v2] In-Reply-To: <2SVUpoNyz1wu-GgLpF_wlxWoAFGeYIncu5pIYOSc95Y=.c4efbc2c-7486-4ad3-adb3-672d448b1cd0@github.com> References: <0rTV2XCqJXx-PVUlcJdxjg30iG2fueUwnxMHe6dFM1M=.2e8fcc35-8dbb-482e-b1ab-d5c377d79c14@github.com> <2SVUpoNyz1wu-GgLpF_wlxWoAFGeYIncu5pIYOSc95Y=.c4efbc2c-7486-4ad3-adb3-672d448b1cd0@github.com> Message-ID: On Tue, 3 Nov 2020 12:20:15 GMT, Aleksey Shipilev wrote: >> Everywhere else in VM code we effectively do: >> >> if (CountBytecodes || TraceBytecodes || StopInterpreterAt) BytecodeCounter::... >> if (PrintBytecodeHistogram) BytecodeHistogram::... >> >> But not in `DO_UPDATE_INSTRUCTION_COUNT` macro. >> Adding these flags avoid the writes to statistics what would never be used (and those writes can even contend, afaics). >> This change drops the Linux x86_64 Zero fastdebug build time from ~18m to ~17.5m. >> >> Testing: >> - [x] Ad-hoc runs with Zero and affected flags > > 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: > > - Rewrite the block to hide flags under major check > - Merge branch 'master' into JDK-8255737-zero-do-update-flags > - 8255737: Zero: DO_UPDATE_INSTRUCTION_COUNT should only update when relevant VM flags are set LGTM ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/997 From sgehwolf at openjdk.java.net Tue Nov 3 13:34:04 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 3 Nov 2020 13:34:04 GMT Subject: RFR: 8255737: Zero: DO_UPDATE_INSTRUCTION_COUNT should only update when relevant VM flags are set [v2] In-Reply-To: References: <0rTV2XCqJXx-PVUlcJdxjg30iG2fueUwnxMHe6dFM1M=.2e8fcc35-8dbb-482e-b1ab-d5c377d79c14@github.com> <67LKUJ6Gi6JfVbgTLlN9Sa0GO5kG9k1nA0LvirvZJQs=.6a527790-ed6a-4fbc-aa82-60c9278adb72@github.com> Message-ID: <6Ss6vOLuTb-uFHHLdFyQH3mKjmaqAACRxZU78I0SMxA=.73e97e8a-3f1f-427c-a6d3-801f09cfa388@github.com> On Tue, 3 Nov 2020 12:17:24 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 138: >> >>> 136: #define DO_UPDATE_INSTRUCTION_COUNT(opcode) \ >>> 137: { \ >>> 138: if (CountBytecodes || TraceBytecodes || StopInterpreterAt) BytecodeCounter::_counter_value++; \ >> >> Elsewhere we do `[...] || StopInterpreterAt > 0` which is clearer as it's a flag expecting an int value. Perhaps you could use that instead of the implicit boolean conversion? >> >> Yes, this doesn't seem consistent throughout the code, but while at it... > > Right on. I went on fixing the uses of `StopInterpreterAt` in this macro. I thought we can just check it against `_counter_value` without implicitly checking for `0` in the line below. But then Zero fastdebug build times exploded on me! So I thought to rewrite the block to hide most of the branches under the big one. See the update. This also clusters the uses of `BytecodeCounter::_counter_value`. Thanks for the update! ------------- PR: https://git.openjdk.java.net/jdk/pull/997 From shade at openjdk.java.net Tue Nov 3 13:59:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 13:59:59 GMT Subject: RFR: 8255737: Zero: DO_UPDATE_INSTRUCTION_COUNT should only update when relevant VM flags are set [v2] In-Reply-To: References: <0rTV2XCqJXx-PVUlcJdxjg30iG2fueUwnxMHe6dFM1M=.2e8fcc35-8dbb-482e-b1ab-d5c377d79c14@github.com> <2SVUpoNyz1wu-GgLpF_wlxWoAFGeYIncu5pIYOSc95Y=.c4efbc2c-7486-4ad3-adb3-672d448b1cd0@github.com> Message-ID: On Tue, 3 Nov 2020 13:30:49 GMT, Severin Gehwolf 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: >> >> - Rewrite the block to hide flags under major check >> - Merge branch 'master' into JDK-8255737-zero-do-update-flags >> - 8255737: Zero: DO_UPDATE_INSTRUCTION_COUNT should only update when relevant VM flags are set > > LGTM Thanks @jerboaa! ------------- PR: https://git.openjdk.java.net/jdk/pull/997 From shade at openjdk.java.net Tue Nov 3 14:00:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 14:00:59 GMT Subject: RFR: 8255810: Zero: build fails without JVMTI In-Reply-To: <8RuFCVYY-9hEzt8yw9K_PUuMLx74KRXeihjGMPZnKtA=.8da9b0de-e209-4f10-807e-5388680dd3c1@github.com> References: <8RuFCVYY-9hEzt8yw9K_PUuMLx74KRXeihjGMPZnKtA=.8da9b0de-e209-4f10-807e-5388680dd3c1@github.com> Message-ID: On Tue, 3 Nov 2020 13:04:08 GMT, Coleen Phillimore wrote: >> Zero interpreter has two modes: with JVMTI built-in, and without. But we cannot test it properly, because the build fails without JVMTI in shared code. Mostly due to JDK-8147388. >> >> Additional testing: >> - [x] Linux x86_64 Zero fastdebug builds `--with-jvm-features=-jvmti` > > Looks good. Thanks @coleenp! Would you say it is trivial? ------------- PR: https://git.openjdk.java.net/jdk/pull/1036 From shade at openjdk.java.net Tue Nov 3 14:08:05 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 14:08:05 GMT Subject: Integrated: 8255737: Zero: DO_UPDATE_INSTRUCTION_COUNT should only update when relevant VM flags are set In-Reply-To: <0rTV2XCqJXx-PVUlcJdxjg30iG2fueUwnxMHe6dFM1M=.2e8fcc35-8dbb-482e-b1ab-d5c377d79c14@github.com> References: <0rTV2XCqJXx-PVUlcJdxjg30iG2fueUwnxMHe6dFM1M=.2e8fcc35-8dbb-482e-b1ab-d5c377d79c14@github.com> Message-ID: On Mon, 2 Nov 2020 08:58:56 GMT, Aleksey Shipilev wrote: > Everywhere else in VM code we effectively do: > > if (CountBytecodes || TraceBytecodes || StopInterpreterAt) BytecodeCounter::... > if (PrintBytecodeHistogram) BytecodeHistogram::... > > But not in `DO_UPDATE_INSTRUCTION_COUNT` macro. > Adding these flags avoid the writes to statistics what would never be used (and those writes can even contend, afaics). > This change drops the Linux x86_64 Zero fastdebug build time from ~18m to ~17.5m. > > Testing: > - [x] Ad-hoc runs with Zero and affected flags This pull request has now been integrated. Changeset: f389a718 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/f389a718 Stats: 17 lines in 1 file changed: 6 ins; 0 del; 11 mod 8255737: Zero: DO_UPDATE_INSTRUCTION_COUNT should only update when relevant VM flags are set Reviewed-by: sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/997 From coleenp at openjdk.java.net Tue Nov 3 14:46:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 3 Nov 2020 14:46:58 GMT Subject: RFR: 8255810: Zero: build fails without JVMTI In-Reply-To: References: <8RuFCVYY-9hEzt8yw9K_PUuMLx74KRXeihjGMPZnKtA=.8da9b0de-e209-4f10-807e-5388680dd3c1@github.com> Message-ID: On Tue, 3 Nov 2020 13:58:36 GMT, Aleksey Shipilev wrote: >> Looks good. > > Thanks @coleenp! Would you say it is trivial? Yes, trivial! ------------- PR: https://git.openjdk.java.net/jdk/pull/1036 From iklam at openjdk.java.net Tue Nov 3 15:32:04 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 3 Nov 2020 15:32:04 GMT Subject: RFR: 8255239: The timezone of the hs_err_pid log file is corrupted in Japanese locale In-Reply-To: References: Message-ID: <04F6-lx38UZzoZZCSl2DY_n_q27rXpb_7A-nAaIsAsE=.23745c84-5202-46e7-9973-650a6a4af25c@github.com> On Mon, 2 Nov 2020 23:59:30 GMT, Calvin Cheung wrote: > Please review this simple fix by using the wide char version of strftime, i.e. wcsftime, to convert the timezone into a wide character string. After that, converting the wide character string back to multi-byte string before printing out the time and timezone. > > Testing: ran the test case in the bug report manually on: > > - Windows with ja, zh-tw, and en locales; > > - Linux and Mac OS with en locale. Changes requested by iklam (Reviewer). src/hotspot/share/runtime/os.cpp line 1006: > 1004: if (localtime_pd(&tloc, &tz) != NULL) { > 1005: wchar_t w_buf[80]; > 1006: size_t n = ::wcsftime(w_buf, 80, L"%Z", &tz); According to https://linux.die.net/man/3/wcsftime: "The Linux implementation of this interface may differ (consult the corresponding Linux manual page for details of Linux behavior), or the interface may not be implemented on Linux." Also, the L"%Z" notation is Windows-specific. Maybe we should use the new code only on Windows? An alternative is to use the C++ standard library (std::wcsftime and std:: wcstombs). However, this part of std:: is not yet permitted -- see https://bugs.openjdk.java.net/browse/JDK-8208089 ------------- PR: https://git.openjdk.java.net/jdk/pull/1023 From robbin.ehn at oracle.com Tue Nov 3 15:49:01 2020 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 3 Nov 2020 16:49:01 +0100 Subject: Unified Logging for network In-Reply-To: References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> <41f33608-63de-c7cb-e135-13a6fcc39b05@oracle.com> Message-ID: <445f898e-bcf4-4a24-9b97-43891d5429ea@oracle.com> Hi, Since e.g. syslog-ng already can do all of this and much more, and it can collect from text files, why not just do that? Any serious setup would already have configured syslog to e.g. logstash server. You just need to tell it to collect from the UL configured file(s) also. ? /Robbin On 2020-11-03 09:09, Thomas St?fe wrote: > Hi Yasumasa, > > I don't argue that such a feature would not be useful. Of course it would! > > But as with any other added feature, it will come at the cost of > complexity. It will have to be maintained, tests will have to be written > and run. That increases technical debt for us all. > > That is not a reason not to do it, but to think before doing it and > exploring alternatives. > > -- > > To me, the fact that a logging call now could possibly do Network IO fills > me with deep unease. It violates the principle of least surprise. Logging > should be as basic as possible, in order to be usable anywhere in code. > > - as had been said before, it would introduce unpredictable timing > behavior. The fact that we have this already today is not a big consolation > :( > > - similar to "the User should know what he does" argument - unfortunately > many don't, so a balance has to be found to limit support from these cases > > - AFAICS we do not do network IO anywhere in the hotspot today. That coding > would have to be written and tested. Reusing some other code - e.g. from > the corelibs - is out of question for such a low level API, since you don't > want to risk circularities. > > - But now we have a complete network stack below the innocuous logging > call. This imposes further restrictions on where we can log - eg even if it > were possible before, logging from signal handling is impossible now. > Without these restrictions documented and tested anywhere. To me this makes > UL more and more questionable, and I already tend to shun it when possible > in favour of plain tty printing. > > I argued yesterday against Ioi's concurrent-log-draining, but that is > actually more attractive the more I think about it. > > Only, could the same not be achieved with piping stdout/err to a separate > tool like netcat, as Leo suggested? > > That solution exists today. If netcat does not do it for you, this could > also be a separate utility - could be even part of the jdk. Conceptually > this would be much the same as a separate thread printing out UL, with the > pipe size being the buffer size. Or, communication could happen via shared > memory... > > This would have two distinct advantages over doing network IO in UL: > - we see the whole stderr output (e.g. output from the libc, or any third > party tools) > - we see output also from a VM which crashed and burned. E.g. any last > words from hs-err reporting. > > Cheers, Thomas > > > On Tue, Nov 3, 2020 at 3:12 AM Yasumasa Suenaga > wrote: > >> Hi, >> >> I agree this proposal might occur performance issue. However I think it is >> the responsibility of the user. >> If this proposal is implemented, I think it would be transferred to local >> log shipper process (fluentd, logstash on 127.0.0.1) in most case because >> HotSpot does not send log with JSON. And also log shipper may support >> message buffering and message queue persistence. >> We can avoid (in part of) performance/reliability issues with log shipper. >> >> Even if current implementation, performance issues is occurs when the disk >> is very slow (e.g. storage is broken). >> >> >> Cheers, >> >> Yasumasa >> >> >> On 2020/11/03 6:31, Thomas St?fe wrote: >>> Hi Ioi, >>> >>> I dimly remember proposals like this from the past. Main problem I see is >>> how large would you dimension the buffer, and what do you do if the >> buffer >>> cannot be drained rapidly enough. Discard log output? Hold? The former >>> sounds bad, the latter negates the advantages of such a buffer. >>> >>> Then, access to such a buffer would probably have to be synchronized, >>> whereas today AFAIK the log calls do not have to be. >>> >>> Cheers, Thomas >>> >>> On Mon 2. Nov 2020 at 22:18, Ioi Lam wrote: >>> >>>> For performance, maybe the implementation can log into a memory buffer, >>>> and use a worker thread to send the output over the network? That way we >>>> can minimize the overhead per log_xxx() call. >>>> >>>> I agree that using "-Xlog:foo=debug:network=xyz.com:1234" would be >> quite >>>> handy when you have lots of containers. You don't need to enable remote >>>> access to the container's file system just to get to the log file. >>>> >>>> Thanks >>>> - Ioi >>>> >>>> On 11/2/20 11:10 AM, Kirk Pepperdine wrote: >>>>> Hi Thomas, >>>>> >>>>> I appreciate Yasumasa?s desire to be able to redirect UL output to >>>> somewhere other than? I also appreciate that the highly granular nature >> of >>>> how UL messages are currently structure can be and indeed are an issue. >>>> That said, I?d also like the ability to push the data to some where >> other >>>> than a file on disk. >>>>> >>>>> To the point of granularity, UL might benefit from some message >>>> coarsening. This might also help in with other logging related >> performance >>>> issues that I?ve noted here and there. Quite frankly dealing with logs >> in >>>> containers isn?t a wonderful experience. And while I firmly believe that >>>> there is more that containers can do to ease this, being able to >> redirect >>>> output to something other than a log file does feel like it would be >>>> helpful. That said, I?m also concerned about the potential performance >>>> impacts but I think for this things that one would generally log, this >>>> should be minimal. >>>>> >>>>> Kind regards, >>>>> Kirk Pepperdine >>>>> >>>>> >>>>>> On Nov 2, 2020, at 4:26 AM, Thomas St?fe >>>> wrote: >>>>>> >>>>>> Hi Yasumasa, >>>>>> >>>>>> one problem I see is that this could introduce a surprising amount of >>>> lag >>>>>> into log() calls which do look inconspicuous, thereby distorting >> timing >>>>>> behavior or even create timeout effects. We already have that problem >>>> now >>>>>> to some degree when logging to network shares. >>>>>> >>>>>> Another thing, log output can be very fine granular, which would >> create >>>> a >>>>>> lot of network traffic. >>>>>> >>>>>> Such an addition may also open some security questions. >>>>>> >>>>>> From a more philosophical standpoint, I like the "do one thing and >> do >>>> it >>>>>> right" Unix way and this seems more like something an outside tool >>>> should >>>>>> be doing. Which could also aggregate log output better. But I admit >> that >>>>>> argument is weak. >>>>>> >>>>>> Cheers, Thomas >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga < >>>> suenaga at oss.nttdata.com> >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> We need to out UL to stdout and/or file. If we can out it to TCP >>>> socket, I >>>>>>> think it is useful. >>>>>>> >>>>>>> For example, some system gather all logs to document oriented >> databases >>>>>>> (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. >>>> CloudWatch). If >>>>>>> HotSpot can out UL to TCP socket, we can send all logs to them via >> TCP >>>>>>> input plugin (Fluentd, Logstash). >>>>>>> >>>>>>> I think it is useful for container platform. What do you think? >>>>>>> If it is worth to work, I will add CSR and JBS ticket, and also will >>>>>>> create patch. >>>>>>> >>>> >>>> >> From iklam at openjdk.java.net Tue Nov 3 16:47:55 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 3 Nov 2020 16:47:55 GMT Subject: RFR: 8255239: The timezone of the hs_err_pid log file is corrupted in Japanese locale In-Reply-To: <04F6-lx38UZzoZZCSl2DY_n_q27rXpb_7A-nAaIsAsE=.23745c84-5202-46e7-9973-650a6a4af25c@github.com> References: <04F6-lx38UZzoZZCSl2DY_n_q27rXpb_7A-nAaIsAsE=.23745c84-5202-46e7-9973-650a6a4af25c@github.com> Message-ID: On Tue, 3 Nov 2020 15:26:53 GMT, Ioi Lam wrote: >> Please review this simple fix by using the wide char version of strftime, i.e. wcsftime, to convert the timezone into a wide character string. After that, converting the wide character string back to multi-byte string before printing out the time and timezone. >> >> Testing: ran the test case in the bug report manually on: >> >> - Windows with ja, zh-tw, and en locales; >> >> - Linux and Mac OS with en locale. > > src/hotspot/share/runtime/os.cpp line 1006: > >> 1004: if (localtime_pd(&tloc, &tz) != NULL) { >> 1005: wchar_t w_buf[80]; >> 1006: size_t n = ::wcsftime(w_buf, 80, L"%Z", &tz); > > According to https://linux.die.net/man/3/wcsftime: "The Linux implementation of this interface may differ (consult the corresponding Linux manual page for details of Linux behavior), or the interface may not be implemented on Linux." > > Also, the L"%Z" notation is Windows-specific. > > Maybe we should use the new code only on Windows? > > An alternative is to use the C++ standard library (std::wcsftime and std:: wcstombs). However, this part of std:: is not yet permitted -- see https://bugs.openjdk.java.net/browse/JDK-8208089 After further investigation -- wcsftime is in C99. Also, we use it here only inside `if (localtime_pd(&tloc, &tz) != NULL)`. I supposed any Linux distro that has a minimal of locale support to make that function return non-null would have a working implementation of wcsftime. So I think this code is OK. The only change I request is to change ` L"%Z"` to `"%Z"` ------------- PR: https://git.openjdk.java.net/jdk/pull/1023 From pchilanomate at openjdk.java.net Tue Nov 3 17:02:02 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 3 Nov 2020 17:02:02 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v2] In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 02:32:07 GMT, David Holmes wrote: > This seems functionally fine, but it still seems to me that we are missing a Safepoint or SafepointMechanism API helper method that does: > > ``` > SafepointMechanism::process_if_requested(THREAD); > if (THREAD->has_special_runtime_exit_condition()) { > THREAD->handle_special_runtime_exit_condition(checkAsyncs); > } > ``` > > Lets see if others have an opinion. > Thanks. How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)? > src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 112: > >> 110: CALL_VM(SafepointMechanism::process_if_requested(THREAD); \ >> 111: if (THREAD->has_special_runtime_exit_condition()) { \ >> 112: THREAD->handle_special_runtime_exit_condition(); \ > > Please add explicit arg: "(true /* check asyncs */)" > > Using a multi-statement code block for the CALL_VM macro looks odd to me, but I find these zero macros unpleasant to begin with. Yes, that's also why I liked better the TIVFJ wrapper. But if we can agree on the helper method then that would change to a single line. > src/hotspot/share/runtime/safepoint.cpp line 936: > >> 934: SafepointMechanism::process_if_requested(self); >> 935: if (self->has_special_runtime_exit_condition()) { >> 936: self->handle_special_runtime_exit_condition(); > > Please add explicit arg: "(true /* check asyncs */)" Added. ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From jvernee at openjdk.java.net Tue Nov 3 17:09:00 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 3 Nov 2020 17:09:00 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c Message-ID: Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c This removes the reported warning. Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing). CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed. Testing: tier1-3 [1] https://bugs.openjdk.java.net/browse/JDK-8232022 ------------- Commit messages: - Add 32-bit safe version of jlong <-> casts to libJNIPoint.c Changes: https://git.openjdk.java.net/jdk/pull/1017/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1017&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255128 Stats: 17 lines in 2 files changed: 8 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1017.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1017/head:pull/1017 PR: https://git.openjdk.java.net/jdk/pull/1017 From jvernee at openjdk.java.net Tue Nov 3 17:14:00 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 3 Nov 2020 17:14:00 GMT Subject: RFR: 8255838: Use 32-bit immediate movslq in macro assembler if 64-bit value fits in 32 bits on x86_64 Message-ID: Currently, Macro::Assembler(Address dst, intprt_t src) on x64 uses an intermediate scratch register to store the 64-bit immediate. void MacroAssembler::movptr(Address dst, intptr_t src) { mov64(rscratch1, src); movq(dst, rscratch1); } But, if the value fits into 32-bits, we can also explicitly use the 32-bit immediate overload, which saves an instruction and a register use, by using movslq/movabs instead (sig extended move). This ends up saving about 90k instructions on hello world. It also reduces the size of the interpreter by about 4k. Special thanks to Claes for prior discussion and help with testing. Testing: tier1-3, local startup profiling ------------- Commit messages: - Explicitly convert intptr_t to int32_t to use movslq on 64 bit platforms if possible Changes: https://git.openjdk.java.net/jdk/pull/1038/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1038&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255838 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1038.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1038/head:pull/1038 PR: https://git.openjdk.java.net/jdk/pull/1038 From azeemj at openjdk.java.net Tue Nov 3 17:16:55 2020 From: azeemj at openjdk.java.net (Azeem Jiva) Date: Tue, 3 Nov 2020 17:16:55 GMT Subject: RFR: 8255838: Use 32-bit immediate movslq in macro assembler if 64-bit value fits in 32 bits on x86_64 In-Reply-To: References: Message-ID: <8HfzUNZAzxlNUmR3PVhgjtdIV0jVUcvlo4kFzzXY2TQ=.660948fa-94ac-458e-a08d-b4d7201a66ae@github.com> On Tue, 3 Nov 2020 15:12:50 GMT, Jorn Vernee wrote: > Currently, Macro::Assembler(Address dst, intprt_t src) on x64 uses an intermediate scratch register to store the 64-bit immediate. > > void MacroAssembler::movptr(Address dst, intptr_t src) { > mov64(rscratch1, src); > movq(dst, rscratch1); > } > > But, if the value fits into 32-bits, we can also explicitly use the 32-bit immediate overload, which saves an instruction and a register use, by using movslq/movabs instead (sig extended move). > > This ends up saving about 90k instructions on hello world. It also reduces the size of the interpreter by about 4k. > > Special thanks to Claes for prior discussion and help with testing. > > Testing: tier1-3, local startup profiling This looks good to me, but this is probably compiler. ------------- Marked as reviewed by azeemj (Author). PR: https://git.openjdk.java.net/jdk/pull/1038 From shade at openjdk.java.net Tue Nov 3 17:17:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 17:17:57 GMT Subject: RFR: 8255810: Zero: build fails without JVMTI In-Reply-To: References: <8RuFCVYY-9hEzt8yw9K_PUuMLx74KRXeihjGMPZnKtA=.8da9b0de-e209-4f10-807e-5388680dd3c1@github.com> Message-ID: <7hMYf7a4gV9wNZ-EyvZaMI4scxKjVqv2s55SUDiO8hg=.8f863caa-86c0-4512-bd82-284e9cc324c7@github.com> On Tue, 3 Nov 2020 14:43:52 GMT, Coleen Phillimore wrote: >> Thanks @coleenp! Would you say it is trivial? > > Yes, trivial! Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1036 From minqi at openjdk.java.net Tue Nov 3 17:20:01 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 3 Nov 2020 17:20:01 GMT Subject: RFR: 8255784: appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java test failed resulting in VM crash Message-ID: Please review this simple change. The crash is caused by vm_exit_during_initialization which calls vm_exit, the latter will go check vm shutdown procedures. The shutdown checks thread and lock state, finds inconsistent state so the check fails. Here we could just use vm_direct_exit with some message as the process terminated. vm_direct_exit just calls os::exit which quits without generating a coredump. Tests: tier1-4 Thanks Yumin ------------- Commit messages: - 8255784: appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java test failed resulting in VM crash Changes: https://git.openjdk.java.net/jdk/pull/1040/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1040&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255784 Stats: 13 lines in 4 files changed: 8 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1040.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1040/head:pull/1040 PR: https://git.openjdk.java.net/jdk/pull/1040 From pchilanomate at openjdk.java.net Tue Nov 3 17:22:14 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 3 Nov 2020 17:22:14 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v3] 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 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 8255384-SSBlock - Add explicit bool arg - Make direct calls instead of using transition wrappers - v1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/913/files - new: https://git.openjdk.java.net/jdk/pull/913/files/3f9dfe4c..db8f076d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=913&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=913&range=01-02 Stats: 17602 lines in 577 files changed: 9916 ins; 5054 del; 2632 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 rrich at openjdk.java.net Tue Nov 3 17:22:15 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 3 Nov 2020 17:22:15 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 22:10:58 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 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 > > 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 Hi Patricio, the change looks good to me. In `JavaThread::check_and_handle_async_exceptions()` the block depending on is_at_poll_safepoint() looks like dead code now. I wonder if `ThreadSafepointState::_at_poll_safepoint` could even be DEBUG_ONLY? Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From shade at openjdk.java.net Tue Nov 3 17:27:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 17:27:59 GMT Subject: Integrated: 8255810: Zero: build fails without JVMTI In-Reply-To: References: Message-ID: <0wJLrYNFynBtocdY_3sIeDuDcj8D3xNbO2AmNXvUBP4=.cb9116da-e9ab-4b3e-ba48-a2662c6b60b3@github.com> On Tue, 3 Nov 2020 11:22:50 GMT, Aleksey Shipilev wrote: > Zero interpreter has two modes: with JVMTI built-in, and without. But we cannot test it properly, because the build fails without JVMTI in shared code. Mostly due to JDK-8147388. > > Additional testing: > - [x] Linux x86_64 Zero fastdebug builds `--with-jvm-features=-jvmti` This pull request has now been integrated. Changeset: ca216bae Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/ca216bae Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod 8255810: Zero: build fails without JVMTI Reviewed-by: coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1036 From jvernee at openjdk.java.net Tue Nov 3 17:40:54 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 3 Nov 2020 17:40:54 GMT Subject: RFR: 8255838: Use 32-bit immediate movslq in macro assembler if 64-bit value fits in 32 bits on x86_64 In-Reply-To: <8HfzUNZAzxlNUmR3PVhgjtdIV0jVUcvlo4kFzzXY2TQ=.660948fa-94ac-458e-a08d-b4d7201a66ae@github.com> References: <8HfzUNZAzxlNUmR3PVhgjtdIV0jVUcvlo4kFzzXY2TQ=.660948fa-94ac-458e-a08d-b4d7201a66ae@github.com> Message-ID: On Tue, 3 Nov 2020 17:14:38 GMT, Azeem Jiva wrote: >> Currently, Macro::Assembler(Address dst, intprt_t src) on x64 uses an intermediate scratch register to store the 64-bit immediate. >> >> void MacroAssembler::movptr(Address dst, intptr_t src) { >> mov64(rscratch1, src); >> movq(dst, rscratch1); >> } >> >> But, if the value fits into 32-bits, we can also explicitly use the 32-bit immediate overload, which saves an instruction and a register use, by using movslq/movabs instead (sig extended move). >> >> This ends up saving about 90k instructions on hello world. It also reduces the size of the interpreter by about 4k. >> >> Special thanks to Claes for prior discussion and help with testing. >> >> Testing: tier1-3, local startup profiling > > This looks good to me, but this is probably compiler. @AzeemJiva Thanks for the review. Ok, will CC compiler as well ------------- PR: https://git.openjdk.java.net/jdk/pull/1038 From kvn at openjdk.java.net Tue Nov 3 17:47:59 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 3 Nov 2020 17:47:59 GMT Subject: RFR: 8255838: Use 32-bit immediate movslq in macro assembler if 64-bit value fits in 32 bits on x86_64 In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 15:12:50 GMT, Jorn Vernee wrote: > Currently, Macro::Assembler(Address dst, intprt_t src) on x64 uses an intermediate scratch register to store the 64-bit immediate. > > void MacroAssembler::movptr(Address dst, intptr_t src) { > mov64(rscratch1, src); > movq(dst, rscratch1); > } > > But, if the value fits into 32-bits, we can also explicitly use the 32-bit immediate overload, which saves an instruction and a register use, by using movslq/movabs instead (sig extended move). > > This ends up saving about 90k instructions on hello world. It also reduces the size of the interpreter by about 4k. > > Special thanks to Claes for prior discussion and help with testing. > > Testing: tier1-3, local startup profiling Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1038 From coleenp at openjdk.java.net Tue Nov 3 17:47:59 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 3 Nov 2020 17:47:59 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 18:36:32 GMT, Jorn Vernee wrote: > Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c > > This removes the reported warning. > > Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing). > > CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed. > > Testing: tier1-3 > > [1] https://bugs.openjdk.java.net/browse/JDK-8232022 Marked as reviewed by coleenp (Reviewer). test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/libJNIPoint.c line 32: > 30: #define PTR_TO_JLONG(value) ((jlong) (value)) > 31: #else > 32: #define JLONG_TO_PTR(value, type) ((type*) (jint) (value)) Maybe the jlong thisPoint argument comes from a pointer so it's ok. Not nice, but if you say so, I'll go along. ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From coleenp at openjdk.java.net Tue Nov 3 17:48:00 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 3 Nov 2020 17:48:00 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c In-Reply-To: References: Message-ID: <86GJGpWCz1RDjZwbPBay-WvvZMMTPidoJT22ppTqgRo=.23c9d7de-fa18-4b9a-aab8-99ccedb54b3c@github.com> On Tue, 3 Nov 2020 17:40:38 GMT, Coleen Phillimore wrote: >> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c >> >> This removes the reported warning. >> >> Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing). >> >> CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed. >> >> Testing: tier1-3 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8232022 > > Marked as reviewed by coleenp (Reviewer). I was anxious for this to compile so I reviewed it. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From jvernee at openjdk.java.net Tue Nov 3 17:48:01 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 3 Nov 2020 17:48:01 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c In-Reply-To: References: Message-ID: <6DXVMQgh9e1fzgQvDT2uEy3ttbSLzTj4hKJrH7gJ2y4=.42173fe7-2f20-4796-8500-426a7b872cf3@github.com> On Tue, 3 Nov 2020 17:42:08 GMT, Jorn Vernee wrote: >> test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/libJNIPoint.c line 32: >> >>> 30: #define PTR_TO_JLONG(value) ((jlong) (value)) >>> 31: #else >>> 32: #define JLONG_TO_PTR(value, type) ((type*) (jint) (value)) >> >> Maybe the jlong thisPoint argument comes from a pointer so it's ok. Not nice, but if you say so, I'll go along. > > Yes, it's the same pointer that is returned from allocate. It's just stored in a `jlong` on the Java side (this would be a requirement on x64), but it's not expected that the high-order bits are used. > > Do you have a suggestion for handling this otherwise? Hmm, now that I think about it, we could add overloads that work with `int` for 32-bit platforms. But, for now 32-bit usage of these benchmarks seems unlikely. Since the build passes, and the benchmarks run on both platforms already, I'm reluctant to put much more effort into this at the moment. ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From jvernee at openjdk.java.net Tue Nov 3 17:48:00 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 3 Nov 2020 17:48:00 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 17:40:32 GMT, Coleen Phillimore wrote: >> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c >> >> This removes the reported warning. >> >> Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing). >> >> CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed. >> >> Testing: tier1-3 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8232022 > > test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/libJNIPoint.c line 32: > >> 30: #define PTR_TO_JLONG(value) ((jlong) (value)) >> 31: #else >> 32: #define JLONG_TO_PTR(value, type) ((type*) (jint) (value)) > > Maybe the jlong thisPoint argument comes from a pointer so it's ok. Not nice, but if you say so, I'll go along. Yes, it's the same pointer that is returned from allocate. It's just stored in a `jlong` on the Java side (this would be a requirement on x64), but it's not expected that the high-order bits are used. Do you have a suggestion for handling this otherwise? ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From patricio.chilano.mateo at oracle.com Tue Nov 3 17:50:41 2020 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Tue, 3 Nov 2020 12:50:41 -0500 Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v2] In-Reply-To: References: Message-ID: Hi Richard, On 11/3/20 12:22 PM, Richard Reingruber wrote: > On Thu, 29 Oct 2020 22:10:58 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 w! > rappers 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 >> 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 > Hi Patricio, > > the change looks good to me. Thanks for looking at this. > In `JavaThread::check_and_handle_async_exceptions()` the block depending on is_at_poll_safepoint() looks like dead code now. I wonder if `ThreadSafepointState::_at_poll_safepoint` could even be DEBUG_ONLY? Yes, I actually thought about doing that in the first version but then I realized that code was already dead even before this change. We only call set_at_poll_safepoint() in handle_polling_page_exception() and the handle_special_runtime_exit_condition() call in SS::block() already excludes checking async exceptions for that case. The call I removed from ~TIVMFH was exactly the same. So I don't see a path where it could be called where is_at_poll_safepoint() returned true. I agree that _at_poll_safepoint should probably be DEBUG_ONLY. Then we should add an assert in check_and_handle_async_exceptions(). Do you think I should do that here or in another bug? Thanks, Patricio > Thanks, Richard. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/913 From rrich at openjdk.java.net Tue Nov 3 18:05:05 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 3 Nov 2020 18:05:05 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v3] In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 17:22:14 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 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 > > 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 four additional commits since the last revision: > > - Merge branch 'master' into 8255384-SSBlock > - Add explicit bool arg > - Make direct calls instead of using transition wrappers > - v1 Marked as reviewed by rrich (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From rrich at openjdk.java.net Tue Nov 3 18:05:06 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 3 Nov 2020 18:05:06 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v2] In-Reply-To: References: Message-ID: <9IsIU2kkaQcnTz3dbjrAC9ISvALDPc0tBE9YP9_dSiY=.b85337c1-1e54-4ec7-8266-28aafa781b82@github.com> On Tue, 3 Nov 2020 17:19:04 GMT, Richard Reingruber wrote: >> 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 > > Hi Patricio, > > the change looks good to me. > > In `JavaThread::check_and_handle_async_exceptions()` the block depending on is_at_poll_safepoint() looks like dead code now. I wonder if `ThreadSafepointState::_at_poll_safepoint` could even be DEBUG_ONLY? > > Thanks, Richard. > > > In `JavaThread::check_and_handle_async_exceptions()` the block depending on is_at_poll_safepoint() looks like dead code now. I wonder if `ThreadSafepointState::_at_poll_safepoint` could even be DEBUG_ONLY? > > Yes, I actually thought about doing that in the first version but then I > realized that code was already dead even before this change. We only > call set_at_poll_safepoint() in handle_polling_page_exception() and the > handle_special_runtime_exit_condition() call in SS::block() already > excludes checking async exceptions for that case. The call I removed > from ~TIVMFH was exactly the same. So I don't see a path where it could > be called where is_at_poll_safepoint() returned true. > I agree that _at_poll_safepoint should probably be DEBUG_ONLY. Then we > should add an assert in check_and_handle_async_exceptions(). Do you > think I should do that here or in another bug? I'd think you can do it in another bug also. I'm ok either way actually. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From iklam at openjdk.java.net Tue Nov 3 18:18:58 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 3 Nov 2020 18:18:58 GMT Subject: RFR: 8255239: The timezone of the hs_err_pid log file is corrupted in Japanese locale In-Reply-To: References: Message-ID: <-fuc-F7KNt_PAQwP8Xu1_vdzWwO-oDNKSmgghiL66fY=.8e2fe19e-3433-44ea-9527-a5d044ec6f2d@github.com> On Mon, 2 Nov 2020 23:59:30 GMT, Calvin Cheung wrote: > Please review this simple fix by using the wide char version of strftime, i.e. wcsftime, to convert the timezone into a wide character string. After that, converting the wide character string back to multi-byte string before printing out the time and timezone. > > Testing: ran the test case in the bug report manually on: > > - Windows with ja, zh-tw, and en locales; > > - Linux and Mac OS with en locale. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1023 From iklam at openjdk.java.net Tue Nov 3 18:19:02 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 3 Nov 2020 18:19:02 GMT Subject: RFR: 8255239: The timezone of the hs_err_pid log file is corrupted in Japanese locale In-Reply-To: References: <04F6-lx38UZzoZZCSl2DY_n_q27rXpb_7A-nAaIsAsE=.23745c84-5202-46e7-9973-650a6a4af25c@github.com> Message-ID: On Tue, 3 Nov 2020 16:45:22 GMT, Ioi Lam wrote: >> src/hotspot/share/runtime/os.cpp line 1006: >> >>> 1004: if (localtime_pd(&tloc, &tz) != NULL) { >>> 1005: wchar_t w_buf[80]; >>> 1006: size_t n = ::wcsftime(w_buf, 80, L"%Z", &tz); >> >> According to https://linux.die.net/man/3/wcsftime: "The Linux implementation of this interface may differ (consult the corresponding Linux manual page for details of Linux behavior), or the interface may not be implemented on Linux." >> >> Also, the L"%Z" notation is Windows-specific. >> >> Maybe we should use the new code only on Windows? >> >> An alternative is to use the C++ standard library (std::wcsftime and std:: wcstombs). However, this part of std:: is not yet permitted -- see https://bugs.openjdk.java.net/browse/JDK-8208089 > > After further investigation -- wcsftime is in C99. Also, we use it here only inside `if (localtime_pd(&tloc, &tz) != NULL)`. I supposed any Linux distro that has a minimal of locale support to make that function return non-null would have a working implementation of wcsftime. > > So I think this code is OK. The only change I request is to change ` L"%Z"` to `"%Z"` Upon even more investigation, I was completely wrong :-) According https://en.cppreference.com/w/cpp/language/string_literal, the "L" prefix is for `wchar_t` string literals. So your code is correct. ------------- PR: https://git.openjdk.java.net/jdk/pull/1023 From shade at openjdk.java.net Tue Nov 3 18:33:55 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 3 Nov 2020 18:33:55 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 18:36:32 GMT, Jorn Vernee wrote: > Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c > > This removes the reported warning. > > Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing). > > CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed. > > Testing: tier1-3 > > [1] https://bugs.openjdk.java.net/browse/JDK-8232022 I knew this looks familiar. Look at [existing macros in jlong_md.h](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjava/jlong_md.h#L67-L81) and use/match them? There is a little difference in casting through `jint` in your code, while `jlong_md.h` does it via `int`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From ccheung at openjdk.java.net Tue Nov 3 18:37:55 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 3 Nov 2020 18:37:55 GMT Subject: RFR: 8255784: appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java test failed resulting in VM crash In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 17:12:06 GMT, Yumin Qi wrote: > Please review this simple change. > The crash is caused by vm_exit_during_initialization which calls vm_exit, the latter will go check vm shutdown procedures. The shutdown checks thread and lock state, finds inconsistent state so the check fails. Here we could just use vm_direct_exit with some message as the process terminated. vm_direct_exit just calls os::exit which quits without generating a coredump. > > Tests: tier1-4 > > Thanks > Yumin Looks good. src/hotspot/share/memory/archiveUtils.cpp line 328: > 326: vm_direct_exit(-1, > 327: err_msg("Out of memory. Please run with a larger Java heap, current MaxHeapSize = " > 328: SIZE_FORMAT "M", MaxHeapSize/M)); I didn't know the format string could be broken up into 2 lines. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1040 From ccheung at openjdk.java.net Tue Nov 3 18:40:59 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 3 Nov 2020 18:40:59 GMT Subject: RFR: 8255239: The timezone of the hs_err_pid log file is corrupted in Japanese locale In-Reply-To: References: <04F6-lx38UZzoZZCSl2DY_n_q27rXpb_7A-nAaIsAsE=.23745c84-5202-46e7-9973-650a6a4af25c@github.com> Message-ID: On Tue, 3 Nov 2020 18:15:51 GMT, Ioi Lam wrote: >> After further investigation -- wcsftime is in C99. Also, we use it here only inside `if (localtime_pd(&tloc, &tz) != NULL)`. I supposed any Linux distro that has a minimal of locale support to make that function return non-null would have a working implementation of wcsftime. >> >> So I think this code is OK. The only change I request is to change ` L"%Z"` to `"%Z"` > > Upon even more investigation, I was completely wrong :-) > > According https://en.cppreference.com/w/cpp/language/string_literal, the "L" prefix is for `wchar_t` string literals. So your code is correct. @iklam Thanks for your review and making sure the change is ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/1023 From ihse at openjdk.java.net Tue Nov 3 18:48:58 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 3 Nov 2020 18:48:58 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 18:36:32 GMT, Jorn Vernee wrote: > Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c > > This removes the reported warning. > > Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing). > > CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed. > > Testing: tier1-3 > > [1] https://bugs.openjdk.java.net/browse/JDK-8232022 Changes requested by ihse (Reviewer). make/autoconf/flags-cflags.m4 line 667: > 665: > 666: if test "x$FLAGS_CPU_BITS" = x64; then > 667: if test "x$FLAGS_OS" = xlinux || test "x$FLAGS_OS" = xmacosx || test "x$FLAGS_OS" = xwindows; then At this point, you're almost testing for all supported OSes. :) I can only think of AIX that does not match this if clause. I think it would be better to just remove the if and always define _LP64=1 on 64-bit platforms. @simonis Would that be OK for AIX? ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From minqi at openjdk.java.net Tue Nov 3 18:50:56 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 3 Nov 2020 18:50:56 GMT Subject: RFR: 8255239: The timezone of the hs_err_pid log file is corrupted in Japanese locale In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 23:59:30 GMT, Calvin Cheung wrote: > Please review this simple fix by using the wide char version of strftime, i.e. wcsftime, to convert the timezone into a wide character string. After that, converting the wide character string back to multi-byte string before printing out the time and timezone. > > Testing: ran the test case in the bug report manually on: > > - Windows with ja, zh-tw, and en locales; > > - Linux and Mac OS with en locale. Looks good! ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1023 From minqi at openjdk.java.net Tue Nov 3 18:55:16 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 3 Nov 2020 18:55:16 GMT Subject: RFR: 8255784: appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java test failed resulting in VM crash [v2] In-Reply-To: References: Message-ID: > Please review this simple change. > The crash is caused by vm_exit_during_initialization which calls vm_exit, the latter will go check vm shutdown procedures. The shutdown checks thread and lock state, finds inconsistent state so the check fails. Here we could just use vm_direct_exit with some message as the process terminated. vm_direct_exit just calls os::exit which quits without generating a coredump. > > Tests: tier1-4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Changed vm_exit to vm_direct_exit to avoid shutdown check ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1040/files - new: https://git.openjdk.java.net/jdk/pull/1040/files/e1796d79..e3bb1adc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1040&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1040&range=00-01 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1040.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1040/head:pull/1040 PR: https://git.openjdk.java.net/jdk/pull/1040 From jvernee at openjdk.java.net Tue Nov 3 18:56:00 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 3 Nov 2020 18:56:00 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c In-Reply-To: References: Message-ID: <5RiTHvRKDKf0_Zr2ZQICloKttbvZc_osDtJ_ylpxfrw=.7fe27b37-78fa-47fc-b37b-4ecde950818a@github.com> On Tue, 3 Nov 2020 18:46:29 GMT, Magnus Ihse Bursie wrote: >> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c >> >> This removes the reported warning. >> >> Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing). >> >> CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed. >> >> Testing: tier1-3 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8232022 > > make/autoconf/flags-cflags.m4 line 667: > >> 665: >> 666: if test "x$FLAGS_CPU_BITS" = x64; then >> 667: if test "x$FLAGS_OS" = xlinux || test "x$FLAGS_OS" = xmacosx || test "x$FLAGS_OS" = xwindows; then > > At this point, you're almost testing for all supported OSes. :) I can only think of AIX that does not match this if clause. I think it would be better to just remove the if and always define _LP64=1 on 64-bit platforms. > > @simonis Would that be OK for AIX? Thanks for the suggestion. Note the code that adds _LP64 for the JVM (below): if test "x$FLAGS_OS" != xaix; then # xlc on AIX defines _LP64=1 by default and issues a warning if we redefine it. $1_DEFINES_CPU_JVM="${$1_DEFINES_CPU_JVM} -D_LP64=1" fi So, it seems xlc/aix explicitly does _not_ want this macro defined? I think we could reuse that if-block to add `-D_LP64=` to both `1_DEFINES_CPU_JDK`, and `1_DEFINES_CPU_JVM` though, and remove the first one that checks for linux/mac/windows. ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From john.r.rose at oracle.com Tue Nov 3 19:01:20 2020 From: john.r.rose at oracle.com (John Rose) Date: Tue, 3 Nov 2020 11:01:20 -0800 Subject: Unified Logging for network In-Reply-To: <5c5e812f-9730-4358-b79e-efd4875153f3@oracle.com> References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <5c5e812f-9730-4358-b79e-efd4875153f3@oracle.com> Message-ID: On Nov 2, 2020, at 4:39 AM, Leo Korinth wrote: > > I think it is a mistake. Making UL easy to use over network will make people use it (over network). It will have bad latency and will transfer an unstable log format. I think we have re-invented Heisenlogs here. If there were a lower-latency, more stable backing store for log output, as compared to disk files, then *that* would be a good RFE, but I agree with Thomas and Leo here that plumbing low-level log output straight up to a TCP (!) point is asking for trouble. Specifically, it?s asking for a new class of disruptive and unpredictable observation effects. I think we should inquire what are the best-of-breed log data collectors (that solve for observation effects) and make sure that the JVM has a way to hook up to them?locally. And if those collectors just watch files, then we are done, I guess, although surely there is some fit and finish to add. > If some important data is missing from JFR, would it not be better to add new JFR events? If you need it for debug reasons, you could just pipe stdout through netcat (I guess). From pchilanomate at openjdk.java.net Tue Nov 3 19:06:58 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 3 Nov 2020 19:06:58 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v3] In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 18:01:47 GMT, Richard Reingruber wrote: >> 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 four additional commits since the last revision: >> >> - Merge branch 'master' into 8255384-SSBlock >> - Add explicit bool arg >> - Make direct calls instead of using transition wrappers >> - v1 > > Marked as reviewed by rrich (Committer). > > > In `JavaThread::check_and_handle_async_exceptions()` the block depending on is_at_poll_safepoint() looks like dead code now. I wonder if `ThreadSafepointState::_at_poll_safepoint` could even be DEBUG_ONLY? > > > > > > Yes, I actually thought about doing that in the first version but then I > > realized that code was already dead even before this change. We only > > call set_at_poll_safepoint() in handle_polling_page_exception() and the > > handle_special_runtime_exit_condition() call in SS::block() already > > excludes checking async exceptions for that case. The call I removed > > from ~TIVMFH was exactly the same. So I don't see a path where it could > > be called where is_at_poll_safepoint() returned true. > > I agree that _at_poll_safepoint should probably be DEBUG_ONLY. Then we > > should add an assert in check_and_handle_async_exceptions(). Do you > > think I should do that here or in another bug? > > I'd think you can do it in another bug also. I'm ok either way actually. Ok, I filed 8255849 to track that. Thanks Richard! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From jvernee at openjdk.java.net Tue Nov 3 19:10:55 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 3 Nov 2020 19:10:55 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 18:30:46 GMT, Aleksey Shipilev wrote: >> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c >> >> This removes the reported warning. >> >> Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing). >> >> CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed. >> >> Testing: tier1-3 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8232022 > > I knew this looks familiar. Look at [existing macros in jlong_md.h](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjava/jlong_md.h#L67-L81) and use/match them? There is a little difference in casting through `jint` in your code, while `jlong_md.h` does it via `int`. @shipilev Now that I look at the file you linked, it does look familiar to me as well. Must have copy-pasted it from my subconscious ;) Looks like this file is usable from the benchmark lib code as well, will try to switch. ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From iklam at openjdk.java.net Tue Nov 3 19:13:54 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 3 Nov 2020 19:13:54 GMT Subject: RFR: 8255784: appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java test failed resulting in VM crash [v2] In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 18:55:16 GMT, Yumin Qi wrote: >> Please review this simple change. >> The crash is caused by vm_exit_during_initialization which calls vm_exit, the latter will go check vm shutdown procedures. The shutdown checks thread and lock state, finds inconsistent state so the check fails. Here we could just use vm_direct_exit with some message as the process terminated. vm_direct_exit just calls os::exit which quits without generating a coredump. >> >> Tests: tier1-4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Changed vm_exit to vm_direct_exit to avoid shutdown check Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1040 From ihse at openjdk.java.net Tue Nov 3 19:18:56 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 3 Nov 2020 19:18:56 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c In-Reply-To: <5RiTHvRKDKf0_Zr2ZQICloKttbvZc_osDtJ_ylpxfrw=.7fe27b37-78fa-47fc-b37b-4ecde950818a@github.com> References: <5RiTHvRKDKf0_Zr2ZQICloKttbvZc_osDtJ_ylpxfrw=.7fe27b37-78fa-47fc-b37b-4ecde950818a@github.com> Message-ID: On Tue, 3 Nov 2020 18:52:52 GMT, Jorn Vernee wrote: >> make/autoconf/flags-cflags.m4 line 667: >> >>> 665: >>> 666: if test "x$FLAGS_CPU_BITS" = x64; then >>> 667: if test "x$FLAGS_OS" = xlinux || test "x$FLAGS_OS" = xmacosx || test "x$FLAGS_OS" = xwindows; then >> >> At this point, you're almost testing for all supported OSes. :) I can only think of AIX that does not match this if clause. I think it would be better to just remove the if and always define _LP64=1 on 64-bit platforms. >> >> @simonis Would that be OK for AIX? > > Thanks for the suggestion. > > Note the code that adds _LP64 for the JVM (below): > > if test "x$FLAGS_OS" != xaix; then > # xlc on AIX defines _LP64=1 by default and issues a warning if we redefine it. > $1_DEFINES_CPU_JVM="${$1_DEFINES_CPU_JVM} -D_LP64=1" > fi > > So, it seems xlc/aix explicitly does _not_ want this macro defined? > > I think we could reuse that if-block to add `-D_LP64=` to both `1_DEFINES_CPU_JDK`, and `1_DEFINES_CPU_JVM` though, and remove the first one that checks for linux/mac/windows. Yes, that sounds good. I did not notice this (still not used to github reviews, which I think has too little context by default). ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From ccheung at openjdk.java.net Tue Nov 3 19:36:54 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 3 Nov 2020 19:36:54 GMT Subject: Integrated: 8255239: The timezone of the hs_err_pid log file is corrupted in Japanese locale In-Reply-To: References: Message-ID: <_gE2UtCafaMFrp-Bm7D4t7T_xZ-3uhiLNyPmqYgTLss=.542e205e-34df-43c4-8cff-191fdb0e8257@github.com> On Mon, 2 Nov 2020 23:59:30 GMT, Calvin Cheung wrote: > Please review this simple fix by using the wide char version of strftime, i.e. wcsftime, to convert the timezone into a wide character string. After that, converting the wide character string back to multi-byte string before printing out the time and timezone. > > Testing: ran the test case in the bug report manually on: > > - Windows with ja, zh-tw, and en locales; > > - Linux and Mac OS with en locale. This pull request has now been integrated. Changeset: b46d73be Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/b46d73be Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod 8255239: The timezone of the hs_err_pid log file is corrupted in Japanese locale Reviewed-by: iklam, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/1023 From jvernee at openjdk.java.net Tue Nov 3 19:44:54 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 3 Nov 2020 19:44:54 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c In-Reply-To: References: <5RiTHvRKDKf0_Zr2ZQICloKttbvZc_osDtJ_ylpxfrw=.7fe27b37-78fa-47fc-b37b-4ecde950818a@github.com> Message-ID: On Tue, 3 Nov 2020 19:16:02 GMT, Magnus Ihse Bursie wrote: >> Thanks for the suggestion. >> >> Note the code that adds _LP64 for the JVM (below): >> >> if test "x$FLAGS_OS" != xaix; then >> # xlc on AIX defines _LP64=1 by default and issues a warning if we redefine it. >> $1_DEFINES_CPU_JVM="${$1_DEFINES_CPU_JVM} -D_LP64=1" >> fi >> >> So, it seems xlc/aix explicitly does _not_ want this macro defined? >> >> I think we could reuse that if-block to add `-D_LP64=` to both `1_DEFINES_CPU_JDK`, and `1_DEFINES_CPU_JVM` though, and remove the first one that checks for linux/mac/windows. > > Yes, that sounds good. I did not notice this (still not used to github reviews, which I think has too little context by default). Ok, will do. (FWIW, you can expand the context of the diff with the arrow buttons on the left side of the view. Above or below the line numbers) ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From ihse at openjdk.java.net Tue Nov 3 20:14:54 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 3 Nov 2020 20:14:54 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c In-Reply-To: References: <5RiTHvRKDKf0_Zr2ZQICloKttbvZc_osDtJ_ylpxfrw=.7fe27b37-78fa-47fc-b37b-4ecde950818a@github.com> Message-ID: On Tue, 3 Nov 2020 19:41:49 GMT, Jorn Vernee wrote: >> Yes, that sounds good. I did not notice this (still not used to github reviews, which I think has too little context by default). > > Ok, will do. (FWIW, you can expand the context of the diff with the arrow buttons on the left side of the view. Above or below the line numbers) (Yes, I know. I just didn't think that doing so would reveal anything about AIX. I just wish I had gotten a bit more context automatically.) ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From jvernee at openjdk.java.net Tue Nov 3 20:37:07 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 3 Nov 2020 20:37:07 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c [v2] In-Reply-To: References: Message-ID: > Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c > > This removes the reported warning. > > Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing). > > CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed. > > Testing: tier1-3 > > [1] https://bugs.openjdk.java.net/browse/JDK-8232022 Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - Collapse both _LP64 if blocks in flags-cflags.m4 - Use jlong.h macros instead of spinning new ones ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1017/files - new: https://git.openjdk.java.net/jdk/pull/1017/files/18e2507d..6309e2ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1017&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1017&range=00-01 Stats: 23 lines in 2 files changed: 1 ins; 12 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1017.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1017/head:pull/1017 PR: https://git.openjdk.java.net/jdk/pull/1017 From jvernee at openjdk.java.net Tue Nov 3 20:39:59 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 3 Nov 2020 20:39:59 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c [v2] In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 19:08:05 GMT, Jorn Vernee wrote: >> I knew this looks familiar. Look at [existing macros in jlong_md.h](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjava/jlong_md.h#L67-L81) and use/match them? There is a little difference in casting through `jint` in your code, while `jlong_md.h` does it via `int`. > > @shipilev Now that I look at the file you linked, it does look familiar to me as well. Must have copy-pasted it from my subconscious ;) > > Looks like this file is usable from the benchmark lib code as well, will try to switch. I've updated the PR with the following 2 changes: - Use the pre-exsiting macros from jlong.h to convert between jlong and pointer - Collapse the 2 if-blocks in flags-cflags.m4 for setting _LP64 into one ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From coleenp at openjdk.java.net Tue Nov 3 20:42:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 3 Nov 2020 20:42:58 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c [v2] In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 20:37:07 GMT, Jorn Vernee wrote: >> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c >> >> This removes the reported warning. >> >> Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing). >> >> CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed. >> >> Testing: tier1-3 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8232022 > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - Collapse both _LP64 if blocks in flags-cflags.m4 > - Use jlong.h macros instead of spinning new ones This looks better. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1017 From minqi at openjdk.java.net Tue Nov 3 20:45:55 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 3 Nov 2020 20:45:55 GMT Subject: RFR: 8255784: appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java test failed resulting in VM crash [v2] In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 19:11:13 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed vm_exit to vm_direct_exit to avoid shutdown check > > Marked as reviewed by iklam (Reviewer). @iklam @calvinccheung Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1040 From minqi at openjdk.java.net Tue Nov 3 20:55:56 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 3 Nov 2020 20:55:56 GMT Subject: Integrated: 8255784: appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java test failed resulting in VM crash In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 17:12:06 GMT, Yumin Qi wrote: > Please review this simple change. > The crash is caused by vm_exit_during_initialization which calls vm_exit, the latter will go check vm shutdown procedures. The shutdown checks thread and lock state, finds inconsistent state so the check fails. Here we could just use vm_direct_exit with some message as the process terminated. vm_direct_exit just calls os::exit which quits without generating a coredump. > > Tests: tier1-4 > > Thanks > Yumin This pull request has now been integrated. Changeset: cdf9cd8a Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/cdf9cd8a Stats: 19 lines in 4 files changed: 10 ins; 0 del; 9 mod 8255784: appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java test failed resulting in VM crash Reviewed-by: ccheung, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/1040 From redestad at openjdk.java.net Tue Nov 3 20:58:55 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 3 Nov 2020 20:58:55 GMT Subject: RFR: 8255838: Use 32-bit immediate movslq in macro assembler if 64-bit value fits in 32 bits on x86_64 In-Reply-To: References: Message-ID: <0nRtpc9CMUyecx2YmnF0bCbdUXe4KvMFFdfpbCx7Z08=.7ea1fd92-809a-4c84-adbb-1ab07701b4e2@github.com> On Tue, 3 Nov 2020 15:12:50 GMT, Jorn Vernee wrote: > Currently, Macro::Assembler(Address dst, intprt_t src) on x64 uses an intermediate scratch register to store the 64-bit immediate. > > void MacroAssembler::movptr(Address dst, intptr_t src) { > mov64(rscratch1, src); > movq(dst, rscratch1); > } > > But, if the value fits into 32-bits, we can also explicitly use the 32-bit immediate overload, which saves an instruction and a register use, by using movslq/movabs instead (sig extended move). > > This ends up saving about 90k instructions on hello world. It also reduces the size of the interpreter by about 4k. > > Special thanks to Claes for prior discussion and help with testing. > > Testing: tier1-3, local startup profiling Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1038 From patricio.chilano.mateo at oracle.com Tue Nov 3 21:08:34 2020 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Tue, 3 Nov 2020 16:08:34 -0500 Subject: Biased locking Obsoletion Message-ID: Hi all, As discussed in 8231264, the idea was to switch biased locking to false by default and deprecate all related flags with the intent to remove the code in a future release unless compelling evidence showed that the code is worth maintaining. I see there is only one issue that was filed since biased locking was disabled by default (https://github.com/openjdk/jdk/pull/542) that seems to have been addressed. As per 8231264 change, the code was set to be obsoleted in 16, so we are already in a position to remove biased locking code unless there are arguments for the contrary. The alternative would be to give more time and move biased locking obsoletion to a future release. Let me know your thoughts. Thanks, Patricio From david.holmes at oracle.com Tue Nov 3 21:30:29 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Nov 2020 07:30:29 +1000 Subject: Biased locking Obsoletion In-Reply-To: References: Message-ID: <7ca651a8-5861-92cf-5d31-6a7fd09700c6@oracle.com> Expanding to hotspot-dev. On 4/11/2020 7:08 am, Patricio Chilano wrote: > Hi all, > > As discussed in 8231264, the idea was to switch biased locking to false > by default and deprecate all related flags with the intent to remove the > code in a future release unless compelling evidence showed that the code > is worth maintaining. > I see there is only one issue that was filed since biased locking was > disabled by default (https://github.com/openjdk/jdk/pull/542) that seems > to have been addressed. As per 8231264 change, the code was set to be > obsoleted in 16, so we are already in a position to remove biased > locking code unless there are arguments for the contrary. The > alternative would be to give more time and move biased locking > obsoletion to a future release. > Let me know your thoughts. > > Thanks, > > Patricio From david.holmes at oracle.com Tue Nov 3 21:56:27 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 Nov 2020 07:56:27 +1000 Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v2] In-Reply-To: References: Message-ID: <34fd9c37-2377-5e0a-358d-4ecbc28db688@oracle.com> On 4/11/2020 3:02 am, Patricio Chilano Mateo wrote: > On Tue, 3 Nov 2020 02:32:07 GMT, David Holmes wrote: > >> This seems functionally fine, but it still seems to me that we are missing a Safepoint or SafepointMechanism API helper method that does: >> >> ``` >> SafepointMechanism::process_if_requested(THREAD); >> if (THREAD->has_special_runtime_exit_condition()) { >> THREAD->handle_special_runtime_exit_condition(checkAsyncs); >> } >> ``` >> >> Lets see if others have an opinion. >> Thanks. > > How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)? That works for me. Thanks, David ----- >> src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 112: >> >>> 110: CALL_VM(SafepointMechanism::process_if_requested(THREAD); \ >>> 111: if (THREAD->has_special_runtime_exit_condition()) { \ >>> 112: THREAD->handle_special_runtime_exit_condition(); \ >> >> Please add explicit arg: "(true /* check asyncs */)" >> >> Using a multi-statement code block for the CALL_VM macro looks odd to me, but I find these zero macros unpleasant to begin with. > > Yes, that's also why I liked better the TIVFJ wrapper. But if we can agree on the helper method then that would change to a single line. > >> src/hotspot/share/runtime/safepoint.cpp line 936: >> >>> 934: SafepointMechanism::process_if_requested(self); >>> 935: if (self->has_special_runtime_exit_condition()) { >>> 936: self->handle_special_runtime_exit_condition(); >> >> Please add explicit arg: "(true /* check asyncs */)" > > Added. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/913 > From ihse at openjdk.java.net Tue Nov 3 22:14:57 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 3 Nov 2020 22:14:57 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c [v2] In-Reply-To: References: Message-ID: <_DhMz8Zb2ZoH9S-_MSX5VClHyGfdLhcj4aSl5L2mIS8=.9f7e6452-4171-48c2-8340-ccba15cf0407@github.com> On Tue, 3 Nov 2020 20:37:07 GMT, Jorn Vernee wrote: >> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c >> >> This removes the reported warning. >> >> Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing). >> >> CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed. >> >> Testing: tier1-3 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8232022 > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - Collapse both _LP64 if blocks in flags-cflags.m4 > - Use jlong.h macros instead of spinning new ones Looks good to me now. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1017 From kirk at kodewerk.com Wed Nov 4 00:13:57 2020 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Tue, 3 Nov 2020 16:13:57 -0800 Subject: Unified Logging for network In-Reply-To: References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> Message-ID: <091B2CEC-0FED-4E97-A500-C84CAE6451A3@kodewerk.com> Hi Thomas, I?m reading with interest.. and I?m thinking of submitting a small patch which I guess would need to be preceded with a JBS entry. Kind regards, Kirk > On Nov 3, 2020, at 12:12 AM, Thomas St?fe wrote: > > Hi Kirk, > > On Mon, Nov 2, 2020 at 8:10 PM Kirk Pepperdine wrote: > >> Hi Thomas, >> >> I appreciate Yasumasa?s desire to be able to redirect UL output to >> somewhere other than? I also appreciate that the highly granular nature of >> how UL messages are currently structure can be and indeed are an issue. >> That said, I?d also like the ability to push the data to some where other >> than a file on disk. >> >> To the point of granularity, UL might benefit from some message >> coarsening. This might also help in with other logging related performance >> issues that I?ve noted here and there. Quite frankly dealing with logs in >> containers isn?t a wonderful experience. And while I firmly believe that >> there is more that containers can do to ease this, being able to redirect >> output to something other than a log file does feel like it would be >> helpful. That said, I?m also concerned about the potential performance >> impacts but I think for this things that one would generally log, this >> should be minimal. >> > > About this proposal, see my answer to Yasumasa. > > About UL granularity: feel free to raise concrete examples in JBS or on the > mailing lists! This is often not that difficult to fix. > > Kind Regards, Thomas > > >> >> Kind regards, >> Kirk Pepperdine >> >> >>> On Nov 2, 2020, at 4:26 AM, Thomas St?fe >> wrote: >>> >>> Hi Yasumasa, >>> >>> one problem I see is that this could introduce a surprising amount of lag >>> into log() calls which do look inconspicuous, thereby distorting timing >>> behavior or even create timeout effects. We already have that problem now >>> to some degree when logging to network shares. >>> >>> Another thing, log output can be very fine granular, which would create a >>> lot of network traffic. >>> >>> Such an addition may also open some security questions. >>> >>> From a more philosophical standpoint, I like the "do one thing and do it >>> right" Unix way and this seems more like something an outside tool should >>> be doing. Which could also aggregate log output better. But I admit that >>> argument is weak. >>> >>> Cheers, Thomas >>> >>> >>> >>> On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga < >> suenaga at oss.nttdata.com> >>> wrote: >>> >>>> Hi all, >>>> >>>> We need to out UL to stdout and/or file. If we can out it to TCP >> socket, I >>>> think it is useful. >>>> >>>> For example, some system gather all logs to document oriented databases >>>> (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. >> CloudWatch). If >>>> HotSpot can out UL to TCP socket, we can send all logs to them via TCP >>>> input plugin (Fluentd, Logstash). >>>> >>>> I think it is useful for container platform. What do you think? >>>> If it is worth to work, I will add CSR and JBS ticket, and also will >>>> create patch. >>>> >> >> From suenaga at oss.nttdata.com Wed Nov 4 01:32:04 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 4 Nov 2020 10:32:04 +0900 Subject: Unified Logging for network In-Reply-To: References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> <41f33608-63de-c7cb-e135-13a6fcc39b05@oracle.com> Message-ID: Hi Thomas, On 2020/11/03 17:09, Thomas St?fe wrote: > Hi Yasumasa, > > I don't argue that such a feature would not be useful. Of course it would! > > But as with any other added feature, it will come at the cost of complexity. It will have to be maintained, tests will have to be written and run. That increases technical debt for us all. > > That is not a reason not to do it, but to think before doing it and exploring alternatives. > > -- > > To me, the fact that a logging call now could possibly do Network IO fills me with deep unease. It violates the principle of least surprise. Logging should be as basic as possible, in order to be usable anywhere in code. > > - as had been said before, it would introduce unpredictable timing behavior. The fact that we have this already today is not a big consolation :( > > - similar to "the User should know what he does" argument - unfortunately many don't, so a balance has to be found to limit support from these cases I agree with you. So I want to hear various opinions before submitting RFE :) I want to find "balance" in this discussion. > - AFAICS we do not do network IO anywhere in the hotspot today. That coding would have to be written and tested. Reusing some other code - e.g. from the corelibs - is out of question for such a low level API, since you don't want to risk circularities. Debug VM has networkStream which is used for Ideal Graph Visualizer. I guess we can use it (or similar implementation) for this purpose. We cannot use Java Socket API because UL would out at safepoint (e.g. GC logs) > - But now we have a complete network stack below the innocuous logging call. This imposes further restrictions on where we can log - eg even if it were possible before, logging from signal handling is impossible now. Without these restrictions documented and tested anywhere. To me this makes UL more and more questionable, and I already tend to shun it when possible in favour of plain tty printing. I think UL should be used for most of HotSpot logs, however some critical errors (e.g. at signal handler) should be used tty printing. UL is useful for log management (e.g. log rotation) > I argued yesterday against Ioi's concurrent-log-draining, but that is actually more attractive the more I think about it. > > Only, could the same not be achieved with piping stdout/err to a separate tool like netcat, as Leo suggested? > > That solution exists today. If netcat does not do it for you, this could also be a separate utility - could be even part of the jdk. Conceptually this would be much the same as a separate thread printing out UL, with the pipe size being the buffer size. Or, communication could happen via shared memory... > > This would have two distinct advantages over doing network IO in UL: > - we see the whole stderr output (e.g. output from the libc, or any third party tools) > - we see output also from a VM which crashed and burned. E.g. any last words from hs-err reporting. Now we can use netcat/logstash/fluentd, however I don't use stdout/stderr because application and/or libraries, frameworks might print some messages (includes exception call stacks) into it. It makes difficult to parse log lines. And also I don't want to use UL files for it because it should be one log file (should not rotate), so file size might be large. Cheers, Yasumasa > Cheers, Thomas > > > On Tue, Nov 3, 2020 at 3:12 AM Yasumasa Suenaga > wrote: > > Hi, > > I agree this proposal might occur performance issue. However I think it is the responsibility of the user. > If this proposal is implemented, I think it would be transferred to local log shipper process (fluentd, logstash on 127.0.0.1) in most case because HotSpot does not send log with JSON. And also log shipper may support message buffering and message queue persistence. > We can avoid (in part of) performance/reliability issues with log shipper. > > Even if current implementation, performance issues is occurs when the disk is very slow (e.g. storage is broken). > > > Cheers, > > Yasumasa > > > On 2020/11/03 6:31, Thomas St?fe wrote: > > Hi Ioi, > > > > I dimly remember proposals like this from the past. Main problem I see is > > how large would you dimension the buffer, and what do you do if the buffer > > cannot be drained rapidly enough. Discard log output? Hold? The former > > sounds bad, the latter negates the advantages of such a buffer. > > > > Then, access to such a buffer would probably have to be synchronized, > > whereas today AFAIK the log calls do not have to be. > > > > Cheers, Thomas > > > > On Mon 2. Nov 2020 at 22:18, Ioi Lam > wrote: > > > >> For performance, maybe the implementation can log into a memory buffer, > >> and use a worker thread to send the output over the network? That way we > >> can minimize the overhead per log_xxx() call. > >> > >> I agree that using "-Xlog:foo=debug:network=xyz.com:1234 " would be quite > >> handy when you have lots of containers. You don't need to enable remote > >> access to the container's file system just to get to the log file. > >> > >> Thanks > >> - Ioi > >> > >> On 11/2/20 11:10 AM, Kirk Pepperdine wrote: > >>> Hi Thomas, > >>> > >>> I appreciate Yasumasa?s desire to be able to redirect UL output to > >> somewhere other than? I also appreciate that the highly granular nature of > >> how UL messages are currently structure can be and indeed are an issue. > >> That said, I?d also like the ability to push the data to some where other > >> than a file on disk. > >>> > >>> To the point of granularity, UL might benefit from some message > >> coarsening. This might also help in with other logging related performance > >> issues that I?ve noted here and there. Quite frankly dealing with logs in > >> containers isn?t a wonderful experience. And while I firmly believe that > >> there is more that containers can do to ease this, being able to redirect > >> output to something other than a log file does feel like it would be > >> helpful. That said, I?m also concerned about the potential performance > >> impacts but I think for this things that one would generally log, this > >> should be minimal. > >>> > >>> Kind regards, > >>> Kirk Pepperdine > >>> > >>> > >>>> On Nov 2, 2020, at 4:26 AM, Thomas St?fe > > >> wrote: > >>>> > >>>> Hi Yasumasa, > >>>> > >>>> one problem I see is that this could introduce a surprising amount of > >> lag > >>>> into log() calls which do look inconspicuous, thereby distorting timing > >>>> behavior or even create timeout effects. We already have that problem > >> now > >>>> to some degree when logging to network shares. > >>>> > >>>> Another thing, log output can be very fine granular, which would create > >> a > >>>> lot of network traffic. > >>>> > >>>> Such an addition may also open some security questions. > >>>> > >>>>? ?From a more philosophical standpoint, I like the "do one thing and do > >> it > >>>> right" Unix way and this seems more like something an outside tool > >> should > >>>> be doing. Which could also aggregate log output better. But I admit that > >>>> argument is weak. > >>>> > >>>> Cheers, Thomas > >>>> > >>>> > >>>> > >>>> On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga < > >> suenaga at oss.nttdata.com > > >>>> wrote: > >>>> > >>>>> Hi all, > >>>>> > >>>>> We need to out UL to stdout and/or file. If we can out it to TCP > >> socket, I > >>>>> think it is useful. > >>>>> > >>>>> For example, some system gather all logs to document oriented databases > >>>>> (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. > >> CloudWatch). If > >>>>> HotSpot can out UL to TCP socket, we can send all logs to them via TCP > >>>>> input plugin (Fluentd, Logstash). > >>>>> > >>>>> I think it is useful for container platform. What do you think? > >>>>> If it is worth to work, I will add CSR and JBS ticket, and also will > >>>>> create patch. > >>>>> > >> > >> > From suenaga at oss.nttdata.com Wed Nov 4 01:38:51 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 4 Nov 2020 10:38:51 +0900 Subject: Unified Logging for network In-Reply-To: <445f898e-bcf4-4a24-9b97-43891d5429ea@oracle.com> References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> <41f33608-63de-c7cb-e135-13a6fcc39b05@oracle.com> <445f898e-bcf4-4a24-9b97-43891d5429ea@oracle.com> Message-ID: Hi Robbin, On 2020/11/04 0:49, Robbin Ehn wrote: > Hi, > > Since e.g. syslog-ng already can do all of this and much more, and it > can collect from text files, why not just do that? > > Any serious setup would already have configured syslog to e.g. logstash > server. You just need to tell it to collect from the UL configured > file(s) also. > > ? As I said in reply to Thomas [1], I don't want to dump UL to files because it should be one log file (should not rotate), so file size might be large. It might occur problems in disk usage in container. Thanks, Yasumasa [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043342.html > /Robbin > > On 2020-11-03 09:09, Thomas St?fe wrote: >> Hi Yasumasa, >> >> I don't argue that such a feature would not be useful. Of course it would! >> >> But as with any other added feature, it will come at the cost of >> complexity. It will have to be maintained, tests will have to be written >> and run. That increases technical debt for us all. >> >> That is not a reason not to do it, but to think before doing it and >> exploring alternatives. >> >> -- >> >> To me, the fact that a logging call now could possibly do Network IO fills >> me with deep unease. It violates the principle of least surprise. Logging >> should be as basic as possible, in order to be usable anywhere in code. >> >> - as had been said before, it would introduce unpredictable timing >> behavior. The fact that we have this already today is not a big consolation >> :( >> >> - similar to "the User should know what he does" argument - unfortunately >> many don't, so a balance has to be found to limit support from these cases >> >> - AFAICS we do not do network IO anywhere in the hotspot today. That coding >> would have to be written and tested. Reusing some other code - e.g. from >> the corelibs - is out of question for such a low level API, since you don't >> want to risk circularities. >> >> - But now we have a complete network stack below the innocuous logging >> call. This imposes further restrictions on where we can log - eg even if it >> were possible before, logging from signal handling is impossible now. >> Without these restrictions documented and tested anywhere. To me this makes >> UL more and more questionable, and I already tend to shun it when possible >> in favour of plain tty printing. >> >> I argued yesterday against Ioi's concurrent-log-draining, but that is >> actually more attractive the more I think about it. >> >> Only, could the same not be achieved with piping stdout/err to a separate >> tool like netcat, as Leo suggested? >> >> That solution exists today. If netcat does not do it for you, this could >> also be a separate utility - could be even part of the jdk. Conceptually >> this would be much the same as a separate thread printing out UL, with the >> pipe size being the buffer size. Or, communication could happen via shared >> memory... >> >> This would have two distinct advantages over doing network IO in UL: >> - we see the whole stderr output (e.g. output from the libc, or any third >> party tools) >> - we see output also from a VM which crashed and burned. E.g. any last >> words from hs-err reporting. >> >> Cheers, Thomas >> >> >> On Tue, Nov 3, 2020 at 3:12 AM Yasumasa Suenaga >> wrote: >> >>> Hi, >>> >>> I agree this proposal might occur performance issue. However I think it is >>> the responsibility of the user. >>> If this proposal is implemented, I think it would be transferred to local >>> log shipper process (fluentd, logstash on 127.0.0.1) in most case because >>> HotSpot does not send log with JSON. And also log shipper may support >>> message buffering and message queue persistence. >>> We can avoid (in part of) performance/reliability issues with log shipper. >>> >>> Even if current implementation, performance issues is occurs when the disk >>> is very slow (e.g. storage is broken). >>> >>> >>> Cheers, >>> >>> Yasumasa >>> >>> >>> On 2020/11/03 6:31, Thomas St?fe wrote: >>>> Hi Ioi, >>>> >>>> I dimly remember proposals like this from the past. Main problem I see is >>>> how large would you dimension the buffer, and what do you do if the >>> buffer >>>> cannot be drained rapidly enough. Discard log output? Hold? The former >>>> sounds bad, the latter negates the advantages of such a buffer. >>>> >>>> Then, access to such a buffer would probably have to be synchronized, >>>> whereas today AFAIK the log calls do not have to be. >>>> >>>> Cheers, Thomas >>>> >>>> On Mon 2. Nov 2020 at 22:18, Ioi Lam wrote: >>>> >>>>> For performance, maybe the implementation can log into a memory buffer, >>>>> and use a worker thread to send the output over the network? That way we >>>>> can minimize the overhead per log_xxx() call. >>>>> >>>>> I agree that using "-Xlog:foo=debug:network=xyz.com:1234" would be >>> quite >>>>> handy when you have lots of containers. You don't need to enable remote >>>>> access to the container's file system just to get to the log file. >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>> On 11/2/20 11:10 AM, Kirk Pepperdine wrote: >>>>>> Hi Thomas, >>>>>> >>>>>> I appreciate Yasumasa?s desire to be able to redirect UL output to >>>>> somewhere other than? I also appreciate that the highly granular nature >>> of >>>>> how UL messages are currently structure can be and indeed are an issue. >>>>> That said, I?d also like the ability to push the data to some where >>> other >>>>> than a file on disk. >>>>>> >>>>>> To the point of granularity, UL might benefit from some message >>>>> coarsening. This might also help in with other logging related >>> performance >>>>> issues that I?ve noted here and there. Quite frankly dealing with logs >>> in >>>>> containers isn?t a wonderful experience. And while I firmly believe that >>>>> there is more that containers can do to ease this, being able to >>> redirect >>>>> output to something other than a log file does feel like it would be >>>>> helpful. That said, I?m also concerned about the potential performance >>>>> impacts but I think for this things that one would generally log, this >>>>> should be minimal. >>>>>> >>>>>> Kind regards, >>>>>> Kirk Pepperdine >>>>>> >>>>>> >>>>>>> On Nov 2, 2020, at 4:26 AM, Thomas St?fe >>>>> wrote: >>>>>>> >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> one problem I see is that this could introduce a surprising amount of >>>>> lag >>>>>>> into log() calls which do look inconspicuous, thereby distorting >>> timing >>>>>>> behavior or even create timeout effects. We already have that problem >>>>> now >>>>>>> to some degree when logging to network shares. >>>>>>> >>>>>>> Another thing, log output can be very fine granular, which would >>> create >>>>> a >>>>>>> lot of network traffic. >>>>>>> >>>>>>> Such an addition may also open some security questions. >>>>>>> >>>>>>> ?? From a more philosophical standpoint, I like the "do one thing and >>> do >>>>> it >>>>>>> right" Unix way and this seems more like something an outside tool >>>>> should >>>>>>> be doing. Which could also aggregate log output better. But I admit >>> that >>>>>>> argument is weak. >>>>>>> >>>>>>> Cheers, Thomas >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga < >>>>> suenaga at oss.nttdata.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> We need to out UL to stdout and/or file. If we can out it to TCP >>>>> socket, I >>>>>>>> think it is useful. >>>>>>>> >>>>>>>> For example, some system gather all logs to document oriented >>> databases >>>>>>>> (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. >>>>> CloudWatch). If >>>>>>>> HotSpot can out UL to TCP socket, we can send all logs to them via >>> TCP >>>>>>>> input plugin (Fluentd, Logstash). >>>>>>>> >>>>>>>> I think it is useful for container platform. What do you think? >>>>>>>> If it is worth to work, I will add CSR and JBS ticket, and also will >>>>>>>> create patch. >>>>>>>> >>>>> >>>>> >>> From thartmann at openjdk.java.net Wed Nov 4 07:20:56 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 4 Nov 2020 07:20:56 GMT Subject: RFR: 8255838: Use 32-bit immediate movslq in macro assembler if 64-bit value fits in 32 bits on x86_64 In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 15:12:50 GMT, Jorn Vernee wrote: > Currently, Macro::Assembler(Address dst, intprt_t src) on x64 uses an intermediate scratch register to store the 64-bit immediate. > > void MacroAssembler::movptr(Address dst, intptr_t src) { > mov64(rscratch1, src); > movq(dst, rscratch1); > } > > But, if the value fits into 32-bits, we can also explicitly use the 32-bit immediate overload, which saves an instruction and a register use, by using movslq/movabs instead (sig extended move). > > This ends up saving about 90k instructions on hello world. It also reduces the size of the interpreter by about 4k. > > Special thanks to Claes for prior discussion and help with testing. > > Testing: tier1-3, local startup profiling Marked as reviewed by thartmann (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1038 From robbin.ehn at oracle.com Wed Nov 4 08:12:22 2020 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 4 Nov 2020 09:12:22 +0100 Subject: Unified Logging for network In-Reply-To: References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> <41f33608-63de-c7cb-e135-13a6fcc39b05@oracle.com> <445f898e-bcf4-4a24-9b97-43891d5429ea@oracle.com> Message-ID: <8a09ad25-8181-3705-adcb-d4bead1428fc@oracle.com> Hi, Yasumasa, On 2020-11-04 02:38, Yasumasa Suenaga wrote: > As I said in reply to Thomas [1], I don't want to dump UL to files > because it should be one log file (should not rotate), so file size > might be large. > It might occur problems in disk usage in container. Sorry I don't follow, so I'm guessing here what you mean. The direct output from UL is only used by syslog, so something like: "-Xlog:all=error:file=my_vm.%p.log::filecount=2,filesize=1m" should be fine. - Use syslog to collect from my_vm.*.log.* - Configure syslog to output both to that one large file you mentioned and over network to your e.g. elastic search. If this is not sufficient then implementation syslog/windows event log is much better and simpler alternative, as also mentioned in JEP: https://openjdk.java.net/jeps/158 E.g. "-Xlog:all=error:syslog=my_vm" Thanks, Robbin > > > Thanks, > > Yasumasa > > > [1] > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043342.html > > > >> /Robbin >> >> On 2020-11-03 09:09, Thomas St?fe wrote: >>> Hi Yasumasa, >>> >>> I don't argue that such a feature would not be useful. Of course it >>> would! >>> >>> But as with any other added feature, it will come at the cost of >>> complexity. It will have to be maintained, tests will have to be written >>> and run. That increases technical debt for us all. >>> >>> That is not a reason not to do it, but to think before doing it and >>> exploring alternatives. >>> >>> -- >>> >>> To me, the fact that a logging call now could possibly do Network IO >>> fills >>> me with deep unease. It violates the principle of least surprise. >>> Logging >>> should be as basic as possible, in order to be usable anywhere in code. >>> >>> - as had been said before, it would introduce unpredictable timing >>> behavior. The fact that we have this already today is not a big >>> consolation >>> :( >>> >>> - similar to "the User should know what he does" argument - >>> unfortunately >>> many don't, so a balance has to be found to limit support from these >>> cases >>> >>> - AFAICS we do not do network IO anywhere in the hotspot today. That >>> coding >>> would have to be written and tested. Reusing some other code - e.g. from >>> the corelibs - is out of question for such a low level API, since you >>> don't >>> want to risk circularities. >>> >>> - But now we have a complete network stack below the innocuous logging >>> call. This imposes further restrictions on where we can log - eg even >>> if it >>> were possible before, logging from signal handling is impossible now. >>> Without these restrictions documented and tested anywhere. To me this >>> makes >>> UL more and more questionable, and I already tend to shun it when >>> possible >>> in favour of plain tty printing. >>> >>> I argued yesterday against Ioi's concurrent-log-draining, but that is >>> actually more attractive the more I think about it. >>> >>> Only, could the same not be achieved with piping stdout/err to a >>> separate >>> tool like netcat, as Leo suggested? >>> >>> That solution exists today. If netcat does not do it for you, this could >>> also be a separate utility - could be even part of the jdk. Conceptually >>> this would be much the same as a separate thread printing out UL, >>> with the >>> pipe size being the buffer size. Or, communication could happen via >>> shared >>> memory... >>> >>> This would have two distinct advantages over doing network IO in UL: >>> - we see the whole stderr output (e.g. output from the libc, or any >>> third >>> party tools) >>> - we see output also from a VM which crashed and burned. E.g. any last >>> words from hs-err reporting. >>> >>> Cheers, Thomas >>> >>> >>> On Tue, Nov 3, 2020 at 3:12 AM Yasumasa Suenaga >>> >>> wrote: >>> >>>> Hi, >>>> >>>> I agree this proposal might occur performance issue. However I think >>>> it is >>>> the responsibility of the user. >>>> If this proposal is implemented, I think it would be transferred to >>>> local >>>> log shipper process (fluentd, logstash on 127.0.0.1) in most case >>>> because >>>> HotSpot does not send log with JSON. And also log shipper may support >>>> message buffering and message queue persistence. >>>> We can avoid (in part of) performance/reliability issues with log >>>> shipper. >>>> >>>> Even if current implementation, performance issues is occurs when >>>> the disk >>>> is very slow (e.g. storage is broken). >>>> >>>> >>>> Cheers, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/11/03 6:31, Thomas St?fe wrote: >>>>> Hi Ioi, >>>>> >>>>> I dimly remember proposals like this from the past. Main problem I >>>>> see is >>>>> how large would you dimension the buffer, and what do you do if the >>>> buffer >>>>> cannot be drained rapidly enough. Discard log output? Hold? The former >>>>> sounds bad, the latter negates the advantages of such a buffer. >>>>> >>>>> Then, access to such a buffer would probably have to be synchronized, >>>>> whereas today AFAIK the log calls do not have to be. >>>>> >>>>> Cheers, Thomas >>>>> >>>>> On Mon 2. Nov 2020 at 22:18, Ioi Lam wrote: >>>>> >>>>>> For performance, maybe the implementation can log into a memory >>>>>> buffer, >>>>>> and use a worker thread to send the output over the network? That >>>>>> way we >>>>>> can minimize the overhead per log_xxx() call. >>>>>> >>>>>> I agree that using "-Xlog:foo=debug:network=xyz.com:1234" would be >>>> quite >>>>>> handy when you have lots of containers. You don't need to enable >>>>>> remote >>>>>> access to the container's file system just to get to the log file. >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>>>> >>>>>> On 11/2/20 11:10 AM, Kirk Pepperdine wrote: >>>>>>> Hi Thomas, >>>>>>> >>>>>>> I appreciate Yasumasa?s desire to be able to redirect UL output to >>>>>> somewhere other than? I also appreciate that the highly granular >>>>>> nature >>>> of >>>>>> how UL messages are currently structure can be and indeed are an >>>>>> issue. >>>>>> That said, I?d also like the ability to push the data to some where >>>> other >>>>>> than a file on disk. >>>>>>> >>>>>>> To the point of granularity, UL might benefit from some message >>>>>> coarsening. This might also help in with other logging related >>>> performance >>>>>> issues that I?ve noted here and there. Quite frankly dealing with >>>>>> logs >>>> in >>>>>> containers isn?t a wonderful experience. And while I firmly >>>>>> believe that >>>>>> there is more that containers can do to ease this, being able to >>>> redirect >>>>>> output to something other than a log file does feel like it would be >>>>>> helpful. That said, I?m also concerned about the potential >>>>>> performance >>>>>> impacts but I think for this things that one would generally log, >>>>>> this >>>>>> should be minimal. >>>>>>> >>>>>>> Kind regards, >>>>>>> Kirk Pepperdine >>>>>>> >>>>>>> >>>>>>>> On Nov 2, 2020, at 4:26 AM, Thomas St?fe >>>>>> wrote: >>>>>>>> >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> one problem I see is that this could introduce a surprising >>>>>>>> amount of >>>>>> lag >>>>>>>> into log() calls which do look inconspicuous, thereby distorting >>>> timing >>>>>>>> behavior or even create timeout effects. We already have that >>>>>>>> problem >>>>>> now >>>>>>>> to some degree when logging to network shares. >>>>>>>> >>>>>>>> Another thing, log output can be very fine granular, which would >>>> create >>>>>> a >>>>>>>> lot of network traffic. >>>>>>>> >>>>>>>> Such an addition may also open some security questions. >>>>>>>> >>>>>>>> ?? From a more philosophical standpoint, I like the "do one >>>>>>>> thing and >>>> do >>>>>> it >>>>>>>> right" Unix way and this seems more like something an outside tool >>>>>> should >>>>>>>> be doing. Which could also aggregate log output better. But I admit >>>> that >>>>>>>> argument is weak. >>>>>>>> >>>>>>>> Cheers, Thomas >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga < >>>>>> suenaga at oss.nttdata.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> We need to out UL to stdout and/or file. If we can out it to TCP >>>>>> socket, I >>>>>>>>> think it is useful. >>>>>>>>> >>>>>>>>> For example, some system gather all logs to document oriented >>>> databases >>>>>>>>> (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. >>>>>> CloudWatch). If >>>>>>>>> HotSpot can out UL to TCP socket, we can send all logs to them via >>>> TCP >>>>>>>>> input plugin (Fluentd, Logstash). >>>>>>>>> >>>>>>>>> I think it is useful for container platform. What do you think? >>>>>>>>> If it is worth to work, I will add CSR and JBS ticket, and also >>>>>>>>> will >>>>>>>>> create patch. >>>>>>>>> >>>>>> >>>>>> >>>> From shade at openjdk.java.net Wed Nov 4 09:23:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 4 Nov 2020 09:23:59 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c [v2] In-Reply-To: References: Message-ID: <0kIzU7Og4dKHYW1mYDOFf83yXJ4eUwnNax-ljOF2ap0=.ad40cac6-689d-4d27-98a7-77aa24d291d2@github.com> On Tue, 3 Nov 2020 20:37:07 GMT, Jorn Vernee wrote: >> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c >> >> This removes the reported warning. >> >> Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing). >> >> CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed. >> >> Testing: tier1-3 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8232022 > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - Collapse both _LP64 if blocks in flags-cflags.m4 > - Use jlong.h macros instead of spinning new ones Yup, using `jlong.h` looks much better. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1017 From simonis at openjdk.java.net Wed Nov 4 09:34:05 2020 From: simonis at openjdk.java.net (Volker Simonis) Date: Wed, 4 Nov 2020 09:34:05 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c [v2] In-Reply-To: References: <5RiTHvRKDKf0_Zr2ZQICloKttbvZc_osDtJ_ylpxfrw=.7fe27b37-78fa-47fc-b37b-4ecde950818a@github.com> Message-ID: On Tue, 3 Nov 2020 20:12:35 GMT, Magnus Ihse Bursie wrote: >> Ok, will do. (FWIW, you can expand the context of the diff with the arrow buttons on the left side of the view. Above or below the line numbers) > > (Yes, I know. I just didn't think that doing so would reveal anything about AIX. I just wish I had gotten a bit more context automatically.) Sorry, but I'm neither workin on AIX any more nor do I have access to an AIX machine :) Pulling in @TheRealMDoerr or @tstuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From suenaga at oss.nttdata.com Wed Nov 4 10:06:24 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 4 Nov 2020 19:06:24 +0900 Subject: Unified Logging for network In-Reply-To: <8a09ad25-8181-3705-adcb-d4bead1428fc@oracle.com> References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> <41f33608-63de-c7cb-e135-13a6fcc39b05@oracle.com> <445f898e-bcf4-4a24-9b97-43891d5429ea@oracle.com> <8a09ad25-8181-3705-adcb-d4bead1428fc@oracle.com> Message-ID: <3d860cd2-20ba-6fb3-188e-cd71cacf9426@oss.nttdata.com> Hi Robbin, On 2020/11/04 17:12, Robbin Ehn wrote: > Hi, Yasumasa, > > On 2020-11-04 02:38, Yasumasa Suenaga wrote: >> As I said in reply to Thomas [1], I don't want to dump UL to files because it should be one log file (should not rotate), so file size might be large. >> It might occur problems in disk usage in container. > > Sorry I don't follow, so I'm guessing here what you mean. > > The direct output from UL is only used by syslog, so something like: > "-Xlog:all=error:file=my_vm.%p.log::filecount=2,filesize=1m" should be > fine. > - Use syslog to collect from my_vm.*.log.* IIUC we need to set "my_vm.log.current" to text source in syslog-ng in this solution. However my-vm.log.current would be reopened when log rotation is happen, so syslog-ng might not follow current log. To follow all logs, we should not set log rotation, and log file would be large. > - Configure syslog to output both to that one large file you mentioned > and over network to your e.g. elastic search. > > If this is not sufficient then implementation syslog/windows event log is much better and simpler alternative, as also mentioned in JEP: > https://openjdk.java.net/jeps/158 > > E.g. > > "-Xlog:all=error:syslog=my_vm" "Future possible extensions" JEP 158 mentions socket output as a backend. I think this proposal is same with it. Thanks, Yasumasa > Thanks, Robbin > > >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043342.html >> >> >>> /Robbin >>> >>> On 2020-11-03 09:09, Thomas St?fe wrote: >>>> Hi Yasumasa, >>>> >>>> I don't argue that such a feature would not be useful. Of course it would! >>>> >>>> But as with any other added feature, it will come at the cost of >>>> complexity. It will have to be maintained, tests will have to be written >>>> and run. That increases technical debt for us all. >>>> >>>> That is not a reason not to do it, but to think before doing it and >>>> exploring alternatives. >>>> >>>> -- >>>> >>>> To me, the fact that a logging call now could possibly do Network IO fills >>>> me with deep unease. It violates the principle of least surprise. Logging >>>> should be as basic as possible, in order to be usable anywhere in code. >>>> >>>> - as had been said before, it would introduce unpredictable timing >>>> behavior. The fact that we have this already today is not a big consolation >>>> :( >>>> >>>> - similar to "the User should know what he does" argument - unfortunately >>>> many don't, so a balance has to be found to limit support from these cases >>>> >>>> - AFAICS we do not do network IO anywhere in the hotspot today. That coding >>>> would have to be written and tested. Reusing some other code - e.g. from >>>> the corelibs - is out of question for such a low level API, since you don't >>>> want to risk circularities. >>>> >>>> - But now we have a complete network stack below the innocuous logging >>>> call. This imposes further restrictions on where we can log - eg even if it >>>> were possible before, logging from signal handling is impossible now. >>>> Without these restrictions documented and tested anywhere. To me this makes >>>> UL more and more questionable, and I already tend to shun it when possible >>>> in favour of plain tty printing. >>>> >>>> I argued yesterday against Ioi's concurrent-log-draining, but that is >>>> actually more attractive the more I think about it. >>>> >>>> Only, could the same not be achieved with piping stdout/err to a separate >>>> tool like netcat, as Leo suggested? >>>> >>>> That solution exists today. If netcat does not do it for you, this could >>>> also be a separate utility - could be even part of the jdk. Conceptually >>>> this would be much the same as a separate thread printing out UL, with the >>>> pipe size being the buffer size. Or, communication could happen via shared >>>> memory... >>>> >>>> This would have two distinct advantages over doing network IO in UL: >>>> - we see the whole stderr output (e.g. output from the libc, or any third >>>> party tools) >>>> - we see output also from a VM which crashed and burned. E.g. any last >>>> words from hs-err reporting. >>>> >>>> Cheers, Thomas >>>> >>>> >>>> On Tue, Nov 3, 2020 at 3:12 AM Yasumasa Suenaga >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I agree this proposal might occur performance issue. However I think it is >>>>> the responsibility of the user. >>>>> If this proposal is implemented, I think it would be transferred to local >>>>> log shipper process (fluentd, logstash on 127.0.0.1) in most case because >>>>> HotSpot does not send log with JSON. And also log shipper may support >>>>> message buffering and message queue persistence. >>>>> We can avoid (in part of) performance/reliability issues with log shipper. >>>>> >>>>> Even if current implementation, performance issues is occurs when the disk >>>>> is very slow (e.g. storage is broken). >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2020/11/03 6:31, Thomas St?fe wrote: >>>>>> Hi Ioi, >>>>>> >>>>>> I dimly remember proposals like this from the past. Main problem I see is >>>>>> how large would you dimension the buffer, and what do you do if the >>>>> buffer >>>>>> cannot be drained rapidly enough. Discard log output? Hold? The former >>>>>> sounds bad, the latter negates the advantages of such a buffer. >>>>>> >>>>>> Then, access to such a buffer would probably have to be synchronized, >>>>>> whereas today AFAIK the log calls do not have to be. >>>>>> >>>>>> Cheers, Thomas >>>>>> >>>>>> On Mon 2. Nov 2020 at 22:18, Ioi Lam wrote: >>>>>> >>>>>>> For performance, maybe the implementation can log into a memory buffer, >>>>>>> and use a worker thread to send the output over the network? That way we >>>>>>> can minimize the overhead per log_xxx() call. >>>>>>> >>>>>>> I agree that using "-Xlog:foo=debug:network=xyz.com:1234" would be >>>>> quite >>>>>>> handy when you have lots of containers. You don't need to enable remote >>>>>>> access to the container's file system just to get to the log file. >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >>>>>>> >>>>>>> On 11/2/20 11:10 AM, Kirk Pepperdine wrote: >>>>>>>> Hi Thomas, >>>>>>>> >>>>>>>> I appreciate Yasumasa?s desire to be able to redirect UL output to >>>>>>> somewhere other than? I also appreciate that the highly granular nature >>>>> of >>>>>>> how UL messages are currently structure can be and indeed are an issue. >>>>>>> That said, I?d also like the ability to push the data to some where >>>>> other >>>>>>> than a file on disk. >>>>>>>> >>>>>>>> To the point of granularity, UL might benefit from some message >>>>>>> coarsening. This might also help in with other logging related >>>>> performance >>>>>>> issues that I?ve noted here and there. Quite frankly dealing with logs >>>>> in >>>>>>> containers isn?t a wonderful experience. And while I firmly believe that >>>>>>> there is more that containers can do to ease this, being able to >>>>> redirect >>>>>>> output to something other than a log file does feel like it would be >>>>>>> helpful. That said, I?m also concerned about the potential performance >>>>>>> impacts but I think for this things that one would generally log, this >>>>>>> should be minimal. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Kirk Pepperdine >>>>>>>> >>>>>>>> >>>>>>>>> On Nov 2, 2020, at 4:26 AM, Thomas St?fe >>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> one problem I see is that this could introduce a surprising amount of >>>>>>> lag >>>>>>>>> into log() calls which do look inconspicuous, thereby distorting >>>>> timing >>>>>>>>> behavior or even create timeout effects. We already have that problem >>>>>>> now >>>>>>>>> to some degree when logging to network shares. >>>>>>>>> >>>>>>>>> Another thing, log output can be very fine granular, which would >>>>> create >>>>>>> a >>>>>>>>> lot of network traffic. >>>>>>>>> >>>>>>>>> Such an addition may also open some security questions. >>>>>>>>> >>>>>>>>> ?? From a more philosophical standpoint, I like the "do one thing and >>>>> do >>>>>>> it >>>>>>>>> right" Unix way and this seems more like something an outside tool >>>>>>> should >>>>>>>>> be doing. Which could also aggregate log output better. But I admit >>>>> that >>>>>>>>> argument is weak. >>>>>>>>> >>>>>>>>> Cheers, Thomas >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga < >>>>>>> suenaga at oss.nttdata.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> We need to out UL to stdout and/or file. If we can out it to TCP >>>>>>> socket, I >>>>>>>>>> think it is useful. >>>>>>>>>> >>>>>>>>>> For example, some system gather all logs to document oriented >>>>> databases >>>>>>>>>> (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. >>>>>>> CloudWatch). If >>>>>>>>>> HotSpot can out UL to TCP socket, we can send all logs to them via >>>>> TCP >>>>>>>>>> input plugin (Fluentd, Logstash). >>>>>>>>>> >>>>>>>>>> I think it is useful for container platform. What do you think? >>>>>>>>>> If it is worth to work, I will add CSR and JBS ticket, and also will >>>>>>>>>> create patch. >>>>>>>>>> >>>>>>> >>>>>>> >>>>> From mdoerr at openjdk.java.net Wed Nov 4 10:12:57 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 4 Nov 2020 10:12:57 GMT Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c [v2] In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 20:37:07 GMT, Jorn Vernee wrote: >> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c >> >> This removes the reported warning. >> >> Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing). >> >> CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed. >> >> Testing: tier1-3 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8232022 > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - Collapse both _LP64 if blocks in flags-cflags.m4 > - Use jlong.h macros instead of spinning new ones Builds on AIX. ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From robbin.ehn at oracle.com Wed Nov 4 11:12:18 2020 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 4 Nov 2020 12:12:18 +0100 Subject: Unified Logging for network In-Reply-To: <3d860cd2-20ba-6fb3-188e-cd71cacf9426@oss.nttdata.com> References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> <41f33608-63de-c7cb-e135-13a6fcc39b05@oracle.com> <445f898e-bcf4-4a24-9b97-43891d5429ea@oracle.com> <8a09ad25-8181-3705-adcb-d4bead1428fc@oracle.com> <3d860cd2-20ba-6fb3-188e-cd71cacf9426@oss.nttdata.com> Message-ID: <412cb15a-f0ef-0fdf-d413-822996db757a@oracle.com> Hi Yasumasa, On 2020-11-04 11:06, Yasumasa Suenaga wrote: > Hi Robbin, > > On 2020/11/04 17:12, Robbin Ehn wrote: >> Hi, Yasumasa, >> >> On 2020-11-04 02:38, Yasumasa Suenaga wrote: >>> As I said in reply to Thomas [1], I don't want to dump UL to files >>> because it should be one log file (should not rotate), so file size >>> might be large. >>> It might occur problems in disk usage in container. >> >> Sorry I don't follow, so I'm guessing here what you mean. >> >> The direct output from UL is only used by syslog, so something like: >> "-Xlog:all=error:file=my_vm.%p.log::filecount=2,filesize=1m" should be >> fine. >> - Use syslog to collect from my_vm.*.log.* > > IIUC we need to set "my_vm.log.current" to text source in syslog-ng in > this solution. > However my-vm.log.current would be reopened when log rotation is happen, > so syslog-ng might not follow current log. > To follow all logs, we should not set log rotation, and log file would > be large. https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.17/administration-guide/18 "The syslog-ng application notices if a file is renamed or replaced with a new file, so it can correctly follow the file even if logrotation is used." If we do something weird so that this does not work we should fix the log-rotation so syslog can be proper used. Thanks, Robbin > > >> - Configure syslog to output both to that one large file you mentioned >> and over network to your e.g. elastic search. >> >> If this is not sufficient then implementation syslog/windows event log >> is much better and simpler alternative, as also mentioned in JEP: >> https://openjdk.java.net/jeps/158 >> >> E.g. >> >> "-Xlog:all=error:syslog=my_vm" > > "Future possible extensions" JEP 158 mentions socket output as a backend. > I think this proposal is same with it. > > > Thanks, > > Yasumasa > > >> Thanks, Robbin >> >> >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043342.html >>> >>> >>> >>>> /Robbin >>>> >>>> On 2020-11-03 09:09, Thomas St?fe wrote: >>>>> Hi Yasumasa, >>>>> >>>>> I don't argue that such a feature would not be useful. Of course it >>>>> would! >>>>> >>>>> But as with any other added feature, it will come at the cost of >>>>> complexity. It will have to be maintained, tests will have to be >>>>> written >>>>> and run. That increases technical debt for us all. >>>>> >>>>> That is not a reason not to do it, but to think before doing it and >>>>> exploring alternatives. >>>>> >>>>> -- >>>>> >>>>> To me, the fact that a logging call now could possibly do Network >>>>> IO fills >>>>> me with deep unease. It violates the principle of least surprise. >>>>> Logging >>>>> should be as basic as possible, in order to be usable anywhere in >>>>> code. >>>>> >>>>> - as had been said before, it would introduce unpredictable timing >>>>> behavior. The fact that we have this already today is not a big >>>>> consolation >>>>> :( >>>>> >>>>> - similar to "the User should know what he does" argument - >>>>> unfortunately >>>>> many don't, so a balance has to be found to limit support from >>>>> these cases >>>>> >>>>> - AFAICS we do not do network IO anywhere in the hotspot today. >>>>> That coding >>>>> would have to be written and tested. Reusing some other code - e.g. >>>>> from >>>>> the corelibs - is out of question for such a low level API, since >>>>> you don't >>>>> want to risk circularities. >>>>> >>>>> - But now we have a complete network stack below the innocuous logging >>>>> call. This imposes further restrictions on where we can log - eg >>>>> even if it >>>>> were possible before, logging from signal handling is impossible now. >>>>> Without these restrictions documented and tested anywhere. To me >>>>> this makes >>>>> UL more and more questionable, and I already tend to shun it when >>>>> possible >>>>> in favour of plain tty printing. >>>>> >>>>> I argued yesterday against Ioi's concurrent-log-draining, but that is >>>>> actually more attractive the more I think about it. >>>>> >>>>> Only, could the same not be achieved with piping stdout/err to a >>>>> separate >>>>> tool like netcat, as Leo suggested? >>>>> >>>>> That solution exists today. If netcat does not do it for you, this >>>>> could >>>>> also be a separate utility - could be even part of the jdk. >>>>> Conceptually >>>>> this would be much the same as a separate thread printing out UL, >>>>> with the >>>>> pipe size being the buffer size. Or, communication could happen via >>>>> shared >>>>> memory... >>>>> >>>>> This would have two distinct advantages over doing network IO in UL: >>>>> - we see the whole stderr output (e.g. output from the libc, or any >>>>> third >>>>> party tools) >>>>> - we see output also from a VM which crashed and burned. E.g. any last >>>>> words from hs-err reporting. >>>>> >>>>> Cheers, Thomas >>>>> >>>>> >>>>> On Tue, Nov 3, 2020 at 3:12 AM Yasumasa Suenaga >>>>> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I agree this proposal might occur performance issue. However I >>>>>> think it is >>>>>> the responsibility of the user. >>>>>> If this proposal is implemented, I think it would be transferred >>>>>> to local >>>>>> log shipper process (fluentd, logstash on 127.0.0.1) in most case >>>>>> because >>>>>> HotSpot does not send log with JSON. And also log shipper may support >>>>>> message buffering and message queue persistence. >>>>>> We can avoid (in part of) performance/reliability issues with log >>>>>> shipper. >>>>>> >>>>>> Even if current implementation, performance issues is occurs when >>>>>> the disk >>>>>> is very slow (e.g. storage is broken). >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2020/11/03 6:31, Thomas St?fe wrote: >>>>>>> Hi Ioi, >>>>>>> >>>>>>> I dimly remember proposals like this from the past. Main problem >>>>>>> I see is >>>>>>> how large would you dimension the buffer, and what do you do if the >>>>>> buffer >>>>>>> cannot be drained rapidly enough. Discard log output? Hold? The >>>>>>> former >>>>>>> sounds bad, the latter negates the advantages of such a buffer. >>>>>>> >>>>>>> Then, access to such a buffer would probably have to be >>>>>>> synchronized, >>>>>>> whereas today AFAIK the log calls do not have to be. >>>>>>> >>>>>>> Cheers, Thomas >>>>>>> >>>>>>> On Mon 2. Nov 2020 at 22:18, Ioi Lam wrote: >>>>>>> >>>>>>>> For performance, maybe the implementation can log into a memory >>>>>>>> buffer, >>>>>>>> and use a worker thread to send the output over the network? >>>>>>>> That way we >>>>>>>> can minimize the overhead per log_xxx() call. >>>>>>>> >>>>>>>> I agree that using "-Xlog:foo=debug:network=xyz.com:1234" would be >>>>>> quite >>>>>>>> handy when you have lots of containers. You don't need to enable >>>>>>>> remote >>>>>>>> access to the container's file system just to get to the log file. >>>>>>>> >>>>>>>> Thanks >>>>>>>> - Ioi >>>>>>>> >>>>>>>> On 11/2/20 11:10 AM, Kirk Pepperdine wrote: >>>>>>>>> Hi Thomas, >>>>>>>>> >>>>>>>>> I appreciate Yasumasa?s desire to be able to redirect UL output to >>>>>>>> somewhere other than? I also appreciate that the highly granular >>>>>>>> nature >>>>>> of >>>>>>>> how UL messages are currently structure can be and indeed are an >>>>>>>> issue. >>>>>>>> That said, I?d also like the ability to push the data to some where >>>>>> other >>>>>>>> than a file on disk. >>>>>>>>> >>>>>>>>> To the point of granularity, UL might benefit from some message >>>>>>>> coarsening. This might also help in with other logging related >>>>>> performance >>>>>>>> issues that I?ve noted here and there. Quite frankly dealing >>>>>>>> with logs >>>>>> in >>>>>>>> containers isn?t a wonderful experience. And while I firmly >>>>>>>> believe that >>>>>>>> there is more that containers can do to ease this, being able to >>>>>> redirect >>>>>>>> output to something other than a log file does feel like it >>>>>>>> would be >>>>>>>> helpful. That said, I?m also concerned about the potential >>>>>>>> performance >>>>>>>> impacts but I think for this things that one would generally >>>>>>>> log, this >>>>>>>> should be minimal. >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> Kirk Pepperdine >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Nov 2, 2020, at 4:26 AM, Thomas St?fe >>>>>>>>>> >>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> one problem I see is that this could introduce a surprising >>>>>>>>>> amount of >>>>>>>> lag >>>>>>>>>> into log() calls which do look inconspicuous, thereby distorting >>>>>> timing >>>>>>>>>> behavior or even create timeout effects. We already have that >>>>>>>>>> problem >>>>>>>> now >>>>>>>>>> to some degree when logging to network shares. >>>>>>>>>> >>>>>>>>>> Another thing, log output can be very fine granular, which would >>>>>> create >>>>>>>> a >>>>>>>>>> lot of network traffic. >>>>>>>>>> >>>>>>>>>> Such an addition may also open some security questions. >>>>>>>>>> >>>>>>>>>> ?? From a more philosophical standpoint, I like the "do one >>>>>>>>>> thing and >>>>>> do >>>>>>>> it >>>>>>>>>> right" Unix way and this seems more like something an outside >>>>>>>>>> tool >>>>>>>> should >>>>>>>>>> be doing. Which could also aggregate log output better. But I >>>>>>>>>> admit >>>>>> that >>>>>>>>>> argument is weak. >>>>>>>>>> >>>>>>>>>> Cheers, Thomas >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga < >>>>>>>> suenaga at oss.nttdata.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> We need to out UL to stdout and/or file. If we can out it to TCP >>>>>>>> socket, I >>>>>>>>>>> think it is useful. >>>>>>>>>>> >>>>>>>>>>> For example, some system gather all logs to document oriented >>>>>> databases >>>>>>>>>>> (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. >>>>>>>> CloudWatch). If >>>>>>>>>>> HotSpot can out UL to TCP socket, we can send all logs to >>>>>>>>>>> them via >>>>>> TCP >>>>>>>>>>> input plugin (Fluentd, Logstash). >>>>>>>>>>> >>>>>>>>>>> I think it is useful for container platform. What do you think? >>>>>>>>>>> If it is worth to work, I will add CSR and JBS ticket, and >>>>>>>>>>> also will >>>>>>>>>>> create patch. >>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> From rehn at openjdk.java.net Wed Nov 4 11:48:56 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 4 Nov 2020 11:48:56 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v3] In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 19:04:14 GMT, Patricio Chilano Mateo wrote: >> Marked as reviewed by rrich (Committer). > >> > > In `JavaThread::check_and_handle_async_exceptions()` the block depending on is_at_poll_safepoint() looks like dead code now. I wonder if `ThreadSafepointState::_at_poll_safepoint` could even be DEBUG_ONLY? >> > >> > >> > Yes, I actually thought about doing that in the first version but then I >> > realized that code was already dead even before this change. We only >> > call set_at_poll_safepoint() in handle_polling_page_exception() and the >> > handle_special_runtime_exit_condition() call in SS::block() already >> > excludes checking async exceptions for that case. The call I removed >> > from ~TIVMFH was exactly the same. So I don't see a path where it could >> > be called where is_at_poll_safepoint() returned true. >> > I agree that _at_poll_safepoint should probably be DEBUG_ONLY. Then we >> > should add an assert in check_and_handle_async_exceptions(). Do you >> > think I should do that here or in another bug? >> >> I'd think you can do it in another bug also. I'm ok either way actually. > Ok, I filed 8255849 to track that. > Thanks Richard! > > Patricio > > How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)? But _suspend_flag have nothing to do with safepoint polling, handling it with SafepointMechanism doesn't seem right? Thanks, Robbin > > That works for me. > > Thanks, > David > ----- # ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From suenaga at oss.nttdata.com Wed Nov 4 12:32:09 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 4 Nov 2020 21:32:09 +0900 Subject: Unified Logging for network In-Reply-To: <412cb15a-f0ef-0fdf-d413-822996db757a@oracle.com> References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <6C80E721-BB78-403F-ABF4-4FE224564B12@kodewerk.com> <41f33608-63de-c7cb-e135-13a6fcc39b05@oracle.com> <445f898e-bcf4-4a24-9b97-43891d5429ea@oracle.com> <8a09ad25-8181-3705-adcb-d4bead1428fc@oracle.com> <3d860cd2-20ba-6fb3-188e-cd71cacf9426@oss.nttdata.com> <412cb15a-f0ef-0fdf-d413-822996db757a@oracle.com> Message-ID: <0d1adb9d-fa2c-6b4b-6d30-6bf7aff028e8@oss.nttdata.com> Hi Robbin, Thanks for your information! but I prefer to push log to log shipper directly. For example, if we push logs to Elasticsearch with syslog-ng, we need to use as following: JVM -> UL file -> syslog-ng -> Logstash -> Elasticsearch If JVM can send logs to socket directly, we can be it simply as following: JVM -> Logstash -> Elasticsearch Your suggestion is very useful in current JDK, but I'm happy if next LTS has this feature. Thanks, Yasumasa On 2020/11/04 20:12, Robbin Ehn wrote: > Hi Yasumasa, > > On 2020-11-04 11:06, Yasumasa Suenaga wrote: >> Hi Robbin, >> >> On 2020/11/04 17:12, Robbin Ehn wrote: >>> Hi, Yasumasa, >>> >>> On 2020-11-04 02:38, Yasumasa Suenaga wrote: >>>> As I said in reply to Thomas [1], I don't want to dump UL to files because it should be one log file (should not rotate), so file size might be large. >>>> It might occur problems in disk usage in container. >>> >>> Sorry I don't follow, so I'm guessing here what you mean. >>> >>> The direct output from UL is only used by syslog, so something like: >>> "-Xlog:all=error:file=my_vm.%p.log::filecount=2,filesize=1m" should be >>> fine. >>> - Use syslog to collect from my_vm.*.log.* >> >> IIUC we need to set "my_vm.log.current" to text source in syslog-ng in this solution. >> However my-vm.log.current would be reopened when log rotation is happen, so syslog-ng might not follow current log. >> To follow all logs, we should not set log rotation, and log file would be large. > > https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.17/administration-guide/18 > > "The syslog-ng application notices if a file is renamed or replaced with a new file, so it can correctly follow the file even if logrotation is used." > > If we do something weird so that this does not work we should fix the log-rotation so syslog can be proper used. > > Thanks, Robbin > >> >> >>> - Configure syslog to output both to that one large file you mentioned >>> and over network to your e.g. elastic search. >>> >>> If this is not sufficient then implementation syslog/windows event log is much better and simpler alternative, as also mentioned in JEP: >>> https://openjdk.java.net/jeps/158 >>> >>> E.g. >>> >>> "-Xlog:all=error:syslog=my_vm" >> >> "Future possible extensions" JEP 158 mentions socket output as a backend. >> I think this proposal is same with it. >> >> >> Thanks, >> >> Yasumasa >> >> >>> Thanks, Robbin >>> >>> >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043342.html >>>> >>>> >>>>> /Robbin >>>>> >>>>> On 2020-11-03 09:09, Thomas St?fe wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> I don't argue that such a feature would not be useful. Of course it would! >>>>>> >>>>>> But as with any other added feature, it will come at the cost of >>>>>> complexity. It will have to be maintained, tests will have to be written >>>>>> and run. That increases technical debt for us all. >>>>>> >>>>>> That is not a reason not to do it, but to think before doing it and >>>>>> exploring alternatives. >>>>>> >>>>>> -- >>>>>> >>>>>> To me, the fact that a logging call now could possibly do Network IO fills >>>>>> me with deep unease. It violates the principle of least surprise. Logging >>>>>> should be as basic as possible, in order to be usable anywhere in code. >>>>>> >>>>>> - as had been said before, it would introduce unpredictable timing >>>>>> behavior. The fact that we have this already today is not a big consolation >>>>>> :( >>>>>> >>>>>> - similar to "the User should know what he does" argument - unfortunately >>>>>> many don't, so a balance has to be found to limit support from these cases >>>>>> >>>>>> - AFAICS we do not do network IO anywhere in the hotspot today. That coding >>>>>> would have to be written and tested. Reusing some other code - e.g. from >>>>>> the corelibs - is out of question for such a low level API, since you don't >>>>>> want to risk circularities. >>>>>> >>>>>> - But now we have a complete network stack below the innocuous logging >>>>>> call. This imposes further restrictions on where we can log - eg even if it >>>>>> were possible before, logging from signal handling is impossible now. >>>>>> Without these restrictions documented and tested anywhere. To me this makes >>>>>> UL more and more questionable, and I already tend to shun it when possible >>>>>> in favour of plain tty printing. >>>>>> >>>>>> I argued yesterday against Ioi's concurrent-log-draining, but that is >>>>>> actually more attractive the more I think about it. >>>>>> >>>>>> Only, could the same not be achieved with piping stdout/err to a separate >>>>>> tool like netcat, as Leo suggested? >>>>>> >>>>>> That solution exists today. If netcat does not do it for you, this could >>>>>> also be a separate utility - could be even part of the jdk. Conceptually >>>>>> this would be much the same as a separate thread printing out UL, with the >>>>>> pipe size being the buffer size. Or, communication could happen via shared >>>>>> memory... >>>>>> >>>>>> This would have two distinct advantages over doing network IO in UL: >>>>>> - we see the whole stderr output (e.g. output from the libc, or any third >>>>>> party tools) >>>>>> - we see output also from a VM which crashed and burned. E.g. any last >>>>>> words from hs-err reporting. >>>>>> >>>>>> Cheers, Thomas >>>>>> >>>>>> >>>>>> On Tue, Nov 3, 2020 at 3:12 AM Yasumasa Suenaga >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I agree this proposal might occur performance issue. However I think it is >>>>>>> the responsibility of the user. >>>>>>> If this proposal is implemented, I think it would be transferred to local >>>>>>> log shipper process (fluentd, logstash on 127.0.0.1) in most case because >>>>>>> HotSpot does not send log with JSON. And also log shipper may support >>>>>>> message buffering and message queue persistence. >>>>>>> We can avoid (in part of) performance/reliability issues with log shipper. >>>>>>> >>>>>>> Even if current implementation, performance issues is occurs when the disk >>>>>>> is very slow (e.g. storage is broken). >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2020/11/03 6:31, Thomas St?fe wrote: >>>>>>>> Hi Ioi, >>>>>>>> >>>>>>>> I dimly remember proposals like this from the past. Main problem I see is >>>>>>>> how large would you dimension the buffer, and what do you do if the >>>>>>> buffer >>>>>>>> cannot be drained rapidly enough. Discard log output? Hold? The former >>>>>>>> sounds bad, the latter negates the advantages of such a buffer. >>>>>>>> >>>>>>>> Then, access to such a buffer would probably have to be synchronized, >>>>>>>> whereas today AFAIK the log calls do not have to be. >>>>>>>> >>>>>>>> Cheers, Thomas >>>>>>>> >>>>>>>> On Mon 2. Nov 2020 at 22:18, Ioi Lam wrote: >>>>>>>> >>>>>>>>> For performance, maybe the implementation can log into a memory buffer, >>>>>>>>> and use a worker thread to send the output over the network? That way we >>>>>>>>> can minimize the overhead per log_xxx() call. >>>>>>>>> >>>>>>>>> I agree that using "-Xlog:foo=debug:network=xyz.com:1234" would be >>>>>>> quite >>>>>>>>> handy when you have lots of containers. You don't need to enable remote >>>>>>>>> access to the container's file system just to get to the log file. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> - Ioi >>>>>>>>> >>>>>>>>> On 11/2/20 11:10 AM, Kirk Pepperdine wrote: >>>>>>>>>> Hi Thomas, >>>>>>>>>> >>>>>>>>>> I appreciate Yasumasa?s desire to be able to redirect UL output to >>>>>>>>> somewhere other than? I also appreciate that the highly granular nature >>>>>>> of >>>>>>>>> how UL messages are currently structure can be and indeed are an issue. >>>>>>>>> That said, I?d also like the ability to push the data to some where >>>>>>> other >>>>>>>>> than a file on disk. >>>>>>>>>> >>>>>>>>>> To the point of granularity, UL might benefit from some message >>>>>>>>> coarsening. This might also help in with other logging related >>>>>>> performance >>>>>>>>> issues that I?ve noted here and there. Quite frankly dealing with logs >>>>>>> in >>>>>>>>> containers isn?t a wonderful experience. And while I firmly believe that >>>>>>>>> there is more that containers can do to ease this, being able to >>>>>>> redirect >>>>>>>>> output to something other than a log file does feel like it would be >>>>>>>>> helpful. That said, I?m also concerned about the potential performance >>>>>>>>> impacts but I think for this things that one would generally log, this >>>>>>>>> should be minimal. >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> Kirk Pepperdine >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Nov 2, 2020, at 4:26 AM, Thomas St?fe >>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> one problem I see is that this could introduce a surprising amount of >>>>>>>>> lag >>>>>>>>>>> into log() calls which do look inconspicuous, thereby distorting >>>>>>> timing >>>>>>>>>>> behavior or even create timeout effects. We already have that problem >>>>>>>>> now >>>>>>>>>>> to some degree when logging to network shares. >>>>>>>>>>> >>>>>>>>>>> Another thing, log output can be very fine granular, which would >>>>>>> create >>>>>>>>> a >>>>>>>>>>> lot of network traffic. >>>>>>>>>>> >>>>>>>>>>> Such an addition may also open some security questions. >>>>>>>>>>> >>>>>>>>>>> ?? From a more philosophical standpoint, I like the "do one thing and >>>>>>> do >>>>>>>>> it >>>>>>>>>>> right" Unix way and this seems more like something an outside tool >>>>>>>>> should >>>>>>>>>>> be doing. Which could also aggregate log output better. But I admit >>>>>>> that >>>>>>>>>>> argument is weak. >>>>>>>>>>> >>>>>>>>>>> Cheers, Thomas >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Nov 2, 2020 at 12:21 PM Yasumasa Suenaga < >>>>>>>>> suenaga at oss.nttdata.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> We need to out UL to stdout and/or file. If we can out it to TCP >>>>>>>>> socket, I >>>>>>>>>>>> think it is useful. >>>>>>>>>>>> >>>>>>>>>>>> For example, some system gather all logs to document oriented >>>>>>> databases >>>>>>>>>>>> (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. >>>>>>>>> CloudWatch). If >>>>>>>>>>>> HotSpot can out UL to TCP socket, we can send all logs to them via >>>>>>> TCP >>>>>>>>>>>> input plugin (Fluentd, Logstash). >>>>>>>>>>>> >>>>>>>>>>>> I think it is useful for container platform. What do you think? >>>>>>>>>>>> If it is worth to work, I will add CSR and JBS ticket, and also will >>>>>>>>>>>> create patch. >>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> From pchilanomate at openjdk.java.net Wed Nov 4 14:08:55 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 4 Nov 2020 14:08:55 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v3] In-Reply-To: References: Message-ID: <5Nooh2OHBkGysZN9EEQuKYYP-dZH_J_hU1_P2oTjXxM=.d38455e2-68e5-484f-825a-4ef384d9a0db@github.com> On Wed, 4 Nov 2020 11:46:30 GMT, Robbin Ehn wrote: >>> > > In `JavaThread::check_and_handle_async_exceptions()` the block depending on is_at_poll_safepoint() looks like dead code now. I wonder if `ThreadSafepointState::_at_poll_safepoint` could even be DEBUG_ONLY? >>> > >>> > >>> > Yes, I actually thought about doing that in the first version but then I >>> > realized that code was already dead even before this change. We only >>> > call set_at_poll_safepoint() in handle_polling_page_exception() and the >>> > handle_special_runtime_exit_condition() call in SS::block() already >>> > excludes checking async exceptions for that case. The call I removed >>> > from ~TIVMFH was exactly the same. So I don't see a path where it could >>> > be called where is_at_poll_safepoint() returned true. >>> > I agree that _at_poll_safepoint should probably be DEBUG_ONLY. Then we >>> > should add an assert in check_and_handle_async_exceptions(). Do you >>> > think I should do that here or in another bug? >>> >>> I'd think you can do it in another bug also. I'm ok either way actually. >> Ok, I filed 8255849 to track that. >> Thanks Richard! >> >> Patricio > >> > How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)? > > But _suspend_flag have nothing to do with safepoint polling, handling it with SafepointMechanism doesn't seem right? > > Thanks, Robbin > >> >> That works for me. >> >> Thanks, >> David >> ----- > > # Hi Robbin, Thanks, for looking at this. > > > How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)? > > But _suspend_flag have nothing to do with safepoint polling, handling it with SafepointMechanism doesn't seem right? Yes, but today we are already checking the _suspend_flag cases inside SS::block(), so this would only add a method to explicitly do that if you want, i.e. make it visible. In any case, I'm fine with both ways of doing it. I can leave as it is right now and see if David is fine with that. Patricio > Thanks, Robbin > > > That works for me. > > ## Thanks, > > David ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From rehn at openjdk.java.net Wed Nov 4 14:26:57 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 4 Nov 2020 14:26:57 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v3] In-Reply-To: <5Nooh2OHBkGysZN9EEQuKYYP-dZH_J_hU1_P2oTjXxM=.d38455e2-68e5-484f-825a-4ef384d9a0db@github.com> References: <5Nooh2OHBkGysZN9EEQuKYYP-dZH_J_hU1_P2oTjXxM=.d38455e2-68e5-484f-825a-4ef384d9a0db@github.com> Message-ID: <-k2h1RQzmL0Kzj-snh0ojk4Qdv7X06t9Jb_QAqdSzk8=.0f5ddbd0-85eb-45ab-8624-25c68c9303cc@github.com> On Wed, 4 Nov 2020 14:05:52 GMT, Patricio Chilano Mateo wrote: > Hi Robbin, > > Thanks, for looking at this. > > > > > How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)? > > > > > > But _suspend_flag have nothing to do with safepoint polling, handling it with SafepointMechanism doesn't seem right? > > Yes, but today we are already checking the _suspend_flag cases inside SS::block(), so this would only add a method to explicitly do that if you want, i.e. make it visible. In any case, I'm fine with both ways of doing it. I can leave as it is right now and see if David is fine with that. > > Patricio > > > Thanks, Robbin > > > That works for me. > > > ## Thanks, > > > David Skimming a bit, as far as I can see void ThreadSafepointState::handle_polling_page_exception() should use ThreadInVMfromJava and in the other path ThreadInVMfromJavaNoAsyncException. No? ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From redestad at openjdk.java.net Wed Nov 4 15:22:01 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 4 Nov 2020 15:22:01 GMT Subject: RFR: 8255900: x86: Reduce impact when VerifyOops is disabled Message-ID: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> - Don't generate stub _verify_oop_subroutine_entry on startup if -VerifyOops - Make VerifyOops check in calls to MacroAssembler::verify_oop inlineable. (VerifyOops is a develop flag, so this allows more aggressive code elimination in a few place) - (trivial pile-on) remove unused set_word_if_not_zero Slightly improves static footprint, gets rid of a stub and reduce jitter during jitting in product builds. ------------- Commit messages: - Fix copy-paste error - add checked variants of _verify_oop to avoid calls in product builds - Merge branch 'master' into verify_oop_stub - Cleanup verify_oop Changes: https://git.openjdk.java.net/jdk/pull/1058/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1058&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255900 Stats: 27 lines in 4 files changed: 13 ins; 9 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1058.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1058/head:pull/1058 PR: https://git.openjdk.java.net/jdk/pull/1058 From neliasso at openjdk.java.net Wed Nov 4 16:28:54 2020 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Wed, 4 Nov 2020 16:28:54 GMT Subject: RFR: 8255900: x86: Reduce impact when VerifyOops is disabled In-Reply-To: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> References: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> Message-ID: <88u6xCsIwiZ7Sq549-tTRU8IKhjPc8gXcuMk7LvW5o0=.2350d90c-dc8a-4070-8b36-105097fa5068@github.com> On Wed, 4 Nov 2020 14:49:41 GMT, Claes Redestad wrote: > - Don't generate stub _verify_oop_subroutine_entry on startup if -VerifyOops > - Make VerifyOops check in calls to MacroAssembler::verify_oop inlineable. (VerifyOops is a develop flag, so this allows more aggressive code elimination in a few place) > - (trivial pile-on) remove unused set_word_if_not_zero > > Slightly improves static footprint, gets rid of a stub and reduce jitter during jitting in product builds. Looks good! ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1058 From shade at openjdk.java.net Wed Nov 4 16:40:03 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 4 Nov 2020 16:40:03 GMT Subject: RFR: 8255890: Zero: remove unused methods from BytecodeInterpreter Message-ID: There are lots of local/stack management methods that are not used at all. Macro-definitions are used instead. Can clean them up to avoid further bitrot. ------------- Commit messages: - 8255890: Zero: remove unused methods from BytecodeInterpreter Changes: https://git.openjdk.java.net/jdk/pull/1060/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1060&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255890 Stats: 186 lines in 2 files changed: 1 ins; 185 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1060.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1060/head:pull/1060 PR: https://git.openjdk.java.net/jdk/pull/1060 From coleenp at openjdk.java.net Wed Nov 4 17:00:54 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 4 Nov 2020 17:00:54 GMT Subject: RFR: 8255890: Zero: remove unused methods from BytecodeInterpreter In-Reply-To: References: Message-ID: <2GcUgjKH782zyIL2BwCjLveeWwnfS_L0QaOHyNka2VQ=.05fb89a3-b3db-4a42-a4b3-feb99aa9d848@github.com> On Wed, 4 Nov 2020 16:28:05 GMT, Aleksey Shipilev wrote: > There are lots of local/stack management methods that are not used at all. Macro-definitions are used instead. Can clean them up to avoid further bitrot. Through random sampling, I see no evidence of these ever being called. Looks trivial since it builds for you. Thank you for all this cleanup of Zero. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1060 From shade at openjdk.java.net Wed Nov 4 17:05:54 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 4 Nov 2020 17:05:54 GMT Subject: RFR: 8255890: Zero: remove unused methods from BytecodeInterpreter In-Reply-To: <2GcUgjKH782zyIL2BwCjLveeWwnfS_L0QaOHyNka2VQ=.05fb89a3-b3db-4a42-a4b3-feb99aa9d848@github.com> References: <2GcUgjKH782zyIL2BwCjLveeWwnfS_L0QaOHyNka2VQ=.05fb89a3-b3db-4a42-a4b3-feb99aa9d848@github.com> Message-ID: On Wed, 4 Nov 2020 16:57:47 GMT, Coleen Phillimore wrote: > Through random sampling, I see no evidence of these ever being called. Looks trivial since it builds for you. Thank you for all this cleanup of Zero. Thanks. GH actions actually build Zero on x86_64, and it does not seem to complain either. ------------- PR: https://git.openjdk.java.net/jdk/pull/1060 From ccheung at openjdk.java.net Wed Nov 4 17:12:00 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 4 Nov 2020 17:12:00 GMT Subject: RFR: 8255855: appcds/jigsaw/NewModuleFinderTest.java test failed due to unexpected NPE Message-ID: <8oqBX10AVMGz8vKAkF4IbGKoK3vwmxRlj66bb2Dw8DY=.f11be5e0-3c47-4307-b615-b49b62f18971@github.com> The test.src system property is not being passed to the child process. The problem was not noticed before the fix for https://bugs.openjdk.java.net/browse/JDK-8254876 because the child process does not require the test.src property. After the fix for JDK-8254876, we got NPE in the following call because the first arg is null: `Paths.get(TEST_SRC, "modulepath/src");` A simple fix is to pass the system property to the child process. Testing: tiers 1,2,3. ------------- Commit messages: - remove the test from the ProblemList - Merge branch 'master' into 8255855 - 8255855: appcds/jigsaw/NewModuleFinderTest.java test failed due to unexpected NPE Changes: https://git.openjdk.java.net/jdk/pull/1063/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1063&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255855 Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1063.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1063/head:pull/1063 PR: https://git.openjdk.java.net/jdk/pull/1063 From iklam at openjdk.java.net Wed Nov 4 17:16:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 4 Nov 2020 17:16:56 GMT Subject: RFR: 8255855: appcds/jigsaw/NewModuleFinderTest.java test failed due to unexpected NPE In-Reply-To: <8oqBX10AVMGz8vKAkF4IbGKoK3vwmxRlj66bb2Dw8DY=.f11be5e0-3c47-4307-b615-b49b62f18971@github.com> References: <8oqBX10AVMGz8vKAkF4IbGKoK3vwmxRlj66bb2Dw8DY=.f11be5e0-3c47-4307-b615-b49b62f18971@github.com> Message-ID: <2gLc9ATxn2bFCHMCA3HyHUuZ_8BDT-nrK2MnhWoAWZs=.b9f931cb-2a4b-4d72-9f56-21c10847cd9b@github.com> On Wed, 4 Nov 2020 17:06:50 GMT, Calvin Cheung wrote: > The test.src system property is not being passed to the child process. The problem was not noticed before the fix for https://bugs.openjdk.java.net/browse/JDK-8254876 because the child process does not require the test.src property. > > After the fix for JDK-8254876, we got NPE in the following call because the first arg is null: > `Paths.get(TEST_SRC, "modulepath/src");` > > A simple fix is to pass the system property to the child process. > > Testing: tiers 1,2,3. Looks good and a trivial fix. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1063 From ccheung at openjdk.java.net Wed Nov 4 17:20:55 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 4 Nov 2020 17:20:55 GMT Subject: Integrated: 8255855: appcds/jigsaw/NewModuleFinderTest.java test failed due to unexpected NPE In-Reply-To: <8oqBX10AVMGz8vKAkF4IbGKoK3vwmxRlj66bb2Dw8DY=.f11be5e0-3c47-4307-b615-b49b62f18971@github.com> References: <8oqBX10AVMGz8vKAkF4IbGKoK3vwmxRlj66bb2Dw8DY=.f11be5e0-3c47-4307-b615-b49b62f18971@github.com> Message-ID: On Wed, 4 Nov 2020 17:06:50 GMT, Calvin Cheung wrote: > The test.src system property is not being passed to the child process. The problem was not noticed before the fix for https://bugs.openjdk.java.net/browse/JDK-8254876 because the child process does not require the test.src property. > > After the fix for JDK-8254876, we got NPE in the following call because the first arg is null: > `Paths.get(TEST_SRC, "modulepath/src");` > > A simple fix is to pass the system property to the child process. > > Testing: tiers 1,2,3. This pull request has now been integrated. Changeset: 5348298f Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/5348298f Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod 8255855: appcds/jigsaw/NewModuleFinderTest.java test failed due to unexpected NPE Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/1063 From minqi at openjdk.java.net Wed Nov 4 17:44:56 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 4 Nov 2020 17:44:56 GMT Subject: RFR: 8255900: x86: Reduce impact when VerifyOops is disabled In-Reply-To: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> References: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> Message-ID: On Wed, 4 Nov 2020 14:49:41 GMT, Claes Redestad wrote: > - Don't generate stub _verify_oop_subroutine_entry on startup if -VerifyOops > - Make VerifyOops check in calls to MacroAssembler::verify_oop inlineable. (VerifyOops is a develop flag, so this allows more aggressive code elimination in a few place) > - (trivial pile-on) remove unused set_word_if_not_zero > > Slightly improves static footprint, gets rid of a stub and reduce jitter during jitting in product builds. Why only for x86_64 not including other platforms? ------------- PR: https://git.openjdk.java.net/jdk/pull/1058 From jvernee at openjdk.java.net Wed Nov 4 18:12:57 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 4 Nov 2020 18:12:57 GMT Subject: Integrated: 8255838: Use 32-bit immediate movslq in macro assembler if 64-bit value fits in 32 bits on x86_64 In-Reply-To: References: Message-ID: <-QogyhUBZmh1XoX_wQtGgQI3oqYp3VbxyloVP_wRnHE=.cfc76426-043b-4c7c-b0d1-ee3e86d6c26b@github.com> On Tue, 3 Nov 2020 15:12:50 GMT, Jorn Vernee wrote: > Currently, Macro::Assembler(Address dst, intprt_t src) on x64 uses an intermediate scratch register to store the 64-bit immediate. > > void MacroAssembler::movptr(Address dst, intptr_t src) { > mov64(rscratch1, src); > movq(dst, rscratch1); > } > > But, if the value fits into 32-bits, we can also explicitly use the 32-bit immediate overload, which saves an instruction and a register use, by using movslq/movabs instead (sig extended move). > > This ends up saving about 90k instructions on hello world. It also reduces the size of the interpreter by about 4k. > > Special thanks to Claes for prior discussion and help with testing. > > Testing: tier1-3, local startup profiling This pull request has now been integrated. Changeset: 160759ce Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/160759ce Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8255838: Use 32-bit immediate movslq in macro assembler if 64-bit value fits in 32 bits on x86_64 Reviewed-by: azeemj, kvn, redestad, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/1038 From jvernee at openjdk.java.net Wed Nov 4 18:13:59 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 4 Nov 2020 18:13:59 GMT Subject: Integrated: 8255128: linux x86 build failure with libJNIPoint.c In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 18:36:32 GMT, Jorn Vernee wrote: > Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c > > This removes the reported warning. > > Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing). > > CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed. > > Testing: tier1-3 > > [1] https://bugs.openjdk.java.net/browse/JDK-8232022 This pull request has now been integrated. Changeset: 804bd725 Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/804bd725 Stats: 17 lines in 2 files changed: 1 ins; 6 del; 10 mod 8255128: linux x86 build failure with libJNIPoint.c Reviewed-by: coleenp, shade, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/1017 From iklam at openjdk.java.net Wed Nov 4 18:27:04 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 4 Nov 2020 18:27:04 GMT Subject: RFR: 8255860: Clean up CDS logging related to lambda Message-ID: A small clean up to make the logging more manageable. [1] Moved some debug printing from `tty->print_cr()` to `-Xlog:cds+lambda=debug` [2] Moved some logs from `-Xlog:cds` to `-Xlog:cds+lambda` ------------- Commit messages: - 8255860: Clean up CDS logging related to lambda Changes: https://git.openjdk.java.net/jdk/pull/1062/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1062&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255860 Stats: 29 lines in 6 files changed: 5 ins; 1 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/1062.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1062/head:pull/1062 PR: https://git.openjdk.java.net/jdk/pull/1062 From ccheung at openjdk.java.net Wed Nov 4 18:49:56 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 4 Nov 2020 18:49:56 GMT Subject: RFR: 8255860: Clean up CDS logging related to lambda In-Reply-To: References: Message-ID: <5WMC4tgIYAj4OSuawwovEIRWAAmmwyHVYc64iDCYR6M=.7bb1e69f-01e0-471c-aced-af8d6f209c91@github.com> On Wed, 4 Nov 2020 16:32:33 GMT, Ioi Lam wrote: > A small clean up to make the logging more manageable. > > [1] Moved some debug printing from `tty->print_cr()` to `-Xlog:cds+lambda=debug` > [2] Moved some logs from `-Xlog:cds` to `-Xlog:cds+lambda` The cleanup looks good. Just couple of nits below. src/hotspot/share/classfile/classListParser.cpp line 464: > 462: > 463: void ClassListParser::resolve_indy(Symbol* class_name_symbol, TRAPS) { > 464: Line deleted by accident? test/hotspot/jtreg/runtime/cds/appcds/BadBSM.java line 46: > 44: TestCommon.list("WrongBSM", > 45: "@lambda-proxy WrongBSM 7"), > 46: "-Xlog:cds+lambda=debug"); Please align line 46 with 45. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1062 From iklam at openjdk.java.net Wed Nov 4 18:49:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 4 Nov 2020 18:49:57 GMT Subject: RFR: 8255860: Clean up CDS logging related to lambda In-Reply-To: <5WMC4tgIYAj4OSuawwovEIRWAAmmwyHVYc64iDCYR6M=.7bb1e69f-01e0-471c-aced-af8d6f209c91@github.com> References: <5WMC4tgIYAj4OSuawwovEIRWAAmmwyHVYc64iDCYR6M=.7bb1e69f-01e0-471c-aced-af8d6f209c91@github.com> Message-ID: On Wed, 4 Nov 2020 18:41:11 GMT, Calvin Cheung wrote: >> A small clean up to make the logging more manageable. >> >> [1] Moved some debug printing from `tty->print_cr()` to `-Xlog:cds+lambda=debug` >> [2] Moved some logs from `-Xlog:cds` to `-Xlog:cds+lambda` > > src/hotspot/share/classfile/classListParser.cpp line 464: > >> 462: >> 463: void ClassListParser::resolve_indy(Symbol* class_name_symbol, TRAPS) { >> 464: > > Line deleted by accident? It's uncommon to have a blank line at the beginning of a function, so I deleted it. > test/hotspot/jtreg/runtime/cds/appcds/BadBSM.java line 46: > >> 44: TestCommon.list("WrongBSM", >> 45: "@lambda-proxy WrongBSM 7"), >> 46: "-Xlog:cds+lambda=debug"); > > Please align line 46 with 45. The `"-Xlog:cds+lambda=debug"` parameter is actually at the same level as the `TestCommon.list("WrongBSM",...)` parameter. Aligning it with line 45 would make it look like an argument for the `TestCommon.list()` call. ------------- PR: https://git.openjdk.java.net/jdk/pull/1062 From redestad at openjdk.java.net Wed Nov 4 18:56:55 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 4 Nov 2020 18:56:55 GMT Subject: RFR: 8255900: x86: Reduce impact when VerifyOops is disabled In-Reply-To: References: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> Message-ID: On Wed, 4 Nov 2020 17:42:30 GMT, Yumin Qi wrote: > Why only for x86_64 not including other platforms? It's uneasy changing platforms I don't have access to to test. Generally it seems more appropriate that someone with access ports the changes. This case might be trivial enough to port without testing, but I looked at aarch64 which does not use the same macro structure, for example, so I backed away from attempting that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1058 From minqi at openjdk.java.net Wed Nov 4 19:10:00 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 4 Nov 2020 19:10:00 GMT Subject: RFR: 8255900: x86: Reduce impact when VerifyOops is disabled In-Reply-To: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> References: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> Message-ID: On Wed, 4 Nov 2020 14:49:41 GMT, Claes Redestad wrote: > - Don't generate stub _verify_oop_subroutine_entry on startup if -VerifyOops > - Make VerifyOops check in calls to MacroAssembler::verify_oop inlineable. (VerifyOops is a develop flag, so this allows more aggressive code elimination in a few place) > - (trivial pile-on) remove unused set_word_if_not_zero > > Slightly improves static footprint, gets rid of a stub and reduce jitter during jitting in product builds. Then looks good to me. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1058 From kvn at openjdk.java.net Wed Nov 4 19:24:57 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 4 Nov 2020 19:24:57 GMT Subject: RFR: 8255900: x86: Reduce impact when VerifyOops is disabled In-Reply-To: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> References: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> Message-ID: <1quZg5MPENLj0Nlu32wA3emIPtcObY4IVBYCxYsI-wY=.b987385a-fa10-4a5a-a37a-b3816651aeb8@github.com> On Wed, 4 Nov 2020 14:49:41 GMT, Claes Redestad wrote: > - Don't generate stub _verify_oop_subroutine_entry on startup if -VerifyOops > - Make VerifyOops check in calls to MacroAssembler::verify_oop inlineable. (VerifyOops is a develop flag, so this allows more aggressive code elimination in a few place) > - (trivial pile-on) remove unused set_word_if_not_zero > > Slightly improves static footprint, gets rid of a stub and reduce jitter during jitting in product builds. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1058 From pchilanomate at openjdk.java.net Wed Nov 4 19:34:55 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 4 Nov 2020 19:34:55 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v3] In-Reply-To: <-k2h1RQzmL0Kzj-snh0ojk4Qdv7X06t9Jb_QAqdSzk8=.0f5ddbd0-85eb-45ab-8624-25c68c9303cc@github.com> References: <5Nooh2OHBkGysZN9EEQuKYYP-dZH_J_hU1_P2oTjXxM=.d38455e2-68e5-484f-825a-4ef384d9a0db@github.com> <-k2h1RQzmL0Kzj-snh0ojk4Qdv7X06t9Jb_QAqdSzk8=.0f5ddbd0-85eb-45ab-8624-25c68c9303cc@github.com> Message-ID: On Wed, 4 Nov 2020 14:24:00 GMT, Robbin Ehn wrote: > > Hi Robbin, > > Thanks, for looking at this. > > > > > How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)? > > > > > > > > > But _suspend_flag have nothing to do with safepoint polling, handling it with SafepointMechanism doesn't seem right? > > > Yes, but today we are already checking the _suspend_flag cases inside SS::block(), so this would only add a method to explicitly do that if you want, i.e. make it visible. In any case, I'm fine with both ways of doing it. I can leave as it is right now and see if David is fine with that. > > > > > > Patricio > > > Thanks, Robbin > > > > That works for me. > > > > ## Thanks, > > > > David > > Skimming a bit, as far as I can see void ThreadSafepointState::handle_polling_page_exception() should use ThreadInVMfromJava and in the other path ThreadInVMfromJavaNoAsyncException. > No? Yes, that was actually v1 but then I agreed with David that it was better to make explicit calls. Let me know though if you are still okay with this version. I see that you want to properly transition to vm before going to thread_blocked but as we discussed offline we will need more work to fix all instances of that. : ) Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From minqi at openjdk.java.net Wed Nov 4 20:12:55 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 4 Nov 2020 20:12:55 GMT Subject: RFR: 8255860: Clean up CDS logging related to lambda In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 16:32:33 GMT, Ioi Lam wrote: > A small clean up to make the logging more manageable. > > [1] Moved some debug printing from `tty->print_cr()` to `-Xlog:cds+lambda=debug` > [2] Moved some logs from `-Xlog:cds` to `-Xlog:cds+lambda` LGTM ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1062 From redestad at openjdk.java.net Wed Nov 4 20:41:14 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 4 Nov 2020 20:41:14 GMT Subject: RFR: 8255900: x86: Reduce impact when VerifyOops is disabled [v2] In-Reply-To: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> References: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> Message-ID: > - Don't generate stub _verify_oop_subroutine_entry on startup if -VerifyOops > - Make VerifyOops check in calls to MacroAssembler::verify_oop inlineable. (VerifyOops is a develop flag, so this allows more aggressive code elimination in a few place) > - (trivial pile-on) remove unused set_word_if_not_zero > > Slightly improves static footprint, gets rid of a stub and reduce jitter during jitting in product builds. 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 seven additional commits since the last revision: - Revert arm/aarch64 changes - Merge branch 'master' into verify_oop_stub - Apply similar improvements on arm/aarch64 - Fix copy-paste error - add checked variants of _verify_oop to avoid calls in product builds - Merge branch 'master' into verify_oop_stub - Cleanup verify_oop ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1058/files - new: https://git.openjdk.java.net/jdk/pull/1058/files/0e083d99..5407d476 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1058&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1058&range=00-01 Stats: 1820 lines in 271 files changed: 737 ins; 712 del; 371 mod Patch: https://git.openjdk.java.net/jdk/pull/1058.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1058/head:pull/1058 PR: https://git.openjdk.java.net/jdk/pull/1058 From redestad at openjdk.java.net Wed Nov 4 21:43:00 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 4 Nov 2020 21:43:00 GMT Subject: Integrated: 8255900: x86: Reduce impact when VerifyOops is disabled In-Reply-To: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> References: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> Message-ID: On Wed, 4 Nov 2020 14:49:41 GMT, Claes Redestad wrote: > - Don't generate stub _verify_oop_subroutine_entry on startup if -VerifyOops > - Make VerifyOops check in calls to MacroAssembler::verify_oop inlineable. (VerifyOops is a develop flag, so this allows more aggressive code elimination in a few place) > - (trivial pile-on) remove unused set_word_if_not_zero > > Slightly improves static footprint, gets rid of a stub and reduce jitter during jitting in product builds. This pull request has now been integrated. Changeset: a0ade220 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/a0ade220 Stats: 27 lines in 4 files changed: 13 ins; 9 del; 5 mod 8255900: x86: Reduce impact when VerifyOops is disabled Reviewed-by: neliasso, minqi, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/1058 From redestad at openjdk.java.net Wed Nov 4 21:42:59 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 4 Nov 2020 21:42:59 GMT Subject: RFR: 8255900: x86: Reduce impact when VerifyOops is disabled [v2] In-Reply-To: <1quZg5MPENLj0Nlu32wA3emIPtcObY4IVBYCxYsI-wY=.b987385a-fa10-4a5a-a37a-b3816651aeb8@github.com> References: <4KIoPcjQ3ibI-BXMRVwuBHrVRekcsQDaEepwo2gIrmc=.7704e62b-771e-451f-83ea-8875524a064f@github.com> <1quZg5MPENLj0Nlu32wA3emIPtcObY4IVBYCxYsI-wY=.b987385a-fa10-4a5a-a37a-b3816651aeb8@github.com> Message-ID: On Wed, 4 Nov 2020 19:22:33 GMT, Vladimir Kozlov 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 seven additional commits since the last revision: >> >> - Revert arm/aarch64 changes >> - Merge branch 'master' into verify_oop_stub >> - Apply similar improvements on arm/aarch64 >> - Fix copy-paste error >> - add checked variants of _verify_oop to avoid calls in product builds >> - Merge branch 'master' into verify_oop_stub >> - Cleanup verify_oop > > Good. @vnkozlov @neliasso @yminqi - thank you for reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/1058 From david.holmes at oracle.com Wed Nov 4 22:27:15 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 Nov 2020 08:27:15 +1000 Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v3] In-Reply-To: <-k2h1RQzmL0Kzj-snh0ojk4Qdv7X06t9Jb_QAqdSzk8=.0f5ddbd0-85eb-45ab-8624-25c68c9303cc@github.com> References: <5Nooh2OHBkGysZN9EEQuKYYP-dZH_J_hU1_P2oTjXxM=.d38455e2-68e5-484f-825a-4ef384d9a0db@github.com> <-k2h1RQzmL0Kzj-snh0ojk4Qdv7X06t9Jb_QAqdSzk8=.0f5ddbd0-85eb-45ab-8624-25c68c9303cc@github.com> Message-ID: On 5/11/2020 12:26 am, Robbin Ehn wrote: > On Wed, 4 Nov 2020 14:05:52 GMT, Patricio Chilano Mateo wrote: > >> Hi Robbin, >> >> Thanks, for looking at this. >> >>>>> How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)? >>> >>> >>> But _suspend_flag have nothing to do with safepoint polling, handling it with SafepointMechanism doesn't seem right? >>> Yes, but today we are already checking the _suspend_flag cases inside SS::block(), so this would only add a method to explicitly do that if you want, i.e. make it visible. In any case, I'm fine with both ways of doing it. I can leave as it is right now and see if David is fine with that. >> >> Patricio >> >>> Thanks, Robbin >>>> That works for me. >>>> ## Thanks, >>>> David > > Skimming a bit, as far as I can see void ThreadSafepointState::handle_polling_page_exception() should use ThreadInVMfromJava and in the other path ThreadInVMfromJavaNoAsyncException. > No? No :) I strongly object to using dummy thread-state transitions just to get the side-effects that are part of real thread-state transitions. If you need that side-effect in this code then it should be explicit in this code. And when we have a recurring pattern like: SafepointMechanism::process_if_requested(THREAD); if (THREAD->has_special_runtime_exit_condition()) { THREAD->handle_special_runtime_exit_condition(checkAsyncs); } it says to me that we are missing an appropriate API abstraction to capture why we need these checks in the calling code. Whether there are things presently inside handle_special_runtime_exit_condition that are not relevant to these calls sites (eg. suspend flag) is a different issue. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/913 > From redestad at openjdk.java.net Wed Nov 4 22:43:03 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 4 Nov 2020 22:43:03 GMT Subject: RFR: 8255909: Remove unused delayed_value methods Message-ID: Usage of and definitions of Assembler::delayed_value have been removed, but declarations linger along with various platform specific definitions of delayed_value_impl (all of which areunused) Clean up and remove. Untested on arm/aarch/ppc/s390, but as there are no mentions of delayed_value in the repository after this cleanup this is hopefully OK. ------------- Commit messages: - Remove unused delayed_value methods Changes: https://git.openjdk.java.net/jdk/pull/1065/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1065&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255909 Stats: 181 lines in 15 files changed: 0 ins; 181 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1065.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1065/head:pull/1065 PR: https://git.openjdk.java.net/jdk/pull/1065 From minqi at openjdk.java.net Wed Nov 4 23:46:55 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 4 Nov 2020 23:46:55 GMT Subject: RFR: 8255909: Remove unused delayed_value methods In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 22:12:29 GMT, Claes Redestad wrote: > Usage of and definitions of Assembler::delayed_value have been removed, but declarations linger along with various platform specific definitions of delayed_value_impl (all of which areunused) > > Clean up and remove. > > Untested on arm/aarch/ppc/s390, but as there are no mentions of delayed_value in the repository after this cleanup this is hopefully OK. Looks good to me. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1065 From coleenp at openjdk.java.net Thu Nov 5 00:08:55 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 5 Nov 2020 00:08:55 GMT Subject: RFR: 8255909: Remove unused delayed_value methods In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 22:12:29 GMT, Claes Redestad wrote: > Usage of and definitions of Assembler::delayed_value have been removed, but declarations linger along with various platform specific definitions of delayed_value_impl (all of which areunused) > > Clean up and remove. > > Untested on arm/aarch/ppc/s390, but as there are no mentions of delayed_value in the repository after this cleanup this is hopefully OK. Wow, this seems to be code left over from sparc. Looks good, and trivial if it builds. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1065 From iklam at openjdk.java.net Thu Nov 5 00:17:55 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 5 Nov 2020 00:17:55 GMT Subject: RFR: 8255756: Disabling logging does unnecessary work In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 12:43:42 GMT, Claes Redestad wrote: > When disabling UL outputs - for example when shutting down the JVM - we are doing some unnecessary work: > > - we always disable all outputs in bulk, but the routine searches up outputs one by one in the LogTagSet output lists - instead we could just drop all nodes in these lists in one quick pass. > - when finalizing for a JVM shutdown, it's unnecessary to update decorators > > While not technically startup this gets rid of some noise on JVM exit (~45k instructions) that show up when using full JVM executions as a proxy for startup testing (or when running many shortlived JVMs back-to-back). Changes requested by iklam (Reviewer). src/hotspot/share/logging/logOutputList.cpp line 72: > 70: > 71: void LogOutputList::clear() { > 72: // Grab the linked list I am not quite sure how the LogOutputList is synchronized. I think you will probably need to call `wait_until_no_readers()` here. ------------- PR: https://git.openjdk.java.net/jdk/pull/1005 From kvn at openjdk.java.net Thu Nov 5 04:27:00 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 5 Nov 2020 04:27:00 GMT Subject: RFR: 8255914: [AOT] Using AOT flag should give warning when AOT is not included in build Message-ID: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> Currently if AOT feature is not included in a build AOT flags specified on command line are silently ignored: $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version java version "16-internal" 2021-03-16 It should give warning: $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version Java HotSpot(TM) 64-Bit Server VM warning: -XX:+UseAOT not supported in this VM java version "16-internal" 2021-03-16 ------------- Commit messages: - 8255914: [AOT] Using AOT flag should give warning when AOT is not included in build Changes: https://git.openjdk.java.net/jdk/pull/1071/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1071&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255914 Stats: 28 lines in 2 files changed: 28 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1071/head:pull/1071 PR: https://git.openjdk.java.net/jdk/pull/1071 From dholmes at openjdk.java.net Thu Nov 5 04:34:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 5 Nov 2020 04:34:56 GMT Subject: RFR: 8255914: [AOT] Using AOT flag should give warning when AOT is not included in build In-Reply-To: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> References: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> Message-ID: On Thu, 5 Nov 2020 04:21:01 GMT, Vladimir Kozlov wrote: > Currently if AOT feature is not included in a build AOT flags specified on command line are silently ignored: > $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version > java version "16-internal" 2021-03-16 > > It should give warning: > > $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version > Java HotSpot(TM) 64-Bit Server VM warning: -XX:+UseAOT not supported in this VM > java version "16-internal" 2021-03-16 Hi Vladimir, This all looks fine, but can you simply replace UNSUPPORTED_OPTION_NULL with UNSUPPORTED_OPTION_INIT and update the two existing usages, so that we don't have three versions of the macro? Thanks, David ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1071 From kvn at openjdk.java.net Thu Nov 5 05:06:55 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 5 Nov 2020 05:06:55 GMT Subject: RFR: 8255914: [AOT] Using AOT flag should give warning when AOT is not included in build In-Reply-To: References: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> Message-ID: On Thu, 5 Nov 2020 04:32:30 GMT, David Holmes wrote: > This all looks fine, but can you simply replace UNSUPPORTED_OPTION_NULL with UNSUPPORTED_OPTION_INIT and update the two existing usages, so that we don't have three versions of the macro? Okay. I agree with that. But, please, note it will change current VM behavior for these flags. UNSUPPORTED_OPTION_INIT macro unconditionally set flag's value without checking current value and it gives warning regardless value specified on command line. UNSUPPORTED_OPTION_NULL macro does not give warning if flag's value specified on command line is NULL. ------------- PR: https://git.openjdk.java.net/jdk/pull/1071 From iklam at openjdk.java.net Thu Nov 5 05:23:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 5 Nov 2020 05:23:57 GMT Subject: RFR: 8255860: Clean up CDS logging related to lambda In-Reply-To: <5WMC4tgIYAj4OSuawwovEIRWAAmmwyHVYc64iDCYR6M=.7bb1e69f-01e0-471c-aced-af8d6f209c91@github.com> References: <5WMC4tgIYAj4OSuawwovEIRWAAmmwyHVYc64iDCYR6M=.7bb1e69f-01e0-471c-aced-af8d6f209c91@github.com> Message-ID: On Wed, 4 Nov 2020 18:42:44 GMT, Calvin Cheung wrote: >> A small clean up to make the logging more manageable. >> >> [1] Moved some debug printing from `tty->print_cr()` to `-Xlog:cds+lambda=debug` >> [2] Moved some logs from `-Xlog:cds` to `-Xlog:cds+lambda` > > The cleanup looks good. Just couple of nits below. Thanks @calvinccheung and @yminqi for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1062 From iklam at openjdk.java.net Thu Nov 5 05:23:58 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 5 Nov 2020 05:23:58 GMT Subject: Integrated: 8255860: Clean up CDS logging related to lambda In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 16:32:33 GMT, Ioi Lam wrote: > A small clean up to make the logging more manageable. > > [1] Moved some debug printing from `tty->print_cr()` to `-Xlog:cds+lambda=debug` > [2] Moved some logs from `-Xlog:cds` to `-Xlog:cds+lambda` This pull request has now been integrated. Changeset: 397bae20 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/397bae20 Stats: 29 lines in 6 files changed: 5 ins; 1 del; 23 mod 8255860: Clean up CDS logging related to lambda Reviewed-by: ccheung, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/1062 From david.holmes at oracle.com Thu Nov 5 06:02:51 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 Nov 2020 16:02:51 +1000 Subject: RFR: 8255914: [AOT] Using AOT flag should give warning when AOT is not included in build In-Reply-To: References: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> Message-ID: <1b9a2b3c-b9e2-b8aa-a9c9-867f8f3986dd@oracle.com> On 5/11/2020 3:06 pm, Vladimir Kozlov wrote: > On Thu, 5 Nov 2020 04:32:30 GMT, David Holmes wrote: > >> This all looks fine, but can you simply replace UNSUPPORTED_OPTION_NULL with UNSUPPORTED_OPTION_INIT and update the two existing usages, so that we don't have three versions of the macro? > > Okay. I agree with that. > > But, please, note it will change current VM behavior for these flags. > UNSUPPORTED_OPTION_INIT macro unconditionally set flag's value without checking current value and it gives warning regardless value specified on command line. > UNSUPPORTED_OPTION_NULL macro does not give warning if flag's value specified on command line is NULL. Sorry I missed that subtlety in how the macros are expressed. Please leave as is. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1071 > From dholmes at openjdk.java.net Thu Nov 5 06:05:54 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 5 Nov 2020 06:05:54 GMT Subject: RFR: 8255914: [AOT] Using AOT flag should give warning when AOT is not included in build In-Reply-To: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> References: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> Message-ID: On Thu, 5 Nov 2020 04:21:01 GMT, Vladimir Kozlov wrote: > Currently if AOT feature is not included in a build AOT flags specified on command line are silently ignored: > $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version > java version "16-internal" 2021-03-16 > > It should give warning: > > $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version > Java HotSpot(TM) 64-Bit Server VM warning: -XX:+UseAOT not supported in this VM > java version "16-internal" 2021-03-16 Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1071 From kvn at openjdk.java.net Thu Nov 5 06:11:54 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 5 Nov 2020 06:11:54 GMT Subject: RFR: 8255914: [AOT] Using AOT flag should give warning when AOT is not included in build In-Reply-To: References: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> Message-ID: On Thu, 5 Nov 2020 06:03:27 GMT, David Holmes wrote: >> Currently if AOT feature is not included in a build AOT flags specified on command line are silently ignored: >> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version >> java version "16-internal" 2021-03-16 >> >> It should give warning: >> >> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version >> Java HotSpot(TM) 64-Bit Server VM warning: -XX:+UseAOT not supported in this VM >> java version "16-internal" 2021-03-16 > > Marked as reviewed by dholmes (Reviewer). Thank you, David. ------------- PR: https://git.openjdk.java.net/jdk/pull/1071 From shade at openjdk.java.net Thu Nov 5 06:33:54 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 5 Nov 2020 06:33:54 GMT Subject: Integrated: 8255890: Zero: remove unused methods from BytecodeInterpreter In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 16:28:05 GMT, Aleksey Shipilev wrote: > There are lots of local/stack management methods that are not used at all. Macro-definitions are used instead. Can clean them up to avoid further bitrot. This pull request has now been integrated. Changeset: 60e4aca8 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/60e4aca8 Stats: 186 lines in 2 files changed: 1 ins; 185 del; 0 mod 8255890: Zero: remove unused methods from BytecodeInterpreter Reviewed-by: coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1060 From thartmann at openjdk.java.net Thu Nov 5 07:40:55 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 5 Nov 2020 07:40:55 GMT Subject: RFR: 8255909: Remove unused delayed_value methods In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 22:12:29 GMT, Claes Redestad wrote: > Usage of and definitions of Assembler::delayed_value have been removed, but declarations linger along with various platform specific definitions of delayed_value_impl (all of which areunused) > > Clean up and remove. > > Untested on arm/aarch/ppc/s390, but as there are no mentions of delayed_value in the repository after this cleanup this is hopefully OK. Nice cleanup! ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1065 From redestad at openjdk.java.net Thu Nov 5 08:39:54 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 5 Nov 2020 08:39:54 GMT Subject: RFR: 8255909: Remove unused delayed_value methods In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 23:44:33 GMT, Yumin Qi wrote: >> Usage of and definitions of Assembler::delayed_value have been removed, but declarations linger along with various platform specific definitions of delayed_value_impl (all of which areunused) >> >> Clean up and remove. >> >> Untested on arm/aarch/ppc/s390, but as there are no mentions of delayed_value in the repository after this cleanup this is hopefully OK. > > Looks good to me. @yminqi @coleenp @TobiHartmann - thanks you for reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/1065 From redestad at openjdk.java.net Thu Nov 5 08:39:55 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 5 Nov 2020 08:39:55 GMT Subject: Integrated: 8255909: Remove unused delayed_value methods In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 22:12:29 GMT, Claes Redestad wrote: > Usage of and definitions of Assembler::delayed_value have been removed, but declarations linger along with various platform specific definitions of delayed_value_impl (all of which areunused) > > Clean up and remove. > > Untested on arm/aarch/ppc/s390, but as there are no mentions of delayed_value in the repository after this cleanup this is hopefully OK. This pull request has now been integrated. Changeset: 700447f7 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/700447f7 Stats: 181 lines in 15 files changed: 0 ins; 181 del; 0 mod 8255909: Remove unused delayed_value methods Reviewed-by: minqi, coleenp, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/1065 From redestad at openjdk.java.net Thu Nov 5 10:59:21 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 5 Nov 2020 10:59:21 GMT Subject: RFR: 8255756: Disabling logging does unnecessary work [v2] In-Reply-To: References: Message-ID: > When disabling UL outputs - for example when shutting down the JVM - we are doing some unnecessary work: > > - we always disable all outputs in bulk, but the routine searches up outputs one by one in the LogTagSet output lists - instead we could just drop all nodes in these lists in one quick pass. > - when finalizing for a JVM shutdown, it's unnecessary to update decorators > > While not technically startup this gets rid of some noise on JVM exit (~45k instructions) that show up when using full JVM executions as a proxy for startup testing (or when running many shortlived JVMs back-to-back). 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 10 additional commits since the last revision: - clear should mimic remove_output and wait_until_no_readers before deleting nodes - Merge branch 'master' into disable_logging - Improve wording - Remove extra lines - Clean up and fix clear - Shortcut clearing of all outputs from tagsets - Shortcut clearing of all outputs from tagsets - Fix loop - Merge branch 'master' into disable_logging - Disabling logging outputs on exit does unnecessary work ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1005/files - new: https://git.openjdk.java.net/jdk/pull/1005/files/1b38bd77..e08bdfc6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1005&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1005&range=00-01 Stats: 10978 lines in 673 files changed: 5696 ins; 3531 del; 1751 mod Patch: https://git.openjdk.java.net/jdk/pull/1005.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1005/head:pull/1005 PR: https://git.openjdk.java.net/jdk/pull/1005 From iklam at openjdk.java.net Thu Nov 5 15:05:02 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 5 Nov 2020 15:05:02 GMT Subject: RFR: 8255756: Disabling logging does unnecessary work [v2] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 10:59:21 GMT, Claes Redestad wrote: >> When disabling UL outputs - for example when shutting down the JVM - we are doing some unnecessary work: >> >> - we always disable all outputs in bulk, but the routine searches up outputs one by one in the LogTagSet output lists - instead we could just drop all nodes in these lists in one quick pass. >> - when finalizing for a JVM shutdown, it's unnecessary to update decorators >> >> While not technically startup this gets rid of some noise on JVM exit (~45k instructions) that show up when using full JVM executions as a proxy for startup testing (or when running many shortlived JVMs back-to-back). > > 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 10 additional commits since the last revision: > > - clear should mimic remove_output and wait_until_no_readers before deleting nodes > - Merge branch 'master' into disable_logging > - Improve wording > - Remove extra lines > - Clean up and fix clear > - Shortcut clearing of all outputs from tagsets > - Shortcut clearing of all outputs from tagsets > - Fix loop > - Merge branch 'master' into disable_logging > - Disabling logging outputs on exit does unnecessary work Lgtm ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1005 From pchilanomate at openjdk.java.net Thu Nov 5 16:22:56 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 5 Nov 2020 16:22:56 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v3] In-Reply-To: <-k2h1RQzmL0Kzj-snh0ojk4Qdv7X06t9Jb_QAqdSzk8=.0f5ddbd0-85eb-45ab-8624-25c68c9303cc@github.com> References: <5Nooh2OHBkGysZN9EEQuKYYP-dZH_J_hU1_P2oTjXxM=.d38455e2-68e5-484f-825a-4ef384d9a0db@github.com> <-k2h1RQzmL0Kzj-snh0ojk4Qdv7X06t9Jb_QAqdSzk8=.0f5ddbd0-85eb-45ab-8624-25c68c9303cc@github.com> Message-ID: On Wed, 4 Nov 2020 14:24:00 GMT, Robbin Ehn wrote: >> Hi Robbin, >> >> Thanks, for looking at this. >> >>> > > How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)? >>> >>> But _suspend_flag have nothing to do with safepoint polling, handling it with SafepointMechanism doesn't seem right? >> Yes, but today we are already checking the _suspend_flag cases inside SS::block(), so this would only add a method to explicitly do that if you want, i.e. make it visible. In any case, I'm fine with both ways of doing it. I can leave as it is right now and see if David is fine with that. >> >> Patricio >>> Thanks, Robbin >>> >>> > That works for me. >>> > ## Thanks, >>> > David > >> Hi Robbin, >> >> Thanks, for looking at this. >> >> > > > How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)? >> > >> > >> > But _suspend_flag have nothing to do with safepoint polling, handling it with SafepointMechanism doesn't seem right? >> > Yes, but today we are already checking the _suspend_flag cases inside SS::block(), so this would only add a method to explicitly do that if you want, i.e. make it visible. In any case, I'm fine with both ways of doing it. I can leave as it is right now and see if David is fine with that. >> >> Patricio >> >> > Thanks, Robbin >> > > That works for me. >> > > ## Thanks, >> > > David > > Skimming a bit, as far as I can see void ThreadSafepointState::handle_polling_page_exception() should use ThreadInVMfromJava and in the other path ThreadInVMfromJavaNoAsyncException. > No? @robehn are you okay with SafepointMechanism::process_if_requested_with_exit_check()? Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From iveresov at openjdk.java.net Thu Nov 5 17:13:00 2020 From: iveresov at openjdk.java.net (Igor Veresov) Date: Thu, 5 Nov 2020 17:13:00 GMT Subject: RFR: 8255914: [AOT] Using AOT flag should give warning when AOT is not included in build In-Reply-To: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> References: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> Message-ID: On Thu, 5 Nov 2020 04:21:01 GMT, Vladimir Kozlov wrote: > Currently if AOT feature is not included in a build AOT flags specified on command line are silently ignored: > $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version > java version "16-internal" 2021-03-16 > > It should give warning: > > $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version > Java HotSpot(TM) 64-Bit Server VM warning: -XX:+UseAOT not supported in this VM > java version "16-internal" 2021-03-16 Marked as reviewed by iveresov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1071 From kvn at openjdk.java.net Thu Nov 5 17:21:58 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 5 Nov 2020 17:21:58 GMT Subject: RFR: 8255914: [AOT] Using AOT flag should give warning when AOT is not included in build In-Reply-To: References: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> Message-ID: On Thu, 5 Nov 2020 17:09:47 GMT, Igor Veresov wrote: >> Currently if AOT feature is not included in a build AOT flags specified on command line are silently ignored: >> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version >> java version "16-internal" 2021-03-16 >> >> It should give warning: >> >> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version >> Java HotSpot(TM) 64-Bit Server VM warning: -XX:+UseAOT not supported in this VM >> java version "16-internal" 2021-03-16 > > Marked as reviewed by iveresov (Reviewer). Thank you, Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/1071 From kvn at openjdk.java.net Thu Nov 5 17:21:59 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 5 Nov 2020 17:21:59 GMT Subject: Integrated: 8255914: [AOT] Using AOT flag should give warning when AOT is not included in build In-Reply-To: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> References: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> Message-ID: <9IE2ar8hY-gqvpI2iYgnybZ62HNwuE_Yhc2wFMZhR8A=.a50748df-89b9-4a55-af13-24af45393be2@github.com> On Thu, 5 Nov 2020 04:21:01 GMT, Vladimir Kozlov wrote: > Currently if AOT feature is not included in a build AOT flags specified on command line are silently ignored: > $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version > java version "16-internal" 2021-03-16 > > It should give warning: > > $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version > Java HotSpot(TM) 64-Bit Server VM warning: -XX:+UseAOT not supported in this VM > java version "16-internal" 2021-03-16 This pull request has now been integrated. Changeset: 1b59595e Author: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/1b59595e Stats: 28 lines in 2 files changed: 28 ins; 0 del; 0 mod 8255914: [AOT] Using AOT flag should give warning when AOT is not included in build Reviewed-by: dholmes, iveresov ------------- PR: https://git.openjdk.java.net/jdk/pull/1071 From neliasso at openjdk.java.net Thu Nov 5 17:31:03 2020 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Thu, 5 Nov 2020 17:31:03 GMT Subject: RFR: 8255914: [AOT] Using AOT flag should give warning when AOT is not included in build In-Reply-To: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> References: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> Message-ID: On Thu, 5 Nov 2020 04:21:01 GMT, Vladimir Kozlov wrote: > Currently if AOT feature is not included in a build AOT flags specified on command line are silently ignored: > $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version > java version "16-internal" 2021-03-16 > > It should give warning: > > $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version > Java HotSpot(TM) 64-Bit Server VM warning: -XX:+UseAOT not supported in this VM > java version "16-internal" 2021-03-16 Looks good! ------------- PR: https://git.openjdk.java.net/jdk/pull/1071 From kvn at openjdk.java.net Thu Nov 5 17:38:01 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 5 Nov 2020 17:38:01 GMT Subject: RFR: 8255914: [AOT] Using AOT flag should give warning when AOT is not included in build In-Reply-To: References: <5LnO5kvk5GEiviuVD8BG7zLJggwAEA3Q32UnHnMogh4=.ce751828-6589-4baa-b4a9-9a964d3d2541@github.com> Message-ID: <1x8KZqksew3sfjsyqjhCLYg6SqO_CaF4Vehmq2WvqKU=.5961cfd0-dea0-478e-ba93-2b54153fe343@github.com> On Thu, 5 Nov 2020 17:27:52 GMT, Nils Eliasson wrote: >> Currently if AOT feature is not included in a build AOT flags specified on command line are silently ignored: >> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version >> java version "16-internal" 2021-03-16 >> >> It should give warning: >> >> $ java -XX:+UnlockExperimentalVMOptions -XX:+UseAOT -version >> Java HotSpot(TM) 64-Bit Server VM warning: -XX:+UseAOT not supported in this VM >> java version "16-internal" 2021-03-16 > > Looks good! Thank you, Nils ------------- PR: https://git.openjdk.java.net/jdk/pull/1071 From rehn at openjdk.java.net Thu Nov 5 18:19:00 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 5 Nov 2020 18:19:00 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v3] In-Reply-To: <-k2h1RQzmL0Kzj-snh0ojk4Qdv7X06t9Jb_QAqdSzk8=.0f5ddbd0-85eb-45ab-8624-25c68c9303cc@github.com> References: <5Nooh2OHBkGysZN9EEQuKYYP-dZH_J_hU1_P2oTjXxM=.d38455e2-68e5-484f-825a-4ef384d9a0db@github.com> <-k2h1RQzmL0Kzj-snh0ojk4Qdv7X06t9Jb_QAqdSzk8=.0f5ddbd0-85eb-45ab-8624-25c68c9303cc@github.com> Message-ID: On Wed, 4 Nov 2020 14:24:00 GMT, Robbin Ehn wrote: >> Hi Robbin, >> >> Thanks, for looking at this. >> >>> > > How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)? >>> >>> But _suspend_flag have nothing to do with safepoint polling, handling it with SafepointMechanism doesn't seem right? >> Yes, but today we are already checking the _suspend_flag cases inside SS::block(), so this would only add a method to explicitly do that if you want, i.e. make it visible. In any case, I'm fine with both ways of doing it. I can leave as it is right now and see if David is fine with that. >> >> Patricio >>> Thanks, Robbin >>> >>> > That works for me. >>> > ## Thanks, >>> > David > >> Hi Robbin, >> >> Thanks, for looking at this. >> >> > > > How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)? >> > >> > >> > But _suspend_flag have nothing to do with safepoint polling, handling it with SafepointMechanism doesn't seem right? >> > Yes, but today we are already checking the _suspend_flag cases inside SS::block(), so this would only add a method to explicitly do that if you want, i.e. make it visible. In any case, I'm fine with both ways of doing it. I can leave as it is right now and see if David is fine with that. >> >> Patricio >> >> > Thanks, Robbin >> > > That works for me. >> > > ## Thanks, >> > > David > > Skimming a bit, as far as I can see void ThreadSafepointState::handle_polling_page_exception() should use ThreadInVMfromJava and in the other path ThreadInVMfromJavaNoAsyncException. > No? > @robehn are you okay with SafepointMechanism::process_if_requested_with_exit_check()? > > Patricio Yes, with a caveat; I may try to move it later. > SafepointMechanism::process_if_requested(THREAD); > if (THREAD->has_special_runtime_exit_condition()) { > THREAD->handle_special_runtime_exit_condition(checkAsyncs); > } > > it says to me that we are missing an appropriate API abstraction to > capture why we need these checks in the calling code. Yes in this is what interfaceSupport.xxx gives us. So I would had preferred a method in there or use transition RAII thingies. (I argue we would not be using them for side effect, because you should to be in VM to be blocked. E.g. blocked in native makes no sense and we have no 'blocked' in java. So to me this is just a place where cheat transition because we can get away with it.) > > Whether there are things presently inside > handle_special_runtime_exit_condition that are not relevant to these > calls sites (eg. suspend flag) is a different issue. > > Cheers, > David ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From ayang at openjdk.java.net Thu Nov 5 18:38:58 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 5 Nov 2020 18:38:58 GMT Subject: RFR: 8255598: [PPC64] assert(Universe::heap()->is_in(result)) failed: object not in heap In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 16:46:43 GMT, Martin Doerr wrote: > JDK-8237363 introduced "assert(Universe::heap()->is_in..." check in CompressedOops::decode functions. > This assertion restricts the usability of the decode functions. There are periods of time (during GC) at which we can't use " Universe::heap()->is_in" because the pointer gets switched between old and new location, but "Universe::heap()->is_in" is not yet accurate. > PPC64 code has a usage of CompressedOops::decode which is affected by this problem. (It was observed with SerialGC, see JBS.) > We could also use a weaker assertion, but seems like other people value the stronger assertion more. So I suggest to use decode_raw as workaround for PPC64. Given the following naming pair, I would have guess that `decode_raw` can handle null properly, so the explicit check of null in this PR struck me as a surprise. Why so? static inline oop decode_raw_not_null(narrowOop v); static inline oop decode_raw(narrowOop v); I think having some concise inline comments to explain why `decode_raw` is used over `decode` could improve readability. ------------- Changes requested by ayang (Author). PR: https://git.openjdk.java.net/jdk/pull/1078 From pchilanomate at openjdk.java.net Thu Nov 5 19:44:16 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 5 Nov 2020 19:44:16 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v4] 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 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 8255384-SSBlock - Add SafepointMechanism::process_if_requested_with_exit_check() - Merge branch 'master' into 8255384-SSBlock - Add explicit bool arg - Make direct calls instead of using transition wrappers - v1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/913/files - new: https://git.openjdk.java.net/jdk/pull/913/files/db8f076d..c68abac6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=913&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=913&range=02-03 Stats: 8299 lines in 604 files changed: 4364 ins; 2712 del; 1223 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 Nov 5 19:44:16 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 5 Nov 2020 19:44:16 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v3] In-Reply-To: References: <5Nooh2OHBkGysZN9EEQuKYYP-dZH_J_hU1_P2oTjXxM=.d38455e2-68e5-484f-825a-4ef384d9a0db@github.com> <-k2h1RQzmL0Kzj-snh0ojk4Qdv7X06t9Jb_QAqdSzk8=.0f5ddbd0-85eb-45ab-8624-25c68c9303cc@github.com> Message-ID: On Thu, 5 Nov 2020 18:16:38 GMT, Robbin Ehn wrote: > > @robehn are you okay with SafepointMechanism::process_if_requested_with_exit_check()? > > Patricio > > Yes, with a caveat; I may try to move it later. > Ok, sounds good. I'll update. ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From dcubed at openjdk.java.net Thu Nov 5 20:23:07 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 5 Nov 2020 20:23:07 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v4] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 19:44:16 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 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 > > 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 six additional commits since the last revision: > > - Merge branch 'master' into 8255384-SSBlock > - Add SafepointMechanism::process_if_requested_with_exit_check() > - Merge branch 'master' into 8255384-SSBlock > - Add explicit bool arg > - Make direct calls instead of using transition wrappers > - v1 Okay. It took me some time to be convinced of the equivalence, but I'm on-board at this point. The new code is much more clear and easy to reason about (once you convince yourself that the new, simpler code is equivalent to the older code). As @dholmes-ora likes to say: the proof is in the testing. I'll add that the proof will be in the stress testing. src/hotspot/share/runtime/safepoint.cpp line 961: > 959: // as otherwise we may never deliver it. > 960: if (self->has_async_condition()) { > 961: ThreadInVMfromJavaNoAsyncException __tiv(self); It's not clear to me why this if-block is deleted. You change to call SafepointMechanism::process_if_requested_with_exit_check(), but I don't see equivalent code there. Update: I found it in JavaThread::handle_special_runtime_exit_condition(). src/hotspot/share/runtime/safepoint.cpp line 982: > 980: } > 981: } > 982: } It's not clear to me why this if-block is deleted. You change to call SafepointMechanism::process_if_requested_with_exit_check(), but I don't see equivalent code there. Update: I found it in JavaThread::handle_special_runtime_exit_condition(). src/hotspot/share/runtime/safepoint.cpp line 952: > 950: // We never deliver an async exception at a polling point as the > 951: // compiler may not have an exception handler for it. The polling > 952: // code will notice the async and deoptimize and the exception will Perhaps a little rewording: code will notice the pending async exception, deoptimize and the exception will and then reformat the block comment a bit. src/hotspot/share/runtime/safepointMechanism.cpp line 83: > 81: // Otherwise we might load an old safepoint counter (for example). > 82: OrderAccess::loadload(); > 83: SafepointSynchronize::block(thread); Wasn't that comment just added recently? :-) src/hotspot/share/runtime/thread.cpp line 2510: > 2508: // Also check for pending async exception (not including unsafe access error). > 2509: // Note only the native==>VM/Java barriers can call this function and when > 2510: // thread state is _thread_in_native_trans. It's not clear to me why this if-block is deleted. You change to call SafepointMechanism::process_if_requested_with_exit_check(), but I don't see equivalent code there. Update: I found it in JavaThread::handle_special_runtime_exit_condition(). src/hotspot/share/runtime/thread.cpp line 2512: > 2510: // thread state is _thread_in_native_trans. > 2511: void JavaThread::check_special_condition_for_native_trans(JavaThread *thread) { > 2512: check_safepoint_and_suspend_for_native_trans(thread); Where's the equivalent of this JFR code? Update: I found it in JavaThread::handle_special_runtime_exit_condition(). src/hotspot/share/runtime/thread.cpp line 2503: > 2501: SafepointMechanism::process_if_requested_with_exit_check(thread, false /* check asyncs */); > 2502: } > 2503: I found the equivalent of this part of the if-statement in JavaThread::handle_special_runtime_exit_condition(). ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/913 From pchilanomate at openjdk.java.net Thu Nov 5 21:20:20 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 5 Nov 2020 21:20:20 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v4] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 20:20:25 GMT, Daniel D. Daugherty wrote: > Okay. It took me some time to be convinced of the equivalence, > but I'm on-board at this point. The new code is much more clear > and easy to reason about (once you convince yourself that the > new, simpler code is equivalent to the older code). > > As @dholmes-ora likes to say: the proof is in the testing. I'll add > that the proof will be in the stress testing. Sounds good. So far I tested it a lot in mach5 and locally and will run a last round before pushing. : ) Thanks Dan! > src/hotspot/share/runtime/safepoint.cpp line 952: > >> 950: // We never deliver an async exception at a polling point as the >> 951: // compiler may not have an exception handler for it. The polling >> 952: // code will notice the async and deoptimize and the exception will > > Perhaps a little rewording: > > code will notice the pending async exception, deoptimize and the exception will > > and then reformat the block comment a bit. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From pchilanomate at openjdk.java.net Thu Nov 5 21:20:19 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 5 Nov 2020 21:20:19 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v5] 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: fix comment in handle_polling_page_exception() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/913/files - new: https://git.openjdk.java.net/jdk/pull/913/files/c68abac6..ed4f8d4b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=913&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=913&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 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 Nov 5 21:20:21 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 5 Nov 2020 21:20:21 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v5] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 19:50:48 GMT, Daniel D. Daugherty wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> fix comment in handle_polling_page_exception() > > src/hotspot/share/runtime/safepointMechanism.cpp line 83: > >> 81: // Otherwise we might load an old safepoint counter (for example). >> 82: OrderAccess::loadload(); >> 83: SafepointSynchronize::block(thread); > > Wasn't that comment just added recently? :-) : ) Should have been there before that! ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From redestad at openjdk.java.net Thu Nov 5 21:23:00 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 5 Nov 2020 21:23:00 GMT Subject: RFR: 8255756: Disabling logging does unnecessary work [v2] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 15:02:14 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 10 additional commits since the last revision: >> >> - clear should mimic remove_output and wait_until_no_readers before deleting nodes >> - Merge branch 'master' into disable_logging >> - Improve wording >> - Remove extra lines >> - Clean up and fix clear >> - Shortcut clearing of all outputs from tagsets >> - Shortcut clearing of all outputs from tagsets >> - Fix loop >> - Merge branch 'master' into disable_logging >> - Disabling logging outputs on exit does unnecessary work > > Lgtm Thanks @iklam ! ------------- PR: https://git.openjdk.java.net/jdk/pull/1005 From redestad at openjdk.java.net Thu Nov 5 21:23:00 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 5 Nov 2020 21:23:00 GMT Subject: Integrated: 8255756: Disabling logging does unnecessary work In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 12:43:42 GMT, Claes Redestad wrote: > When disabling UL outputs - for example when shutting down the JVM - we are doing some unnecessary work: > > - we always disable all outputs in bulk, but the routine searches up outputs one by one in the LogTagSet output lists - instead we could just drop all nodes in these lists in one quick pass. > - when finalizing for a JVM shutdown, it's unnecessary to update decorators > > While not technically startup this gets rid of some noise on JVM exit (~45k instructions) that show up when using full JVM executions as a proxy for startup testing (or when running many shortlived JVMs back-to-back). This pull request has now been integrated. Changeset: e66fd6f0 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/e66fd6f0 Stats: 50 lines in 5 files changed: 32 ins; 4 del; 14 mod 8255756: Disabling logging does unnecessary work Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/1005 From david.holmes at oracle.com Thu Nov 5 22:19:33 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 Nov 2020 08:19:33 +1000 Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v3] In-Reply-To: References: <5Nooh2OHBkGysZN9EEQuKYYP-dZH_J_hU1_P2oTjXxM=.d38455e2-68e5-484f-825a-4ef384d9a0db@github.com> <-k2h1RQzmL0Kzj-snh0ojk4Qdv7X06t9Jb_QAqdSzk8=.0f5ddbd0-85eb-45ab-8624-25c68c9303cc@github.com> Message-ID: <5c2ba65a-c4b2-404b-cb4c-fd43eb224345@oracle.com> On 6/11/2020 4:19 am, Robbin Ehn wrote: > On Wed, 4 Nov 2020 14:24:00 GMT, Robbin Ehn wrote: > >>> Hi Robbin, >>> >>> Thanks, for looking at this. >>> >>>>>> How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)? >>>> >>>> But _suspend_flag have nothing to do with safepoint polling, handling it with SafepointMechanism doesn't seem right? >>> Yes, but today we are already checking the _suspend_flag cases inside SS::block(), so this would only add a method to explicitly do that if you want, i.e. make it visible. In any case, I'm fine with both ways of doing it. I can leave as it is right now and see if David is fine with that. >>> >>> Patricio >>>> Thanks, Robbin >>>> >>>>> That works for me. >>>>> ## Thanks, >>>>> David >> >>> Hi Robbin, >>> >>> Thanks, for looking at this. >>> >>>>>> How about SafepointMechanism::process_if_requested_with_exit_check(bool check_asyncs)? >>>> >>>> >>>> But _suspend_flag have nothing to do with safepoint polling, handling it with SafepointMechanism doesn't seem right? >>>> Yes, but today we are already checking the _suspend_flag cases inside SS::block(), so this would only add a method to explicitly do that if you want, i.e. make it visible. In any case, I'm fine with both ways of doing it. I can leave as it is right now and see if David is fine with that. >>> >>> Patricio >>> >>>> Thanks, Robbin >>>>> That works for me. >>>>> ## Thanks, >>>>> David >> >> Skimming a bit, as far as I can see void ThreadSafepointState::handle_polling_page_exception() should use ThreadInVMfromJava and in the other path ThreadInVMfromJavaNoAsyncException. >> No? > >> @robehn are you okay with SafepointMechanism::process_if_requested_with_exit_check()? >> >> Patricio > > Yes, with a caveat; I may try to move it later. > >> SafepointMechanism::process_if_requested(THREAD); >> if (THREAD->has_special_runtime_exit_condition()) { >> THREAD->handle_special_runtime_exit_condition(checkAsyncs); >> } >> >> it says to me that we are missing an appropriate API abstraction to >> capture why we need these checks in the calling code. > > Yes in this is what interfaceSupport.xxx gives us. > So I would had preferred a method in there or use transition RAII thingies. > (I argue we would not be using them for side effect, because you should to be in VM to be blocked. > E.g. blocked in native makes no sense and we have no 'blocked' in java. > So to me this is just a place where cheat transition because we can get away with it.) I don't understand what you are referring to here with reference to being blocked? The version 1 code used the transition helpers in a standalone/isolated way e.g.: { ThreadInVMfromJava tivm; } which transitions from Java to VM and back, for absolutely no reason other than to get the side-effects of doing those transitions. David ----- >> >> Whether there are things presently inside >> handle_special_runtime_exit_condition that are not relevant to these >> calls sites (eg. suspend flag) is a different issue. >> >> Cheers, >> David > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/913 > From dholmes at openjdk.java.net Thu Nov 5 22:24:05 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 5 Nov 2020 22:24:05 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v5] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 21:20:19 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 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 > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > fix comment in handle_polling_page_exception() Thanks for the updates! All LGTM. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/913 From mdoerr at openjdk.java.net Thu Nov 5 22:29:11 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 5 Nov 2020 22:29:11 GMT Subject: RFR: 8255598: [PPC64] assert(Universe::heap()->is_in(result)) failed: object not in heap [v2] In-Reply-To: References: Message-ID: > JDK-8237363 introduced "assert(Universe::heap()->is_in..." check in CompressedOops::decode functions. > This assertion restricts the usability of the decode functions. There are periods of time (during GC) at which we can't use " Universe::heap()->is_in" because the pointer gets switched between old and new location, but "Universe::heap()->is_in" is not yet accurate. > PPC64 code has a usage of CompressedOops::decode which is affected by this problem. (It was observed with SerialGC, see JBS.) > We could also use a weaker assertion, but seems like other people value the stronger assertion more. So I suggest to use decode_raw as workaround for PPC64. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: add comment and use CompressedOops::is_null ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1078/files - new: https://git.openjdk.java.net/jdk/pull/1078/files/4ffffa95..400ecfda Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1078&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1078&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1078.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1078/head:pull/1078 PR: https://git.openjdk.java.net/jdk/pull/1078 From mdoerr at openjdk.java.net Thu Nov 5 22:33:58 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 5 Nov 2020 22:33:58 GMT Subject: RFR: 8255598: [PPC64] assert(Universe::heap()->is_in(result)) failed: object not in heap [v2] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 18:36:16 GMT, Albert Mingkun Yang wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> add comment and use CompressedOops::is_null > > Given the following naming pair, I would have guess that `decode_raw` can handle null properly, so the explicit check of null in this PR struck me as a surprise. Why so? > > static inline oop decode_raw_not_null(narrowOop v); > static inline oop decode_raw(narrowOop v); > > I think having some concise inline comments to explain why `decode_raw` is used over `decode` could improve readability. @albertnetymk: Thanks for looking at this. I've added a comment. I was also surprised about that decode_raw doesn't handle null properly. I'd have expected decode_raw to call decode_raw_not_null, but it's implemented vice-versa. Therefore the null check before the call. Note that there's another usage with preceding null check in oopDesc::load_oop_raw. ------------- PR: https://git.openjdk.java.net/jdk/pull/1078 From dcubed at openjdk.java.net Thu Nov 5 22:45:07 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 5 Nov 2020 22:45:07 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v5] In-Reply-To: References: Message-ID: <2j3r8RMrYsmfUX-_Axokf29d5mDdIfbd_Tyq2lBzY6E=.2042ca3d-2937-4029-b745-3f94a4296c6a@github.com> On Thu, 5 Nov 2020 21:20:19 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 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 > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > fix comment in handle_polling_page_exception() Marked as reviewed by dcubed (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From pchilanomate at openjdk.java.net Thu Nov 5 23:51:03 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 5 Nov 2020 23:51:03 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v5] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 22:21:19 GMT, David Holmes wrote: > Thanks for the updates! All LGTM. > > David Great, thanks David! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From rehn at openjdk.java.net Fri Nov 6 08:39:04 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 6 Nov 2020 08:39:04 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v5] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 23:48:19 GMT, Patricio Chilano Mateo wrote: >> Thanks for the updates! All LGTM. >> >> David > >> Thanks for the updates! All LGTM. >> >> David > Great, thanks David! > > Patricio > { > ThreadInVMfromJava tivm; > } > > which transitions from Java to VM and back, for absolutely no reason > other than to get the side-effects of doing those transitions. As I see it, if you have an oop map and are executing in VM, you are technically in VM. But here we skip going to VM since SS:block used to need to know where you are going back to due to suspend flag is handle inside SS:block(). And the safepoint synchronizer will treat java/vm the same thus we can cheat. If the thread is in Java it is not guaranteed that it will have an oop map and it's not certain that it can be made walkable. Being blocked requires you to be walkable, thus going from java->blocked cannot be done as general rule. Instead of having a ton of special rules which no one can remember, the rule is you can only block in VM where we know you can be made walkable. Polling page exception handling can thus been seen as a cheat avoiding setting in vm since it will actually have no effect on the safepoint synchronizer. So no we are not looking for side-effects, we need to be in VM (at minimum technically) to become blocked. Thus the rules for going from VM to Java applies, and we should deliver e.g. async exceptions. { ThreadInVMfromJava tivm; SS:block() } Would be the preferred way of doing it. > > David > ----- ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From ayang at openjdk.java.net Fri Nov 6 09:13:58 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 6 Nov 2020 09:13:58 GMT Subject: RFR: 8255598: [PPC64] assert(Universe::heap()->is_in(result)) failed: object not in heap [v2] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 22:31:28 GMT, Martin Doerr wrote: > I've added a comment. Thank you for that. I believe `decode_raw` handles null well; `decode_raw_not_null` is there just to have an extra assertion when the caller *knows* that the oop is not null. > Note that there's another usage with preceding null check in oopDesc::load_oop_raw. Indeed, but I think that one is unnecessary as well, which could (or should) be addressed in this PR or another. ------------- PR: https://git.openjdk.java.net/jdk/pull/1078 From mdoerr at openjdk.java.net Fri Nov 6 09:38:54 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 6 Nov 2020 09:38:54 GMT Subject: RFR: 8255598: [PPC64] assert(Universe::heap()->is_in(result)) failed: object not in heap [v2] In-Reply-To: References: Message-ID: On Fri, 6 Nov 2020 09:11:23 GMT, Albert Mingkun Yang wrote: >> @albertnetymk: Thanks for looking at this. I've added a comment. >> I was also surprised about that decode_raw doesn't handle null properly. I'd have expected decode_raw to call decode_raw_not_null, but it's implemented vice-versa. Therefore the null check before the call. Note that there's another usage with preceding null check in oopDesc::load_oop_raw. > >> I've added a comment. > > Thank you for that. > > I believe `decode_raw` handles null well; `decode_raw_not_null` is there just to have an extra assertion when the caller *knows* that the oop is not null. > >> Note that there's another usage with preceding null check in oopDesc::load_oop_raw. > > Indeed, but I think that one is unnecessary as well, which could (or should) be addressed in this PR or another. Unfortunately, no. Assume we're using "HeapBasedNarrowOop". decode_raw adds the base, so decode_raw(0) returns base which is wrong. Also see Stefan's comment in the bug: "I see that decode and decode_raw has different semantics w.r.t. 0, so be careful if you change this code to use decode_raw" ------------- PR: https://git.openjdk.java.net/jdk/pull/1078 From ayang at openjdk.java.net Fri Nov 6 11:12:58 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 6 Nov 2020 11:12:58 GMT Subject: RFR: 8255598: [PPC64] assert(Universe::heap()->is_in(result)) failed: object not in heap [v2] In-Reply-To: References: Message-ID: On Fri, 6 Nov 2020 09:36:05 GMT, Martin Doerr wrote: > Assume we're using "HeapBasedNarrowOop". decode_raw adds the base, so decode_raw(0) returns base which is wrong. Yes, you are right. Thank you for pointing this out. ------------- PR: https://git.openjdk.java.net/jdk/pull/1078 From ayang at openjdk.java.net Fri Nov 6 11:12:57 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 6 Nov 2020 11:12:57 GMT Subject: RFR: 8255598: [PPC64] assert(Universe::heap()->is_in(result)) failed: object not in heap [v2] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 22:29:11 GMT, Martin Doerr wrote: >> JDK-8237363 introduced "assert(Universe::heap()->is_in..." check in CompressedOops::decode functions. >> This assertion restricts the usability of the decode functions. There are periods of time (during GC) at which we can't use " Universe::heap()->is_in" because the pointer gets switched between old and new location, but "Universe::heap()->is_in" is not yet accurate. >> PPC64 code has a usage of CompressedOops::decode which is affected by this problem. (It was observed with SerialGC, see JBS.) >> We could also use a weaker assertion, but seems like other people value the stronger assertion more. So I suggest to use decode_raw as workaround for PPC64. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > add comment and use CompressedOops::is_null Marked as reviewed by ayang (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/1078 From martin.doerr at sap.com Fri Nov 6 17:29:23 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 6 Nov 2020 17:29:23 +0000 Subject: Biased locking Obsoletion In-Reply-To: <7ca651a8-5861-92cf-5d31-6a7fd09700c6@oracle.com> References: <7ca651a8-5861-92cf-5d31-6a7fd09700c6@oracle.com> Message-ID: Hi Patricio, seems like nobody wanted to be the first person to reply. So I just share a few thoughts. Unfortunately, I haven't heard any feedback from end users. If the Biased Locking Code removal is not urgent because it's in the way for something else, I'd slightly prefer to remove it early in JDK17. My impression is that modern workloads are fine without BL, so typical JDK15 users will probably not notice it was switched off. Some old workloads are heavily affected, like SPEC jvm98. See performance drop on Power9: http://cr.openjdk.java.net/~mdoerr/BiasedLocking_Power9.png and on Intel Xeon E5: http://cr.openjdk.java.net/~mdoerr/BiasedLocking_XeonE5.png Are there any plans for mitigations? If so, it would be nice to implement them before finally removing BL. My 0.02$. Best regards, Martin > -----Original Message----- > From: hotspot-runtime-dev > On Behalf Of David Holmes > Sent: Dienstag, 3. November 2020 22:30 > To: Patricio Chilano ; hotspot-runtime- > dev at openjdk.java.net; hotspot-dev developers dev at openjdk.java.net> > Subject: Re: Biased locking Obsoletion > > Expanding to hotspot-dev. > > > On 4/11/2020 7:08 am, Patricio Chilano wrote: > > Hi all, > > > > As discussed in 8231264, the idea was to switch biased locking to false > > by default and deprecate all related flags with the intent to remove the > > code in a future release unless compelling evidence showed that the code > > is worth maintaining. > > I see there is only one issue that was filed since biased locking was > > disabled by default (https://github.com/openjdk/jdk/pull/542) that seems > > to have been addressed. As per 8231264 change, the code was set to be > > obsoleted in 16, so we are already in a position to remove biased > > locking code unless there are arguments for the contrary. The > > alternative would be to give more time and move biased locking > > obsoletion to a future release. > > Let me know your thoughts. > > > > Thanks, > > > > Patricio From patricio.chilano.mateo at oracle.com Sat Nov 7 07:52:30 2020 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Sat, 7 Nov 2020 02:52:30 -0500 Subject: Biased locking Obsoletion In-Reply-To: References: <7ca651a8-5861-92cf-5d31-6a7fd09700c6@oracle.com> Message-ID: Hi Martin, Thanks for your feedback. On 11/6/20 12:29 PM, Doerr, Martin wrote: > Hi Patricio, > > seems like nobody wanted to be the first person to reply. So I just share a few thoughts. > > Unfortunately, I haven't heard any feedback from end users. > If the Biased Locking Code removal is not urgent because it's in the way for something else, I'd slightly prefer to remove it early in JDK17. > > My impression is that modern workloads are fine without BL, so typical JDK15 users will probably not notice it was switched off. > > Some old workloads are heavily affected, like SPEC jvm98. See performance drop on Power9: > http://cr.openjdk.java.net/~mdoerr/BiasedLocking_Power9.png > and on Intel Xeon E5: > http://cr.openjdk.java.net/~mdoerr/BiasedLocking_XeonE5.png > > Are there any plans for mitigations? > If so, it would be nice to implement them before finally removing BL. SPECjvm98 uses some classes that synchronize on pretty much every access and almost all workloads are single-threaded. To give you a couple of examples, I logged all synchronizations attempts from _209_db, _228_jack and _202_jess, benchmarks for which I saw regressions from 10%(_202_jess) up to 25%-30%(_209_db), similar to the results you sent. Here are the results showing the amount of times a thread synchronized on objects of a given class (run a single iteration with -g -M1 -s100): _209_db: ?Count ??? ??? Thread ??? ??? ??? ??? ??? Class 56255655 ??? 0x00007f9a18026dd0 ??? java.util.Vector ? 24252 ??? ??? 0x00007f9a18026dd0 ??? spec.io.FileInputStream ? 15326 ??? ??? 0x00007f9a18026dd0 ??? java.lang.StringBuffer ?? 5203 ??? ??? 0x00007f9a18026dd0 ??? java.io.ByteArrayOutputStream ?? 5203 ??? ??? 0x00007f9a18026dd0 ??? java.io.ByteArrayInputStream ?? 4088 ??? ??? 0x00007f9a18026dd0 ??? java.io.OutputStreamWriter ?? 1643 ??? ??? 0x00007f9a18026dd0 ??? spec.io.PrintStream ??? 931 ??? ??? 0x00007f9a18026dd0 ??? java.io.BufferedOutputStream ??? 633 ??? ??? 0x00007f9a18026dd0 ??? spec.io.TableOfExistingFiles ??? 625 ??? ??? 0x00007f9a18026dd0 ??? java.io.PrintStream ??? 369 ??? ??? 0x00007f9a18026dd0 ?java.util.concurrent.ConcurrentHashMap$Node (Full trace: http://cr.openjdk.java.net/~pchilanomate/specjvm98synctests/_209_db.txt) _228_jack ?Count ??? ??? Thread ??? ??? ??? ??? ??? Class 8349013 ??? 0x00007fba14026dd0 ??? java.util.Vector 2808067 ??? 0x00007fba14026dd0 ??? java.util.Hashtable 1173017 ??? ??? 0x00007fba14026dd0 ??? java.io.OutputStreamWriter ?886454 ??? 0x00007fba14026dd0 ??? java.lang.StringBuffer ?580516 ??? 0x00007fba14026dd0 spec.benchmarks._228_jack.JackPrintStream ?291017 ??? ??? 0x00007fba14026dd0 ??? spec.io.FileInputStream ?? 1116 ??? ??? 0x00007fba14026dd0 ??? java.io.ByteArrayOutputStream ?? 1116 ??? ??? 0x00007fba14026dd0 ??? java.io.ByteArrayInputStream ??? 633 ??? ??? 0x00007fba14026dd0 ??? spec.io.TableOfExistingFiles ??? 525 ??? ??? 0x00007fba14026dd0 java.util.concurrent.ConcurrentHashMap$Node ??? 414 ??? ??? 0x00007fba14026dd0 ??? java.io.FileDescriptor (Full trace: http://cr.openjdk.java.net/~pchilanomate/specjvm98synctests/_228_jack.txt) _202_jess ?Count ??? ??? Thread ??? ??? ??? ??? ??? Class 3515114 ??? 0x00007f6ad4026dd0 ??? java.util.Hashtable 1323387 ??? 0x00007f6ad4026dd0 ??? java.util.Vector ? 43451 ??? ??? 0x00007f6ad4026dd0 ??? java.util.Stack ? 18920 ??? ??? 0x00007f6ad4026dd0 ??? java.lang.StringBuffer ? 14952 ??? ??? 0x00007f6ad4026dd0 ??? spec.io.FileInputStream ?? 3811 ??? ??? 0x00007f6ad4026dd0 ??? java.io.OutputStreamWriter ?? 2413 ??? ??? 0x00007f6ad4026dd0 ??? java.io.ByteArrayOutputStream ?? 2413 ??? ??? 0x00007f6ad4026dd0 ??? java.io.ByteArrayInputStream ?? 1623 ??? ??? 0x00007f6ad4026dd0 ??? spec.io.PrintStream ?? 1380 ??? ??? 0x00007f6ad4026dd0 ??? java.lang.Class ??? 847 ??? ??? 0x00007f6ad4026dd0 ??? java.io.FileDescriptor ??? 814 ??? ??? 0x00007f6ad4026dd0 java.util.concurrent.ConcurrentHashMap$Node ??? 633 ??? ??? 0x00007f6ad4026dd0 ??? spec.io.TableOfExistingFiles (Full trace: http://cr.openjdk.java.net/~pchilanomate/specjvm98synctests/_202_jess.txt) So all the work is done by the same JavaThread, and given the amount of uncontended synchronization biased locking shines. Not sure if the pictures you sent happen to be from those particular benchmarks or others(_201_compress, _200_check, etc), but we could use the same technique and find out which classes we are synchronizing on that are causing the tests to prefer BL and whether the workload is single or multithreaded. We can do the same for other benchmarks. Note: you can also get those numbers with DiagnoseSyncOnPrimitiveWrappers, the flag I added recently for Valhalla (plus some minor changes). The same tests on benchmark _222_mpegaudio, for which I didn't see major performance difference with biased locking disabled, showed the following results (run a single iteration with -g -M1 -s100): _222_mpegaudio ?Count ??? ??? Thread ??? ??? ??? ??? Class 2165 ??? 0x00007fc4d0026dd0 ??? spec.io.FileInputStream ??? 790 ??? 0x00007fc4d0026dd0 ??? java.lang.StringBuffer ??? 633 ??? 0x00007fc4d0026dd0 ??? spec.io.TableOfExistingFiles ??? 581 ??? 0x00007fc4d0026dd0 java.util.concurrent.ConcurrentHashMap$Node ??? 365 ??? 0x00007fc4d0026dd0 ??? java.io.FileDescriptor ??? 266 ??? 0x00007fc4d0026dd0 ??? java.lang.Object ??? 208 ??? 0x00007fc4d0026dd0 ??? java.io.ByteArrayOutputStream ??? 208 ??? 0x00007fc4d0026dd0 ??? java.io.ByteArrayInputStream (Full trace: http://cr.openjdk.java.net/~pchilanomate/specjvm98synctests/_222_mpegaudio.txt) Still single-threaded with many synchronized calls but not as much as the above benchmarks, so it makes sense performance doesn't change much with or without BL. If the benchmarks above would be part of a real world app for which we would be trying to solve a performance issue, I think the solution would be to just drop java.util.Vector and java.util.Hashtable and use java.util.ArrayList and java.util.HashMap instead. Also if using custom classes, they shouldn't use synchronized keyword unless it's necessary. Then, not only performance would not be affected but it's also likely it will improve since we are not wasting time in unneeded monitorenter/exit bytecodes. If the issue is that the JDK library only provides synchronized classes, then I think we should have an unsynchronized flavor too. Then there could be workflows that still benefit from BL (although I tend to think the app code can probably be re-written so as to avoid those unnecessary synchronization calls) but the question is whether we want to support those cases. I agree that since there is nothing urgent that needs BL to go away we can push it to the next release instead. Then we will be having even more time for feedback and/or fix any issues. Thanks, Patricio > My 0.02$. > > Best regards, > Martin > > >> -----Original Message----- >> From: hotspot-runtime-dev >> On Behalf Of David Holmes >> Sent: Dienstag, 3. November 2020 22:30 >> To: Patricio Chilano ; hotspot-runtime- >> dev at openjdk.java.net; hotspot-dev developers > dev at openjdk.java.net> >> Subject: Re: Biased locking Obsoletion >> >> Expanding to hotspot-dev. >> >> >> On 4/11/2020 7:08 am, Patricio Chilano wrote: >>> Hi all, >>> >>> As discussed in 8231264, the idea was to switch biased locking to false >>> by default and deprecate all related flags with the intent to remove the >>> code in a future release unless compelling evidence showed that the code >>> is worth maintaining. >>> I see there is only one issue that was filed since biased locking was >>> disabled by default (https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/542__;!!GqivPVa7Brio!NtUU4TDlOTLoheSxnnQbTo4M64nbmca-8qDkdq0V4MjIqCudEEvdyj8am8BnV257S3q83fUh7g$ ) that seems >>> to have been addressed. As per 8231264 change, the code was set to be >>> obsoleted in 16, so we are already in a position to remove biased >>> locking code unless there are arguments for the contrary. The >>> alternative would be to give more time and move biased locking >>> obsoletion to a future release. >>> Let me know your thoughts. >>> >>> Thanks, >>> >>> Patricio From ysuenaga at openjdk.java.net Sat Nov 7 12:35:00 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 7 Nov 2020 12:35:00 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails Message-ID: If there are no disk space enough to write UL, it does not report. So the user cannot know lack of logs timely. `LogFileStreamOutput::write()` uses `jio_fprintf()` and `fflush()` to write log. However return values from them would not be checked. We should check them, and should report what happened if error occurred. How to reproduce on Linux: 1. Mount tmpfs with 512K $ mkdir /tmp/tmp $ mount -t tmpfs -o size=512k tmpfs /tmp/tmp 2. Run `java` with `-Xlog` $ java -Xlog:all=trace:file=/tmp/tmp/all.log --version ------------- Commit messages: - Fix typo - 8256008: UL does not report anything if disk writing fails Changes: https://git.openjdk.java.net/jdk/pull/1106/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1106&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256008 Stats: 77 lines in 2 files changed: 53 ins; 5 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/1106.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1106/head:pull/1106 PR: https://git.openjdk.java.net/jdk/pull/1106 From suenaga at oss.nttdata.com Sat Nov 7 13:26:10 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Sat, 7 Nov 2020 22:26:10 +0900 Subject: Unified Logging for network In-Reply-To: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> Message-ID: <8b197334-69bc-a325-a759-c6cae021fe24@oss.nttdata.com> Hi all, Thank you for sharing various opinions! The most of concerns seems TCP socket handling in UL. So I described my opinion on Gist. Could you read it? https://gist.github.com/YaSuenag/dacb6d94d8684915422232c7a08d5b5d Thanks, Yasumasa On 2020/11/02 20:20, Yasumasa Suenaga wrote: > Hi all, > > We need to out UL to stdout and/or file. If we can out it to TCP socket, I think it is useful. > > For example, some system gather all logs to document oriented databases (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. CloudWatch). If HotSpot can out UL to TCP socket, we can send all logs to them via TCP input plugin (Fluentd, Logstash). > > I think it is useful for container platform. What do you think? > If it is worth to work, I will add CSR and JBS ticket, and also will create patch. From thomas.stuefe at gmail.com Sat Nov 7 18:52:06 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 7 Nov 2020 19:52:06 +0100 Subject: Unified Logging for network In-Reply-To: <8b197334-69bc-a325-a759-c6cae021fe24@oss.nttdata.com> References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <8b197334-69bc-a325-a759-c6cae021fe24@oss.nttdata.com> Message-ID: Hi Yasumasa, similar solutions - buffering UL output and draining it in a separate thread (regardless the sink) - have been proposed in the past, see e.g. Amazon's proposal here: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-January/037849.html. In their case, to make gc logging less jittery. I think the strategy to stop all loggers if the buffer is full does not really solve anything. A laggy network connection can still screw up the timing behavior of the VM. Therefore, optionally one should be able to specify that log output gets discarded rather than loggers be stopped, and that should be marked in the output of course. Also, maybe the log buffer should be able to resize itself, and shrink once a log spike is over. And so on. Then, we have the problem of synchronization. Ideally, such a log buffer would be implemented in a lock less fashion. Otherwise log calls cause synchronization over all threads. So if done right, this gets a bit complex. And I think it is worth doing right. Therefore I think, like John and Robbin, that before reinventing this wheel we should check if there are standard tools which do all this already. The fact that this discussion springs up again and again means that there is a need for a solution. Let's hear what the others think. Cheers, Thomas Thanks, Thomas On Sat, Nov 7, 2020 at 2:26 PM Yasumasa Suenaga wrote: > Hi all, > > Thank you for sharing various opinions! > The most of concerns seems TCP socket handling in UL. > > So I described my opinion on Gist. Could you read it? > > https://gist.github.com/YaSuenag/dacb6d94d8684915422232c7a08d5b5d > > > Thanks, > > Yasumasa > > > On 2020/11/02 20:20, Yasumasa Suenaga wrote: > > Hi all, > > > > We need to out UL to stdout and/or file. If we can out it to TCP socket, > I think it is useful. > > > > For example, some system gather all logs to document oriented databases > (e.g. Elasticsearch) and/or cloud monitoring platform (e.g. CloudWatch). If > HotSpot can out UL to TCP socket, we can send all logs to them via TCP > input plugin (Fluentd, Logstash). > > > > I think it is useful for container platform. What do you think? > > If it is worth to work, I will add CSR and JBS ticket, and also will > create patch. > From john.r.rose at oracle.com Sat Nov 7 21:13:00 2020 From: john.r.rose at oracle.com (John Rose) Date: Sat, 7 Nov 2020 13:13:00 -0800 Subject: Unified Logging for network In-Reply-To: References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <8b197334-69bc-a325-a759-c6cae021fe24@oss.nttdata.com> Message-ID: <93EE5A60-0F67-49E5-9C15-730224CAC473@oracle.com> On Nov 7, 2020, at 10:52 AM, Thomas St?fe wrote: > > So if done right, this gets a bit complex. And I think it is worth doing > right. Therefore I think, like John and Robbin, that before reinventing > this wheel we should check if there are standard tools which do all this > already. I?d go a little farther: Surely such a tool exists, because the JVM is not unique as an event source. Even if exactly the right tool (a ?UL shipper? in the gist) does not exist, it does not follow that we should create and maintain such a thing. That?s the job of cloud infrastructure engineers, who do something different from JVM engineers. If the JVM puts special requirements on such a tool, then we need to work with one or more ?UL shipper? tool providers to meet in the middle, not go off and build our own. Thanks for the good discussion! ? John From suenaga at oss.nttdata.com Sun Nov 8 02:53:16 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Sun, 8 Nov 2020 11:53:16 +0900 Subject: Unified Logging for network In-Reply-To: <93EE5A60-0F67-49E5-9C15-730224CAC473@oracle.com> References: <7734942d-7ae5-fb05-e982-43319372378f@oss.nttdata.com> <8b197334-69bc-a325-a759-c6cae021fe24@oss.nttdata.com> <93EE5A60-0F67-49E5-9C15-730224CAC473@oracle.com> Message-ID: <10e039d8-4e72-eceb-c6e7-74716ef4b8a9@oss.nttdata.com> Hi Thomas, John, I'd like JVM to provide "sink mechanism" for UL other than file/stdout/stderr in a word. stdout/err might be mixed application log (other than UL output). If we use combination of file and other tools (e.g. syslogd), we also need to consider them. JEP 158 (Unified JVM Logging) mentions syslog, Windows Event Viewer, socket could be added as UL backend in future possible extensions. I think this proposal is not specialized to some tools because JVM would just send UL as plain text to some consumer, and also it is evolutional work for JEP 158. On 2020/11/08 6:13, John Rose wrote: > On Nov 7, 2020, at 10:52 AM, Thomas St?fe > wrote: >> >> So if done right, this gets a bit complex. And I think it is worth doing >> right. Therefore I think, like John and Robbin, that before reinventing >> this wheel we should check if there are standard tools which do all this >> already. > > I?d go a little farther: ?Surely such a tool exists, because > the JVM is not unique as an event source. ?Even if exactly > the right tool (a ?UL shipper? in the gist) does not exist, > it does not follow that we should create and maintain > such a thing. ?That?s the job of cloud infrastructure > engineers, who do something different from JVM > engineers. ?If the JVM puts special requirements on > such a tool, then we need to work with one or more > ?UL shipper? tool providers to meet in the middle, > not go off and build our own. > > Thanks for the good discussion! > > ? John From stuefe at openjdk.java.net Sun Nov 8 08:15:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 8 Nov 2020 08:15:55 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails In-Reply-To: References: Message-ID: <1K5zbwcC_LPNVUZmN4abFHyAnCe4Kkm5mM1tmNS7j2M=.1c23a3ac-9c7d-4598-ad61-75e25cd6a5e1@github.com> On Sat, 7 Nov 2020 07:19:09 GMT, Yasumasa Suenaga wrote: > If there are no disk space enough to write UL, it does not report. So the user cannot know lack of logs timely. > > `LogFileStreamOutput::write()` uses `jio_fprintf()` and `fflush()` to write log. However return values from them would not be checked. > We should check them, and should report what happened if error occurred. > > > How to reproduce on Linux: > > 1. Mount tmpfs with 512K > > $ mkdir /tmp/tmp > $ mount -t tmpfs -o size=512k tmpfs /tmp/tmp > > 2. Run `java` with `-Xlog` > > $ java -Xlog:all=trace:file=/tmp/tmp/all.log --version Hi Yasumasa, This fix makes sense. Not a full review, just some initial remarks: - A simpler way to reproduce may be to set an IO quota with ulimit. We ignore SIGXFSZ, so this should make the io calls fail. This could also maybe used for a jtreg test, though I see that this could be a bit more work and I won't insist on it. - I would like it if we could attempt to write some final words into the log stream. Because that may still work, even if the larger output does not (I really hope we do not print characters individually, don't we?). Something like `("write failed (%d)", errno)`. That may or may not work but if it does its helpful when looking at the logfile. - If you handle errors from writing, make sure you handle intermittend write errors correctly. You probably want to handle EINTR by re-trying to write. - I see you make an RAII object to handle flock. Could you leave this out please to make this change easier to review? I am not against it, but would prefer this in a separate cleanup change. More remarks later. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1106 From ysuenaga at openjdk.java.net Sun Nov 8 12:31:55 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sun, 8 Nov 2020 12:31:55 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails In-Reply-To: <1K5zbwcC_LPNVUZmN4abFHyAnCe4Kkm5mM1tmNS7j2M=.1c23a3ac-9c7d-4598-ad61-75e25cd6a5e1@github.com> References: <1K5zbwcC_LPNVUZmN4abFHyAnCe4Kkm5mM1tmNS7j2M=.1c23a3ac-9c7d-4598-ad61-75e25cd6a5e1@github.com> Message-ID: On Sun, 8 Nov 2020 08:12:56 GMT, Thomas Stuefe wrote: >> If there are no disk space enough to write UL, it does not report. So the user cannot know lack of logs timely. >> >> `LogFileStreamOutput::write()` uses `jio_fprintf()` and `fflush()` to write log. However return values from them would not be checked. >> We should check them, and should report what happened if error occurred. >> >> >> How to reproduce on Linux: >> >> 1. Mount tmpfs with 512K >> >> $ mkdir /tmp/tmp >> $ mount -t tmpfs -o size=512k tmpfs /tmp/tmp >> >> 2. Run `java` with `-Xlog` >> >> $ java -Xlog:all=trace:file=/tmp/tmp/all.log --version > > Hi Yasumasa, > > This fix makes sense. > > Not a full review, just some initial remarks: > > - A simpler way to reproduce may be to set an IO quota with ulimit. We ignore SIGXFSZ, so this should make the io calls fail. This could also maybe used for a jtreg test, though I see that this could be a bit more work and I won't insist on it. > > - I would like it if we could attempt to write some final words into the log stream. Because that may still work, even if the larger output does not (I really hope we do not print characters individually, don't we?). Something like `("write failed (%d)", errno)`. That may or may not work but if it does its helpful when looking at the logfile. > > - If you handle errors from writing, make sure you handle intermittend write errors correctly. You probably want to handle EINTR by re-trying to write. > > - I see you make an RAII object to handle flock. Could you leave this out please to make this change easier to review? I am not against it, but would prefer this in a separate cleanup change. > > More remarks later. > > Thanks, Thomas Thanks @tstuefe for reviewing! > * A simpler way to reproduce may be to set an IO quota with ulimit. We ignore SIGXFSZ, so this should make the io calls fail. This could also maybe used for a jtreg test, though I see that this could be a bit more work and I won't insist on it. In case of my test (`java -Xlog:all=trace:file=/tmp/tmp/all.log --version`) would happen crash with SIGXFSZ before register signal handlers, so we can see SIGXFSZ at `fflush()` call. I saw coredump caused by SIGXFSZ with `ulimit -f 1`. Whatever the case JVM would receive SIGXFSZ, so we may test this change with `ulimit -f`. > * I would like it if we could attempt to write some final words into the log stream. Because that may still work, even if the larger output does not (I really hope we do not print characters individually, don't we?). Something like `("write failed (%d)", errno)`. That may or may not work but if it does its helpful when looking at the logfile. Agree, I will add log message. > * If you handle errors from writing, make sure you handle intermittend write errors correctly. You probably want to handle EINTR by re-trying to write. `LogFileStreamOutput::write()` uses `jio_fprintf()` (wrapper of `vfprintf()` ) and `fflush()`. In case of `fflush()`, we can retry, however `jio_fprintf()` can be done in the same way? `vfprintf()` might not set `errno` if error happens. (I'm not sure) > * I see you make an RAII object to handle flock. Could you leave this out please to make this change easier to review? I am not against it, but would prefer this in a separate cleanup change. If `FileLocker` is removed from this change, I want to add it on another RFE before this because this change makes to return from several locations in `LogFileStreamOutput::write()`. Do you agree create subtask (RFE) to add `FileLocker`? ------------- PR: https://git.openjdk.java.net/jdk/pull/1106 From david.holmes at oracle.com Sun Nov 8 22:04:42 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 9 Nov 2020 08:04:42 +1000 Subject: Biased locking Obsoletion In-Reply-To: References: <7ca651a8-5861-92cf-5d31-6a7fd09700c6@oracle.com> Message-ID: <26c5c51e-9bbe-455c-7bf0-1f7cbcd126f2@oracle.com> Hi Martin, On 7/11/2020 3:29 am, Doerr, Martin wrote: > Hi Patricio, > > seems like nobody wanted to be the first person to reply. So I just share a few thoughts. > > Unfortunately, I haven't heard any feedback from end users. > If the Biased Locking Code removal is not urgent because it's in the way for something else, I'd slightly prefer to remove it early in JDK17. > > My impression is that modern workloads are fine without BL, so typical JDK15 users will probably not notice it was switched off. > > Some old workloads are heavily affected, like SPEC jvm98. See performance drop on Power9: > http://cr.openjdk.java.net/~mdoerr/BiasedLocking_Power9.png > and on Intel Xeon E5: > http://cr.openjdk.java.net/~mdoerr/BiasedLocking_XeonE5.png > > Are there any plans for mitigations? I don't see what mitigations are possible. We know that if you use heavily synchronized code when it is not necessary (i.e. uncontended) then BL shines at improving performance. Real "old" code would have been updated years ago to move away from the synchronized library classes (Vector, Hashtable) that typically result in these situations. Given that we can't update things like SPEC jvm98, they will show lower performance without BL. But I don't think we should care about this in 2020. Cheers, David > If so, it would be nice to implement them before finally removing BL. > > My 0.02$. > > Best regards, > Martin > > >> -----Original Message----- >> From: hotspot-runtime-dev >> On Behalf Of David Holmes >> Sent: Dienstag, 3. November 2020 22:30 >> To: Patricio Chilano ; hotspot-runtime- >> dev at openjdk.java.net; hotspot-dev developers > dev at openjdk.java.net> >> Subject: Re: Biased locking Obsoletion >> >> Expanding to hotspot-dev. >> >> >> On 4/11/2020 7:08 am, Patricio Chilano wrote: >>> Hi all, >>> >>> As discussed in 8231264, the idea was to switch biased locking to false >>> by default and deprecate all related flags with the intent to remove the >>> code in a future release unless compelling evidence showed that the code >>> is worth maintaining. >>> I see there is only one issue that was filed since biased locking was >>> disabled by default (https://github.com/openjdk/jdk/pull/542) that seems >>> to have been addressed. As per 8231264 change, the code was set to be >>> obsoleted in 16, so we are already in a position to remove biased >>> locking code unless there are arguments for the contrary. The >>> alternative would be to give more time and move biased locking >>> obsoletion to a future release. >>> Let me know your thoughts. >>> >>> Thanks, >>> >>> Patricio From david.holmes at oracle.com Mon Nov 9 00:55:48 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 9 Nov 2020 10:55:48 +1000 Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v5] In-Reply-To: References: Message-ID: Hi Robbin, On 6/11/2020 6:39 pm, Robbin Ehn wrote: > David wrote: >> { >> ThreadInVMfromJava tivm; >> } >> >> which transitions from Java to VM and back, for absolutely no reason >> other than to get the side-effects of doing those transitions. > > As I see it, if you have an oop map and are executing in VM, you are technically in VM. > But here we skip going to VM since SS:block used to need to know where you are going back to due to suspend flag is handle inside SS:block(). > And the safepoint synchronizer will treat java/vm the same thus we can cheat. > > If the thread is in Java it is not guaranteed that it will have an oop map and it's not certain that it can be made walkable. > Being blocked requires you to be walkable, thus going from java->blocked cannot be done as general rule. > Instead of having a ton of special rules which no one can remember, the rule is you can only block in VM where we know you can be made walkable. Sorry but I don't understand the point you are making here. The transition from Java to VM does nothing except change the thread-state and so has no affect on whether a thread can be made walkable or not. And SS:block() makes the thread walkable in any case. > Polling page exception handling can thus been seen as a cheat avoiding setting in vm since it will actually have no effect on the safepoint synchronizer. > > So no we are not looking for side-effects, we need to be in VM (at minimum technically) to become blocked. But that is simply not true - we end up being blocked for safepoints/handshakes from a wide-range of thread states. > Thus the rules for going from VM to Java applies, and we should deliver e.g. async exceptions. > > { > ThreadInVMfromJava tivm; > SS:block() > } > > Would be the preferred way of doing it. ??? Why would you call SS::block explicitly there - the transition back to VM would do that. David ----- >> >> David >> ----- > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/913 > From redestad at openjdk.java.net Mon Nov 9 08:12:03 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 9 Nov 2020 08:12:03 GMT Subject: RFR: 8256017: Remove unused elapsedTimer constructor Message-ID: 8256017: Remove unused elapsedTimer constructor ------------- Commit messages: - Merge branch 'master' into elapsedTimer_cleanup - Remove unused elapsedTimer constructor Changes: https://git.openjdk.java.net/jdk/pull/1112/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1112&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256017 Stats: 17 lines in 2 files changed: 0 ins; 17 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1112.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1112/head:pull/1112 PR: https://git.openjdk.java.net/jdk/pull/1112 From redestad at openjdk.java.net Mon Nov 9 08:22:56 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 9 Nov 2020 08:22:56 GMT Subject: RFR: 8256017: Remove unused elapsedTimer constructor In-Reply-To: References: Message-ID: On Sun, 8 Nov 2020 18:50:42 GMT, Claes Redestad wrote: > 8256017: Remove unused elapsedTimer constructor elapsedTimer(jlong time, jlong timeUnitsPerSecond) was added by JDK-8136421 but the only use has disappeared since. ------------- PR: https://git.openjdk.java.net/jdk/pull/1112 From rehn at openjdk.java.net Mon Nov 9 08:31:05 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 9 Nov 2020 08:31:05 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v5] In-Reply-To: References: Message-ID: On Fri, 6 Nov 2020 08:36:36 GMT, Robbin Ehn wrote: >>> Thanks for the updates! All LGTM. >>> >>> David >> Great, thanks David! >> >> Patricio > >> { >> ThreadInVMfromJava tivm; >> } >> >> which transitions from Java to VM and back, for absolutely no reason >> other than to get the side-effects of doing those transitions. > > As I see it, if you have an oop map and are executing in VM, you are technically in VM. > But here we skip going to VM since SS:block used to need to know where you are going back to due to suspend flag is handle inside SS:block(). > And the safepoint synchronizer will treat java/vm the same thus we can cheat. > > If the thread is in Java it is not guaranteed that it will have an oop map and it's not certain that it can be made walkable. > Being blocked requires you to be walkable, thus going from java->blocked cannot be done as general rule. > Instead of having a ton of special rules which no one can remember, the rule is you can only block in VM where we know you can be made walkable. > > Polling page exception handling can thus been seen as a cheat avoiding setting in vm since it will actually have no effect on the safepoint synchronizer. > > So no we are not looking for side-effects, we need to be in VM (at minimum technically) to become blocked. > Thus the rules for going from VM to Java applies, and we should deliver e.g. async exceptions. > > { > ThreadInVMfromJava tivm; > SS:block() > } > > Would be the preferred way of doing it. > >> >> David >> ----- Hi David, > > And the safepoint synchronizer will treat java/vm the same thus we can cheat. > > If the thread is in Java it is not guaranteed that it will have an oop map and it's not certain that it can be made walkable. > > Being blocked requires you to be walkable, thus going from java->blocked cannot be done as general rule. > > Instead of having a ton of special rules which no one can remember, the rule is you can only block in VM where we know you can be made walkable. > > Sorry but I don't understand the point you are making here. The > transition from Java to VM does nothing except change the thread-state > and so has no affect on whether a thread can be made walkable or not. > And SS:block() makes the thread walkable in any case. We have many such transition which only sets correct thread state. > > Polling page exception handling can thus been seen as a cheat avoiding setting in vm since it will actually have no effect on the safepoint synchronizer. > > So no we are not looking for side-effects, we need to be in VM (at minimum technically) to become blocked. > Either you can look this as set of rules that we can follow. Where at some places we have choose to optimize away some parts. Or everything in the code is just ad-hoc and special cases. > But that is simply not true - we end up being blocked for > safepoints/handshakes from a wide-range of thread states. > > > Thus the rules for going from VM to Java applies, and we should deliver e.g. async exceptions. > > { > > ThreadInVMfromJava tivm; > > SS:block() > > } > > Would be the preferred way of doing it. > > ??? Why would you call SS::block explicitly there - the transition back > to VM would do that. The point being that we should be in VM when entering SS:block(). The rules for being in VM from applies: ~ You must be walkable, no _suspend_flag check is needed. And the same when going back from VM back to java: ~ Deliver all _suspend_flag events. So you can either see this "special code". Or, we have just removed redundant code, other than that this follows the 'generic rules'. It is much easier to read/review the code as: Java->VM, oopmap, no front edge polling/_suspend_flag, no fence VM->Blocked, walkable, no front edge polling/_suspend, no fence *blocked* Blocked->VM, back edges polling, no suspend_flag, fence VM->Java, back edges polling, all suspend_flag big, no fence When setting thread state without fence we may skip it, front edge of going Java->VM->Blocked can be optimized to: - walkable - set blocked Back edge can be optimized to: - set any unsafe state (e.g. vm/block_trans) + fence - check poll, check suspend_flag - set thread state to Java This is what we do, but it is distributed several methods ~3-4 methods. So the reason for ending-up in SS:block with all kinds of state is that in some-cases the first part of the transition is in another methods e.g. the native wrapper. That case can be seen as native->vm->blocked->vm->java: Native->VM, oopmap, front edge polling/_suspend_flag, fence (safe>unsafe) VM->Blocked, walkable, no front edge polling/_suspend, no fence, unsafe->safe *blocked* Blocked->VM, back edges polling, no suspend_flag, fence VM->Java, back edges polling, all suspend_flag big, no fence The native wrapper does the front edge polling safe->unsafe + fence Since native_trans is also an unsafe state and going to another unsafe state does not require a fence, we can just optimize that away and just set blocked directly, so optimized it looks like: - native wrapper - walkable - set blocked When going back it looks the other case of blocked->vm->java, but native wrapper sets the final thread state of thread in Java. - set any unsafe state (e.g. any _trans state) + fence - check poll, check suspend_flag - set thread state to Java done by wrapper in this case You don't have to think of it like this, but it certainly helps me when writing/reviewing the code. Thanks, Robbin > > David > ----- # # ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From tschatzl at openjdk.java.net Mon Nov 9 08:39:55 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 9 Nov 2020 08:39:55 GMT Subject: RFR: 8256017: Remove unused elapsedTimer constructor In-Reply-To: References: Message-ID: On Sun, 8 Nov 2020 18:50:42 GMT, Claes Redestad wrote: > 8256017: Remove unused elapsedTimer constructor Lgtm. Maybe the copyright dates can be updated too, but feel free to ignore. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1112 From tschatzl at openjdk.java.net Mon Nov 9 10:16:58 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 9 Nov 2020 10:16:58 GMT Subject: RFR: 8255598: [PPC64] assert(Universe::heap()->is_in(result)) failed: object not in heap [v2] In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 22:29:11 GMT, Martin Doerr wrote: >> JDK-8237363 introduced "assert(Universe::heap()->is_in..." check in CompressedOops::decode functions. >> This assertion restricts the usability of the decode functions. There are periods of time (during GC) at which we can't use " Universe::heap()->is_in" because the pointer gets switched between old and new location, but "Universe::heap()->is_in" is not yet accurate. >> PPC64 code has a usage of CompressedOops::decode which is affected by this problem. (It was observed with SerialGC, see JBS.) >> We could also use a weaker assertion, but seems like other people value the stronger assertion more. So I suggest to use decode_raw as workaround for PPC64. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > add comment and use CompressedOops::is_null An alternative change could be investigating whether setting `top()` earlier in the serial gc full gc. It seems to only be a problem with that collector, as the others are seemingly not affected. I'm okay with this change too though. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1078 From martin.doerr at sap.com Mon Nov 9 11:23:34 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 9 Nov 2020 11:23:34 +0000 Subject: Biased locking Obsoletion In-Reply-To: <26c5c51e-9bbe-455c-7bf0-1f7cbcd126f2@oracle.com> References: <7ca651a8-5861-92cf-5d31-6a7fd09700c6@oracle.com> <26c5c51e-9bbe-455c-7bf0-1f7cbcd126f2@oracle.com> Message-ID: Thanks for all your replies! And thanks for bringing up JDK-8254078 again, Andrew! I think we can live with the regression in jvm98, but we should better address the planned mitigations before finally removing BL. Maybe there are more such kind of things planned? Besides this, I'm only a bit concerned about the LTS users. I guess most "traditional" workload is running on jdk8 or 11. So these users may notice the impact when migrating to 17. I hope people will not refrain from doing so because of missing BL. Best regards, Martin > -----Original Message----- > From: David Holmes > Sent: Sonntag, 8. November 2020 23:05 > To: Doerr, Martin ; Patricio Chilano > ; hotspot-runtime- > dev at openjdk.java.net; hotspot-dev developers dev at openjdk.java.net> > Subject: Re: Biased locking Obsoletion > > Hi Martin, > > On 7/11/2020 3:29 am, Doerr, Martin wrote: > > Hi Patricio, > > > > seems like nobody wanted to be the first person to reply. So I just share a > few thoughts. > > > > Unfortunately, I haven't heard any feedback from end users. > > If the Biased Locking Code removal is not urgent because it's in the way for > something else, I'd slightly prefer to remove it early in JDK17. > > > > My impression is that modern workloads are fine without BL, so typical > JDK15 users will probably not notice it was switched off. > > > > Some old workloads are heavily affected, like SPEC jvm98. See > performance drop on Power9: > > http://cr.openjdk.java.net/~mdoerr/BiasedLocking_Power9.png > > and on Intel Xeon E5: > > http://cr.openjdk.java.net/~mdoerr/BiasedLocking_XeonE5.png > > > > Are there any plans for mitigations? > > I don't see what mitigations are possible. We know that if you use > heavily synchronized code when it is not necessary (i.e. uncontended) > then BL shines at improving performance. Real "old" code would have been > updated years ago to move away from the synchronized library classes > (Vector, Hashtable) that typically result in these situations. Given > that we can't update things like SPEC jvm98, they will show lower > performance without BL. But I don't think we should care about this in 2020. > > Cheers, > David > > > If so, it would be nice to implement them before finally removing BL. > > > > My 0.02$. > > > > Best regards, > > Martin > > > > > >> -----Original Message----- > >> From: hotspot-runtime-dev retn at openjdk.java.net> > >> On Behalf Of David Holmes > >> Sent: Dienstag, 3. November 2020 22:30 > >> To: Patricio Chilano ; hotspot- > runtime- > >> dev at openjdk.java.net; hotspot-dev developers >> dev at openjdk.java.net> > >> Subject: Re: Biased locking Obsoletion > >> > >> Expanding to hotspot-dev. > >> > >> > >> On 4/11/2020 7:08 am, Patricio Chilano wrote: > >>> Hi all, > >>> > >>> As discussed in 8231264, the idea was to switch biased locking to false > >>> by default and deprecate all related flags with the intent to remove the > >>> code in a future release unless compelling evidence showed that the > code > >>> is worth maintaining. > >>> I see there is only one issue that was filed since biased locking was > >>> disabled by default (https://github.com/openjdk/jdk/pull/542) that > seems > >>> to have been addressed. As per 8231264 change, the code was set to be > >>> obsoleted in 16, so we are already in a position to remove biased > >>> locking code unless there are arguments for the contrary. The > >>> alternative would be to give more time and move biased locking > >>> obsoletion to a future release. > >>> Let me know your thoughts. > >>> > >>> Thanks, > >>> > >>> Patricio From github.com+16932759+shqking at openjdk.java.net Mon Nov 9 18:25:04 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Mon, 9 Nov 2020 18:25:04 GMT Subject: RFR: 8255975: Fix AArch64 OpenJDK build failure with gcc-5 Message-ID: As one C++17 feature, the argument 'message' of static_assert can be optional. This feature, i.e. static_assert with no message, is supported by gcc-6 or higher.[1] Add 'message' arguments in order to avoid compilation failures if gcc-5 is used. [1] https://gcc.gnu.org/projects/cxx-status.html ------------- Commit messages: - 8255975: Fix AArch64 OpenJDK build failure with gcc-5 Changes: https://git.openjdk.java.net/jdk/pull/1088/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1088&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255975 Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/1088.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1088/head:pull/1088 PR: https://git.openjdk.java.net/jdk/pull/1088 From mdoerr at openjdk.java.net Mon Nov 9 20:43:03 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 9 Nov 2020 20:43:03 GMT Subject: RFR: 8255598: [PPC64] assert(Universe::heap()->is_in(result)) failed: object not in heap [v2] In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 10:14:06 GMT, Thomas Schatzl wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> add comment and use CompressedOops::is_null > > An alternative change could be investigating whether setting `top()` earlier in the serial gc full gc. It seems to only be a problem with that collector, as the others are seemingly not affected. > > I'm okay with this change too though. Thanks for the reviews! @tschatzl: Calling `set_top` during phase 2 sounds like a nice idea, but it's currently done in `reset_after_compaction` and it may possibly break other things if I move it to an earlier phase. So I should probably better go ahead with the current version. ------------- PR: https://git.openjdk.java.net/jdk/pull/1078 From hseigel at openjdk.java.net Mon Nov 9 21:45:00 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 9 Nov 2020 21:45:00 GMT Subject: RFR: 8256017: Remove unused elapsedTimer constructor In-Reply-To: References: Message-ID: On Sun, 8 Nov 2020 18:50:42 GMT, Claes Redestad wrote: > 8256017: Remove unused elapsedTimer constructor Changes look good. ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1112 From mdoerr at openjdk.java.net Tue Nov 10 11:52:55 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 10 Nov 2020 11:52:55 GMT Subject: Integrated: 8255598: [PPC64] assert(Universe::heap()->is_in(result)) failed: object not in heap In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 16:46:43 GMT, Martin Doerr wrote: > JDK-8237363 introduced "assert(Universe::heap()->is_in..." check in CompressedOops::decode functions. > This assertion restricts the usability of the decode functions. There are periods of time (during GC) at which we can't use " Universe::heap()->is_in" because the pointer gets switched between old and new location, but "Universe::heap()->is_in" is not yet accurate. > PPC64 code has a usage of CompressedOops::decode which is affected by this problem. (It was observed with SerialGC, see JBS.) > We could also use a weaker assertion, but seems like other people value the stronger assertion more. So I suggest to use decode_raw as workaround for PPC64. This pull request has now been integrated. Changeset: 9d07259f Author: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/9d07259f Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8255598: [PPC64] assert(Universe::heap()->is_in(result)) failed: object not in heap Reviewed-by: ayang, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/1078 From redestad at openjdk.java.net Tue Nov 10 20:43:13 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 10 Nov 2020 20:43:13 GMT Subject: RFR: 8256017: Remove unused elapsedTimer constructor [v2] In-Reply-To: References: Message-ID: > 8256017: Remove unused elapsedTimer constructor 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 four additional commits since the last revision: - Copyrights - Merge branch 'master' into elapsedTimer_cleanup - Merge branch 'master' into elapsedTimer_cleanup - Remove unused elapsedTimer constructor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1112/files - new: https://git.openjdk.java.net/jdk/pull/1112/files/ae7e057e..b67a64b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1112&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1112&range=00-01 Stats: 3122 lines in 128 files changed: 1301 ins; 1298 del; 523 mod Patch: https://git.openjdk.java.net/jdk/pull/1112.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1112/head:pull/1112 PR: https://git.openjdk.java.net/jdk/pull/1112 From redestad at openjdk.java.net Tue Nov 10 20:43:15 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 10 Nov 2020 20:43:15 GMT Subject: Integrated: 8256017: Remove unused elapsedTimer constructor In-Reply-To: References: Message-ID: On Sun, 8 Nov 2020 18:50:42 GMT, Claes Redestad wrote: > 8256017: Remove unused elapsedTimer constructor This pull request has now been integrated. Changeset: f2a0bf3e Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/f2a0bf3e Stats: 19 lines in 2 files changed: 0 ins; 17 del; 2 mod 8256017: Remove unused elapsedTimer constructor Reviewed-by: tschatzl, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/1112 From redestad at openjdk.java.net Tue Nov 10 20:43:15 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 10 Nov 2020 20:43:15 GMT Subject: RFR: 8256017: Remove unused elapsedTimer constructor [v2] In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 08:36:42 GMT, Thomas Schatzl 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 four additional commits since the last revision: >> >> - Copyrights >> - Merge branch 'master' into elapsedTimer_cleanup >> - Merge branch 'master' into elapsedTimer_cleanup >> - Remove unused elapsedTimer constructor > > Lgtm. Maybe the copyright dates can be updated too, but feel free to ignore. @tschatzl @hseigel: thank you both for reviewing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1112 From ccheung at openjdk.java.net Tue Nov 10 23:30:05 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 10 Nov 2020 23:30:05 GMT Subject: RFR: 8255990: Bitmap region of dynamic CDS archive is not unmapped Message-ID: Add the missing call to `unmap_region` to unmap the bitmap region of a dynamic CDS archive. Also modify the `DynamicArchiveRelocationTest` to check for the "Unmapping region" message. Testing: - [x] tier1 - tiers 2,3,4 (in progress) ------------- Commit messages: - 8255990: Bitmap region of dynamic CDS archive is not unmapped Changes: https://git.openjdk.java.net/jdk/pull/1151/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1151&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255990 Stats: 9 lines in 2 files changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1151/head:pull/1151 PR: https://git.openjdk.java.net/jdk/pull/1151 From minqi at openjdk.java.net Tue Nov 10 23:43:02 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 10 Nov 2020 23:43:02 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 Message-ID: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Hi, Please review JDK-8255917 failed on not finding the committed region from the _reserved_regions list when try to add the region to the committed list. It looks like possible the region was released without logged. Added a log tag for tracing Native Memory Tracking (NMT) add/remove recorded info. This could help us to identify the problem for NMT or the code behind NMT. Function pd_attempt_reserve_memory_at could fail, but no message logged, so added a logging for its failure. Tests: tier1-4, local jtreg. ------------- Commit messages: - Fix tab space - 8255973: Add more logging to debug JDK-8255917 Changes: https://git.openjdk.java.net/jdk/pull/1150/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1150&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255973 Stats: 45 lines in 5 files changed: 36 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1150/head:pull/1150 PR: https://git.openjdk.java.net/jdk/pull/1150 From iklam at openjdk.java.net Wed Nov 11 00:08:54 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 11 Nov 2020 00:08:54 GMT Subject: RFR: 8255990: Bitmap region of dynamic CDS archive is not unmapped In-Reply-To: References: Message-ID: <1gCSJMBq0F5q_oSBuYz3n6zjFds03A8JtNZRTFMVpj4=.ce0828a1-b2e2-4bff-b56d-2b2b552f9fe6@github.com> On Tue, 10 Nov 2020 23:25:11 GMT, Calvin Cheung wrote: > Add the missing call to `unmap_region` to unmap the bitmap region of a dynamic CDS archive. > > Also modify the `DynamicArchiveRelocationTest` to check for the "Unmapping region" message. > > Testing: > > - [x] tier1 > - tiers 2,3,4 (in progress) LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1151 From minqi at openjdk.java.net Wed Nov 11 00:24:56 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 11 Nov 2020 00:24:56 GMT Subject: RFR: 8255990: Bitmap region of dynamic CDS archive is not unmapped In-Reply-To: References: Message-ID: On Tue, 10 Nov 2020 23:25:11 GMT, Calvin Cheung wrote: > Add the missing call to `unmap_region` to unmap the bitmap region of a dynamic CDS archive. > > Also modify the `DynamicArchiveRelocationTest` to check for the "Unmapping region" message. > > Testing: > > - [x] tier1 > - tiers 2,3,4 (in progress) Looks good! ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1151 From ccheung at openjdk.java.net Wed Nov 11 00:48:04 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 11 Nov 2020 00:48:04 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 In-Reply-To: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Tue, 10 Nov 2020 23:23:29 GMT, Yumin Qi wrote: > Hi, Please review > > JDK-8255917 failed on not finding the committed region from the _reserved_regions list when try to add the region to the committed list. It looks like possible the region was released without logged. > Added a log tag for tracing Native Memory Tracking (NMT) add/remove recorded info. This could help us to identify the problem for NMT or the code behind NMT. Function pd_attempt_reserve_memory_at could fail, but no message logged, so added a logging for its failure. > > Tests: tier1-4, local jtreg. Looks good. Some nits below. src/hotspot/share/services/virtualMemoryTracker.cpp line 387: > 385: if (reserved_rgn->flag() == mtClassShared) { > 386: log_info(nmt)("CDS reserved region \'%s\' as a whole type class (" INTPTR_FORMAT ", " SIZE_FORMAT ")", > 387: reserved_rgn->flag_name(), p2i(reserved_rgn->base()), reserved_rgn->size()); Since you're logging the region name, I don't think you need to say `type class`. src/hotspot/share/services/virtualMemoryTracker.cpp line 396: > 394: if (reserved_rgn->flag() == mtJavaHeap) { > 395: log_info(nmt)("CDS reserved region \'%s\' as a whole type heap " INTPTR_FORMAT ": " SIZE_FORMAT, > 396: reserved_rgn->flag_name(), p2i(reserved_rgn->base()), reserved_rgn->size()); Since you're logging the region name, I don't think you need to say `type heap`. src/hotspot/share/services/virtualMemoryTracker.hpp line 309: > 307: void set_flag(MEMFLAGS flag); > 308: inline MEMFLAGS flag() const { return _flag; } > 309: // uncommitted thread stack bottom, above guard pages if there is any. Line deleted by accident? ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1150 From ccheung at openjdk.java.net Wed Nov 11 00:53:55 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 11 Nov 2020 00:53:55 GMT Subject: RFR: 8255990: Bitmap region of dynamic CDS archive is not unmapped In-Reply-To: <1gCSJMBq0F5q_oSBuYz3n6zjFds03A8JtNZRTFMVpj4=.ce0828a1-b2e2-4bff-b56d-2b2b552f9fe6@github.com> References: <1gCSJMBq0F5q_oSBuYz3n6zjFds03A8JtNZRTFMVpj4=.ce0828a1-b2e2-4bff-b56d-2b2b552f9fe6@github.com> Message-ID: On Wed, 11 Nov 2020 00:06:02 GMT, Ioi Lam wrote: >> Add the missing call to `unmap_region` to unmap the bitmap region of a dynamic CDS archive. >> >> Also modify the `DynamicArchiveRelocationTest` to check for the "Unmapping region" message. >> >> Testing: >> >> - [x] tier1 >> - tiers 2,3,4 (in progress) > > LGTM @iklam, @yminqi, Thanks for your reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/1151 From minqi at openjdk.java.net Wed Nov 11 02:28:09 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 11 Nov 2020 02:28:09 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v2] In-Reply-To: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: > Hi, Please review > > JDK-8255917 failed on not finding the committed region from the _reserved_regions list when try to add the region to the committed list. It looks like possible the region was released without logged. > Added a log tag for tracing Native Memory Tracking (NMT) add/remove recorded info. This could help us to identify the problem for NMT or the code behind NMT. Function pd_attempt_reserve_memory_at could fail, but no message logged, so added a logging for its failure. > > Tests: tier1-4, local jtreg. Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fix the region extra type name ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1150/files - new: https://git.openjdk.java.net/jdk/pull/1150/files/51aef422..fd827f0c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1150&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1150&range=00-01 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1150/head:pull/1150 PR: https://git.openjdk.java.net/jdk/pull/1150 From minqi at openjdk.java.net Wed Nov 11 02:28:11 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 11 Nov 2020 02:28:11 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v2] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: <6fMBGdtFfu2qv-_XS_QGtJ1rpnXHSbnOSARBdElgYcU=.6315019c-12c5-42a1-830f-8430518af57c@github.com> On Wed, 11 Nov 2020 00:44:13 GMT, Calvin Cheung wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix the region extra type name > > src/hotspot/share/services/virtualMemoryTracker.cpp line 396: > >> 394: if (reserved_rgn->flag() == mtJavaHeap) { >> 395: log_info(nmt)("CDS reserved region \'%s\' as a whole type heap " INTPTR_FORMAT ": " SIZE_FORMAT, >> 396: reserved_rgn->flag_name(), p2i(reserved_rgn->base()), reserved_rgn->size()); > > Since you're logging the region name, I don't think you need to say `type heap`. Thanks. fixed. > src/hotspot/share/services/virtualMemoryTracker.cpp line 387: > >> 385: if (reserved_rgn->flag() == mtClassShared) { >> 386: log_info(nmt)("CDS reserved region \'%s\' as a whole type class (" INTPTR_FORMAT ", " SIZE_FORMAT ")", >> 387: reserved_rgn->flag_name(), p2i(reserved_rgn->base()), reserved_rgn->size()); > > Since you're logging the region name, I don't think you need to say `type class`. Fixed. > src/hotspot/share/services/virtualMemoryTracker.hpp line 309: > >> 307: void set_flag(MEMFLAGS flag); >> 308: inline MEMFLAGS flag() const { return _flag; } >> 309: // uncommitted thread stack bottom, above guard pages if there is any. > > Line deleted by accident? Yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/1150 From stuefe at openjdk.java.net Wed Nov 11 05:42:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 11 Nov 2020 05:42:56 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails In-Reply-To: <1K5zbwcC_LPNVUZmN4abFHyAnCe4Kkm5mM1tmNS7j2M=.1c23a3ac-9c7d-4598-ad61-75e25cd6a5e1@github.com> References: <1K5zbwcC_LPNVUZmN4abFHyAnCe4Kkm5mM1tmNS7j2M=.1c23a3ac-9c7d-4598-ad61-75e25cd6a5e1@github.com> Message-ID: On Sun, 8 Nov 2020 08:12:56 GMT, Thomas Stuefe wrote: >> If there are no disk space enough to write UL, it does not report. So the user cannot know lack of logs timely. >> >> `LogFileStreamOutput::write()` uses `jio_fprintf()` and `fflush()` to write log. However return values from them would not be checked. >> We should check them, and should report what happened if error occurred. >> >> >> How to reproduce on Linux: >> >> 1. Mount tmpfs with 512K >> >> $ mkdir /tmp/tmp >> $ mount -t tmpfs -o size=512k tmpfs /tmp/tmp >> >> 2. Run `java` with `-Xlog` >> >> $ java -Xlog:all=trace:file=/tmp/tmp/all.log --version > > Hi Yasumasa, > > This fix makes sense. > > Not a full review, just some initial remarks: > > - A simpler way to reproduce may be to set an IO quota with ulimit. We ignore SIGXFSZ, so this should make the io calls fail. This could also maybe used for a jtreg test, though I see that this could be a bit more work and I won't insist on it. > > - I would like it if we could attempt to write some final words into the log stream. Because that may still work, even if the larger output does not (I really hope we do not print characters individually, don't we?). Something like `("write failed (%d)", errno)`. That may or may not work but if it does its helpful when looking at the logfile. > > - If you handle errors from writing, make sure you handle intermittend write errors correctly. You probably want to handle EINTR by re-trying to write. > > - I see you make an RAII object to handle flock. Could you leave this out please to make this change easier to review? I am not against it, but would prefer this in a separate cleanup change. > > More remarks later. > > Thanks, Thomas > Thanks @tstuefe for reviewing! > > > * A simpler way to reproduce may be to set an IO quota with ulimit. We ignore SIGXFSZ, so this should make the io calls fail. This could also maybe used for a jtreg test, though I see that this could be a bit more work and I won't insist on it. > > In case of my test (`java -Xlog:all=trace:file=/tmp/tmp/all.log --version`) would happen crash with SIGXFSZ before register signal handlers, so we can see SIGXFSZ at `fflush()` call. I saw coredump caused by SIGXFSZ with `ulimit -f 1`. > Whatever the case JVM would receive SIGXFSZ, so we may test this change with `ulimit -f`. > > > * I would like it if we could attempt to write some final words into the log stream. Because that may still work, even if the larger output does not (I really hope we do not print characters individually, don't we?). Something like `("write failed (%d)", errno)`. That may or may not work but if it does its helpful when looking at the logfile. > > Agree, I will add log message. > > > * If you handle errors from writing, make sure you handle intermittend write errors correctly. You probably want to handle EINTR by re-trying to write. > > `LogFileStreamOutput::write()` uses `jio_fprintf()` (wrapper of `vfprintf()` ) and `fflush()`. In case of `fflush()`, we can retry, however `jio_fprintf()` can be done in the same way? `vfprintf()` might not set `errno` if error happens. (I'm not sure) Hmm. Thinking about this some more: Without reading your patch closely, what is the strategy you propose if a write error happens? 1) Will you write a message, then refuse further log attempts? 2) Will you write a message, but continue logging? Writing a message each time an error happens? 3) Will you write a message only for the first write error and then not refuse further log attempts? Depending on this we should handle intermittent errors (EINTR and maybe EAGAIN) or can continute to ignore them. With (1) we should handle (ignore) intermittent errors to prevent one spurious write error from stoppng the log. With (2) we don't have to handle them since we do essentially what we do today, but a bad IO device may now cause a flood of messages. With (3) we don't have to either but will only see the first UL writing problem. Not sure what I like best. What did you propose? > > > * I see you make an RAII object to handle flock. Could you leave this out please to make this change easier to review? I am not against it, but would prefer this in a separate cleanup change. > > If `FileLocker` is removed from this change, I want to add it on another RFE before this because this change makes to return from several locations in `LogFileStreamOutput::write()`. > Do you agree create subtask (RFE) to add `FileLocker`? Yes. But on second thought, I don't want to cause you unnecessary work. So if that is all the cleanup you'll do in this patch, I am fine with it too. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1106 From ysuenaga at openjdk.java.net Wed Nov 11 06:50:54 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 Nov 2020 06:50:54 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails In-Reply-To: References: <1K5zbwcC_LPNVUZmN4abFHyAnCe4Kkm5mM1tmNS7j2M=.1c23a3ac-9c7d-4598-ad61-75e25cd6a5e1@github.com> Message-ID: On Wed, 11 Nov 2020 05:40:01 GMT, Thomas Stuefe wrote: > > > * If you handle errors from writing, make sure you handle intermittend write errors correctly. You probably want to handle EINTR by re-trying to write. > > > > > > `LogFileStreamOutput::write()` uses `jio_fprintf()` (wrapper of `vfprintf()` ) and `fflush()`. In case of `fflush()`, we can retry, however `jio_fprintf()` can be done in the same way? `vfprintf()` might not set `errno` if error happens. (I'm not sure) > > Hmm. Thinking about this some more: > > Without reading your patch closely, what is the strategy you propose if a write error happens? > > 1. Will you write a message, then refuse further log attempts? > 2. Will you write a message, but continue logging? Writing a message each time an error happens? > 3. Will you write a message only for the first write error and then not refuse further log attempts? > > Depending on this we should handle intermittent errors (EINTR and maybe EAGAIN) or can continute to ignore them. > With (1) we should handle (ignore) intermittent errors to prevent one spurious write error from stoppng the log. > With (2) we don't have to handle them since we do essentially what we do today, but a bad IO device may now cause a flood of messages. > With (3) we don't have to either but will only see the first UL writing problem. > > Not sure what I like best. What did you propose? I've proposed (3) on this patch. I want to notice log writing is failed due to some error when log file is strange. Error message would be shown only the first time an error occurs, however logger would not be disabled because someone might make free disk space without rebooting JVM. I thought (1) at first, but I didn't do so because it requires operator to resume logging (e.g. `jcmd VM.log`) when the problem is fixed. > > > * I see you make an RAII object to handle flock. Could you leave this out please to make this change easier to review? I am not against it, but would prefer this in a separate cleanup change. > > > > > > If `FileLocker` is removed from this change, I want to add it on another RFE before this because this change makes to return from several locations in `LogFileStreamOutput::write()`. > > Do you agree create subtask (RFE) to add `FileLocker`? > > Yes. But on second thought, I don't want to cause you unnecessary work. So if that is all the cleanup you'll do in this patch, I am fine with it too. No problem, I will add it as RFE to JBS. ------------- PR: https://git.openjdk.java.net/jdk/pull/1106 From dholmes at openjdk.java.net Wed Nov 11 07:02:55 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 11 Nov 2020 07:02:55 GMT Subject: RFR: 8255975: Fix AArch64 OpenJDK build failure with gcc-5 In-Reply-To: References: Message-ID: <_iUL0AV24tshGU9tP0eVkmlvlY7EA1xOrBxk6hucO0w=.48c6ff16-fb2c-4d56-aca3-634db273ee0d@github.com> On Fri, 6 Nov 2020 07:31:58 GMT, Hao Sun wrote: > As one C++17 feature, the argument 'message' of static_assert can be optional. > This feature, i.e. static_assert with no message, is supported by gcc-6 or > higher.[1] > > Add 'message' arguments in order to avoid compilation failures if gcc-5 is used. > > [1] https://gcc.gnu.org/projects/cxx-status.html This seems fine to me. This C++17 construct should not have crept in. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1088 From stuefe at openjdk.java.net Wed Nov 11 07:14:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 11 Nov 2020 07:14:58 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails In-Reply-To: References: <1K5zbwcC_LPNVUZmN4abFHyAnCe4Kkm5mM1tmNS7j2M=.1c23a3ac-9c7d-4598-ad61-75e25cd6a5e1@github.com> Message-ID: <3cwv2rmGojtsvDcQXWdfCx8tqrRjbx9Fe-rnMoUazqY=.254ef493-a888-4955-a50c-122dedec8772@github.com> On Wed, 11 Nov 2020 06:48:23 GMT, Yasumasa Suenaga wrote: > > > > * If you handle errors from writing, make sure you handle intermittend write errors correctly. You probably want to handle EINTR by re-trying to write. > > > > > > > > > `LogFileStreamOutput::write()` uses `jio_fprintf()` (wrapper of `vfprintf()` ) and `fflush()`. In case of `fflush()`, we can retry, however `jio_fprintf()` can be done in the same way? `vfprintf()` might not set `errno` if error happens. (I'm not sure) > > > > > > Hmm. Thinking about this some more: > > Without reading your patch closely, what is the strategy you propose if a write error happens? > > > > 1. Will you write a message, then refuse further log attempts? > > 2. Will you write a message, but continue logging? Writing a message each time an error happens? > > 3. Will you write a message only for the first write error and then not refuse further log attempts? > > > > Depending on this we should handle intermittent errors (EINTR and maybe EAGAIN) or can continute to ignore them. > > With (1) we should handle (ignore) intermittent errors to prevent one spurious write error from stoppng the log. > > With (2) we don't have to handle them since we do essentially what we do today, but a bad IO device may now cause a flood of messages. > > With (3) we don't have to either but will only see the first UL writing problem. > > Not sure what I like best. What did you propose? > > I've proposed (3) on this patch. I want to notice log writing is failed due to some error when log file is strange. > > Error message would be shown only the first time an error occurs, however logger would not be disabled because someone might make free disk space without rebooting JVM. > I thought (1) at first, but I didn't do so because it requires operator to resume logging (e.g. `jcmd VM.log`) when the problem is fixed. This makes sense. Its what I would have done too. > > > > > * I see you make an RAII object to handle flock. Could you leave this out please to make this change easier to review? I am not against it, but would prefer this in a separate cleanup change. > > > > > > > > > If `FileLocker` is removed from this change, I want to add it on another RFE before this because this change makes to return from several locations in `LogFileStreamOutput::write()`. > > > Do you agree create subtask (RFE) to add `FileLocker`? > > > > > > Yes. But on second thought, I don't want to cause you unnecessary work. So if that is all the cleanup you'll do in this patch, I am fine with it too. > > No problem, I will add it as RFE to JBS. Thanks. I'll review the patch in detail in the next days. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1106 From ysuenaga at openjdk.java.net Wed Nov 11 07:17:03 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 Nov 2020 07:17:03 GMT Subject: RFR: 8256178: Add RAII object for file lock Message-ID: This PR is subtask of [JDK-8256008](https://bugs.openjdk.java.net/browse/JDK-8256008) (#1106) `LogFileStreamOutput::write()` uses `os::flockfile()` and `os::funlockfile()` to serialize write ops. It is better to use RAII because we can ensure `os::funlockfile()` call. ------------- Commit messages: - Add RAII object for file lock Changes: https://git.openjdk.java.net/jdk/pull/1156/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1156&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256178 Stats: 17 lines in 1 file changed: 14 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1156/head:pull/1156 PR: https://git.openjdk.java.net/jdk/pull/1156 From ysuenaga at openjdk.java.net Wed Nov 11 07:17:55 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 Nov 2020 07:17:55 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails In-Reply-To: <3cwv2rmGojtsvDcQXWdfCx8tqrRjbx9Fe-rnMoUazqY=.254ef493-a888-4955-a50c-122dedec8772@github.com> References: <1K5zbwcC_LPNVUZmN4abFHyAnCe4Kkm5mM1tmNS7j2M=.1c23a3ac-9c7d-4598-ad61-75e25cd6a5e1@github.com> <3cwv2rmGojtsvDcQXWdfCx8tqrRjbx9Fe-rnMoUazqY=.254ef493-a888-4955-a50c-122dedec8772@github.com> Message-ID: On Wed, 11 Nov 2020 07:12:26 GMT, Thomas Stuefe wrote: >>> > > * If you handle errors from writing, make sure you handle intermittend write errors correctly. You probably want to handle EINTR by re-trying to write. >>> > >>> > >>> > `LogFileStreamOutput::write()` uses `jio_fprintf()` (wrapper of `vfprintf()` ) and `fflush()`. In case of `fflush()`, we can retry, however `jio_fprintf()` can be done in the same way? `vfprintf()` might not set `errno` if error happens. (I'm not sure) >>> >>> Hmm. Thinking about this some more: >>> >>> Without reading your patch closely, what is the strategy you propose if a write error happens? >>> >>> 1. Will you write a message, then refuse further log attempts? >>> 2. Will you write a message, but continue logging? Writing a message each time an error happens? >>> 3. Will you write a message only for the first write error and then not refuse further log attempts? >>> >>> Depending on this we should handle intermittent errors (EINTR and maybe EAGAIN) or can continute to ignore them. >>> With (1) we should handle (ignore) intermittent errors to prevent one spurious write error from stoppng the log. >>> With (2) we don't have to handle them since we do essentially what we do today, but a bad IO device may now cause a flood of messages. >>> With (3) we don't have to either but will only see the first UL writing problem. >>> >>> Not sure what I like best. What did you propose? >> >> I've proposed (3) on this patch. I want to notice log writing is failed due to some error when log file is strange. >> >> Error message would be shown only the first time an error occurs, however logger would not be disabled because someone might make free disk space without rebooting JVM. >> I thought (1) at first, but I didn't do so because it requires operator to resume logging (e.g. `jcmd VM.log`) when the problem is fixed. >> >>> > > * I see you make an RAII object to handle flock. Could you leave this out please to make this change easier to review? I am not against it, but would prefer this in a separate cleanup change. >>> > >>> > >>> > If `FileLocker` is removed from this change, I want to add it on another RFE before this because this change makes to return from several locations in `LogFileStreamOutput::write()`. >>> > Do you agree create subtask (RFE) to add `FileLocker`? >>> >>> Yes. But on second thought, I don't want to cause you unnecessary work. So if that is all the cleanup you'll do in this patch, I am fine with it too. >> >> No problem, I will add it as RFE to JBS. > >> > > > * If you handle errors from writing, make sure you handle intermittend write errors correctly. You probably want to handle EINTR by re-trying to write. >> > > >> > > >> > > `LogFileStreamOutput::write()` uses `jio_fprintf()` (wrapper of `vfprintf()` ) and `fflush()`. In case of `fflush()`, we can retry, however `jio_fprintf()` can be done in the same way? `vfprintf()` might not set `errno` if error happens. (I'm not sure) >> > >> > >> > Hmm. Thinking about this some more: >> > Without reading your patch closely, what is the strategy you propose if a write error happens? >> > >> > 1. Will you write a message, then refuse further log attempts? >> > 2. Will you write a message, but continue logging? Writing a message each time an error happens? >> > 3. Will you write a message only for the first write error and then not refuse further log attempts? >> > >> > Depending on this we should handle intermittent errors (EINTR and maybe EAGAIN) or can continute to ignore them. >> > With (1) we should handle (ignore) intermittent errors to prevent one spurious write error from stoppng the log. >> > With (2) we don't have to handle them since we do essentially what we do today, but a bad IO device may now cause a flood of messages. >> > With (3) we don't have to either but will only see the first UL writing problem. >> > Not sure what I like best. What did you propose? >> >> I've proposed (3) on this patch. I want to notice log writing is failed due to some error when log file is strange. >> >> Error message would be shown only the first time an error occurs, however logger would not be disabled because someone might make free disk space without rebooting JVM. >> I thought (1) at first, but I didn't do so because it requires operator to resume logging (e.g. `jcmd VM.log`) when the problem is fixed. > > This makes sense. Its what I would have done too. > >> >> > > > * I see you make an RAII object to handle flock. Could you leave this out please to make this change easier to review? I am not against it, but would prefer this in a separate cleanup change. >> > > >> > > >> > > If `FileLocker` is removed from this change, I want to add it on another RFE before this because this change makes to return from several locations in `LogFileStreamOutput::write()`. >> > > Do you agree create subtask (RFE) to add `FileLocker`? >> > >> > >> > Yes. But on second thought, I don't want to cause you unnecessary work. So if that is all the cleanup you'll do in this patch, I am fine with it too. >> >> No problem, I will add it as RFE to JBS. > > Thanks. I'll review the patch in detail in the next days. > > Cheers, Thomas Thanks @tstuefe ! I've sent PR for RAII object in #1156 . I will update this PR after #1156 is pushed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1106 From ysuenaga at openjdk.java.net Wed Nov 11 07:25:12 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 Nov 2020 07:25:12 GMT Subject: RFR: 8256178: Add RAII object for file lock [v2] In-Reply-To: References: Message-ID: > This PR is subtask of [JDK-8256008](https://bugs.openjdk.java.net/browse/JDK-8256008) (#1106) > > `LogFileStreamOutput::write()` uses `os::flockfile()` and `os::funlockfile()` to serialize write ops. It is better to use RAII because we can ensure `os::funlockfile()` call. Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Remove funlockfile() call ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1156/files - new: https://git.openjdk.java.net/jdk/pull/1156/files/71adb8e4..ada14868 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1156&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1156&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1156.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1156/head:pull/1156 PR: https://git.openjdk.java.net/jdk/pull/1156 From stuefe at openjdk.java.net Wed Nov 11 08:19:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 11 Nov 2020 08:19:58 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails In-Reply-To: <3cwv2rmGojtsvDcQXWdfCx8tqrRjbx9Fe-rnMoUazqY=.254ef493-a888-4955-a50c-122dedec8772@github.com> References: <1K5zbwcC_LPNVUZmN4abFHyAnCe4Kkm5mM1tmNS7j2M=.1c23a3ac-9c7d-4598-ad61-75e25cd6a5e1@github.com> <3cwv2rmGojtsvDcQXWdfCx8tqrRjbx9Fe-rnMoUazqY=.254ef493-a888-4955-a50c-122dedec8772@github.com> Message-ID: <9FFZ2_lflMLIQgNDqNOAYVjFGDTq6dEMtYzf7Iv_uCY=.e6d9e449-1f17-4ece-ab44-c700a0e19959@github.com> On Wed, 11 Nov 2020 07:12:26 GMT, Thomas Stuefe wrote: >>> > > * If you handle errors from writing, make sure you handle intermittend write errors correctly. You probably want to handle EINTR by re-trying to write. >>> > >>> > >>> > `LogFileStreamOutput::write()` uses `jio_fprintf()` (wrapper of `vfprintf()` ) and `fflush()`. In case of `fflush()`, we can retry, however `jio_fprintf()` can be done in the same way? `vfprintf()` might not set `errno` if error happens. (I'm not sure) >>> >>> Hmm. Thinking about this some more: >>> >>> Without reading your patch closely, what is the strategy you propose if a write error happens? >>> >>> 1. Will you write a message, then refuse further log attempts? >>> 2. Will you write a message, but continue logging? Writing a message each time an error happens? >>> 3. Will you write a message only for the first write error and then not refuse further log attempts? >>> >>> Depending on this we should handle intermittent errors (EINTR and maybe EAGAIN) or can continute to ignore them. >>> With (1) we should handle (ignore) intermittent errors to prevent one spurious write error from stoppng the log. >>> With (2) we don't have to handle them since we do essentially what we do today, but a bad IO device may now cause a flood of messages. >>> With (3) we don't have to either but will only see the first UL writing problem. >>> >>> Not sure what I like best. What did you propose? >> >> I've proposed (3) on this patch. I want to notice log writing is failed due to some error when log file is strange. >> >> Error message would be shown only the first time an error occurs, however logger would not be disabled because someone might make free disk space without rebooting JVM. >> I thought (1) at first, but I didn't do so because it requires operator to resume logging (e.g. `jcmd VM.log`) when the problem is fixed. >> >>> > > * I see you make an RAII object to handle flock. Could you leave this out please to make this change easier to review? I am not against it, but would prefer this in a separate cleanup change. >>> > >>> > >>> > If `FileLocker` is removed from this change, I want to add it on another RFE before this because this change makes to return from several locations in `LogFileStreamOutput::write()`. >>> > Do you agree create subtask (RFE) to add `FileLocker`? >>> >>> Yes. But on second thought, I don't want to cause you unnecessary work. So if that is all the cleanup you'll do in this patch, I am fine with it too. >> >> No problem, I will add it as RFE to JBS. > >> > > > * If you handle errors from writing, make sure you handle intermittend write errors correctly. You probably want to handle EINTR by re-trying to write. >> > > >> > > >> > > `LogFileStreamOutput::write()` uses `jio_fprintf()` (wrapper of `vfprintf()` ) and `fflush()`. In case of `fflush()`, we can retry, however `jio_fprintf()` can be done in the same way? `vfprintf()` might not set `errno` if error happens. (I'm not sure) >> > >> > >> > Hmm. Thinking about this some more: >> > Without reading your patch closely, what is the strategy you propose if a write error happens? >> > >> > 1. Will you write a message, then refuse further log attempts? >> > 2. Will you write a message, but continue logging? Writing a message each time an error happens? >> > 3. Will you write a message only for the first write error and then not refuse further log attempts? >> > >> > Depending on this we should handle intermittent errors (EINTR and maybe EAGAIN) or can continute to ignore them. >> > With (1) we should handle (ignore) intermittent errors to prevent one spurious write error from stoppng the log. >> > With (2) we don't have to handle them since we do essentially what we do today, but a bad IO device may now cause a flood of messages. >> > With (3) we don't have to either but will only see the first UL writing problem. >> > Not sure what I like best. What did you propose? >> >> I've proposed (3) on this patch. I want to notice log writing is failed due to some error when log file is strange. >> >> Error message would be shown only the first time an error occurs, however logger would not be disabled because someone might make free disk space without rebooting JVM. >> I thought (1) at first, but I didn't do so because it requires operator to resume logging (e.g. `jcmd VM.log`) when the problem is fixed. > > This makes sense. Its what I would have done too. > >> >> > > > * I see you make an RAII object to handle flock. Could you leave this out please to make this change easier to review? I am not against it, but would prefer this in a separate cleanup change. >> > > >> > > >> > > If `FileLocker` is removed from this change, I want to add it on another RFE before this because this change makes to return from several locations in `LogFileStreamOutput::write()`. >> > > Do you agree create subtask (RFE) to add `FileLocker`? >> > >> > >> > Yes. But on second thought, I don't want to cause you unnecessary work. So if that is all the cleanup you'll do in this patch, I am fine with it too. >> >> No problem, I will add it as RFE to JBS. > > Thanks. I'll review the patch in detail in the next days. > > Cheers, Thomas > Thanks @tstuefe ! I've sent PR for RAII object in #1156 . I will update this PR after #1156 is pushed. Okay I'll wait ------------- PR: https://git.openjdk.java.net/jdk/pull/1106 From stuefe at openjdk.java.net Wed Nov 11 10:19:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 11 Nov 2020 10:19:59 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v2] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Wed, 11 Nov 2020 02:28:09 GMT, Yumin Qi wrote: >> Hi, Please review >> >> JDK-8255917 failed on not finding the committed region from the _reserved_regions list when try to add the region to the committed list. It looks like possible the region was released without logged. >> Added a log tag for tracing Native Memory Tracking (NMT) add/remove recorded info. This could help us to identify the problem for NMT or the code behind NMT. Function pd_attempt_reserve_memory_at could fail, but no message logged, so added a logging for its failure. >> >> Tests: tier1-4, local jtreg. > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fix the region extra type name Hi, Yumin, are you sure UL is safe to use from inside NMT? I see that UL seems to allocate memory, see e.g. LogTagSet::vwrite(). Mentally I had earmarked UL as "don't use in anything at or below os::malloc". Other than that, only small nits. Cheers, Thomas src/hotspot/share/runtime/os.cpp line 1672: > 1670: MemTracker::record_virtual_memory_reserve((address)result, bytes, CALLER_PC); > 1671: } else { > 1672: log_info(metaspace)("Attempt to reserve memory at " INTPTR_FORMAT " for " Why is this logged for "metaspace"? I would use "os" src/hotspot/share/services/virtualMemoryTracker.cpp line 293: > 291: void ReservedMemoryRegion::set_flag(MEMFLAGS f) { > 292: assert((flag() == mtNone || flag() == f), > 293: "Overwrite memory type for region [" INTPTR_FORMAT "-" INTPTR_FORMAT "), %u->%u.", Why the explicit change to INTPTR_FORMAT? (real question, I actually do not know the difference to PTR_FORMAT, since their definition seems to be identical) ------------- PR: https://git.openjdk.java.net/jdk/pull/1150 From stuefe at openjdk.java.net Wed Nov 11 14:13:06 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 11 Nov 2020 14:13:06 GMT Subject: RFR: JDK-8255978: [windows] os::release_memory may not release the full range Message-ID: On Windows, os::release_memory(p,size) may not actually release the whole region if it contains multiple mappings. This may cause memory bloat or runaway leaks or errors which look like failed mappings to specific wish addresses. Background: On Windows, memory mappings are established with VirtualAlloc() [1] and released with VirtualFree() [2]. In constrast to POSIX munmap(), VirtualFree() can only release a single full range established with VirtualAlloc(). It cannot release multiple ranges, or parts of a range. The Windows implementation of os::release_memory(p, size) [3] calls VirtualFree(p, NULL, MEM_RELEASE) - it ignores the size parameter and releases whatever mapping happens to start at p: bool os::pd_release_memory(char* addr, size_t bytes) { return VirtualFree(addr, 0, MEM_RELEASE) != 0; } ... which assumes that the given range size corresponds to the size of a mapping starting at p. This may be incorrect: 1) For NUMA-friendly allocation, we allocate memory in stripes, each stripe individually allocated. 2) For +UseLargePagesIndividualAllocation we do the same 3) apart from that, the given region size may just be wrong. Since we never check these, we may never have noticed. I am currently running tests to find out if we have other mismatched releases. For cases (1) and (2), we would just release the first stripe in that striped range, leaving the rest of the mappings intact. This is not immediately noticeable, since VirtualFree() returns success. And even if it did not, we usually ignore the return code of os::release_memory(). The problem is aggrevated since, on Windows, we often employ an "optimistically-release-and-remap" approach: since mappings are undivisible, if one wants to change their size, split them or similar, one has to follow this sequence: a) release old allocation b) place into the now vacated address room one or more new allocations This is not guaranteed to work, since between (a) and (b) someone may have grabbed the address space. We live with that since there is no way to do this differently. When used on a range which contains multiple mappings, this technique is almost guaranteed to fail. In that case, (a) would only release the first mapping in the range. (b) would almost certainly fail since most of the original range would still be mapped. Examples of these technique in os_windows.cpp: - os::split_reseved_memory() (see also [4]) - map_or_reserve_memory_aligned() - os::replace_existing_mapping_with_file_mapping() This can manifest as small memory leak or inability to attach to a given wish address. It could also result in a viscous loop ([5], [6]) and result in ballooning and native OOMs. -- AFAICS this is an old issue, dating back to at least jdk 8. -- The change in detail: - os::release_memory() on Window now: - in LP/NUMA case we unmap all mappings in the given range. The mappings must match the range exactly, otherwise we assert. - In normal case we just check the given range and assert if it does not match. Note: in release builds I just print a warning and return false. Should this be a guarantee? I leave that up to the Reviewers. - Added gtests which test os::release_memory() with a variety of scenarios. Includes both positive and negative tests. The latter includes a death test for debug. - Added a helper function to find mappings, for now windows only (os::win32::find_mapping()), including gtests for that function. - Added a function to print mappings, for diagnostic purposes: os::print_memory_mappings(). Provided an implementation for linux and windows. -- [1] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc [2] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualfree [3] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3394 [4] https://bugs.openjdk.java.net/browse/JDK-8253649 [5] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3150 [6] https://bugs.openjdk.java.net/browse/JDK-8255954 ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/1143/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1143&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255978 Stats: 494 lines in 7 files changed: 493 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1143.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1143/head:pull/1143 PR: https://git.openjdk.java.net/jdk/pull/1143 From redestad at openjdk.java.net Wed Nov 11 18:55:00 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 Nov 2020 18:55:00 GMT Subject: RFR: 8256205: Simplify compiler calling convention handling Message-ID: Clean up and simplify some of the calling convention handling: - Remove Matcher::calling_convention/c_calling_convention and replace select few call sites with direct calls to SharedRuntime - Remove unused is_outgoing args. Since the SPARC removal the is_outgoing has no effect on the calling_convention or return_value methods. - Move in_preserved_stack_slots to SharedRuntime to match out_preserved_stack_slots. This has a tiny positive impact by reducing calls and improving inlining (at least gcc has a hard time inlining anything that goes in the .ad files, even when it's defined to the same class), but is mainly a cleanup effort. Testing: Oracle tier1-2 testing; S390, PPC and ARM32 builds ------------- Commit messages: - trailing whitespace - Merge branch 'master' into call_conv - Merge branch 'master' into call_conv - Remove in_preserve_stack_slots to SharedRuntime - Fix missing return_value fixup - Drop out_preserve_stack_slots from adlc output - Clean-up calling_convention handling Changes: https://git.openjdk.java.net/jdk/pull/1168/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1168&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256205 Stats: 359 lines in 31 files changed: 54 ins; 255 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/1168.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1168/head:pull/1168 PR: https://git.openjdk.java.net/jdk/pull/1168 From shade at openjdk.java.net Wed Nov 11 19:47:01 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 Nov 2020 19:47:01 GMT Subject: RFR: 8256237: Zero: non-PCH build fails after JDK-8253064 Message-ID: This shows up in GH actions, and reproduces locally: 42 | Handle thread_group (THREAD, Universe::system_thread_group()); | ^~~~~~~~ Attention @dcubed-ojdk ;) Testing: - [x] Local Linux x86_64 Zero fastdebug build ------------- Commit messages: - 8256237: Zero: non-PCH build fails after JDK-8253064 Changes: https://git.openjdk.java.net/jdk/pull/1174/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1174&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256237 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1174.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1174/head:pull/1174 PR: https://git.openjdk.java.net/jdk/pull/1174 From zgu at openjdk.java.net Wed Nov 11 19:47:01 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 11 Nov 2020 19:47:01 GMT Subject: RFR: 8256237: Zero: non-PCH build fails after JDK-8253064 In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 19:39:55 GMT, Aleksey Shipilev wrote: > This shows up in GH actions, and reproduces locally: > > > > 42 | Handle thread_group (THREAD, Universe::system_thread_group()); > | ^~~~~~~~ > Attention @dcubed-ojdk ;) > > Testing: > - [x] Local Linux x86_64 Zero fastdebug build Looks good and trivial. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1174 From dcubed at openjdk.java.net Wed Nov 11 19:50:56 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 11 Nov 2020 19:50:56 GMT Subject: RFR: 8256237: Zero: non-PCH build fails after JDK-8253064 In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 19:39:55 GMT, Aleksey Shipilev wrote: > This shows up in GH actions, and reproduces locally: > > > > 42 | Handle thread_group (THREAD, Universe::system_thread_group()); > | ^~~~~~~~ > Attention @dcubed-ojdk ;) > > Testing: > - [x] Local Linux x86_64 Zero fastdebug build Thanks for fixing this. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1174 From shade at openjdk.java.net Wed Nov 11 19:54:55 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 Nov 2020 19:54:55 GMT Subject: RFR: 8256237: Zero: non-PCH build fails after JDK-8253064 In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 19:48:07 GMT, Daniel D. Daugherty wrote: >> This shows up in GH actions, and reproduces locally: >> >> >> >> 42 | Handle thread_group (THREAD, Universe::system_thread_group()); >> | ^~~~~~~~ >> Attention @dcubed-ojdk ;) >> >> Testing: >> - [x] Local Linux x86_64 Zero fastdebug build > > Thanks for fixing this. Cheers! @dcubed-ojdk, please consider re-enabling submit workflow, if you had it disabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/1174 From shade at openjdk.java.net Wed Nov 11 19:54:56 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 Nov 2020 19:54:56 GMT Subject: Integrated: 8256237: Zero: non-PCH build fails after JDK-8253064 In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 19:39:55 GMT, Aleksey Shipilev wrote: > This shows up in GH actions, and reproduces locally: > > > > 42 | Handle thread_group (THREAD, Universe::system_thread_group()); > | ^~~~~~~~ > Attention @dcubed-ojdk ;) > > Testing: > - [x] Local Linux x86_64 Zero fastdebug build This pull request has now been integrated. Changeset: 59965c17 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/59965c17 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8256237: Zero: non-PCH build fails after JDK-8253064 Reviewed-by: zgu, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/1174 From minqi at openjdk.java.net Wed Nov 11 19:58:57 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 11 Nov 2020 19:58:57 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v2] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Wed, 11 Nov 2020 10:17:07 GMT, Thomas Stuefe wrote: > Hi, Yumin, > > are you sure UL is safe to use from inside NMT? I see that UL seems to allocate memory, see e.g. LogTagSet::vwrite(). Mentally I had earmarked UL as "don't use in anything at or below os::malloc". > > Other than that, only small nits. > > Cheers, Thomas The stack allocated buffer size is a const here, logTagSet.cpp:110 const size_t vwrite_buffer_size = 512; That says if the print string is greater than 512, it will allocate heap for print the part over 512. For this case, it will not be over size of 512. ------------- PR: https://git.openjdk.java.net/jdk/pull/1150 From minqi at openjdk.java.net Wed Nov 11 20:05:58 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 11 Nov 2020 20:05:58 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v2] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Wed, 11 Nov 2020 10:12:18 GMT, Thomas Stuefe wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix the region extra type name > > src/hotspot/share/services/virtualMemoryTracker.cpp line 293: > >> 291: void ReservedMemoryRegion::set_flag(MEMFLAGS f) { >> 292: assert((flag() == mtNone || flag() == f), >> 293: "Overwrite memory type for region [" INTPTR_FORMAT "-" INTPTR_FORMAT "), %u->%u.", > > Why the explicit change to INTPTR_FORMAT? (real question, I actually do not know the difference to PTR_FORMAT, since their definition seems to be identical) They are defined as same, and p2i: inline intptr_t p2i(const void * p) { return (intptr_t) p; } This way I think better use INTPTR_FORMAT, it is consistent with the type here. > src/hotspot/share/runtime/os.cpp line 1672: > >> 1670: MemTracker::record_virtual_memory_reserve((address)result, bytes, CALLER_PC); >> 1671: } else { >> 1672: log_info(metaspace)("Attempt to reserve memory at " INTPTR_FORMAT " for " > > Why is this logged for "metaspace"? I would use "os" Since we in this bug only concern about metaspace, if we specify -Xlog:os, it will output messaged we are not interested in from other places. I will wait for other inputs for this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1150 From iklam at openjdk.java.net Thu Nov 12 00:46:53 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 12 Nov 2020 00:46:53 GMT Subject: RFR: JDK-8255978: [windows] os::release_memory may not release the full range In-Reply-To: References: Message-ID: On Tue, 10 Nov 2020 13:55:54 GMT, Thomas Stuefe wrote: > On Windows, os::release_memory(p,size) may not actually release the whole region if it contains multiple mappings. This may cause memory bloat or runaway leaks or errors which look like failed mappings to specific wish addresses. > > Background: > > On Windows, memory mappings are established with VirtualAlloc() [1] and released with VirtualFree() [2]. In constrast to POSIX munmap(), VirtualFree() can only release a single full range established with VirtualAlloc(). It cannot release multiple ranges, or parts of a range. > > The Windows implementation of os::release_memory(p, size) [3] calls VirtualFree(p, NULL, MEM_RELEASE) - it ignores the size parameter and releases whatever mapping happens to start at p: > > bool os::pd_release_memory(char* addr, size_t bytes) { > return VirtualFree(addr, 0, MEM_RELEASE) != 0; > } > > ... which assumes that the given range size corresponds to the size of a mapping starting at p. > > This may be incorrect: > > 1) For NUMA-friendly allocation, we allocate memory in stripes, each stripe individually allocated. > 2) For +UseLargePagesIndividualAllocation we do the same > 3) apart from that, the given region size may just be wrong. Since we never check these, we may never have noticed. I am currently running tests to find out if we have other mismatched releases. > > For cases (1) and (2), we would just release the first stripe in that striped range, leaving the rest of the mappings intact. This is not immediately noticeable, since VirtualFree() returns success. And even if it did not, we usually ignore the return code of os::release_memory(). > > The problem is aggrevated since, on Windows, we often employ an "optimistically-release-and-remap" approach: since mappings are undivisible, if one wants to change their size, split them or similar, one has to follow this sequence: > > a) release old allocation > b) place into the now vacated address room one or more new allocations > > This is not guaranteed to work, since between (a) and (b) someone may have grabbed the address space. We live with that since there is no way to do this differently. > > When used on a range which contains multiple mappings, this technique is almost guaranteed to fail. In that case, (a) would only release the first mapping in the range. (b) would almost certainly fail since most of the original range would still be mapped. > > Examples of these technique in os_windows.cpp: > - os::split_reseved_memory() (see also [4]) > - map_or_reserve_memory_aligned() > - os::replace_existing_mapping_with_file_mapping() > > This can manifest as small memory leak or inability to attach to a given wish address. It could also result in a viscous loop ([5], [6]) and result in ballooning and native OOMs. > > -- > > AFAICS this is an old issue, dating back to at least jdk 8. > > -- > > The change in detail: > > - os::release_memory() on Window now: > - in LP/NUMA case we unmap all mappings in the given range. The mappings must match the range exactly, otherwise we assert. > - In normal case we just check the given range and assert if it does not match. > Note: in release builds I just print a warning and return false. Should this be a guarantee? I leave that up to the Reviewers. > > - Added gtests which test os::release_memory() with a variety of scenarios. Includes both positive and negative tests. The latter includes a death test for debug. > > - Added a helper function to find mappings, for now windows only (os::win32::find_mapping()), including gtests for that function. > > - Added a function to print mappings, for diagnostic purposes: os::print_memory_mappings(). Provided an implementation for linux and windows. > > > -- > [1] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc > [2] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualfree > [3] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3394 > [4] https://bugs.openjdk.java.net/browse/JDK-8253649 > [5] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3150 > [6] https://bugs.openjdk.java.net/browse/JDK-8255954 LGTM. I am running on mach5 tiers 1-3 to make sure the new test cases don't have any surprises :-) ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1143 From dholmes at openjdk.java.net Thu Nov 12 02:27:59 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 Nov 2020 02:27:59 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v2] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Wed, 11 Nov 2020 02:28:09 GMT, Yumin Qi wrote: >> Hi, Please review >> >> JDK-8255917 failed on not finding the committed region from the _reserved_regions list when try to add the region to the committed list. It looks like possible the region was released without logged. >> Added a log tag for tracing Native Memory Tracking (NMT) add/remove recorded info. This could help us to identify the problem for NMT or the code behind NMT. Function pd_attempt_reserve_memory_at could fail, but no message logged, so added a logging for its failure. >> >> Tests: tier1-4, local jtreg. > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fix the region extra type name Hi Yumin, I also have concerns about the safety of using UL in these low-level NMT routines as it is not obvious that you can't get into some kind of recursion situation. More comments below. Thanks, David ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1150 From dholmes at openjdk.java.net Thu Nov 12 02:27:59 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 Nov 2020 02:27:59 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v2] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Wed, 11 Nov 2020 20:03:32 GMT, Yumin Qi wrote: >> src/hotspot/share/runtime/os.cpp line 1672: >> >>> 1670: MemTracker::record_virtual_memory_reserve((address)result, bytes, CALLER_PC); >>> 1671: } else { >>> 1672: log_info(metaspace)("Attempt to reserve memory at " INTPTR_FORMAT " for " >> >> Why is this logged for "metaspace"? I would use "os" > > Since we in this bug only concern about metaspace, if we specify -Xlog:os, it will output messaged we are not interested in from other places. I will wait for other inputs for this. This is 'os' code so the logging should be in the os tag space, though it could be os+metaspace. I also think info is inappropriate and this should be debug or trace level. Alternatively put the logging in a caller that is more obviously only for metaspace. >> src/hotspot/share/services/virtualMemoryTracker.cpp line 293: >> >>> 291: void ReservedMemoryRegion::set_flag(MEMFLAGS f) { >>> 292: assert((flag() == mtNone || flag() == f), >>> 293: "Overwrite memory type for region [" INTPTR_FORMAT "-" INTPTR_FORMAT "), %u->%u.", >> >> Why the explicit change to INTPTR_FORMAT? (real question, I actually do not know the difference to PTR_FORMAT, since their definition seems to be identical) > > They are defined as same, and p2i: > inline intptr_t p2i(const void * p) { > return (intptr_t) p; > } > This way I think better use INTPTR_FORMAT, it is consistent with the type here. I agree - semantically we use INTPTR_FORMAT when passing a p2i(x). Though it does beg the question as to why we are applying p2i in this case? ------------- PR: https://git.openjdk.java.net/jdk/pull/1150 From github.com+16932759+shqking at openjdk.java.net Thu Nov 12 02:33:56 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Thu, 12 Nov 2020 02:33:56 GMT Subject: Integrated: 8255975: Fix AArch64 OpenJDK build failure with gcc-5 In-Reply-To: References: Message-ID: On Fri, 6 Nov 2020 07:31:58 GMT, Hao Sun wrote: > As one C++17 feature, the argument 'message' of static_assert can be optional. > This feature, i.e. static_assert with no message, is supported by gcc-6 or > higher.[1] > > Add 'message' arguments in order to avoid compilation failures if gcc-5 is used. > > [1] https://gcc.gnu.org/projects/cxx-status.html This pull request has now been integrated. Changeset: da48003a Author: Hao Sun Committer: Nick Gasson URL: https://git.openjdk.java.net/jdk/commit/da48003a Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod 8255975: Fix AArch64 OpenJDK build failure with gcc-5 Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1088 From stuefe at openjdk.java.net Thu Nov 12 04:50:53 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 12 Nov 2020 04:50:53 GMT Subject: RFR: JDK-8255978: [windows] os::release_memory may not release the full range In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 00:44:19 GMT, Ioi Lam wrote: > LGTM. I am running on mach5 tiers 1-3 to make sure the new test cases don't have any surprises :-) Thank you Ioi! Our nightlies yesterday did not show anything, but we do not test much with LP or NUMA. Nor with NVDimm. So exotic combinations like those may pass us by. ------------- PR: https://git.openjdk.java.net/jdk/pull/1143 From minqi at openjdk.java.net Thu Nov 12 05:15:09 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 12 Nov 2020 05:15:09 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v3] In-Reply-To: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: > Hi, Please review > > JDK-8255917 failed on not finding the committed region from the _reserved_regions list when try to add the region to the committed list. It looks like possible the region was released without logged. > Added a log tag for tracing Native Memory Tracking (NMT) add/remove recorded info. This could help us to identify the problem for NMT or the code behind NMT. Function pd_attempt_reserve_memory_at could fail, but no message logged, so added a logging for its failure. > > Tests: tier1-4, local jtreg. Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Make nmt log at debug level, and attempt_reserve_memory_at failed log to os+metaspace debug level ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1150/files - new: https://git.openjdk.java.net/jdk/pull/1150/files/fd827f0c..67082078 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1150&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1150&range=01-02 Stats: 17 lines in 3 files changed: 3 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1150/head:pull/1150 PR: https://git.openjdk.java.net/jdk/pull/1150 From minqi at openjdk.java.net Thu Nov 12 05:15:09 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 12 Nov 2020 05:15:09 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v2] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Thu, 12 Nov 2020 02:10:41 GMT, David Holmes wrote: >> Since we in this bug only concern about metaspace, if we specify -Xlog:os, it will output messaged we are not interested in from other places. I will wait for other inputs for this. > > This is 'os' code so the logging should be in the os tag space, though it could be os+metaspace. I also think info is inappropriate and this should be debug or trace level. Alternatively put the logging in a caller that is more obviously only for metaspace. @dholmes-ora Thanks. I changed the log to os+metaspace at debug level. ------------- PR: https://git.openjdk.java.net/jdk/pull/1150 From dholmes at openjdk.java.net Thu Nov 12 05:27:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 Nov 2020 05:27:56 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v3] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Thu, 12 Nov 2020 05:15:09 GMT, Yumin Qi wrote: >> Hi, Please review >> >> JDK-8255917 failed on not finding the committed region from the _reserved_regions list when try to add the region to the committed list. It looks like possible the region was released without logged. >> Added a log tag for tracing Native Memory Tracking (NMT) add/remove recorded info. This could help us to identify the problem for NMT or the code behind NMT. Function pd_attempt_reserve_memory_at could fail, but no message logged, so added a logging for its failure. >> >> Tests: tier1-4, local jtreg. > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Make nmt log at debug level, and attempt_reserve_memory_at failed log to os+metaspace debug level Changes requested by dholmes (Reviewer). src/hotspot/share/runtime/os.cpp line 1672: > 1670: MemTracker::record_virtual_memory_reserve((address)result, bytes, CALLER_PC); > 1671: } else { > 1672: LogTarget(Debug, os, metaspace) lt; You only needed to change: `log_info(metaspace)("...");` to `log_debug(os, metaspace)("...")` ------------- PR: https://git.openjdk.java.net/jdk/pull/1150 From stuefe at openjdk.java.net Thu Nov 12 05:27:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 12 Nov 2020 05:27:57 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v3] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Thu, 12 Nov 2020 05:24:05 GMT, David Holmes wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Make nmt log at debug level, and attempt_reserve_memory_at failed log to os+metaspace debug level > > Changes requested by dholmes (Reviewer). Please don't use the metaspace tag for logging inside these generic functions, this makes no sense. Also, I kept the "metaspace" log clean and consistent with JEP387. This should log with only "os" and nothing else. Contrary to David I think the original "info" level is fine. We have no guidelines for this unfortunately, but I usually do hard errors - which are too "soft" for warning level, which is printed always - at info. And this output will not be seen often. About UL circularity, UL should get fixed - it should not allocate memory while logging. > src/hotspot/share/runtime/os.cpp line 1672: > >> 1670: MemTracker::record_virtual_memory_reserve((address)result, bytes, CALLER_PC); >> 1671: } else { >> 1672: LogTarget(Debug, os, metaspace) lt; > > You only needed to change: > `log_info(metaspace)("...");` > to > `log_debug(os, metaspace)("...")` I'd opt for info. This is a hard bug, which - almost - is worth a log_warning. It should not get drowned in debug or trace. ------------- PR: https://git.openjdk.java.net/jdk/pull/1150 From minqi at openjdk.java.net Thu Nov 12 05:46:55 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 12 Nov 2020 05:46:55 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v3] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Thu, 12 Nov 2020 05:25:26 GMT, Thomas Stuefe wrote: > Please don't use the metaspace tag for logging inside these generic functions, this makes no sense. Also, I kept the "metaspace" log clean and consistent with JEP387. This should log with only "os" and nothing else. > > Contrary to David I think the original "info" level is fine. We have no guidelines for this unfortunately, but I usually do hard errors - which are too "soft" for warning level, which is printed always - at info. And this output will not be seen often. > > About UL circularity, UL should get fixed - it should not allocate memory while logging. OK, I will use 'os' at info level then. I will file a separate issue for UL heap allocation issue. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1150 From stuefe at openjdk.java.net Thu Nov 12 06:12:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 12 Nov 2020 06:12:58 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v3] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Thu, 12 Nov 2020 05:15:09 GMT, Yumin Qi wrote: >> Hi, Please review >> >> JDK-8255917 failed on not finding the committed region from the _reserved_regions list when try to add the region to the committed list. It looks like possible the region was released without logged. >> Added a log tag for tracing Native Memory Tracking (NMT) add/remove recorded info. This could help us to identify the problem for NMT or the code behind NMT. Function pd_attempt_reserve_memory_at could fail, but no message logged, so added a logging for its failure. >> >> Tests: tier1-4, local jtreg. > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Make nmt log at debug level, and attempt_reserve_memory_at failed log to os+metaspace debug level Hi Yumin, thinking this through more closely, and looking at your work with JDK-8255917, I am not sure that you really need logging inside NMT. NMT just shows an error we should have detected way earlier when reserving. Knowing when reserve or commit failed would be very helpful. Currently I think Iois theory about the split_memory() messing up is the most probable. Even though I am not sure how that could have happened. But could you please also add logging to os::split_memory() on windows? Especially I'd like to know if the two re-reservation calls failed. To stop blocking this, I relent and leave all decisions about tags or log level to you. Lets get this logging out of the door, once we found the problem we can brush up the logging in a separate step. src/hotspot/share/runtime/os.cpp line 1676: > 1674: lt.print("Attempt to reserve memory at " INTPTR_FORMAT " for " > 1675: SIZE_FORMAT " bytes failed\n", p2i(addr), bytes); > 1676: } Can you please add GetLastError? (returns a 32bit unsigned, so use %u and maybe cast to unsigned explicitly: (.. failed (%u)", ..., (unsigned) ::GetLastError()) Is there any reason not to just use log_info(os)("..") instead of LogTarget? ------------- PR: https://git.openjdk.java.net/jdk/pull/1150 From minqi at openjdk.java.net Thu Nov 12 06:21:58 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 12 Nov 2020 06:21:58 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v3] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Thu, 12 Nov 2020 06:05:02 GMT, Thomas Stuefe wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Make nmt log at debug level, and attempt_reserve_memory_at failed log to os+metaspace debug level > > src/hotspot/share/runtime/os.cpp line 1676: > >> 1674: lt.print("Attempt to reserve memory at " INTPTR_FORMAT " for " >> 1675: SIZE_FORMAT " bytes failed\n", p2i(addr), bytes); >> 1676: } > > Can you please add GetLastError? (returns a 32bit unsigned, so use %u and maybe cast to unsigned explicitly: (.. failed (%u)", ..., (unsigned) ::GetLastError()) > > Is there any reason not to just use log_info(os)("..") instead of LogTarget? With using LogTarget, we can check if it is enabled, and skip the real printing work, but log_info etc also check that I think. I will add to get last error and change to use log_info(os)("...."). ------------- PR: https://git.openjdk.java.net/jdk/pull/1150 From dholmes at openjdk.java.net Thu Nov 12 07:21:55 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 Nov 2020 07:21:55 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v3] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Thu, 12 Nov 2020 06:10:29 GMT, Thomas Stuefe wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Make nmt log at debug level, and attempt_reserve_memory_at failed log to os+metaspace debug level > > Hi Yumin, > > thinking this through more closely, and looking at your work with JDK-8255917, I am not sure that you really need logging inside NMT. NMT just shows an error we should have detected way earlier when reserving. Knowing when reserve or commit failed would be very helpful. > > Currently I think Iois theory about the split_memory() messing up is the most probable. Even though I am not sure how that could have happened. But could you please also add logging to os::split_memory() on windows? Especially I'd like to know if the two re-reservation calls failed. > > To stop blocking this, I relent and leave all decisions about tags or log level to you. Lets get this logging out of the door, once we found the problem we can brush up the logging in a separate step. If we are adding _debugging_ output then the log level should be debug IMO. ------------- PR: https://git.openjdk.java.net/jdk/pull/1150 From pchilanomate at openjdk.java.net Thu Nov 12 15:31:05 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 12 Nov 2020 15:31:05 GMT Subject: RFR: 8256276: Temporarily disable gtest special_flags Message-ID: <_kMmcnhPTBtzHCQ5Pac3GRK7tAGiLe-gH-xv5aoIsec=.f564f119-8ffe-482f-a524-e59bbee84fec@github.com> Please review the following small fix. This issue will get resolved in the next days so this is just to reduce noise in the pipeline. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.java.net/jdk/pull/1188/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1188&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256276 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1188.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1188/head:pull/1188 PR: https://git.openjdk.java.net/jdk/pull/1188 From tschatzl at openjdk.java.net Thu Nov 12 15:44:59 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 12 Nov 2020 15:44:59 GMT Subject: RFR: 8256276: Temporarily disable gtest special_flags In-Reply-To: <_kMmcnhPTBtzHCQ5Pac3GRK7tAGiLe-gH-xv5aoIsec=.f564f119-8ffe-482f-a524-e59bbee84fec@github.com> References: <_kMmcnhPTBtzHCQ5Pac3GRK7tAGiLe-gH-xv5aoIsec=.f564f119-8ffe-482f-a524-e59bbee84fec@github.com> Message-ID: On Thu, 12 Nov 2020 15:23:27 GMT, Patricio Chilano Mateo wrote: > Please review the following small fix. This issue will get resolved in the next days so this is just to reduce noise in the pipeline. > > Thanks, > Patricio lgtm ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1188 From dcubed at openjdk.java.net Thu Nov 12 15:45:01 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 12 Nov 2020 15:45:01 GMT Subject: RFR: 8256276: Temporarily disable gtest special_flags In-Reply-To: <_kMmcnhPTBtzHCQ5Pac3GRK7tAGiLe-gH-xv5aoIsec=.f564f119-8ffe-482f-a524-e59bbee84fec@github.com> References: <_kMmcnhPTBtzHCQ5Pac3GRK7tAGiLe-gH-xv5aoIsec=.f564f119-8ffe-482f-a524-e59bbee84fec@github.com> Message-ID: On Thu, 12 Nov 2020 15:23:27 GMT, Patricio Chilano Mateo wrote: > Please review the following small fix. This issue will get resolved in the next days so this is just to reduce noise in the pipeline. > > Thanks, > Patricio Thumbs up! Thanks for taking care of this. This is a trivial fix and does not need to wait for 24 hours. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1188 From pchilanomate at openjdk.java.net Thu Nov 12 15:45:02 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 12 Nov 2020 15:45:02 GMT Subject: RFR: 8256276: Temporarily disable gtest special_flags In-Reply-To: References: <_kMmcnhPTBtzHCQ5Pac3GRK7tAGiLe-gH-xv5aoIsec=.f564f119-8ffe-482f-a524-e59bbee84fec@github.com> Message-ID: On Thu, 12 Nov 2020 15:40:01 GMT, Thomas Schatzl wrote: >> Please review the following small fix. This issue will get resolved in the next days so this is just to reduce noise in the pipeline. >> >> Thanks, >> Patricio > > lgtm Thanks @tschatzl and @dcubed-ojdk! ------------- PR: https://git.openjdk.java.net/jdk/pull/1188 From pchilanomate at openjdk.java.net Thu Nov 12 15:48:55 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 12 Nov 2020 15:48:55 GMT Subject: Integrated: 8256276: Temporarily disable gtest special_flags In-Reply-To: <_kMmcnhPTBtzHCQ5Pac3GRK7tAGiLe-gH-xv5aoIsec=.f564f119-8ffe-482f-a524-e59bbee84fec@github.com> References: <_kMmcnhPTBtzHCQ5Pac3GRK7tAGiLe-gH-xv5aoIsec=.f564f119-8ffe-482f-a524-e59bbee84fec@github.com> Message-ID: <25kwGG4guUwxWzcBAL5_i3_j99CbSMl3fDxNhy8ZwUU=.c00839e4-2124-42e1-b486-b3148ee89422@github.com> On Thu, 12 Nov 2020 15:23:27 GMT, Patricio Chilano Mateo wrote: > Please review the following small fix. This issue will get resolved in the next days so this is just to reduce noise in the pipeline. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 943acd22 Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/943acd22 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8256276: Temporarily disable gtest special_flags Reviewed-by: tschatzl, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/1188 From stuefe at openjdk.java.net Thu Nov 12 16:04:02 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 12 Nov 2020 16:04:02 GMT Subject: RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned Message-ID: Hi, may I please have reviews for this little fix: On windows, `map_or_reserve_memory_aligned()` attempts to allocate aligned memory by: 1) reserving larger area 2) releasing it 3) attempting to re-reserve into the vacated address space a smaller area at the aligned start address Since this may fail (between (2) and (3) someone may have grabbed that address concurrently), we do this in a loop. However, when failing to release it we will loop-reserve endlessly. This is one of the reasons for JDK-8255954 whose root cause will be fixed with JDK-8255978. But we should guard against endless loops independently from that. This patch: - limits the number we try this to 20. If in 20 cases someone else grabs address space concurrently, something is off... - now correctly handles the return code of the release operation (1): in debug we assert, since if release_memory() fails something is wrong and we should take a look. In the release case, we now return an error. Thanks! ------------- Commit messages: - Initial patch Changes: https://git.openjdk.java.net/jdk/pull/1191/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1191&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256287 Stats: 11 lines in 1 file changed: 6 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1191/head:pull/1191 PR: https://git.openjdk.java.net/jdk/pull/1191 From ccheung at openjdk.java.net Thu Nov 12 16:19:56 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 12 Nov 2020 16:19:56 GMT Subject: Integrated: 8255990: Bitmap region of dynamic CDS archive is not unmapped In-Reply-To: References: Message-ID: On Tue, 10 Nov 2020 23:25:11 GMT, Calvin Cheung wrote: > Add the missing call to `unmap_region` to unmap the bitmap region of a dynamic CDS archive. > > Also modify the `DynamicArchiveRelocationTest` to check for the "Unmapping region" message. > > Testing: > > - [x] tier1 > - tiers 2,3,4 (in progress) This pull request has now been integrated. Changeset: c6ab0fdb Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/c6ab0fdb Stats: 9 lines in 2 files changed: 8 ins; 0 del; 1 mod 8255990: Bitmap region of dynamic CDS archive is not unmapped Reviewed-by: iklam, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/1151 From stuefe at openjdk.java.net Thu Nov 12 17:00:04 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 12 Nov 2020 17:00:04 GMT Subject: RFR: JDK-8255885: Metaspace: freelist commit counter is not updated when purging Message-ID: Metaspace chunks are uncommitted, under certain conditions, when being returned to the Metaspace by a dying class loader. There are two places where this happens: 1) when individual chunks are returned (see ChunkManager::return_chunk_locked()) 2) later, when CLDG::purge()->Metaspace::purge()->ChunkManager::purge() is called - all free chunks are again checked and potentially uncommitted. Free chunks are kept in FreeChunkList. FreeChunkList has a counter for words-comitted. That counter gets updated when chunks are added and removed. However, path (2) does not change the list, it just uncommits chunks residing in that list. That passes under the FreeChunkList's radar and now the counter is off. ----- Review note: `ChunkManager` keeps free chunks. It has an instance of `FreeChunkListVector`, which has a series (one per chunk size) of `FreeChunkList` instances. The commit counter value is handed up from `FreeChunkList` to, eventually, `ChunkManager`. What changed: - I removed the counter (_committed_word_size) from FreeChunkList. This seemed the simplest and safest measure. Keeping this counter up-to-date is a hassle, since chunks may get committed and uncommitted while being in this list. - Now we calculate the number of committed words on the fly if asked, by iterating all chunks in the list and accumulating. To reflect this change, I change the name of "FreeChunkList::committed_word_size()" to "FreeChunkList::calc_committed_word_size()". In metaspace, anything named "calc_" is potentially expensive. - Same renamings in FreeChunkListVector and ChunkManager::total_committed_word_size() - to ChunkManager::calc_committed_word_size() Now these functions always deliver the correct result. However, they are potentially slower and now require the central metaspace lock. That is not a problem: the only user of this function is when collecting the statistics for the "VM.metaspace" jcmd report, and that happens under lock protection and walks all kind of stuff anyway, so walking the freelists won't hurt. Just to be sure, I removed the use of these functions from ChunkManager::print_on(), even though that was just a debug function. ----- Tests: This patch has been tested in our nightlies for a week now. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/1057/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1057&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255885 Stats: 60 lines in 6 files changed: 30 ins; 11 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/1057.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1057/head:pull/1057 PR: https://git.openjdk.java.net/jdk/pull/1057 From hseigel at openjdk.java.net Thu Nov 12 19:04:01 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 12 Nov 2020 19:04:01 GMT Subject: RFR: 8245215 Obsolete InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace Message-ID: Please review this change to obsolete options "InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace in JDK-16. The change was tested with tiers 1-2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64. Additionally, the options were tested locally: > $JAVA_TEST/bin/java -XX:+UseLargePagesInMetaspace -version Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseLargePagesInMetaspace; support was removed in 16.0 java version "16-internal" 2021-03-16 ... > $JAVA_TEST/bin/java -XX:InitialBootClassLoaderMetaspaceSize=4 -version Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option InitialBootClassLoaderMetaspaceSize; support was removed in 16.0 java version "16-internal" 2021-03-16 ... Thanks, Harold ------------- Commit messages: - 8245215 Obsolete InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace Changes: https://git.openjdk.java.net/jdk/pull/1194/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1194&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245215 Stats: 31 lines in 3 files changed: 2 ins; 29 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1194.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1194/head:pull/1194 PR: https://git.openjdk.java.net/jdk/pull/1194 From lfoltan at openjdk.java.net Thu Nov 12 19:28:57 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Thu, 12 Nov 2020 19:28:57 GMT Subject: RFR: 8245215 Obsolete InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 18:58:13 GMT, Harold Seigel wrote: > Please review this change to obsolete options "InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace in JDK-16. The change was tested with tiers 1-2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64. Additionally, the options were tested locally: > >> $JAVA_TEST/bin/java -XX:+UseLargePagesInMetaspace -version > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseLargePagesInMetaspace; support was removed in 16.0 > java version "16-internal" 2021-03-16 > ... >> $JAVA_TEST/bin/java -XX:InitialBootClassLoaderMetaspaceSize=4 -version > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option InitialBootClassLoaderMetaspaceSize; support was removed in 16.0 > java version "16-internal" 2021-03-16 > ... > > Thanks, Harold Looks good. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1194 From ccheung at openjdk.java.net Thu Nov 12 19:37:59 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 12 Nov 2020 19:37:59 GMT Subject: RFR: 8245215 Obsolete InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 18:58:13 GMT, Harold Seigel wrote: > Please review this change to obsolete options "InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace in JDK-16. The change was tested with tiers 1-2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64. Additionally, the options were tested locally: > >> $JAVA_TEST/bin/java -XX:+UseLargePagesInMetaspace -version > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseLargePagesInMetaspace; support was removed in 16.0 > java version "16-internal" 2021-03-16 > ... >> $JAVA_TEST/bin/java -XX:InitialBootClassLoaderMetaspaceSize=4 -version > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option InitialBootClassLoaderMetaspaceSize; support was removed in 16.0 > java version "16-internal" 2021-03-16 > ... > > Thanks, Harold LGTM ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1194 From hseigel at openjdk.java.net Thu Nov 12 19:38:00 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 12 Nov 2020 19:38:00 GMT Subject: RFR: 8245215 Obsolete InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 19:33:05 GMT, Calvin Cheung wrote: >> Please review this change to obsolete options "InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace in JDK-16. The change was tested with tiers 1-2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64. Additionally, the options were tested locally: >> >>> $JAVA_TEST/bin/java -XX:+UseLargePagesInMetaspace -version >> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseLargePagesInMetaspace; support was removed in 16.0 >> java version "16-internal" 2021-03-16 >> ... >>> $JAVA_TEST/bin/java -XX:InitialBootClassLoaderMetaspaceSize=4 -version >> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option InitialBootClassLoaderMetaspaceSize; support was removed in 16.0 >> java version "16-internal" 2021-03-16 >> ... >> >> Thanks, Harold > > LGTM Thanks Lois and Calvin for the reivews! ------------- PR: https://git.openjdk.java.net/jdk/pull/1194 From stuefe at openjdk.java.net Thu Nov 12 20:03:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 12 Nov 2020 20:03:59 GMT Subject: RFR: 8245215 Obsolete InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 18:58:13 GMT, Harold Seigel wrote: > Please review this change to obsolete options "InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace in JDK-16. The change was tested with tiers 1-2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64. Additionally, the options were tested locally: > >> $JAVA_TEST/bin/java -XX:+UseLargePagesInMetaspace -version > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseLargePagesInMetaspace; support was removed in 16.0 > java version "16-internal" 2021-03-16 > ... >> $JAVA_TEST/bin/java -XX:InitialBootClassLoaderMetaspaceSize=4 -version > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option InitialBootClassLoaderMetaspaceSize; support was removed in 16.0 > java version "16-internal" 2021-03-16 > ... > > Thanks, Harold LGTM. Thanks for taking care of this. Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1194 From minqi at openjdk.java.net Thu Nov 12 20:34:10 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 12 Nov 2020 20:34:10 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v4] In-Reply-To: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: > Hi, Please review > > JDK-8255917 failed on not finding the committed region from the _reserved_regions list when try to add the region to the committed list. It looks like possible the region was released without logged. > Added a log tag for tracing Native Memory Tracking (NMT) add/remove recorded info. This could help us to identify the problem for NMT or the code behind NMT. Function pd_attempt_reserve_memory_at could fail, but no message logged, so added a logging for its failure. > > Tests: tier1-4, local jtreg. Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Print out errno at failing to reserve memory region at debug log level ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1150/files - new: https://git.openjdk.java.net/jdk/pull/1150/files/67082078..c1fed912 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1150&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1150&range=02-03 Stats: 6 lines in 2 files changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1150/head:pull/1150 PR: https://git.openjdk.java.net/jdk/pull/1150 From stuefe at openjdk.java.net Thu Nov 12 21:12:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 12 Nov 2020 21:12:59 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v4] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: <1Wr_ZwntomUFEpEtB6Hi8V_aizwl6FcFNTxQ5L0IHoA=.f1d3153b-bc94-41ef-bc71-dae485f940a0@github.com> On Thu, 12 Nov 2020 20:34:10 GMT, Yumin Qi wrote: >> Hi, Please review >> >> JDK-8255917 failed on not finding the committed region from the _reserved_regions list when try to add the region to the committed list. It looks like possible the region was released without logged. >> Added a log tag for tracing Native Memory Tracking (NMT) add/remove recorded info. This could help us to identify the problem for NMT or the code behind NMT. Function pd_attempt_reserve_memory_at could fail, but no message logged, so added a logging for its failure. >> >> Tests: tier1-4, local jtreg. > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Print out errno at failing to reserve memory region at debug log level LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1150 From coleenp at openjdk.java.net Thu Nov 12 22:23:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 12 Nov 2020 22:23:57 GMT Subject: RFR: 8245215 Obsolete InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 18:58:13 GMT, Harold Seigel wrote: > Please review this change to obsolete options "InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace in JDK-16. The change was tested with tiers 1-2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64. Additionally, the options were tested locally: > >> $JAVA_TEST/bin/java -XX:+UseLargePagesInMetaspace -version > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseLargePagesInMetaspace; support was removed in 16.0 > java version "16-internal" 2021-03-16 > ... >> $JAVA_TEST/bin/java -XX:InitialBootClassLoaderMetaspaceSize=4 -version > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option InitialBootClassLoaderMetaspaceSize; support was removed in 16.0 > java version "16-internal" 2021-03-16 > ... > > Thanks, Harold thanks for fixing this! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1194 From iklam at openjdk.java.net Fri Nov 13 00:46:02 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 13 Nov 2020 00:46:02 GMT Subject: RFR: 8255973: Add more logging to debug JDK-8255917 [v4] In-Reply-To: References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Thu, 12 Nov 2020 20:34:10 GMT, Yumin Qi wrote: >> Hi, Please review >> >> JDK-8255917 failed on not finding the committed region from the _reserved_regions list when try to add the region to the committed list. It looks like possible the region was released without logged. >> Added a log tag for tracing Native Memory Tracking (NMT) add/remove recorded info. This could help us to identify the problem for NMT or the code behind NMT. Function pd_attempt_reserve_memory_at could fail, but no message logged, so added a logging for its failure. >> >> Tests: tier1-4, local jtreg. > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Print out errno at failing to reserve memory region at debug log level LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1150 From dholmes at openjdk.java.net Fri Nov 13 00:56:06 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 13 Nov 2020 00:56:06 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor Message-ID: This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. Testing: - GH actions - mach5 tiers 1-3 - selected performance testing (guided by that used for JDK-8253064) Thanks, David ------------- Commit messages: - 8225631: Consider replacing muxAcquire/Release with PlatformMonitor Changes: https://git.openjdk.java.net/jdk/pull/1196/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1196&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225631 Stats: 189 lines in 6 files changed: 11 ins; 164 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1196.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1196/head:pull/1196 PR: https://git.openjdk.java.net/jdk/pull/1196 From minqi at openjdk.java.net Fri Nov 13 03:47:57 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 13 Nov 2020 03:47:57 GMT Subject: Integrated: 8255973: Add more logging to debug JDK-8255917 In-Reply-To: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> References: <3QL0AFcF2z-bG8PZBCiEy3tdb0FqH-_QdqsoXqzXoN4=.47b78749-e179-4e35-a89e-74943eb56c40@github.com> Message-ID: On Tue, 10 Nov 2020 23:23:29 GMT, Yumin Qi wrote: > Hi, Please review > > JDK-8255917 failed on not finding the committed region from the _reserved_regions list when try to add the region to the committed list. It looks like possible the region was released without logged. > Added a log tag for tracing Native Memory Tracking (NMT) add/remove recorded info. This could help us to identify the problem for NMT or the code behind NMT. Function pd_attempt_reserve_memory_at could fail, but no message logged, so added a logging for its failure. > > Tests: tier1-4, local jtreg. This pull request has now been integrated. Changeset: 1d3d64f3 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/1d3d64f3 Stats: 44 lines in 5 files changed: 36 ins; 0 del; 8 mod 8255973: Add more logging to debug JDK-8255917 Reviewed-by: ccheung, stuefe, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/1150 From iklam at openjdk.java.net Fri Nov 13 06:06:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 13 Nov 2020 06:06:56 GMT Subject: RFR: JDK-8255978: [windows] os::release_memory may not release the full range In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 04:48:09 GMT, Thomas Stuefe wrote: > LGTM. I am running on mach5 tiers 1-3 to make sure the new test cases don't have any surprises :-) mach5 tiers 1-3 finished with no failure. ------------- PR: https://git.openjdk.java.net/jdk/pull/1143 From stuefe at openjdk.java.net Fri Nov 13 06:19:54 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 13 Nov 2020 06:19:54 GMT Subject: RFR: JDK-8255978: [windows] os::release_memory may not release the full range In-Reply-To: References: Message-ID: On Fri, 13 Nov 2020 06:03:50 GMT, Ioi Lam wrote: >>> LGTM. I am running on mach5 tiers 1-3 to make sure the new test cases don't have any surprises :-) >> >> Thank you Ioi! >> >> Our nightlies yesterday did not show anything, but we do not test much with LP or NUMA. Nor with NVDimm. So exotic combinations like those may pass us by. > >> LGTM. I am running on mach5 tiers 1-3 to make sure the new test cases don't have any surprises :-) > > mach5 tiers 1-3 finished with no failure. Great, thanks Ioi. May I please have a second review? This is tied to a P2 issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/1143 From stuefe at openjdk.java.net Fri Nov 13 07:02:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 13 Nov 2020 07:02:11 GMT Subject: RFR: JDK-8255978: [windows] os::release_memory may not release the full range [v2] In-Reply-To: References: Message-ID: > On Windows, os::release_memory(p,size) may not actually release the whole region if it contains multiple mappings. This may cause memory bloat or runaway leaks or errors which look like failed mappings to specific wish addresses. > > Background: > > On Windows, memory mappings are established with VirtualAlloc() [1] and released with VirtualFree() [2]. In constrast to POSIX munmap(), VirtualFree() can only release a single full range established with VirtualAlloc(). It cannot release multiple ranges, or parts of a range. > > The Windows implementation of os::release_memory(p, size) [3] calls VirtualFree(p, NULL, MEM_RELEASE) - it ignores the size parameter and releases whatever mapping happens to start at p: > > bool os::pd_release_memory(char* addr, size_t bytes) { > return VirtualFree(addr, 0, MEM_RELEASE) != 0; > } > > ... which assumes that the given range size corresponds to the size of a mapping starting at p. > > This may be incorrect: > > 1) For NUMA-friendly allocation, we allocate memory in stripes, each stripe individually allocated. > 2) For +UseLargePagesIndividualAllocation we do the same > 3) apart from that, the given region size may just be wrong. Since we never check these, we may never have noticed. I am currently running tests to find out if we have other mismatched releases. > > For cases (1) and (2), we would just release the first stripe in that striped range, leaving the rest of the mappings intact. This is not immediately noticeable, since VirtualFree() returns success. And even if it did not, we usually ignore the return code of os::release_memory(). > > The problem is aggrevated since, on Windows, we often employ an "optimistically-release-and-remap" approach: since mappings are undivisible, if one wants to change their size, split them or similar, one has to follow this sequence: > > a) release old allocation > b) place into the now vacated address room one or more new allocations > > This is not guaranteed to work, since between (a) and (b) someone may have grabbed the address space. We live with that since there is no way to do this differently. > > When used on a range which contains multiple mappings, this technique is almost guaranteed to fail. In that case, (a) would only release the first mapping in the range. (b) would almost certainly fail since most of the original range would still be mapped. > > Examples of these technique in os_windows.cpp: > - os::split_reseved_memory() (see also [4]) > - map_or_reserve_memory_aligned() > - os::replace_existing_mapping_with_file_mapping() > > This can manifest as small memory leak or inability to attach to a given wish address. It could also result in a viscous loop ([5], [6]) and result in ballooning and native OOMs. > > -- > > AFAICS this is an old issue, dating back to at least jdk 8. > > -- > > The change in detail: > > - os::release_memory() on Window now: > - in LP/NUMA case we unmap all mappings in the given range. The mappings must match the range exactly, otherwise we assert. > - In normal case we just check the given range and assert if it does not match. > Note: in release builds I just print a warning and return false. Should this be a guarantee? I leave that up to the Reviewers. > > - Added gtests which test os::release_memory() with a variety of scenarios. Includes both positive and negative tests. The latter includes a death test for debug. > > - Added a helper function to find mappings, for now windows only (os::win32::find_mapping()), including gtests for that function. > > - Added a function to print mappings, for diagnostic purposes: os::print_memory_mappings(). Provided an implementation for linux and windows. > > > -- > [1] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc > [2] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualfree > [3] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3394 > [4] https://bugs.openjdk.java.net/browse/JDK-8253649 > [5] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3150 > [6] https://bugs.openjdk.java.net/browse/JDK-8255954 Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge - Initial ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1143/files - new: https://git.openjdk.java.net/jdk/pull/1143/files/0a47110b..62ae188b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1143&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1143&range=00-01 Stats: 15353 lines in 292 files changed: 7833 ins; 5678 del; 1842 mod Patch: https://git.openjdk.java.net/jdk/pull/1143.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1143/head:pull/1143 PR: https://git.openjdk.java.net/jdk/pull/1143 From xxinliu at amazon.com Fri Nov 13 08:39:00 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Fri, 13 Nov 2020 08:39:00 +0000 Subject: RFR(S): 8247732: validate user-input intrinsic_ids in ControlIntrinsic In-Reply-To: <1596523192072.15354@amazon.com> References: <821e3d29-c95b-aafc-8ee5-6e49a1bdde82@amazon.com> <9b324805-eb86-27e1-5dcb-96a823f8495b@amazon.com> <82cba5e4-2020-ce0a-4576-e8e0cc2e5ae5@oracle.com> <1595401959932.33284@amazon.com> <1595520162373.22868@amazon.com> <916b3a4a-5617-941d-6161-840f3ea900bd@oracle.com> <1596523192072.15354@amazon.com> Message-ID: Hi, Nils, Could you take a look at this PR: https://github.com/openjdk/jdk/pull/1179 It should be the last patch of ControlIntrinsic, which add validation logic and regression test. I just renew it from the webrev. Because global.hpp has changed since then, I modify slightly to make sure it works with the new macros. This is non-trivial because the end-users have multiple approaches to use Disable/ControlIntrinsic. Now it conforms to the spec you gave me. https://bugs.openjdk.java.net/browse/JDK-8247732?focusedCommentId=14362773&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14362773 I add a few tests to cover different use cases. The only case that doesn't cover is invalid input directly from vmflag. Here it is: $java -XX:+UnlockDiagnosticVMOptions -XX:ControlIntrinsic=+_dtan,+_hello,+_max -version Unrecognized intrinsic detected in ControlIntrinsic: _hello Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Thanks, --lx ?On 8/3/20, 11:41 PM, "hotspot-runtime-dev on behalf of Liu, Xin" wrote: hi, Nils, Tobias would like to keep the parser behavior consistency. I think it means that the hotspot need to suppress the warning if the intrinsic_id doesn't exists in compiler directive. eg. -XX:CompileCommand=option,,ControlIntrinsic=-_nonexist. What do you think about it? Here is the latest webrev: http://cr.openjdk.java.net/~xliu/8247732/01/webrev/ thanks, --lx ________________________________________ From: Tobias Hartmann Sent: Friday, July 24, 2020 2:52 AM To: Liu, Xin; Nils Eliasson; hotspot-compiler-dev at openjdk.java.net; hotspot-runtime-dev Subject: RE: [EXTERNAL] RFR(S): 8247732: validate user-input intrinsic_ids in ControlIntrinsic CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi Liu, On 23.07.20 18:02, Liu, Xin wrote: > That is my intention too, but CompilerOracle doesn't exit JVM when it encounters parsing errors. > It just exacts information from CompileCommand as many as possible. That makes sense because compiler "directives" are supposed to be optional for program execution. > > I do put the error message in parser's errorbuf. I set a flag "exit_on_error" to quit JVM after it dumps parser errors. yes, I treat undefined intrinsics as fatal errors. > This behavior is from Nils comment: "I want to see an error on startup if the user has specified unknown intrinsic names." It is also consistent with JVM option -XX:ControlIntrinsic=. Okay, thanks for the explanation! I would prefer consistency in error handling of compiler directives, i.e., handle all parser failures the same way. But I leave it to Nils to decide. Best regards, Tobias From hseigel at openjdk.java.net Fri Nov 13 13:16:59 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 13 Nov 2020 13:16:59 GMT Subject: RFR: 8245215 Obsolete InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 22:20:43 GMT, Coleen Phillimore wrote: >> Please review this change to obsolete options "InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace in JDK-16. The change was tested with tiers 1-2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64. Additionally, the options were tested locally: >> >>> $JAVA_TEST/bin/java -XX:+UseLargePagesInMetaspace -version >> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseLargePagesInMetaspace; support was removed in 16.0 >> java version "16-internal" 2021-03-16 >> ... >>> $JAVA_TEST/bin/java -XX:InitialBootClassLoaderMetaspaceSize=4 -version >> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option InitialBootClassLoaderMetaspaceSize; support was removed in 16.0 >> java version "16-internal" 2021-03-16 >> ... >> >> Thanks, Harold > > thanks for fixing this! Thanks Thomas and Coleen for reviewing this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1194 From hseigel at openjdk.java.net Fri Nov 13 13:17:00 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 13 Nov 2020 13:17:00 GMT Subject: Integrated: 8245215 Obsolete InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 18:58:13 GMT, Harold Seigel wrote: > Please review this change to obsolete options "InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace in JDK-16. The change was tested with tiers 1-2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64. Additionally, the options were tested locally: > >> $JAVA_TEST/bin/java -XX:+UseLargePagesInMetaspace -version > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option UseLargePagesInMetaspace; support was removed in 16.0 > java version "16-internal" 2021-03-16 > ... >> $JAVA_TEST/bin/java -XX:InitialBootClassLoaderMetaspaceSize=4 -version > Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option InitialBootClassLoaderMetaspaceSize; support was removed in 16.0 > java version "16-internal" 2021-03-16 > ... > > Thanks, Harold This pull request has now been integrated. Changeset: 56ea7864 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/56ea7864 Stats: 31 lines in 3 files changed: 2 ins; 29 del; 0 mod 8245215: Obsolete InitialBootClassLoaderMetaspaceSize and UseLargePagesInMetaspace Reviewed-by: lfoltan, ccheung, stuefe, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1194 From coleenp at openjdk.java.net Fri Nov 13 13:51:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 13 Nov 2020 13:51:01 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor In-Reply-To: References: Message-ID: <4sk1VQN1HZyYkWvhSBTYSggS5It91ZYPHkFoaBUN_wU=.592c5d1e-df3b-4feb-a021-89c1f06ca666@github.com> On Fri, 13 Nov 2020 00:51:02 GMT, David Holmes wrote: > This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. > > On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. > > Testing: > - GH actions > - mach5 tiers 1-3 > - selected performance testing (guided by that used for JDK-8253064) > > Thanks, > David I've been waiting so long for this change! I love it. src/hotspot/share/runtime/synchronizer.cpp line 807: > 805: ObjectSynchronizer::gInflationLocks[ix]->lock(); > 806: while (obj->mark() == markWord::INFLATING()) { > 807: // Beware: naked_yield() is advisory and has almost no effect on some platforms Maybe you could hoist Thread::current() out of this loop? src/hotspot/share/runtime/synchronizer.hpp line 119: > 117: > 118: static const int NINFLATIONLOCKS = 256; > 119: static os::PlatformMutex* gInflationLocks[NINFLATIONLOCKS]; Why export these? Why not keep them local to synchronizer.cpp? src/hotspot/share/runtime/synchronizer.cpp line 801: > 799: // would detach the list and set the markword to inflated with a single CAS and > 800: // then for each thread on the list, set the flag and unpark() the thread. > 801: int ix = (cast_from_oop(obj) >> 5) & (ObjectSynchronizer::NINFLATIONLOCKS-1); I was trying to understand what this did. The comment is a lot less helpful than the code, but there are 3 TODO comments above this that I don't think we'll ever TODO (or haven't in the past 20 years) and refers to SafepointSynchronize::do_call_back(). Can you remove these in this change since adjacent? Also these ideas for future work in this comment really don't look like good ideas to me. ------------- Changes requested by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1196 From stefank at openjdk.java.net Fri Nov 13 14:18:12 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 13 Nov 2020 14:18:12 GMT Subject: RFR: 8256337: ap01t001.cpp, 67: Received unexpected number of ObjectFree events: 7 Message-ID: <7thDKusqZ5qwzxJF5J3GpAJZZXNmxeXGFUIHnb9uGYY=.57151319-45fb-48e4-beb7-458fb388093b@github.com> The ap01t001 test creates six extra instances of the tested class, let them die, and then checks that it gets exactly six ObjectFree callbacks. The problem is that this is verified in the VMDeath callback and at that point the instance has gone out-of-scope and and a seventh ObjectFree event has been triggered. My proposed fix is to ensure that the test instance is kept alive. ------------- Commit messages: - 8256337: ap01t001.cpp, 67: Received unexpected number of ObjectFree events: 7 Changes: https://git.openjdk.java.net/jdk/pull/1204/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1204&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256337 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1204.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1204/head:pull/1204 PR: https://git.openjdk.java.net/jdk/pull/1204 From stefank at openjdk.java.net Fri Nov 13 14:18:12 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 13 Nov 2020 14:18:12 GMT Subject: RFR: 8256337: ap01t001.cpp, 67: Received unexpected number of ObjectFree events: 7 In-Reply-To: <7thDKusqZ5qwzxJF5J3GpAJZZXNmxeXGFUIHnb9uGYY=.57151319-45fb-48e4-beb7-458fb388093b@github.com> References: <7thDKusqZ5qwzxJF5J3GpAJZZXNmxeXGFUIHnb9uGYY=.57151319-45fb-48e4-beb7-458fb388093b@github.com> Message-ID: On Fri, 13 Nov 2020 14:11:23 GMT, Stefan Karlsson wrote: > The ap01t001 test creates six extra instances of the tested class, let them die, and then checks that it gets exactly six ObjectFree callbacks. The problem is that this is verified in the VMDeath callback and at that point the instance has gone out-of-scope and and a seventh ObjectFree event has been triggered. > > My proposed fix is to ensure that the test instance is kept alive. I've tested this by running the following reproducer that used to trigger this bug: `while true; do make -C ../build/fastdebug jdk test-only TEST=test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP01/ap01t001/TestDescription.java JTREG="JAVA_OPTIONS= -XX:+UseZGC -Xmx2g -XX:ZCollectionInterval=0.01"; done` ------------- PR: https://git.openjdk.java.net/jdk/pull/1204 From coleenp at openjdk.java.net Fri Nov 13 14:38:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 13 Nov 2020 14:38:58 GMT Subject: RFR: 8256337: ap01t001.cpp, 67: Received unexpected number of ObjectFree events: 7 In-Reply-To: <7thDKusqZ5qwzxJF5J3GpAJZZXNmxeXGFUIHnb9uGYY=.57151319-45fb-48e4-beb7-458fb388093b@github.com> References: <7thDKusqZ5qwzxJF5J3GpAJZZXNmxeXGFUIHnb9uGYY=.57151319-45fb-48e4-beb7-458fb388093b@github.com> Message-ID: <-EkGKsgKr_YhOvzonEuoZKQQKdakFxI8kMoQ75uwCWE=.637c895f-3496-42b7-ade8-4e9dd1f3524c@github.com> On Fri, 13 Nov 2020 14:11:23 GMT, Stefan Karlsson wrote: > The ap01t001 test creates six extra instances of the tested class, let them die, and then checks that it gets exactly six ObjectFree callbacks. The problem is that this is verified in the VMDeath callback and at that point the instance has gone out-of-scope and and a seventh ObjectFree event has been triggered. > > My proposed fix is to ensure that the test instance is kept alive. Looks good and trivial. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1204 From dcubed at openjdk.java.net Fri Nov 13 17:44:10 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 13 Nov 2020 17:44:10 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor In-Reply-To: References: Message-ID: <26WWqn8l3KvS8W5vg45hrSM8Do4v8SnKGgZ5kqjUZ7s=.32530a8c-d73e-46a6-a070-64b621457de8@github.com> On Fri, 13 Nov 2020 00:51:02 GMT, David Holmes wrote: > This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. > > On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. > > Testing: > - GH actions > - mach5 tiers 1-3 > - selected performance testing (guided by that used for JDK-8253064) > > Thanks, > David I'm good with this fix modulo resolving @coleenp's comments about making NINFLATIONLOCKS and gInflationLocks exported. src/hotspot/share/runtime/thread.cpp line 4607: > 4605: // mechanism. > 4606: // > 4607: // Testing has shown that contention on the ListLock guarding gFreeList Ouch! I missed a reference to `gFreeList`. Sorry about that. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1196 From dcubed at openjdk.java.net Fri Nov 13 17:44:12 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 13 Nov 2020 17:44:12 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor In-Reply-To: <4sk1VQN1HZyYkWvhSBTYSggS5It91ZYPHkFoaBUN_wU=.592c5d1e-df3b-4feb-a021-89c1f06ca666@github.com> References: <4sk1VQN1HZyYkWvhSBTYSggS5It91ZYPHkFoaBUN_wU=.592c5d1e-df3b-4feb-a021-89c1f06ca666@github.com> Message-ID: On Fri, 13 Nov 2020 13:43:56 GMT, Coleen Phillimore wrote: >> This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. >> >> On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. >> >> Testing: >> - GH actions >> - mach5 tiers 1-3 >> - selected performance testing (guided by that used for JDK-8253064) >> >> Thanks, >> David > > src/hotspot/share/runtime/synchronizer.hpp line 119: > >> 117: >> 118: static const int NINFLATIONLOCKS = 256; >> 119: static os::PlatformMutex* gInflationLocks[NINFLATIONLOCKS]; > > Why export these? Why not keep them local to synchronizer.cpp? I was also wondering why. ------------- PR: https://git.openjdk.java.net/jdk/pull/1196 From sspitsyn at openjdk.java.net Fri Nov 13 19:29:00 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 13 Nov 2020 19:29:00 GMT Subject: RFR: 8256337: ap01t001.cpp, 67: Received unexpected number of ObjectFree events: 7 In-Reply-To: <7thDKusqZ5qwzxJF5J3GpAJZZXNmxeXGFUIHnb9uGYY=.57151319-45fb-48e4-beb7-458fb388093b@github.com> References: <7thDKusqZ5qwzxJF5J3GpAJZZXNmxeXGFUIHnb9uGYY=.57151319-45fb-48e4-beb7-458fb388093b@github.com> Message-ID: On Fri, 13 Nov 2020 14:11:23 GMT, Stefan Karlsson wrote: > The ap01t001 test creates six extra instances of the tested class, let them die, and then checks that it gets exactly six ObjectFree callbacks. The problem is that this is verified in the VMDeath callback and at that point the instance has gone out-of-scope and and a seventh ObjectFree event has been triggered. > > My proposed fix is to ensure that the test instance is kept alive. Hi Stefan, It looks good to me. Thank you for fixing it! Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1204 From dcubed at openjdk.java.net Fri Nov 13 22:51:08 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 13 Nov 2020 22:51:08 GMT Subject: RFR: 8134630: make code and comments consistent for stack lock optimization Message-ID: Comment only changes copied from the 'arm' version to the aarch64 and x86 versions of the files. I looked at the ppc and s390 files and it wasn't at all clear to me how to apply the same comment changes to those platforms. ------------- Commit messages: - 8134630: make code and comments consistent for stack lock optimization Changes: https://git.openjdk.java.net/jdk/pull/1210/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1210&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8134630 Stats: 42 lines in 2 files changed: 36 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1210.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1210/head:pull/1210 PR: https://git.openjdk.java.net/jdk/pull/1210 From dcubed at openjdk.java.net Fri Nov 13 23:24:00 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 13 Nov 2020 23:24:00 GMT Subject: RFR: 8244376: possibly stale comment above "struct SharedGlobals" in synchronizer.cpp Message-ID: Trivial change to delete a stale comment block. ------------- Commit messages: - 8244376: possibly stale comment above "struct SharedGlobals" in synchronizer.cpp Changes: https://git.openjdk.java.net/jdk/pull/1212/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1212&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244376 Stats: 18 lines in 1 file changed: 0 ins; 18 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1212/head:pull/1212 PR: https://git.openjdk.java.net/jdk/pull/1212 From dcubed at openjdk.java.net Fri Nov 13 23:24:01 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 13 Nov 2020 23:24:01 GMT Subject: RFR: 8244376: possibly stale comment above "struct SharedGlobals" in synchronizer.cpp In-Reply-To: References: Message-ID: On Fri, 13 Nov 2020 23:19:09 GMT, Daniel D. Daugherty wrote: > Trivial change to delete a stale comment block. label add hotspot-runtime ------------- PR: https://git.openjdk.java.net/jdk/pull/1212 From stuefe at openjdk.java.net Sat Nov 14 06:19:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 14 Nov 2020 06:19:59 GMT Subject: RFR: JDK-8256367: [windows] Better logging for some system calls Message-ID: Hi, may I please have reviews for the following patch. Its purpose is to make error analysis easier for cases like https://bugs.openjdk.java.net/browse/JDK-8255917 or https://bugs.openjdk.java.net/browse/JDK-8255954. It does two things: - it adds consistent tracing to some of the more important system calls, especially those having to do with virtual memory handling. We now log the success case (on the highest level only) as well as the error case (on the lowest possible level below warning). - It adds error handling and logging to os::split_reserved_memory(). It adds an assert if that function fails, since if it fails, we really should stop. Thank you, Thomas ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/1214/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1214&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256367 Stats: 112 lines in 1 file changed: 91 ins; 5 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1214.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1214/head:pull/1214 PR: https://git.openjdk.java.net/jdk/pull/1214 From hseigel at openjdk.java.net Sat Nov 14 16:20:54 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Sat, 14 Nov 2020 16:20:54 GMT Subject: RFR: 8244376: possibly stale comment above "struct SharedGlobals" in synchronizer.cpp In-Reply-To: References: Message-ID: On Fri, 13 Nov 2020 23:19:09 GMT, Daniel D. Daugherty wrote: > Trivial change to delete a stale comment block. Looks good! ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1212 From dcubed at openjdk.java.net Sun Nov 15 05:20:57 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sun, 15 Nov 2020 05:20:57 GMT Subject: RFR: 8244376: possibly stale comment above "struct SharedGlobals" in synchronizer.cpp In-Reply-To: References: Message-ID: <1XW2lfi5lebLtxY8elItLgvQdprpSwe6lxLGN5rp60c=.d3184764-2c6b-4640-b8b9-e9e482cbc5b3@github.com> On Sat, 14 Nov 2020 16:18:08 GMT, Harold Seigel wrote: >> Trivial change to delete a stale comment block. > > Looks good! @hseigel - Thanks for the review! @dholmes-ora - Can you verify that I implemented your suggestion correctly? ------------- PR: https://git.openjdk.java.net/jdk/pull/1212 From kbarrett at openjdk.java.net Sun Nov 15 20:11:55 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 15 Nov 2020 20:11:55 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor In-Reply-To: <4sk1VQN1HZyYkWvhSBTYSggS5It91ZYPHkFoaBUN_wU=.592c5d1e-df3b-4feb-a021-89c1f06ca666@github.com> References: <4sk1VQN1HZyYkWvhSBTYSggS5It91ZYPHkFoaBUN_wU=.592c5d1e-df3b-4feb-a021-89c1f06ca666@github.com> Message-ID: On Fri, 13 Nov 2020 13:47:42 GMT, Coleen Phillimore wrote: >> This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. >> >> On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. >> >> Testing: >> - GH actions >> - mach5 tiers 1-3 >> - selected performance testing (guided by that used for JDK-8253064) >> >> Thanks, >> David > > src/hotspot/share/runtime/synchronizer.cpp line 801: > >> 799: // would detach the list and set the markword to inflated with a single CAS and >> 800: // then for each thread on the list, set the flag and unpark() the thread. >> 801: int ix = (cast_from_oop(obj) >> 5) & (ObjectSynchronizer::NINFLATIONLOCKS-1); > > I was trying to understand what this did. The comment is a lot less helpful than the code, but there are 3 TODO comments above this that I don't think we'll ever TODO (or haven't in the past 20 years) and refers to SafepointSynchronize::do_call_back(). Can you remove these in this change since adjacent? Also these ideas for future work in this comment really don't look like good ideas to me. This is assuming NINFLATIONLOCKS is a power of 2. Consider adding a static_assert. (Note: is_power_of_2 was made constexpr by JDK-8247910.) ------------- PR: https://git.openjdk.java.net/jdk/pull/1196 From kbarrett at openjdk.java.net Sun Nov 15 20:34:54 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 15 Nov 2020 20:34:54 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor In-Reply-To: References: Message-ID: On Fri, 13 Nov 2020 00:51:02 GMT, David Holmes wrote: > This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. > > On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. > > Testing: > - GH actions > - mach5 tiers 1-3 > - selected performance testing (guided by that used for JDK-8253064) > > Thanks, > David Other than the question of the newly public things that others brought up, this looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1196 From david.holmes at oracle.com Sun Nov 15 22:32:10 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Nov 2020 08:32:10 +1000 Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor In-Reply-To: <26WWqn8l3KvS8W5vg45hrSM8Do4v8SnKGgZ5kqjUZ7s=.32530a8c-d73e-46a6-a070-64b621457de8@github.com> References: <26WWqn8l3KvS8W5vg45hrSM8Do4v8SnKGgZ5kqjUZ7s=.32530a8c-d73e-46a6-a070-64b621457de8@github.com> Message-ID: Hi Dan, Thanks for the review. On 14/11/2020 3:44 am, Daniel D.Daugherty wrote: > On Fri, 13 Nov 2020 00:51:02 GMT, David Holmes wrote: > >> This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. >> >> On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. >> >> Testing: >> - GH actions >> - mach5 tiers 1-3 >> - selected performance testing (guided by that used for JDK-8253064) >> >> Thanks, >> David > > I'm good with this fix modulo resolving @coleenp's comments > about making NINFLATIONLOCKS and gInflationLocks exported. Fixed. > src/hotspot/share/runtime/thread.cpp line 4607: > >> 4605: // mechanism. >> 4606: // >> 4607: // Testing has shown that contention on the ListLock guarding gFreeList > > Ouch! I missed a reference to `gFreeList`. Sorry about that. No problem! It forced me to determine which parts of the comments were still relevant. :) Thanks, David ----- > ------------- > > Marked as reviewed by dcubed (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1196 > From david.holmes at oracle.com Sun Nov 15 22:32:06 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Nov 2020 08:32:06 +1000 Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor In-Reply-To: References: <4sk1VQN1HZyYkWvhSBTYSggS5It91ZYPHkFoaBUN_wU=.592c5d1e-df3b-4feb-a021-89c1f06ca666@github.com> Message-ID: Hi Kim, Thanks for the review. On 16/11/2020 6:11 am, Kim Barrett wrote: > On Fri, 13 Nov 2020 13:47:42 GMT, Coleen Phillimore wrote: > >>> This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. >>> >>> On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. >>> >>> Testing: >>> - GH actions >>> - mach5 tiers 1-3 >>> - selected performance testing (guided by that used for JDK-8253064) >>> >>> Thanks, >>> David >> >> src/hotspot/share/runtime/synchronizer.cpp line 801: >> >>> 799: // would detach the list and set the markword to inflated with a single CAS and >>> 800: // then for each thread on the list, set the flag and unpark() the thread. >>> 801: int ix = (cast_from_oop(obj) >> 5) & (ObjectSynchronizer::NINFLATIONLOCKS-1); >> >> I was trying to understand what this did. The comment is a lot less helpful than the code, but there are 3 TODO comments above this that I don't think we'll ever TODO (or haven't in the past 20 years) and refers to SafepointSynchronize::do_call_back(). Can you remove these in this change since adjacent? Also these ideas for future work in this comment really don't look like good ideas to me. > > This is assuming NINFLATIONLOCKS is a power of 2. Consider adding a static_assert. (Note: is_power_of_2 was made constexpr by JDK-8247910.) Added to the initialize() function. Thanks, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1196 > From david.holmes at oracle.com Sun Nov 15 22:32:19 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Nov 2020 08:32:19 +1000 Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor In-Reply-To: <4sk1VQN1HZyYkWvhSBTYSggS5It91ZYPHkFoaBUN_wU=.592c5d1e-df3b-4feb-a021-89c1f06ca666@github.com> References: <4sk1VQN1HZyYkWvhSBTYSggS5It91ZYPHkFoaBUN_wU=.592c5d1e-df3b-4feb-a021-89c1f06ca666@github.com> Message-ID: Hi Coleen, Thanks for reviewing this. On 13/11/2020 11:51 pm, Coleen Phillimore wrote: > On Fri, 13 Nov 2020 00:51:02 GMT, David Holmes wrote: > >> This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. >> >> On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. >> >> Testing: >> - GH actions >> - mach5 tiers 1-3 >> - selected performance testing (guided by that used for JDK-8253064) >> >> Thanks, >> David > > I've been waiting so long for this change! I love it. > > src/hotspot/share/runtime/synchronizer.cpp line 807: > >> 805: ObjectSynchronizer::gInflationLocks[ix]->lock(); >> 806: while (obj->mark() == markWord::INFLATING()) { >> 807: // Beware: naked_yield() is advisory and has almost no effect on some platforms > > Maybe you could hoist Thread::current() out of this loop? I could but there's no real motivation for doing so as we are not trying to minimise the execution cost in this code. On the contrary, by lengthening the execution time of the inner chunk of code we probably improve the chances that the concurrent inflation is over. I will assume Dave Dice had his reasons for the current format. > src/hotspot/share/runtime/synchronizer.hpp line 119: > >> 117: >> 118: static const int NINFLATIONLOCKS = 256; >> 119: static os::PlatformMutex* gInflationLocks[NINFLATIONLOCKS]; > > Why export these? Why not keep them local to synchronizer.cpp? Good question! :) I've had this patch sitting around for 14 months and have no recollection as to why I may have exported these ... perhaps a misconception that they needed to be part of the class so that the initialize() method could access them. Fixed. > src/hotspot/share/runtime/synchronizer.cpp line 801: > >> 799: // would detach the list and set the markword to inflated with a single CAS and >> 800: // then for each thread on the list, set the flag and unpark() the thread. >> 801: int ix = (cast_from_oop(obj) >> 5) & (ObjectSynchronizer::NINFLATIONLOCKS-1); > > I was trying to understand what this did. The comment is a lot less helpful than the code, but there are 3 TODO comments above this that I don't think we'll ever TODO (or haven't in the past 20 years) and refers to SafepointSynchronize::do_call_back(). Can you remove these in this change since adjacent? Also these ideas for future work in this comment really don't look like good ideas to me. Line 801 simply uses part of the object address to index into the lock array - I've added a comment to that effect. I was going to leave the TODO's as Dice's code is always littered with these to provide guidance on future potential enhancements. But in this case the stale reference to do_call_back needed to be fixed, and as you note we're unlikely to ever actually make any changes directly to this part of the code, so I did remove them. Thanks, David ----- > ------------- > > Changes requested by coleenp (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1196 > From dholmes at openjdk.java.net Sun Nov 15 22:37:11 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 15 Nov 2020 22:37:11 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor [v2] In-Reply-To: References: Message-ID: > This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. > > On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. > > Testing: > - GH actions > - mach5 tiers 1-3 > - selected performance testing (guided by that used for JDK-8253064) > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Feedback from Coleen, Kim and Dan. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1196/files - new: https://git.openjdk.java.net/jdk/pull/1196/files/3441a16b..ee0063c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1196&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1196&range=00-01 Stats: 19 lines in 2 files changed: 4 ins; 7 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1196.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1196/head:pull/1196 PR: https://git.openjdk.java.net/jdk/pull/1196 From iklam at openjdk.java.net Mon Nov 16 01:09:55 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 16 Nov 2020 01:09:55 GMT Subject: RFR: JDK-8256367: [windows] Better logging for some system calls In-Reply-To: References: Message-ID: On Sat, 14 Nov 2020 06:15:29 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for the following patch. Its purpose is to make error analysis easier for cases like https://bugs.openjdk.java.net/browse/JDK-8255917 or https://bugs.openjdk.java.net/browse/JDK-8255954. > > It does two things: > - it adds consistent tracing to some of the more important system calls, especially those having to do with virtual memory handling. We now log the success case (on the highest level only) as well as the error case (on the lowest possible level below warning). > - It adds error handling and logging to os::split_reserved_memory(). It adds an assert if that function fails, since if it fails, we really should stop. > > Thank you, > > Thomas LGTM. Should the assert in os::split_reserved_memory() be changed to guarantee so it will stop the product build VM? ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1214 From dholmes at openjdk.java.net Mon Nov 16 04:24:55 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 16 Nov 2020 04:24:55 GMT Subject: RFR: 8244376: possibly stale comment above "struct SharedGlobals" in synchronizer.cpp In-Reply-To: References: Message-ID: On Fri, 13 Nov 2020 23:19:09 GMT, Daniel D. Daugherty wrote: > Trivial change to delete a stale comment block. I'm okay with the comment removal. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1212 From dholmes at openjdk.java.net Mon Nov 16 05:03:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 16 Nov 2020 05:03:10 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor [v3] In-Reply-To: References: Message-ID: > This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. > > On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. > > Testing: > - GH actions > - mach5 tiers 1-3 > - selected performance testing (guided by that used for JDK-8253064) > > Thanks, > David David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into 8225631 - Feedback from Coleen, Kim and Dan. - 8225631: Consider replacing muxAcquire/Release with PlatformMonitor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1196/files - new: https://git.openjdk.java.net/jdk/pull/1196/files/ee0063c6..7e3fe3db Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1196&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1196&range=01-02 Stats: 2807 lines in 63 files changed: 2276 ins; 188 del; 343 mod Patch: https://git.openjdk.java.net/jdk/pull/1196.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1196/head:pull/1196 PR: https://git.openjdk.java.net/jdk/pull/1196 From stuefe at openjdk.java.net Mon Nov 16 06:19:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 16 Nov 2020 06:19:55 GMT Subject: RFR: JDK-8256367: [windows] Better logging for some system calls In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 01:07:29 GMT, Ioi Lam wrote: > LGTM. Should the assert in os::split_reserved_memory() be changed to guarantee so it will stop the product build VM? Thanks Ioi. I'd rather not make it a guarantee - I find those a bad way to communicate errors to the end user. Ideally, the calling function should decide if it is worth continuing, but that would involve fixing ReservedSpace.(first|last)_part and was out of scope for that little fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/1214 From ysuenaga at openjdk.java.net Mon Nov 16 06:32:53 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 16 Nov 2020 06:32:53 GMT Subject: RFR: JDK-8256367: [windows] Better logging for some system calls In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 06:17:05 GMT, Thomas Stuefe wrote: >> LGTM. Should the assert in os::split_reserved_memory() be changed to guarantee so it will stop the product build VM? > >> LGTM. Should the assert in os::split_reserved_memory() be changed to guarantee so it will stop the product build VM? > > Thanks Ioi. I'd rather not make it a guarantee - I find those a bad way to communicate errors to the end user. Ideally, the calling function should decide if it is worth continuing, but that would involve fixing ReservedSpace.(first|last)_part and was out of scope for that little fix. Looks good, but should all `log_info()` should be replaced to `log_warning()`? I wonder why the failure would be reported as info level originally. ------------- PR: https://git.openjdk.java.net/jdk/pull/1214 From iklam at openjdk.java.net Mon Nov 16 06:32:54 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 16 Nov 2020 06:32:54 GMT Subject: RFR: JDK-8256367: [windows] Better logging for some system calls In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 06:17:05 GMT, Thomas Stuefe wrote: > > LGTM. Should the assert in os::split_reserved_memory() be changed to guarantee so it will stop the product build VM? > > Thanks Ioi. I'd rather not make it a guarantee - I find those a bad way to communicate errors to the end user. Ideally, the calling function should decide if it is worth continuing, but that would involve fixing ReservedSpace.(first|last)_part and was out of scope for that little fix. Sounds OK to me. Hopefully we can remove split_reserved_memory soon to make this a non issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/1214 From stuefe at openjdk.java.net Mon Nov 16 07:18:53 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 16 Nov 2020 07:18:53 GMT Subject: RFR: JDK-8256367: [windows] Better logging for some system calls In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 06:30:24 GMT, Ioi Lam wrote: >>> LGTM. Should the assert in os::split_reserved_memory() be changed to guarantee so it will stop the product build VM? >> >> Thanks Ioi. I'd rather not make it a guarantee - I find those a bad way to communicate errors to the end user. Ideally, the calling function should decide if it is worth continuing, but that would involve fixing ReservedSpace.(first|last)_part and was out of scope for that little fix. > >> > LGTM. Should the assert in os::split_reserved_memory() be changed to guarantee so it will stop the product build VM? >> >> Thanks Ioi. I'd rather not make it a guarantee - I find those a bad way to communicate errors to the end user. Ideally, the calling function should decide if it is worth continuing, but that would involve fixing ReservedSpace.(first|last)_part and was out of scope for that little fix. > > Sounds OK to me. Hopefully we can remove split_reserved_memory soon to make this a non issue. Hi Yasumasa, > Looks good, thanks! > but should all `log_info()` should be replaced to `log_warning()`? I wonder why the failure would be reported as info level originally. No, log_warning() logs unconditionally. I do not want to write to stdout/err unless it is really important, since that output may screw up any parsing tools. In this case, the failures may not be fatal or even be expected. log_info() is a good choice here since it pops up when you activate logging, but at the highest level. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1214 From stuefe at openjdk.java.net Mon Nov 16 07:18:54 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 16 Nov 2020 07:18:54 GMT Subject: Integrated: JDK-8256367: [windows] Better logging for some system calls In-Reply-To: References: Message-ID: On Sat, 14 Nov 2020 06:15:29 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for the following patch. Its purpose is to make error analysis easier for cases like https://bugs.openjdk.java.net/browse/JDK-8255917 or https://bugs.openjdk.java.net/browse/JDK-8255954. > > It does two things: > - it adds consistent tracing to some of the more important system calls, especially those having to do with virtual memory handling. We now log the success case (on the highest level only) as well as the error case (on the lowest possible level below warning). > - It adds error handling and logging to os::split_reserved_memory(). It adds an assert if that function fails, since if it fails, we really should stop. > > Thank you, > > Thomas This pull request has now been integrated. Changeset: 298bce1d Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/298bce1d Stats: 112 lines in 1 file changed: 91 ins; 5 del; 16 mod 8256367: [windows] Better logging for some system calls Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/1214 From stefank at openjdk.java.net Mon Nov 16 08:01:58 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 16 Nov 2020 08:01:58 GMT Subject: Integrated: 8256337: ap01t001.cpp, 67: Received unexpected number of ObjectFree events: 7 In-Reply-To: <7thDKusqZ5qwzxJF5J3GpAJZZXNmxeXGFUIHnb9uGYY=.57151319-45fb-48e4-beb7-458fb388093b@github.com> References: <7thDKusqZ5qwzxJF5J3GpAJZZXNmxeXGFUIHnb9uGYY=.57151319-45fb-48e4-beb7-458fb388093b@github.com> Message-ID: On Fri, 13 Nov 2020 14:11:23 GMT, Stefan Karlsson wrote: > The ap01t001 test creates six extra instances of the tested class, let them die, and then checks that it gets exactly six ObjectFree callbacks. The problem is that this is verified in the VMDeath callback and at that point the instance has gone out-of-scope and and a seventh ObjectFree event has been triggered. > > My proposed fix is to ensure that the test instance is kept alive. This pull request has now been integrated. Changeset: 6a69e304 Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/6a69e304 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8256337: ap01t001.cpp, 67: Received unexpected number of ObjectFree events: 7 Reviewed-by: coleenp, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/1204 From stefank at openjdk.java.net Mon Nov 16 08:01:57 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 16 Nov 2020 08:01:57 GMT Subject: RFR: 8256337: ap01t001.cpp, 67: Received unexpected number of ObjectFree events: 7 In-Reply-To: References: <7thDKusqZ5qwzxJF5J3GpAJZZXNmxeXGFUIHnb9uGYY=.57151319-45fb-48e4-beb7-458fb388093b@github.com> Message-ID: On Fri, 13 Nov 2020 19:25:57 GMT, Serguei Spitsyn wrote: >> The ap01t001 test creates six extra instances of the tested class, let them die, and then checks that it gets exactly six ObjectFree callbacks. The problem is that this is verified in the VMDeath callback and at that point the instance has gone out-of-scope and and a seventh ObjectFree event has been triggered. >> >> My proposed fix is to ensure that the test instance is kept alive. > > Hi Stefan, > It looks good to me. > Thank you for fixing it! > Serguei Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/1204 From shade at openjdk.java.net Mon Nov 16 09:53:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 16 Nov 2020 09:53:58 GMT Subject: RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 15:59:44 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for this little fix: > > On windows, `map_or_reserve_memory_aligned()` attempts to allocate aligned memory by: > 1) reserving larger area > 2) releasing it > 3) attempting to re-reserve into the vacated address space a smaller area at the aligned start address > > Since this may fail (between (2) and (3) someone may have grabbed part of that address space concurrently), we do this in a loop. However, when failing to release it we will loop-reserve endlessly. > > This is one of the reasons for JDK-8255954 whose root cause will be fixed with JDK-8255978. But we should guard against endless loops independently from that. > > This patch: > - limits the number we try this to 20. If in 20 cases someone else grabs address space concurrently, something is off... > - now correctly handles the return code of the release operation (1): in debug we assert, since if release_memory() fails something is wrong and we should take a look. In the release case, we now return an error. > > > Thanks! This makes sense to me. Just a few drive-by stylistic comments. src/hotspot/os/windows/os_windows.cpp line 3165: > 3163: > 3164: bool rc = (file_desc != -1) ? os::unmap_memory(extra_base, extra_size) : > 3165: os::release_memory(extra_base, extra_size); This style is inconsistent with style at L3155 and L3172. I think _those_ lines need to be brought in style. src/hotspot/os/windows/os_windows.cpp line 3169: > 3167: if (!rc) { > 3168: aligned_base = NULL; > 3169: break; Seems like we can just `return NULL` on this path, like we do with `extra_base == NULL` check in the same loop? So we can have: if (!rc) { assert(false, "Unmap/release should always succeed here"); return NULL; } src/hotspot/os/windows/os_windows.cpp line 3152: > 3150: > 3151: char* aligned_base = NULL; > 3152: int attempts = 20; static const int max_attempts = 20; int attempts = max_attempts; ...and then you can use `max_attempts` in the assert message? src/hotspot/os/windows/os_windows.cpp line 3175: > 3173: os::attempt_map_memory_to_file_at(aligned_base, size, file_desc) : > 3174: os::attempt_reserve_memory_at(aligned_base, size); > 3175: attempts --; No space before unary op? E.g. `attempts--`? It might be even cleaner to move it to loop condition like `attempts-- > 0`? ------------- PR: https://git.openjdk.java.net/jdk/pull/1191 From stuefe at openjdk.java.net Mon Nov 16 12:24:07 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 16 Nov 2020 12:24:07 GMT Subject: RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned [v2] In-Reply-To: References: Message-ID: > Hi, > > may I please have reviews for this little fix: > > On windows, `map_or_reserve_memory_aligned()` attempts to allocate aligned memory by: > 1) reserving larger area > 2) releasing it > 3) attempting to re-reserve into the vacated address space a smaller area at the aligned start address > > Since this may fail (between (2) and (3) someone may have grabbed part of that address space concurrently), we do this in a loop. However, when failing to release it we will loop-reserve endlessly. > > This is one of the reasons for JDK-8255954 whose root cause will be fixed with JDK-8255978. But we should guard against endless loops independently from that. > > This patch: > - limits the number we try this to 20. If in 20 cases someone else grabs address space concurrently, something is off... > - now correctly handles the return code of the release operation (1): in debug we assert, since if release_memory() fails something is wrong and we should take a look. In the release case, we now return an error. > > > Thanks! Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: - Remove blank before unary ++ - feedback alexey ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1191/files - new: https://git.openjdk.java.net/jdk/pull/1191/files/55486a92..e716a994 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1191&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1191&range=00-01 Stats: 14 lines in 1 file changed: 2 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1191/head:pull/1191 PR: https://git.openjdk.java.net/jdk/pull/1191 From stuefe at openjdk.java.net Mon Nov 16 12:28:01 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 16 Nov 2020 12:28:01 GMT Subject: RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned [v2] In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 09:51:38 GMT, Aleksey Shipilev wrote: > This makes sense to me. Just a few drive-by stylistic comments. Thanks Aleksey! I updated the patch according your suggestions. Yes, that looks better. I also corrected the final assert for the case that the final remap attempt had been successful. .. Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1191 From ysuenaga at openjdk.java.net Mon Nov 16 12:34:55 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 16 Nov 2020 12:34:55 GMT Subject: RFR: JDK-8256367: [windows] Better logging for some system calls In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 07:14:02 GMT, Thomas Stuefe wrote: >>> > LGTM. Should the assert in os::split_reserved_memory() be changed to guarantee so it will stop the product build VM? >>> >>> Thanks Ioi. I'd rather not make it a guarantee - I find those a bad way to communicate errors to the end user. Ideally, the calling function should decide if it is worth continuing, but that would involve fixing ReservedSpace.(first|last)_part and was out of scope for that little fix. >> >> Sounds OK to me. Hopefully we can remove split_reserved_memory soon to make this a non issue. > > Hi Yasumasa, > >> Looks good, > > thanks! > >> but should all `log_info()` should be replaced to `log_warning()`? I wonder why the failure would be reported as info level originally. > > No, log_warning() logs unconditionally. I do not want to write to stdout/err unless it is really important, since that output may screw up any parsing tools. In this case, the failures may not be fatal or even be expected. log_info() is a good choice here since it pops up when you activate logging, but at the highest level. > > Cheers, Thomas Thanks @tstuefe ! I agree with that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1214 From luhenry at openjdk.java.net Mon Nov 16 13:51:06 2020 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Mon, 16 Nov 2020 13:51:06 GMT Subject: RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned [v2] In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 12:24:07 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for this little fix: >> >> On windows, `map_or_reserve_memory_aligned()` attempts to allocate aligned memory by: >> 1) reserving larger area >> 2) releasing it >> 3) attempting to re-reserve into the vacated address space a smaller area at the aligned start address >> >> Since this may fail (between (2) and (3) someone may have grabbed part of that address space concurrently), we do this in a loop. However, when failing to release it we will loop-reserve endlessly. >> >> This is one of the reasons for JDK-8255954 whose root cause will be fixed with JDK-8255978. But we should guard against endless loops independently from that. >> >> This patch: >> - limits the number we try this to 20. If in 20 cases someone else grabs address space concurrently, something is off... >> - now correctly handles the return code of the release operation (1): in debug we assert, since if release_memory() fails something is wrong and we should take a look. In the release case, we now return an error. >> >> >> Thanks! > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - Remove blank before unary ++ > - feedback alexey I'm not a reviewer but it looks good to me. src/hotspot/os/windows/os_windows.cpp line 3152: > 3150: > 3151: char* aligned_base = NULL; > 3152: static const int max_attempts = 20; Stylistic review as well: I'd put that counter in a loop like `for (int attempts = 0; aligned_base == NULL && attempts < 20 /* max attemps */; attemps++) { ... }`. That would clearly indicate that it is a counted loop. Otherwise, now that you can return `NULL` from this function, have you checked that all uses of this function deal with a NULL-returned value correctly? From a cursory glance, it looks good to me. ------------- Marked as reviewed by luhenry (Author). PR: https://git.openjdk.java.net/jdk/pull/1191 From dcubed at openjdk.java.net Mon Nov 16 14:14:02 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 16 Nov 2020 14:14:02 GMT Subject: RFR: 8244376: possibly stale comment above "struct SharedGlobals" in synchronizer.cpp In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 04:22:17 GMT, David Holmes wrote: >> Trivial change to delete a stale comment block. > > I'm okay with the comment removal. > Thanks. @dholmes-ora - Thanks for reviewing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1212 From dcubed at openjdk.java.net Mon Nov 16 14:14:03 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 16 Nov 2020 14:14:03 GMT Subject: Integrated: 8244376: possibly stale comment above "struct SharedGlobals" in synchronizer.cpp In-Reply-To: References: Message-ID: On Fri, 13 Nov 2020 23:19:09 GMT, Daniel D. Daugherty wrote: > Trivial change to delete a stale comment block. This pull request has now been integrated. Changeset: 1d7ed03d Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/1d7ed03d Stats: 18 lines in 1 file changed: 0 ins; 18 del; 0 mod 8244376: possibly stale comment above "struct SharedGlobals" in synchronizer.cpp Reviewed-by: hseigel, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1212 From pchilanomate at openjdk.java.net Mon Nov 16 14:39:37 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 16 Nov 2020 14:39:37 GMT Subject: RFR: 8255384: Remove special_runtime_exit_condition() check from SS::block() [v6] 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Merge branch 'master' into 8255384-SSBlock - Merge branch 'master' into 8255384-SSBlock - fix comment in handle_polling_page_exception() - Merge branch 'master' into 8255384-SSBlock - Add SafepointMechanism::process_if_requested_with_exit_check() - Merge branch 'master' into 8255384-SSBlock - Add explicit bool arg - Make direct calls instead of using transition wrappers - v1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/913/files - new: https://git.openjdk.java.net/jdk/pull/913/files/ed4f8d4b..bddb258b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=913&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=913&range=04-05 Stats: 72833 lines in 886 files changed: 41092 ins; 21156 del; 10585 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 stuefe at openjdk.java.net Mon Nov 16 14:57:15 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 16 Nov 2020 14:57:15 GMT Subject: RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned [v3] In-Reply-To: References: Message-ID: > Hi, > > may I please have reviews for this little fix: > > On windows, `map_or_reserve_memory_aligned()` attempts to allocate aligned memory by: > 1) reserving larger area > 2) releasing it > 3) attempting to re-reserve into the vacated address space a smaller area at the aligned start address > > Since this may fail (between (2) and (3) someone may have grabbed part of that address space concurrently), we do this in a loop. However, when failing to release it we will loop-reserve endlessly. > > This is one of the reasons for JDK-8255954 whose root cause will be fixed with JDK-8255978. But we should guard against endless loops independently from that. > > This patch: > - limits the number we try this to 20. If in 20 cases someone else grabs address space concurrently, something is off... > - now correctly handles the return code of the release operation (1): in debug we assert, since if release_memory() fails something is wrong and we should take a look. In the release case, we now return an error. > > > Thanks! Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: feedback luhenry ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1191/files - new: https://git.openjdk.java.net/jdk/pull/1191/files/e716a994..3e04b75c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1191&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1191&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1191.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1191/head:pull/1191 PR: https://git.openjdk.java.net/jdk/pull/1191 From stuefe at openjdk.java.net Mon Nov 16 15:02:10 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 16 Nov 2020 15:02:10 GMT Subject: RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned [v2] In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 13:48:40 GMT, Ludovic Henry wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove blank before unary ++ >> - feedback alexey > > I'm not a reviewer but it looks good to me. Hi Ludovic, thanks a lot for looking at this! Reformed the loop as suggested. > I'm not a reviewer but it looks good to me. Your feedback is still useful. In the case of hotspot, the project rules want two reviews, only one of which has to be a Reviewer. I see that in the JDK project you are "just" an Author, but you are overdue for Committer anyway I think since you have ~11 patches authored or co-authored. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1191 From dcubed at openjdk.java.net Mon Nov 16 16:37:07 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 16 Nov 2020 16:37:07 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor [v3] In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 05:03:10 GMT, David Holmes wrote: >> This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. >> >> On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. >> >> Testing: >> - GH actions >> - mach5 tiers 1-3 >> - selected performance testing (guided by that used for JDK-8253064) >> >> Thanks, >> David > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into 8225631 > - Feedback from Coleen, Kim and Dan. > - 8225631: Consider replacing muxAcquire/Release with PlatformMonitor Thanks for the minor tweaks. Still looks good. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1196 From coleenp at openjdk.java.net Mon Nov 16 17:04:06 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 16 Nov 2020 17:04:06 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor [v3] In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 05:03:10 GMT, David Holmes wrote: >> This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. >> >> On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. >> >> Testing: >> - GH actions >> - mach5 tiers 1-3 >> - selected performance testing (guided by that used for JDK-8253064) >> >> Thanks, >> David > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into 8225631 > - Feedback from Coleen, Kim and Dan. > - 8225631: Consider replacing muxAcquire/Release with PlatformMonitor Looks good! Thank you for the cleanups. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1196 From pchilanomate at openjdk.java.net Mon Nov 16 17:24:20 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 16 Nov 2020 17:24:20 GMT Subject: Integrated: 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 This pull request has now been integrated. Changeset: 3675653c Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/3675653c Stats: 71 lines in 6 files changed: 14 ins; 41 del; 16 mod 8255384: Remove special_runtime_exit_condition() check from SS::block() Reviewed-by: dholmes, rrich, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/913 From iklam at openjdk.java.net Mon Nov 16 17:38:05 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 16 Nov 2020 17:38:05 GMT Subject: RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned [v3] In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 14:57:15 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for this little fix: >> >> On windows, `map_or_reserve_memory_aligned()` attempts to allocate aligned memory by: >> 1) reserving larger area >> 2) releasing it >> 3) attempting to re-reserve into the vacated address space a smaller area at the aligned start address >> >> Since this may fail (between (2) and (3) someone may have grabbed part of that address space concurrently), we do this in a loop. However, when failing to release it we will loop-reserve endlessly. >> >> This is one of the reasons for JDK-8255954 whose root cause will be fixed with JDK-8255978. But we should guard against endless loops independently from that. >> >> This patch: >> - limits the number we try this to 20. If in 20 cases someone else grabs address space concurrently, something is off... >> - now correctly handles the return code of the release operation (1): in debug we assert, since if release_memory() fails something is wrong and we should take a look. In the release case, we now return an error. >> >> >> Thanks! > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > feedback luhenry LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1191 From kvn at openjdk.java.net Mon Nov 16 19:00:07 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 16 Nov 2020 19:00:07 GMT Subject: RFR: 8256205: Simplify compiler calling convention handling In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 15:35:16 GMT, Claes Redestad wrote: > Clean up and simplify some of the calling convention handling: > > - Remove Matcher::calling_convention/c_calling_convention and replace select few call sites with direct calls to SharedRuntime > - Remove unused is_outgoing args. Since the SPARC removal the is_outgoing has no effect on the calling_convention or return_value methods. > - Move in_preserved_stack_slots to SharedRuntime to match out_preserved_stack_slots. > > This has a tiny positive impact by reducing calls and improving inlining (at least gcc has a hard time inlining anything that goes in the .ad files, even when it's defined to the same class), but is mainly a cleanup effort. > > Testing: Oracle tier1-2 testing; S390, PPC and ARM32 builds Nice clean up. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1168 From minqi at openjdk.java.net Mon Nov 16 19:29:11 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 16 Nov 2020 19:29:11 GMT Subject: RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned [v3] In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 14:57:15 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for this little fix: >> >> On windows, `map_or_reserve_memory_aligned()` attempts to allocate aligned memory by: >> 1) reserving larger area >> 2) releasing it >> 3) attempting to re-reserve into the vacated address space a smaller area at the aligned start address >> >> Since this may fail (between (2) and (3) someone may have grabbed part of that address space concurrently), we do this in a loop. However, when failing to release it we will loop-reserve endlessly. >> >> This is one of the reasons for JDK-8255954 whose root cause will be fixed with JDK-8255978. But we should guard against endless loops independently from that. >> >> This patch: >> - limits the number we try this to 20. If in 20 cases someone else grabs address space concurrently, something is off... >> - now correctly handles the return code of the release operation (1): in debug we assert, since if release_memory() fails something is wrong and we should take a look. In the release case, we now return an error. >> >> >> Thanks! > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > feedback luhenry LGTM ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1191 From neliasso at openjdk.java.net Mon Nov 16 19:36:09 2020 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Mon, 16 Nov 2020 19:36:09 GMT Subject: RFR: 8256205: Simplify compiler calling convention handling In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 15:35:16 GMT, Claes Redestad wrote: > Clean up and simplify some of the calling convention handling: > > - Remove Matcher::calling_convention/c_calling_convention and replace select few call sites with direct calls to SharedRuntime > - Remove unused is_outgoing args. Since the SPARC removal the is_outgoing has no effect on the calling_convention or return_value methods. > - Move in_preserved_stack_slots to SharedRuntime to match out_preserved_stack_slots. > > This has a tiny positive impact by reducing calls and improving inlining (at least gcc has a hard time inlining anything that goes in the .ad files, even when it's defined to the same class), but is mainly a cleanup effort. > > Testing: Oracle tier1-2 testing; S390, PPC and ARM32 builds Looks good! ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1168 From redestad at openjdk.java.net Mon Nov 16 19:43:03 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 16 Nov 2020 19:43:03 GMT Subject: RFR: 8256205: Simplify compiler calling convention handling In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 18:57:38 GMT, Vladimir Kozlov wrote: >> Clean up and simplify some of the calling convention handling: >> >> - Remove Matcher::calling_convention/c_calling_convention and replace select few call sites with direct calls to SharedRuntime >> - Remove unused is_outgoing args. Since the SPARC removal the is_outgoing has no effect on the calling_convention or return_value methods. >> - Move in_preserved_stack_slots to SharedRuntime to match out_preserved_stack_slots. >> >> This has a tiny positive impact by reducing calls and improving inlining (at least gcc has a hard time inlining anything that goes in the .ad files, even when it's defined to the same class), but is mainly a cleanup effort. >> >> Testing: Oracle tier1-2 testing; S390, PPC and ARM32 builds > > Nice clean up. @vnkozlov @neliasso - thank you for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/1168 From redestad at openjdk.java.net Mon Nov 16 19:43:06 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 16 Nov 2020 19:43:06 GMT Subject: Integrated: 8256205: Simplify compiler calling convention handling In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 15:35:16 GMT, Claes Redestad wrote: > Clean up and simplify some of the calling convention handling: > > - Remove Matcher::calling_convention/c_calling_convention and replace select few call sites with direct calls to SharedRuntime > - Remove unused is_outgoing args. Since the SPARC removal the is_outgoing has no effect on the calling_convention or return_value methods. > - Move in_preserved_stack_slots to SharedRuntime to match out_preserved_stack_slots. > > This has a tiny positive impact by reducing calls and improving inlining (at least gcc has a hard time inlining anything that goes in the .ad files, even when it's defined to the same class), but is mainly a cleanup effort. > > Testing: Oracle tier1-2 testing; S390, PPC and ARM32 builds This pull request has now been integrated. Changeset: 6e35bcbf Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/6e35bcbf Stats: 359 lines in 31 files changed: 54 ins; 255 del; 50 mod 8256205: Simplify compiler calling convention handling Reviewed-by: kvn, neliasso ------------- PR: https://git.openjdk.java.net/jdk/pull/1168 From stuefe at openjdk.java.net Mon Nov 16 20:12:09 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 16 Nov 2020 20:12:09 GMT Subject: RFR: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned [v3] In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 19:26:21 GMT, Yumin Qi wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback luhenry > > LGTM Thanks Calvin and Ioi! ------------- PR: https://git.openjdk.java.net/jdk/pull/1191 From stuefe at openjdk.java.net Mon Nov 16 20:12:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 16 Nov 2020 20:12:11 GMT Subject: Integrated: JDK-8256287: [windows] add loop fuse to map_or_reserve_memory_aligned In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 15:59:44 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for this little fix: > > On windows, `map_or_reserve_memory_aligned()` attempts to allocate aligned memory by: > 1) reserving larger area > 2) releasing it > 3) attempting to re-reserve into the vacated address space a smaller area at the aligned start address > > Since this may fail (between (2) and (3) someone may have grabbed part of that address space concurrently), we do this in a loop. However, when failing to release it we will loop-reserve endlessly. > > This is one of the reasons for JDK-8255954 whose root cause will be fixed with JDK-8255978. But we should guard against endless loops independently from that. > > This patch: > - limits the number we try this to 20. If in 20 cases someone else grabs address space concurrently, something is off... > - now correctly handles the return code of the release operation (1): in debug we assert, since if release_memory() fails something is wrong and we should take a look. In the release case, we now return an error. > > > Thanks! This pull request has now been integrated. Changeset: 0357db35 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/0357db35 Stats: 16 lines in 1 file changed: 4 ins; 1 del; 11 mod 8256287: [windows] add loop fuse to map_or_reserve_memory_aligned Reviewed-by: luhenry, iklam, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/1191 From dcubed at openjdk.java.net Mon Nov 16 21:10:00 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 16 Nov 2020 21:10:00 GMT Subject: RFR: 8134630: make code and comments consistent for stack lock optimization In-Reply-To: References: Message-ID: <-AD2JLoGeAH4IAQg-tjunH1kPbDR2jtX7qqNwZ3nJKQ=.5ea07505-a187-4564-a92c-a0b3f0f41ba8@github.com> On Fri, 13 Nov 2020 22:42:05 GMT, Daniel D. Daugherty wrote: > Comment only changes copied from the 'arm' version to the aarch64 and x86 > versions of the files. I looked at the ppc and s390 files and it wasn't at all clear > to me how to apply the same comment changes to those platforms. Ping! These are comment only changes... Any takers? ------------- PR: https://git.openjdk.java.net/jdk/pull/1210 From kbarrett at openjdk.java.net Mon Nov 16 21:10:04 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 16 Nov 2020 21:10:04 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor [v3] In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 17:01:29 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into 8225631 >> - Feedback from Coleen, Kim and Dan. >> - 8225631: Consider replacing muxAcquire/Release with PlatformMonitor > > Looks good! Thank you for the cleanups. > > This is assuming NINFLATIONLOCKS is a power of 2. Consider adding a static_assert. (Note: is_power_of_2 was made constexpr by JDK-8247910.) > > Added to the initialize() function. The initialize() function is the wrong place. There's nothing in initialize that cares. The place for the assert is with the code that cares that it's a power of 2. ------------- PR: https://git.openjdk.java.net/jdk/pull/1196 From dcubed at openjdk.java.net Mon Nov 16 21:16:08 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 16 Nov 2020 21:16:08 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor In-Reply-To: References: Message-ID: <-EFajUfzqEkyPvj2hBhsJnjuekn0Xp4MxoAYaNYMOV8=.fd73d4c4-885e-4f46-92e7-1c51e963c1bc@github.com> On Fri, 13 Nov 2020 00:51:02 GMT, David Holmes wrote: > This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. > > On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. > > Testing: > - GH actions > - mach5 tiers 1-3 > - selected performance testing (guided by that used for JDK-8253064) > > Thanks, > David I'm guessing that @dholmes-ora put it in initialize() because it only needs to be checked once rather than every time the table is used. ------------- PR: https://git.openjdk.java.net/jdk/pull/1196 From dholmes at openjdk.java.net Mon Nov 16 22:37:04 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 16 Nov 2020 22:37:04 GMT Subject: RFR: 8134630: make code and comments consistent for stack lock optimization In-Reply-To: References: Message-ID: On Fri, 13 Nov 2020 22:42:05 GMT, Daniel D. Daugherty wrote: > Comment only changes copied from the 'arm' version to the aarch64 and x86 > versions of the files. I looked at the ppc and s390 files and it wasn't at all clear > to me how to apply the same comment changes to those platforms. Seems fine. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1210 From dcubed at openjdk.java.net Mon Nov 16 22:48:02 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 16 Nov 2020 22:48:02 GMT Subject: RFR: 8134630: make code and comments consistent for stack lock optimization In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 22:34:07 GMT, David Holmes wrote: >> Comment only changes copied from the 'arm' version to the aarch64 and x86 >> versions of the files. I looked at the ppc and s390 files and it wasn't at all clear >> to me how to apply the same comment changes to those platforms. > > Seems fine. > Thanks, > David @dholmes-ora - Thanks for the review! I didn't flag this one as "trivial" because the comments are related to assembly code so trivial didn't feel right. It would be good to get a second pair of eyes on this (long overdue) comment cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/1210 From david.holmes at oracle.com Mon Nov 16 22:48:19 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Nov 2020 08:48:19 +1000 Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor [v3] In-Reply-To: References: Message-ID: On 17/11/2020 7:10 am, Kim Barrett wrote: > On Mon, 16 Nov 2020 17:01:29 GMT, Coleen Phillimore wrote: > >>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >>> >>> - Merge branch 'master' into 8225631 >>> - Feedback from Coleen, Kim and Dan. >>> - 8225631: Consider replacing muxAcquire/Release with PlatformMonitor >> >> Looks good! Thank you for the cleanups. > >>> This is assuming NINFLATIONLOCKS is a power of 2. Consider adding a static_assert. (Note: is_power_of_2 was made constexpr by JDK-8247910.) >> >> Added to the initialize() function. > > The initialize() function is the wrong place. There's nothing in initialize that cares. The place for the assert is with the code that cares that it's a power of 2. As Dan indicated I put it there so that it is only checked once - no point checking it on every use. Initialization code is often used to check invariants. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1196 > From kbarrett at openjdk.java.net Mon Nov 16 23:25:08 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 16 Nov 2020 23:25:08 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor In-Reply-To: <-EFajUfzqEkyPvj2hBhsJnjuekn0Xp4MxoAYaNYMOV8=.fd73d4c4-885e-4f46-92e7-1c51e963c1bc@github.com> References: <-EFajUfzqEkyPvj2hBhsJnjuekn0Xp4MxoAYaNYMOV8=.fd73d4c4-885e-4f46-92e7-1c51e963c1bc@github.com> Message-ID: <24JUeQ02ar97zF0lRgfew4p6V88YddzfpcT_51c-Cvw=.70da2ea1-3d10-4beb-a9c9-f2dd6876a1e9@github.com> On Mon, 16 Nov 2020 21:12:55 GMT, Daniel D. Daugherty wrote: >> This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. >> >> On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. >> >> Testing: >> - GH actions >> - mach5 tiers 1-3 >> - selected performance testing (guided by that used for JDK-8253064) >> >> Thanks, >> David > > I'm guessing that @dholmes-ora put it in initialize() because > it only needs to be checked once rather than every time the > table is used. > > The initialize() function is the wrong place. There's nothing in initialize that cares. The place for the assert is with the code that cares that it's a power of 2. > > As Dan indicated I put it there so that it is only checked once - no > point checking it on every use. Initialization code is often used to > check invariants. A static assert is checked once at compile time. And my opinion probably wouldn't be different if it were a runtime assert. ------------- PR: https://git.openjdk.java.net/jdk/pull/1196 From david.holmes at oracle.com Tue Nov 17 01:30:30 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Nov 2020 11:30:30 +1000 Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor In-Reply-To: <24JUeQ02ar97zF0lRgfew4p6V88YddzfpcT_51c-Cvw=.70da2ea1-3d10-4beb-a9c9-f2dd6876a1e9@github.com> References: <-EFajUfzqEkyPvj2hBhsJnjuekn0Xp4MxoAYaNYMOV8=.fd73d4c4-885e-4f46-92e7-1c51e963c1bc@github.com> <24JUeQ02ar97zF0lRgfew4p6V88YddzfpcT_51c-Cvw=.70da2ea1-3d10-4beb-a9c9-f2dd6876a1e9@github.com> Message-ID: <9675682c-2319-e485-7a39-4fd06fd4eb89@oracle.com> On 17/11/2020 9:25 am, Kim Barrett wrote: > On Mon, 16 Nov 2020 21:12:55 GMT, Daniel D. Daugherty wrote: > >>> This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. >>> >>> On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. >>> >>> Testing: >>> - GH actions >>> - mach5 tiers 1-3 >>> - selected performance testing (guided by that used for JDK-8253064) >>> >>> Thanks, >>> David >> >> I'm guessing that @dholmes-ora put it in initialize() because >> it only needs to be checked once rather than every time the >> table is used. > >>> The initialize() function is the wrong place. There's nothing in initialize that cares. The place for the assert is with the code that cares that it's a power of 2. >> >> As Dan indicated I put it there so that it is only checked once - no >> point checking it on every use. Initialization code is often used to >> check invariants. > > A static assert is checked once at compile time. And my opinion probably wouldn't be different if it were a runtime assert. Okay I hadn't realized the static_assert was checked once at compile-time. But isn't this assertion also checking it is a power of 2? assert((NINFLATIONLOCKS & (NINFLATIONLOCKS-1)) == 0, "invariant"); Should I just replace that with the is_power_of_2() static assert? Thanks, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1196 > From minqi at openjdk.java.net Tue Nov 17 03:09:11 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 17 Nov 2020 03:09:11 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string Message-ID: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Hi, Please review Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. Tests: tier1,tier4 ------------- Commit messages: - 8256256: UL should not use heap allocation for output string Changes: https://git.openjdk.java.net/jdk/pull/1246/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1246&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256256 Stats: 29 lines in 3 files changed: 6 ins; 15 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1246/head:pull/1246 PR: https://git.openjdk.java.net/jdk/pull/1246 From dholmes at openjdk.java.net Tue Nov 17 03:51:04 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 17 Nov 2020 03:51:04 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string In-Reply-To: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Tue, 17 Nov 2020 03:04:07 GMT, Yumin Qi wrote: > Hi, Please review > Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. > > Tests: tier1,tier4 Hi Yumin, Sorry but I don't think it is a reasonable approach to add in truncation where it previously did not occur. And adding a 4K stack buffer can also cause problems if threads are operating near the ends of their stacks (we have had to remove large local stack buffers in the past because of this). I'm not convinced we can make UL safe from absolutely any context automatically. Most of the time heap allocation is not a problem, it is only from within low-level memory related code that it may be a problem. I think that is a special enough case that we should address it more directly - via a different UL API perhaps, that explicitly avoids heap allocation. David ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From dholmes at openjdk.java.net Tue Nov 17 05:46:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 17 Nov 2020 05:46:10 GMT Subject: RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix Message-ID: Mutex::try_lock has to allow for the possibility that the PlatformMutex::try_lock allows recursive locking. Added additional commentary on the semantics provided by Mutex and the PlatformMutex classes. Testing: GHA, mach5 tiers 1-3 ------------- Commit messages: - 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix Changes: https://git.openjdk.java.net/jdk/pull/1247/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1247&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256383 Stats: 18 lines in 4 files changed: 13 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1247.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1247/head:pull/1247 PR: https://git.openjdk.java.net/jdk/pull/1247 From stuefe at openjdk.java.net Tue Nov 17 07:15:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 17 Nov 2020 07:15:11 GMT Subject: RFR: JDK-8255978: [windows] os::release_memory may not release the full range [v3] In-Reply-To: References: Message-ID: > On Windows, os::release_memory(p,size) may not actually release the whole region if it contains multiple mappings. This may cause memory bloat or runaway leaks or errors which look like failed mappings to specific wish addresses. > > Background: > > On Windows, memory mappings are established with VirtualAlloc() [1] and released with VirtualFree() [2]. In constrast to POSIX munmap(), VirtualFree() can only release a single full range established with VirtualAlloc(). It cannot release multiple ranges, or parts of a range. > > The Windows implementation of os::release_memory(p, size) [3] calls VirtualFree(p, NULL, MEM_RELEASE) - it ignores the size parameter and releases whatever mapping happens to start at p: > > bool os::pd_release_memory(char* addr, size_t bytes) { > return VirtualFree(addr, 0, MEM_RELEASE) != 0; > } > > ... which assumes that the given range size corresponds to the size of a mapping starting at p. > > This may be incorrect: > > 1) For NUMA-friendly allocation, we allocate memory in stripes, each stripe individually allocated. > 2) For +UseLargePagesIndividualAllocation we do the same > 3) apart from that, the given region size may just be wrong. Since we never check these, we may never have noticed. I am currently running tests to find out if we have other mismatched releases. > > For cases (1) and (2), we would just release the first stripe in that striped range, leaving the rest of the mappings intact. This is not immediately noticeable, since VirtualFree() returns success. And even if it did not, we usually ignore the return code of os::release_memory(). > > The problem is aggrevated since, on Windows, we often employ an "optimistically-release-and-remap" approach: since mappings are undivisible, if one wants to change their size, split them or similar, one has to follow this sequence: > > a) release old allocation > b) place into the now vacated address room one or more new allocations > > This is not guaranteed to work, since between (a) and (b) someone may have grabbed the address space. We live with that since there is no way to do this differently. > > When used on a range which contains multiple mappings, this technique is almost guaranteed to fail. In that case, (a) would only release the first mapping in the range. (b) would almost certainly fail since most of the original range would still be mapped. > > Examples of these technique in os_windows.cpp: > - os::split_reseved_memory() (see also [4]) > - map_or_reserve_memory_aligned() > - os::replace_existing_mapping_with_file_mapping() > > This can manifest as small memory leak or inability to attach to a given wish address. It could also result in a viscous loop ([5], [6]) and result in ballooning and native OOMs. > > -- > > AFAICS this is an old issue, dating back to at least jdk 8. > > -- > > The change in detail: > > - os::release_memory() on Window now: > - in LP/NUMA case we unmap all mappings in the given range. The mappings must match the range exactly, otherwise we assert. > - In normal case we just check the given range and assert if it does not match. > Note: in release builds I just print a warning and return false. Should this be a guarantee? I leave that up to the Reviewers. > > - Added gtests which test os::release_memory() with a variety of scenarios. Includes both positive and negative tests. The latter includes a death test for debug. > > - Added a helper function to find mappings, for now windows only (os::win32::find_mapping()), including gtests for that function. > > - Added a function to print mappings, for diagnostic purposes: os::print_memory_mappings(). Provided an implementation for linux and windows. > > > -- > [1] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc > [2] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualfree > [3] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3394 > [4] https://bugs.openjdk.java.net/browse/JDK-8253649 > [5] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3150 > [6] https://bugs.openjdk.java.net/browse/JDK-8255954 Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge - Merge - Initial ------------- Changes: https://git.openjdk.java.net/jdk/pull/1143/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1143&range=02 Stats: 491 lines in 7 files changed: 490 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1143.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1143/head:pull/1143 PR: https://git.openjdk.java.net/jdk/pull/1143 From stefank at openjdk.java.net Tue Nov 17 07:29:06 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 17 Nov 2020 07:29:06 GMT Subject: RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 05:41:44 GMT, David Holmes wrote: > Mutex::try_lock has to allow for the possibility that the PlatformMutex::try_lock allows recursive locking. > > Added additional commentary on the semantics provided by Mutex and the PlatformMutex classes. > > Testing: GHA, mach5 tiers 1-3 Thanks for updating Mutex::try_lock and adding the comments! src/hotspot/share/runtime/mutex.cpp line 147: > 145: // safepoint state, but can check blocking state. > 146: check_block_state(self); > 147: if (_owner == NULL && _lock.try_lock()) { It's not obvious that's it is correct to check == NULL. Couldn't there be a lingering value from another thread, causing a spurious failure to acquire the lock? Could this be changed to _owner != self? That way we only check for a value that only the current thread could have written. Also, this is a racy read, should this be using Atomic::load? ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1247 From stuefe at openjdk.java.net Tue Nov 17 07:29:07 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 17 Nov 2020 07:29:07 GMT Subject: RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 05:41:44 GMT, David Holmes wrote: > Mutex::try_lock has to allow for the possibility that the PlatformMutex::try_lock allows recursive locking. > > Added additional commentary on the semantics provided by Mutex and the PlatformMutex classes. > > Testing: GHA, mach5 tiers 1-3 Hi David, LGTM. Minor remarks below. Thanks, Thomas src/hotspot/share/runtime/mutex.cpp line 147: > 145: // safepoint state, but can check blocking state. > 146: check_block_state(self); > 147: if (_owner == NULL && _lock.try_lock()) { `_owner != self` may be a bit clearer, at the expense of maybe unnecessarily calling into platform code (but before, we did that unconditionally). src/hotspot/share/runtime/mutex.cpp line 141: > 139: // Returns true if thread succeeds in grabbing the lock, otherwise false. > 140: // Checking for a NULL owner avoids the call into platform code and hides the > 141: // potential difference in recursive locking behaviour on some platforms. Maybe move comment down to 146? ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1247 From stuefe at openjdk.java.net Tue Nov 17 07:46:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 17 Nov 2020 07:46:00 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Tue, 17 Nov 2020 03:48:43 GMT, David Holmes wrote: >> Hi, Please review >> Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. >> >> Tests: tier1,tier4 > > Hi Yumin, > > Sorry but I don't think it is a reasonable approach to add in truncation where it previously did not occur. And adding a 4K stack buffer can also cause problems if threads are operating near the ends of their stacks (we have had to remove large local stack buffers in the past because of this). > > I'm not convinced we can make UL safe from absolutely any context automatically. Most of the time heap allocation is not a problem, it is only from within low-level memory related code that it may be a problem. I think that is a special enough case that we should address it more directly - via a different UL API perhaps, that explicitly avoids heap allocation. > > David Hi Yumin, thanks for doing this! @dholmes-ora : I think doing this makes a lot of sense. UL is way too vulnerable against circularities. Notes: - I agree that truncation or large stack buffers are not ideal. Alternatives could be: - Deliberately just use ::malloc and ::free. Not our versions. That would be a very simple fix and solve any circularities. - Prepare a thread local printing buffer at initialization time, or when we first log in a thread. Could be as a thread local variable in the logging calls. Or, maybe cleaner, hooked into Thread. Long or even mid term I believe we will separate loggers from writing to the file and make logging sites as quick and "shallow" as possible. This idea has been floating around a lot. That would relegate anything expensive and potentially dangerous to an own writer thread. I have a rough sketch of such a solution - in such a solution we would write to some global memory area which the writer thread would drain, so there is no reason to allocate at a logging site. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From david.holmes at oracle.com Tue Nov 17 08:58:35 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Nov 2020 18:58:35 +1000 Subject: RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix In-Reply-To: References: Message-ID: <906882d0-d657-af46-c90e-3fa094e37d81@oracle.com> Hi Stefan, Thanks for the review (and the initial report!). On 17/11/2020 5:29 pm, Stefan Karlsson wrote: > On Tue, 17 Nov 2020 05:41:44 GMT, David Holmes wrote: > >> Mutex::try_lock has to allow for the possibility that the PlatformMutex::try_lock allows recursive locking. >> >> Added additional commentary on the semantics provided by Mutex and the PlatformMutex classes. >> >> Testing: GHA, mach5 tiers 1-3 > > Thanks for updating Mutex::try_lock and adding the comments! > > src/hotspot/share/runtime/mutex.cpp line 147: > >> 145: // safepoint state, but can check blocking state. >> 146: check_block_state(self); >> 147: if (_owner == NULL && _lock.try_lock()) { > > It's not obvious that's it is correct to check == NULL. Couldn't there be a lingering value from another thread, causing a spurious failure to acquire the lock? Could this be changed to _owner != self? That way we only check for a value that only the current thread could have written. > > Also, this is a racy read, should this be using Atomic::load? Yes it is a racy read but do we care? The only value of _owner that's guaranteed true is if it equals self (which would be a usage bug so we expect it to be really really really rare). Otherwise we are indeed racing with a thread that is releasing the Mutex (or another thread acquiring it!), but that race exists regardless. If I check for != self then it forces us into the PlatformMutex code unnecessarily in most cases. But as you and Thomas both seem unsettled by this I can change it. :) Using Atomic::load is a good idea just from a code hygiene perspective, but doesn't change the raciness. Thanks, David > ------------- > > Changes requested by stefank (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1247 > From david.holmes at oracle.com Tue Nov 17 09:00:08 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Nov 2020 19:00:08 +1000 Subject: RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix In-Reply-To: References: Message-ID: <97604633-2d2c-3c85-d5db-d35ece4b17b6@oracle.com> Hi Thomas, Thanks for reviewing this. On 17/11/2020 5:29 pm, Thomas Stuefe wrote: > On Tue, 17 Nov 2020 05:41:44 GMT, David Holmes wrote: > >> Mutex::try_lock has to allow for the possibility that the PlatformMutex::try_lock allows recursive locking. >> >> Added additional commentary on the semantics provided by Mutex and the PlatformMutex classes. >> >> Testing: GHA, mach5 tiers 1-3 > > Hi David, > > LGTM. Minor remarks below. > > Thanks, Thomas > > src/hotspot/share/runtime/mutex.cpp line 147: > >> 145: // safepoint state, but can check blocking state. >> 146: check_block_state(self); >> 147: if (_owner == NULL && _lock.try_lock()) { > > `_owner != self` may be a bit clearer, at the expense of maybe unnecessarily calling into platform code (but before, we did that unconditionally). Right - see my response to Stefan. > src/hotspot/share/runtime/mutex.cpp line 141: > >> 139: // Returns true if thread succeeds in grabbing the lock, otherwise false. >> 140: // Checking for a NULL owner avoids the call into platform code and hides the >> 141: // potential difference in recursive locking behaviour on some platforms. > > Maybe move comment down to 146? I'll move it and modify it. Thanks, David ----- > ------------- > > Marked as reviewed by stuefe (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1247 > From thomas.stuefe at gmail.com Tue Nov 17 09:04:33 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 17 Nov 2020 10:04:33 +0100 Subject: RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix In-Reply-To: <97604633-2d2c-3c85-d5db-d35ece4b17b6@oracle.com> References: <97604633-2d2c-3c85-d5db-d35ece4b17b6@oracle.com> Message-ID: > > > src/hotspot/share/runtime/mutex.cpp line 147: > > > >> 145: // safepoint state, but can check blocking state. > >> 146: check_block_state(self); > >> 147: if (_owner == NULL && _lock.try_lock()) { > > > > `_owner != self` may be a bit clearer, at the expense of maybe > unnecessarily calling into platform code (but before, we did that > unconditionally). > > Right - see my response to Stefan. > > Thank you, I feel more settled now. :) Thomas From david.holmes at oracle.com Tue Nov 17 09:05:58 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Nov 2020 19:05:58 +1000 Subject: RFR: 8256256: UL should not use heap allocation for output string In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: <8da96698-1b2d-99aa-3787-071bf68b5fd0@oracle.com> Hi Thomas, On 17/11/2020 5:46 pm, Thomas Stuefe wrote: > On Tue, 17 Nov 2020 03:48:43 GMT, David Holmes wrote: > >>> Hi, Please review >>> Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. >>> >>> Tests: tier1,tier4 >> >> Hi Yumin, >> >> Sorry but I don't think it is a reasonable approach to add in truncation where it previously did not occur. And adding a 4K stack buffer can also cause problems if threads are operating near the ends of their stacks (we have had to remove large local stack buffers in the past because of this). >> >> I'm not convinced we can make UL safe from absolutely any context automatically. Most of the time heap allocation is not a problem, it is only from within low-level memory related code that it may be a problem. I think that is a special enough case that we should address it more directly - via a different UL API perhaps, that explicitly avoids heap allocation. >> >> David > > Hi Yumin, thanks for doing this! > > @dholmes-ora : I think doing this makes a lot of sense. UL is way too vulnerable against circularities. Lots of VM facilities are vulnerable to circularities. The general approach is to try and ensure that key facilities don't use other VM facilities, or if they have to, they do so in a manner where we can deal with potential circularities. That said ... > Notes: > > - I agree that truncation or large stack buffers are not ideal. Alternatives could be: Obviously there are a number of ways to tackle this, but my key point was that the current proposal is not a satisfactory way of tackling it IMO. > - Deliberately just use ::malloc and ::free. Not our versions. That would be a very simple fix and solve any circularities. That seems like a better solution at the expense that UL will not be tracked by NMT. > - Prepare a thread local printing buffer at initialization time, or when we first log in a thread. Could be as a thread local variable in the logging calls. Or, maybe cleaner, hooked into Thread. Not quite sure what you mean by this. Cheers, David ----- > Long or even mid term I believe we will separate loggers from writing to the file and make logging sites as quick and "shallow" as possible. This idea has been floating around a lot. That would relegate anything expensive and potentially dangerous to an own writer thread. I have a rough sketch of such a solution - in such a solution we would write to some global memory area which the writer thread would drain, so there is no reason to allocate at a logging site. > > Cheers, Thomas > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1246 > From stuefe at openjdk.java.net Tue Nov 17 09:14:05 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 17 Nov 2020 09:14:05 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: <0VhmgSFWH1JGjwrp2c8TWnTEZHyrvPAUq1qTvrf04zk=.8c44e363-2539-4aa2-8f59-38a303da3194@github.com> On Tue, 17 Nov 2020 07:43:34 GMT, Thomas Stuefe wrote: >> Hi Yumin, >> >> Sorry but I don't think it is a reasonable approach to add in truncation where it previously did not occur. And adding a 4K stack buffer can also cause problems if threads are operating near the ends of their stacks (we have had to remove large local stack buffers in the past because of this). >> >> I'm not convinced we can make UL safe from absolutely any context automatically. Most of the time heap allocation is not a problem, it is only from within low-level memory related code that it may be a problem. I think that is a special enough case that we should address it more directly - via a different UL API perhaps, that explicitly avoids heap allocation. >> >> David > > Hi Yumin, thanks for doing this! > > @dholmes-ora : I think doing this makes a lot of sense. UL is way too vulnerable against circularities. > > Notes: > > - I agree that truncation or large stack buffers are not ideal. Alternatives could be: > - Deliberately just use ::malloc and ::free. Not our versions. That would be a very simple fix and solve any circularities. > - Prepare a thread local printing buffer at initialization time, or when we first log in a thread. Could be as a thread local variable in the logging calls. Or, maybe cleaner, hooked into Thread. > > Long or even mid term I believe we will separate loggers from writing to the file and make logging sites as quick and "shallow" as possible. This idea has been floating around a lot. That would relegate anything expensive and potentially dangerous to an own writer thread. I have a rough sketch of such a solution - in such a solution we would write to some global memory area which the writer thread would drain, so there is no reason to allocate at a logging site. > > Cheers, Thomas > > > - Deliberately just use ::malloc and ::free. Not our versions. That would be a very simple fix and solve any circularities. > > That seems like a better solution at the expense that UL will not be > tracked by NMT. > > > - Prepare a thread local printing buffer at initialization time, or when we first log in a thread. Could be as a thread local variable in the logging calls. Or, maybe cleaner, hooked into Thread. > > Not quite sure what you mean by this. Oh, just allocate a static buffer - large enough for longish lines - beforehand. Can be done with C-Heap allocation since here we don't live on the stack. That buffer must be kept thread local since multiple threads can log at the same time. (While writing this, I believe using ::malloc/::free would probably be simplest.) ..Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From stefank at openjdk.java.net Tue Nov 17 10:14:05 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 17 Nov 2020 10:14:05 GMT Subject: RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 07:26:12 GMT, Thomas Stuefe wrote: >> Mutex::try_lock has to allow for the possibility that the PlatformMutex::try_lock allows recursive locking. >> >> Added additional commentary on the semantics provided by Mutex and the PlatformMutex classes. >> >> Testing: GHA, mach5 tiers 1-3 > > Hi David, > > LGTM. Minor remarks below. > > Thanks, Thomas > Using Atomic::load is a good idea just from a code hygiene perspective, > but doesn't change the raciness. My point was that because this is a racy read we _should_ use Atomic::load. ------------- PR: https://git.openjdk.java.net/jdk/pull/1247 From david.holmes at oracle.com Tue Nov 17 10:29:17 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Nov 2020 20:29:17 +1000 Subject: RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix In-Reply-To: References: Message-ID: On 17/11/2020 8:14 pm, Stefan Karlsson wrote: > On Tue, 17 Nov 2020 07:26:12 GMT, Thomas Stuefe wrote: > >>> Mutex::try_lock has to allow for the possibility that the PlatformMutex::try_lock allows recursive locking. >>> >>> Added additional commentary on the semantics provided by Mutex and the PlatformMutex classes. >>> >>> Testing: GHA, mach5 tiers 1-3 >> >> Hi David, >> >> LGTM. Minor remarks below. >> >> Thanks, Thomas > >> Using Atomic::load is a good idea just from a code hygiene perspective, >> but doesn't change the raciness. > > My point was that because this is a racy read we _should_ use Atomic::load. And my point is that Atomic::load makes no difference to the raciness. The Atomic::load is just how we now wrap/hide the fact the field should be treated as volatile and not optimised in any way by the compiler. And on that note I should point out that the Mutex code has not been converted to that form and raw reads of _owner are all over the place. So I'm actually reluctant to add in this single use of Atomic::load. Happy to file a RFE to update all the Mutex code that way though. Thanks, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1247 > From dholmes at openjdk.java.net Tue Nov 17 10:39:19 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 17 Nov 2020 10:39:19 GMT Subject: RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix [v2] In-Reply-To: References: Message-ID: > Mutex::try_lock has to allow for the possibility that the PlatformMutex::try_lock allows recursive locking. > > Added additional commentary on the semantics provided by Mutex and the PlatformMutex classes. > > Testing: GHA, mach5 tiers 1-3 David Holmes has updated the pull request incrementally with one additional commit since the last revision: Feedback from Stefan and Thomas: prefer a check against self rather than NULL ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1247/files - new: https://git.openjdk.java.net/jdk/pull/1247/files/b9abcb97..e4bd2c72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1247&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1247&range=00-01 Stats: 6 lines in 1 file changed: 3 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1247.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1247/head:pull/1247 PR: https://git.openjdk.java.net/jdk/pull/1247 From stefank at openjdk.java.net Tue Nov 17 13:10:02 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 17 Nov 2020 13:10:02 GMT Subject: RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 05:41:44 GMT, David Holmes wrote: > Mutex::try_lock has to allow for the possibility that the PlatformMutex::try_lock allows recursive locking. > > Added additional commentary on the semantics provided by Mutex and the PlatformMutex classes. > > Testing: GHA, mach5 tiers 1-3 @dholmes-ora It makes difference w.r.t. atomicity. You can argue that this isn't important in this specific use-case, but I thought there was an agreement among HotSpot devs to use Atomic::load for racy access. Esp. now that we've moved to C++11 and racy loads are considered undefined behavior. John created JDK-8234192 when this was discussed earlier. ------------- PR: https://git.openjdk.java.net/jdk/pull/1247 From david.holmes at oracle.com Tue Nov 17 13:16:27 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Nov 2020 05:16:27 -0800 (PST) Subject: RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix In-Reply-To: References: Message-ID: On 17/11/2020 11:10 pm, Stefan Karlsson wrote: > On Tue, 17 Nov 2020 05:41:44 GMT, David Holmes wrote: > >> Mutex::try_lock has to allow for the possibility that the PlatformMutex::try_lock allows recursive locking. >> >> Added additional commentary on the semantics provided by Mutex and the PlatformMutex classes. >> >> Testing: GHA, mach5 tiers 1-3 > > @dholmes-ora It makes difference w.r.t. atomicity. You can argue that this isn't important in this specific use-case, but I thought there was an agreement among HotSpot devs to use Atomic::load for racy access. Esp. now that we've moved to C++11 and racy loads are considered undefined behavior. John created JDK-8234192 when this was discussed earlier. As I said I'm happy to file a RFE to change all the code to do this, but it seems rather pointless to do this one occurrence in this PR. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1247 > From sgehwolf at openjdk.java.net Tue Nov 17 14:47:11 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 17 Nov 2020 14:47:11 GMT Subject: RFR: 8255796: Zero: CASE(_new) should replenish TLABs properly In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 07:57:19 GMT, Aleksey Shipilev wrote: > If you look at how current `CASE(_new)` is structured, then you will notice an odd thing: > > if (ik->is_initialized() && ik->can_be_fastpath_allocated() ) { > size_t obj_size = ik->size_helper(); > oop result = NULL; > if (UseTLAB) { > result = (oop) THREAD->tlab().allocate(obj_size); > } > if (result == NULL) { > // allocate from inline contiguous alloc > } > if (result != NULL) { > // initialize the object and return > } > } > // Slow case allocation > CALL_VM(InterpreterRuntime::_new(THREAD, METHOD->constants(), index), > handle_exception); > // return > > > The oddity here is: when TLAB is depleted and rejects the allocation, we fall through to inline contiguous alloc block that allocates the object in shared eden. That allocation is likely to succeed, and then we return from this path. But TLAB would never get replenished! Because to do that, we need to hit the slowpath allocation in `Interpreter::_new`, let in enter the runtime, and ask GC for a new TLAB! > > So in the end, when +UseTLAB is enabled for Zero, the code only uses the very first issued TLAB, and then always falls through to inline contiguous allocation, until eden is completely depleted. Inline contiguous block makes the shared CAS increment that could be heavily contended under allocations. > > I have observed this with supplying +UseTLAB to my adhoc Zero runs -- it was still slow. I think we can just remove the inline contiguous allocation block, and let the whole thing slide to slowpath on failure. This would also resolve the issue of enabling Zero for GCs that do not support inline contiguous allocs (anything beyond Serial and Parallel). > > I think giving up that block and make use +UseTLAB is enabled (JDK-8255782) would give us sensible improvements: > > | | Original | Original +UseTLAB | Patched +UseTLAB | > | --- | ----- | ----- | ----- | > | Simple alloc, ns/op | 302 +- 5 | 291 +- 5 | 233 +- 3 | > | Linux x86_64 Zero release `make images` | 9m35s | ----- | 9m10s | Seems sensible to me. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1029 From shade at openjdk.java.net Tue Nov 17 14:51:05 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 17 Nov 2020 14:51:05 GMT Subject: RFR: 8255796: Zero: CASE(_new) should replenish TLABs properly In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 14:44:25 GMT, Severin Gehwolf wrote: >> If you look at how current `CASE(_new)` is structured, then you will notice an odd thing: >> >> if (ik->is_initialized() && ik->can_be_fastpath_allocated() ) { >> size_t obj_size = ik->size_helper(); >> oop result = NULL; >> if (UseTLAB) { >> result = (oop) THREAD->tlab().allocate(obj_size); >> } >> if (result == NULL) { >> // allocate from inline contiguous alloc >> } >> if (result != NULL) { >> // initialize the object and return >> } >> } >> // Slow case allocation >> CALL_VM(InterpreterRuntime::_new(THREAD, METHOD->constants(), index), >> handle_exception); >> // return >> >> >> The oddity here is: when TLAB is depleted and rejects the allocation, we fall through to inline contiguous alloc block that allocates the object in shared eden. That allocation is likely to succeed, and then we return from this path. But TLAB would never get replenished! Because to do that, we need to hit the slowpath allocation in `Interpreter::_new`, let in enter the runtime, and ask GC for a new TLAB! >> >> So in the end, when +UseTLAB is enabled for Zero, the code only uses the very first issued TLAB, and then always falls through to inline contiguous allocation, until eden is completely depleted. Inline contiguous block makes the shared CAS increment that could be heavily contended under allocations. >> >> I have observed this with supplying +UseTLAB to my adhoc Zero runs -- it was still slow. I think we can just remove the inline contiguous allocation block, and let the whole thing slide to slowpath on failure. This would also resolve the issue of enabling Zero for GCs that do not support inline contiguous allocs (anything beyond Serial and Parallel). >> >> I think giving up that block and make use +UseTLAB is enabled (JDK-8255782) would give us sensible improvements: >> >> | | Original | Original +UseTLAB | Patched +UseTLAB | >> | --- | ----- | ----- | ----- | >> | Simple alloc, ns/op | 302 +- 5 | 291 +- 5 | 233 +- 3 | >> | Linux x86_64 Zero release `make images` | 9m35s | ----- | 9m10s | > > Seems sensible to me. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1029 From shade at openjdk.java.net Tue Nov 17 14:51:07 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 17 Nov 2020 14:51:07 GMT Subject: Integrated: 8255796: Zero: CASE(_new) should replenish TLABs properly In-Reply-To: References: Message-ID: On Tue, 3 Nov 2020 07:57:19 GMT, Aleksey Shipilev wrote: > If you look at how current `CASE(_new)` is structured, then you will notice an odd thing: > > if (ik->is_initialized() && ik->can_be_fastpath_allocated() ) { > size_t obj_size = ik->size_helper(); > oop result = NULL; > if (UseTLAB) { > result = (oop) THREAD->tlab().allocate(obj_size); > } > if (result == NULL) { > // allocate from inline contiguous alloc > } > if (result != NULL) { > // initialize the object and return > } > } > // Slow case allocation > CALL_VM(InterpreterRuntime::_new(THREAD, METHOD->constants(), index), > handle_exception); > // return > > > The oddity here is: when TLAB is depleted and rejects the allocation, we fall through to inline contiguous alloc block that allocates the object in shared eden. That allocation is likely to succeed, and then we return from this path. But TLAB would never get replenished! Because to do that, we need to hit the slowpath allocation in `Interpreter::_new`, let in enter the runtime, and ask GC for a new TLAB! > > So in the end, when +UseTLAB is enabled for Zero, the code only uses the very first issued TLAB, and then always falls through to inline contiguous allocation, until eden is completely depleted. Inline contiguous block makes the shared CAS increment that could be heavily contended under allocations. > > I have observed this with supplying +UseTLAB to my adhoc Zero runs -- it was still slow. I think we can just remove the inline contiguous allocation block, and let the whole thing slide to slowpath on failure. This would also resolve the issue of enabling Zero for GCs that do not support inline contiguous allocs (anything beyond Serial and Parallel). > > I think giving up that block and make use +UseTLAB is enabled (JDK-8255782) would give us sensible improvements: > > | | Original | Original +UseTLAB | Patched +UseTLAB | > | --- | ----- | ----- | ----- | > | Simple alloc, ns/op | 302 +- 5 | 291 +- 5 | 233 +- 3 | > | Linux x86_64 Zero release `make images` | 9m35s | ----- | 9m10s | This pull request has now been integrated. Changeset: 3b9c5a36 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/3b9c5a36 Stats: 21 lines in 1 file changed: 1 ins; 18 del; 2 mod 8255796: Zero: CASE(_new) should replenish TLABs properly Reviewed-by: sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/1029 From kim.barrett at oracle.com Tue Nov 17 15:18:31 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 17 Nov 2020 10:18:31 -0500 Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor In-Reply-To: <9675682c-2319-e485-7a39-4fd06fd4eb89@oracle.com> References: <-EFajUfzqEkyPvj2hBhsJnjuekn0Xp4MxoAYaNYMOV8=.fd73d4c4-885e-4f46-92e7-1c51e963c1bc@github.com> <24JUeQ02ar97zF0lRgfew4p6V88YddzfpcT_51c-Cvw=.70da2ea1-3d10-4beb-a9c9-f2dd6876a1e9@github.com> <9675682c-2319-e485-7a39-4fd06fd4eb89@oracle.com> Message-ID: <96A6BD7C-0087-418C-86D0-B5EB033BF365@oracle.com> > On Nov 16, 2020, at 8:30 PM, David Holmes wrote: > > Okay I hadn't realized the static_assert was checked once at compile-time. > > But isn't this assertion also checking it is a power of 2? > > assert((NINFLATIONLOCKS & (NINFLATIONLOCKS-1)) == 0, "invariant"); > > Should I just replace that with the is_power_of_2() static assert? I managed to overlook that later ordinary assert. Yes, that's a power-of-2 test, though not named so less obvious than it could be. But it's too late, in the sense that the computation whose output is affected has already executed. At the location of the that assert it's not obvious what it's for. The ordinary assert should be deleted and there should be an is_power_of_2 static_assert before the introduction of the ix variable. From minqi at openjdk.java.net Tue Nov 17 16:44:10 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 17 Nov 2020 16:44:10 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Tue, 17 Nov 2020 03:48:43 GMT, David Holmes wrote: >> Hi, Please review >> Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. >> >> Tests: tier1,tier4 > > Hi Yumin, > > Sorry but I don't think it is a reasonable approach to add in truncation where it previously did not occur. And adding a 4K stack buffer can also cause problems if threads are operating near the ends of their stacks (we have had to remove large local stack buffers in the past because of this). > > I'm not convinced we can make UL safe from absolutely any context automatically. Most of the time heap allocation is not a problem, it is only from within low-level memory related code that it may be a problem. I think that is a special enough case that we should address it more directly - via a different UL API perhaps, that explicitly avoids heap allocation. > > David Hi, @dholmes-ora and @tstuefe Thanks for your review. I came up with this simplest fix with the stack overflow case in concern, but think at that case, the thread will overflow even without using UL log, that is an extreme case, but I do agree 4K is way bigger for it. So next version will keep 512 as the buffer size, and use ::malloc/::free to replace NEW_C_HEAP_ARRAY/FREE_C_HEAP_ARRAY to avoid circularity here. We need manually check OOM here. For the thread local allocation at thread initialization --- we need to check if UL is used, should avoid allocating unused buffer, but that is in future work. @dholmes-ora please let me know if you agree continue working on the current issue. Thanks Yumin ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From pchilanomate at openjdk.java.net Tue Nov 17 17:30:17 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 17 Nov 2020 17:30:17 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks Message-ID: Please review the following patch to add method Mutex::try_lock_without_rank_check(). The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. In summary the patch contains the following changes: - Add method Mutex::try_lock_without_rank_check() - Move rank checks before trying to lock/wait on the underlying PlatformMonitor - Clean up definitions for optimized/debug builds - Add a new gtest to test for different rank violations scenarios Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.java.net/jdk/pull/1242/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1242&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255678 Stats: 324 lines in 3 files changed: 244 ins; 69 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1242.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1242/head:pull/1242 PR: https://git.openjdk.java.net/jdk/pull/1242 From iklam at openjdk.java.net Tue Nov 17 20:17:09 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 17 Nov 2020 20:17:09 GMT Subject: RFR: 8256476: Assert in vmIntrinsics::flags_for with -XX:+Verbose Message-ID: Please review this trivial fix. The bug was introduced by [JDK-8254855](https://bugs.openjdk.java.net/browse/JDK-8254855). `log2_FLAG_LIMIT` [1] is changed from 4 to 3. So the hard-coded value 15 in `vmIntrinsics::flags_for()` should be changed to 7. [1] https://github.com/openjdk/jdk/blame/0570cc10b579580f37b8978f2498459bdd4c870b/src/hotspot/share/classfile/vmIntrinsics.hpp#L1043 ------------- Commit messages: - 8256476: Assert in vmIntrinsics::flags_for with -XX:+Verbose Changes: https://git.openjdk.java.net/jdk/pull/1270/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1270&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256476 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1270.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1270/head:pull/1270 PR: https://git.openjdk.java.net/jdk/pull/1270 From redestad at openjdk.java.net Tue Nov 17 20:24:03 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 17 Nov 2020 20:24:03 GMT Subject: RFR: 8256476: Assert in vmIntrinsics::flags_for with -XX:+Verbose In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 19:19:55 GMT, Ioi Lam wrote: > Please review this trivial fix. > > The bug was introduced by [JDK-8254855](https://bugs.openjdk.java.net/browse/JDK-8254855). `log2_FLAG_LIMIT` [1] is changed from 4 to 3. So the hard-coded value 15 in `vmIntrinsics::flags_for()` should be changed to 7. > > [1] https://github.com/openjdk/jdk/blame/0570cc10b579580f37b8978f2498459bdd4c870b/src/hotspot/share/classfile/vmIntrinsics.hpp#L1043 Looks good and trivial. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1270 From dholmes at openjdk.java.net Tue Nov 17 22:01:03 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 17 Nov 2020 22:01:03 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Tue, 17 Nov 2020 16:41:30 GMT, Yumin Qi wrote: >> Hi Yumin, >> >> Sorry but I don't think it is a reasonable approach to add in truncation where it previously did not occur. And adding a 4K stack buffer can also cause problems if threads are operating near the ends of their stacks (we have had to remove large local stack buffers in the past because of this). >> >> I'm not convinced we can make UL safe from absolutely any context automatically. Most of the time heap allocation is not a problem, it is only from within low-level memory related code that it may be a problem. I think that is a special enough case that we should address it more directly - via a different UL API perhaps, that explicitly avoids heap allocation. >> >> David > > Hi, @dholmes-ora and @tstuefe > Thanks for your review. I came up with this simplest fix with the stack overflow case in concern, but think at that case, the thread will overflow even without using UL log, that is an extreme case, but I do agree 4K is way bigger for it. > So next version will keep 512 as the buffer size, and use ::malloc/::free to replace NEW_C_HEAP_ARRAY/FREE_C_HEAP_ARRAY to avoid circularity here. We need manually check OOM here. > For the thread local allocation at thread initialization --- we need to check if UL is used, should avoid allocating unused buffer, but that is in future work. > @dholmes-ora please let me know if you agree continue working on the current issue. > > Thanks > Yumin Going with the manual malloc/free approach seems reasonable to me. I don't know if the NMT folk will object to UL not being tracked. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From david.holmes at oracle.com Tue Nov 17 22:30:25 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Nov 2020 08:30:25 +1000 Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor In-Reply-To: <96A6BD7C-0087-418C-86D0-B5EB033BF365@oracle.com> References: <-EFajUfzqEkyPvj2hBhsJnjuekn0Xp4MxoAYaNYMOV8=.fd73d4c4-885e-4f46-92e7-1c51e963c1bc@github.com> <24JUeQ02ar97zF0lRgfew4p6V88YddzfpcT_51c-Cvw=.70da2ea1-3d10-4beb-a9c9-f2dd6876a1e9@github.com> <9675682c-2319-e485-7a39-4fd06fd4eb89@oracle.com> <96A6BD7C-0087-418C-86D0-B5EB033BF365@oracle.com> Message-ID: <3b88060e-b8e0-27bb-0c6b-24940fb3ec9e@oracle.com> On 18/11/2020 1:18 am, Kim Barrett wrote: >> On Nov 16, 2020, at 8:30 PM, David Holmes wrote: >> >> Okay I hadn't realized the static_assert was checked once at compile-time. >> >> But isn't this assertion also checking it is a power of 2? >> >> assert((NINFLATIONLOCKS & (NINFLATIONLOCKS-1)) == 0, "invariant"); >> >> Should I just replace that with the is_power_of_2() static assert? > > I managed to overlook that later ordinary assert. Yes, that's a > power-of-2 test, though not named so less obvious than it could be. > But it's too late, in the sense that the computation whose output is > affected has already executed. At the location of the that assert it's > not obvious what it's for. > > The ordinary assert should be deleted and there should be an > is_power_of_2 static_assert before the introduction of the ix > variable. Done. Thanks, David From dholmes at openjdk.java.net Tue Nov 17 22:35:20 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 17 Nov 2020 22:35:20 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor [v4] In-Reply-To: References: Message-ID: > This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. > > On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. > > Testing: > - GH actions > - mach5 tiers 1-3 > - selected performance testing (guided by that used for JDK-8253064) > > Thanks, > David David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Update power_of_2 static assertion placement. - Merge branch 'master' into 8225631 - Move static_assert as requested by Kim. - Merge branch 'master' into 8225631 - Feedback from Coleen, Kim and Dan. - 8225631: Consider replacing muxAcquire/Release with PlatformMonitor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1196/files - new: https://git.openjdk.java.net/jdk/pull/1196/files/7e3fe3db..a0eedf1c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1196&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1196&range=02-03 Stats: 2046 lines in 72 files changed: 1360 ins; 421 del; 265 mod Patch: https://git.openjdk.java.net/jdk/pull/1196.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1196/head:pull/1196 PR: https://git.openjdk.java.net/jdk/pull/1196 From david.holmes at oracle.com Tue Nov 17 22:44:09 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Nov 2020 08:44:09 +1000 Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor [v4] In-Reply-To: References: Message-ID: On 18/11/2020 8:35 am, David Holmes wrote: > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Update power_of_2 static assertion placement. That commit message should have been: "Remove old power-of-2 assertion that is replaced by earlier static assert." David ----- > - Merge branch 'master' into 8225631 > - Move static_assert as requested by Kim. > - Merge branch 'master' into 8225631 > - Feedback from Coleen, Kim and Dan. > - 8225631: Consider replacing muxAcquire/Release with PlatformMonitor > > ------------- > > Changes: > - all: https://git.openjdk.java.net/jdk/pull/1196/files > - new: https://git.openjdk.java.net/jdk/pull/1196/files/7e3fe3db..a0eedf1c > > Webrevs: > - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1196&range=03 > - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1196&range=02-03 > > Stats: 2046 lines in 72 files changed: 1360 ins; 421 del; 265 mod > Patch: https://git.openjdk.java.net/jdk/pull/1196.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1196/head:pull/1196 > > PR: https://git.openjdk.java.net/jdk/pull/1196 > From dcubed at openjdk.java.net Tue Nov 17 22:53:09 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 17 Nov 2020 22:53:09 GMT Subject: RFR: 8238174: migrate ObjectMonitor::_owner field away from C++ volatile semantics Message-ID: Drop volatile from the ObjectMonitor::_owner field. Update all naked field loads to use the new owner_raw() accessor or the existing owner_is_DEFLATER_MARKER() accessor. ------------- Commit messages: - 8238174: migrate ObjectMonitor::_owner field away from C++ volatile semantics Changes: https://git.openjdk.java.net/jdk/pull/1278/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1278&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238174 Stats: 46 lines in 4 files changed: 5 ins; 0 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/1278.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1278/head:pull/1278 PR: https://git.openjdk.java.net/jdk/pull/1278 From dcubed at openjdk.java.net Tue Nov 17 22:53:10 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 17 Nov 2020 22:53:10 GMT Subject: RFR: 8238174: migrate ObjectMonitor::_owner field away from C++ volatile semantics In-Reply-To: References: Message-ID: <3PjOZsbQmFPg-rQPF7th5MpwMFdC1YPZPdmjhXJ4Sis=.a0949a8c-43eb-40c5-8bd2-ff94f52de5aa@github.com> On Tue, 17 Nov 2020 22:44:11 GMT, Daniel D. Daugherty wrote: > Drop volatile from the ObjectMonitor::_owner field. Update all naked > field loads to use the new owner_raw() accessor or the existing > owner_is_DEFLATER_MARKER() accessor. Gory details and background: Note: Previous work updated the setters to use appropriate Atomic operations: JDK-8236035 refactor ObjectMonitor::set_owner() and _owner field setting Note: Previous work also updated the owner() accessor to check for the DEFLATER_MARKER value and return NULL. Those existing calls to owner() did not need to know about the DEFLATER_MARKER value so we hid it from those code sites. To verify that all uses of ObjectMonitor::_owner were found and converted, I temporarily changed the `_owner` field to `_ownerX` and updated the expected `_owner` field uses to `_ownerX`. The resulting JDK built in release, fastdebug and slowdebug configs. ------------- PR: https://git.openjdk.java.net/jdk/pull/1278 From dcubed at openjdk.java.net Tue Nov 17 22:53:10 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 17 Nov 2020 22:53:10 GMT Subject: RFR: 8238174: migrate ObjectMonitor::_owner field away from C++ volatile semantics In-Reply-To: <3PjOZsbQmFPg-rQPF7th5MpwMFdC1YPZPdmjhXJ4Sis=.a0949a8c-43eb-40c5-8bd2-ff94f52de5aa@github.com> References: <3PjOZsbQmFPg-rQPF7th5MpwMFdC1YPZPdmjhXJ4Sis=.a0949a8c-43eb-40c5-8bd2-ff94f52de5aa@github.com> Message-ID: <4TafAcC9Fd1Iuw-8ZRBYU80so2WS3DvemrCUcCzp-uU=.7fc3d4d0-6064-42f4-8758-47011992baa6@github.com> On Tue, 17 Nov 2020 22:47:41 GMT, Daniel D. Daugherty wrote: >> Drop volatile from the ObjectMonitor::_owner field. Update all naked >> field loads to use the new owner_raw() accessor or the existing >> owner_is_DEFLATER_MARKER() accessor. > > Gory details and background: > > Note: Previous work updated the setters to use appropriate Atomic operations: > > JDK-8236035 refactor ObjectMonitor::set_owner() and _owner field setting > > Note: Previous work also updated the owner() accessor to check for the > DEFLATER_MARKER value and return NULL. Those existing calls to owner() > did not need to know about the DEFLATER_MARKER value so we hid it from > those code sites. > > To verify that all uses of ObjectMonitor::_owner were found and converted, > I temporarily changed the `_owner` field to `_ownerX` and updated the > expected `_owner` field uses to `_ownerX`. The resulting JDK built in > release, fastdebug and slowdebug configs. @coleenp and @dholmes-ora - I believe the two of you motivated the creation of this RFE so please chime in when you get the chance. @stefank - You may also be interested in this PR... ------------- PR: https://git.openjdk.java.net/jdk/pull/1278 From dcubed at openjdk.java.net Tue Nov 17 22:54:10 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 17 Nov 2020 22:54:10 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor [v4] In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 22:35:20 GMT, David Holmes wrote: >> This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. >> >> On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. >> >> Testing: >> - GH actions >> - mach5 tiers 1-3 >> - selected performance testing (guided by that used for JDK-8253064) >> >> Thanks, >> David > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Update power_of_2 static assertion placement. > - Merge branch 'master' into 8225631 > - Move static_assert as requested by Kim. > - Merge branch 'master' into 8225631 > - Feedback from Coleen, Kim and Dan. > - 8225631: Consider replacing muxAcquire/Release with PlatformMonitor Still good. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1196 From minqi at openjdk.java.net Tue Nov 17 23:34:10 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 17 Nov 2020 23:34:10 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Tue, 17 Nov 2020 21:58:06 GMT, David Holmes wrote: > Going with the manual malloc/free approach seems reasonable to me. I don't know if the NMT folk will object to UL not being tracked. > Thanks, > David Thanks. Will update with the suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From dcubed at openjdk.java.net Tue Nov 17 23:36:09 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 17 Nov 2020 23:36:09 GMT Subject: RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix [v2] In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 10:39:19 GMT, David Holmes wrote: >> Mutex::try_lock has to allow for the possibility that the PlatformMutex::try_lock allows recursive locking. >> >> Added additional commentary on the semantics provided by Mutex and the PlatformMutex classes. >> >> Testing: GHA, mach5 tiers 1-3 > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Feedback from Stefan and Thomas: prefer a check against self rather than NULL Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1247 From dcubed at openjdk.java.net Tue Nov 17 23:36:12 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 17 Nov 2020 23:36:12 GMT Subject: RFR: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix [v2] In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 07:25:38 GMT, Stefan Karlsson wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback from Stefan and Thomas: prefer a check against self rather than NULL > > src/hotspot/share/runtime/mutex.cpp line 147: > >> 145: // safepoint state, but can check blocking state. >> 146: check_block_state(self); >> 147: if (_owner == NULL && _lock.try_lock()) { > > It's not obvious that's it is correct to check == NULL. Couldn't there be a lingering value from another thread, causing a spurious failure to acquire the lock? Could this be changed to _owner != self? That way we only check for a value that only the current thread could have written. > > Also, this is a racy read, should this be using Atomic::load? I agree with the switch to checking `_owner != self`. The ObjectMonitor code does checks in the same way because a thread should only check for a value that it could have written. ------------- PR: https://git.openjdk.java.net/jdk/pull/1247 From coleenp at openjdk.java.net Tue Nov 17 23:53:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 17 Nov 2020 23:53:01 GMT Subject: RFR: 8134630: make code and comments consistent for stack lock optimization In-Reply-To: References: Message-ID: <-5ova3WCkPsZAg8C2t5Ihivyy3FRV1m8922hfdqKNWM=.afcbcf38-9064-45fa-a01e-b5fd46b45c53@github.com> On Fri, 13 Nov 2020 22:42:05 GMT, Daniel D. Daugherty wrote: > Comment only changes copied from the 'arm' version to the aarch64 and x86 > versions of the files. I looked at the ppc and s390 files and it wasn't at all clear > to me how to apply the same comment changes to those platforms. This looks good. Sorry for the delay. I was a bit unhappy with the same big comment in three places but nobody ever looks at all the places at once, so it's useful in all places. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1210 From dcubed at openjdk.java.net Tue Nov 17 23:56:09 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 17 Nov 2020 23:56:09 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 22:58:35 GMT, Patricio Chilano Mateo wrote: > Please review the following patch to add method Mutex::try_lock_without_rank_check(). > > The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. > > The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. > > Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. > > Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. > > I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. > > In summary the patch contains the following changes: > - Add method Mutex::try_lock_without_rank_check() > - Move rank checks before trying to lock/wait on the underlying PlatformMonitor > - Clean up definitions for optimized/debug builds > - Add a new gtest to test for different rank violations scenarios > > Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. > > Thanks, > Patricio Your call on whether to fix the nits. I like the new test! Most of the longer stress test runs happen in Tier7 and Tier8 so you should also run those. src/hotspot/share/runtime/mutex.cpp line 421: > 419: thread->print_owned_locks(); > 420: assert(false, "Attempting to acquire lock %s/%d out of order with lock %s/%d -- " > 421: "possible deadlock", this->name(), this->rank(),least->name(), least->rank()); nit - missing blank - s/this->rank(),/this->rank(), / src/hotspot/share/runtime/mutex.hpp line 91: > 89: Mutex* _next; // Used by a Thread to link up owned locks > 90: Thread* _last_owner; // the last thread to own the lock > 91: bool _skip_rank_check; // read only by owner whend doing rank checks nit - typo: s/whend/when/ ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1242 From dcubed at openjdk.java.net Wed Nov 18 00:02:02 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 00:02:02 GMT Subject: RFR: 8134630: make code and comments consistent for stack lock optimization In-Reply-To: <-5ova3WCkPsZAg8C2t5Ihivyy3FRV1m8922hfdqKNWM=.afcbcf38-9064-45fa-a01e-b5fd46b45c53@github.com> References: <-5ova3WCkPsZAg8C2t5Ihivyy3FRV1m8922hfdqKNWM=.afcbcf38-9064-45fa-a01e-b5fd46b45c53@github.com> Message-ID: On Tue, 17 Nov 2020 23:50:20 GMT, Coleen Phillimore wrote: >> Comment only changes copied from the 'arm' version to the aarch64 and x86 >> versions of the files. I looked at the ppc and s390 files and it wasn't at all clear >> to me how to apply the same comment changes to those platforms. > > This looks good. Sorry for the delay. I was a bit unhappy with the same big comment in three places but nobody ever looks at all the places at once, so it's useful in all places. @coleenp - Thanks for the review. Someday maybe an enterprising soul will merge the 'arm' and 'aarch64' platforms, so we would have one fewer place, but then the complaints will shift to all the #ifdefs... :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/1210 From dcubed at openjdk.java.net Wed Nov 18 00:02:04 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 00:02:04 GMT Subject: Integrated: 8134630: make code and comments consistent for stack lock optimization In-Reply-To: References: Message-ID: On Fri, 13 Nov 2020 22:42:05 GMT, Daniel D. Daugherty wrote: > Comment only changes copied from the 'arm' version to the aarch64 and x86 > versions of the files. I looked at the ppc and s390 files and it wasn't at all clear > to me how to apply the same comment changes to those platforms. This pull request has now been integrated. Changeset: eb021848 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/eb021848 Stats: 42 lines in 2 files changed: 36 ins; 0 del; 6 mod 8134630: make code and comments consistent for stack lock optimization Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1210 From pchilanomate at openjdk.java.net Wed Nov 18 00:39:22 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 18 Nov 2020 00:39:22 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v2] In-Reply-To: References: Message-ID: > Please review the following patch to add method Mutex::try_lock_without_rank_check(). > > The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. > > The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. > > Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. > > Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. > > I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. > > In summary the patch contains the following changes: > - Add method Mutex::try_lock_without_rank_check() > - Move rank checks before trying to lock/wait on the underlying PlatformMonitor > - Clean up definitions for optimized/debug builds > - Add a new gtest to test for different rank violations scenarios > > Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. > > 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/1242/files - new: https://git.openjdk.java.net/jdk/pull/1242/files/9c035ecd..5ba3fab6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1242&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1242&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1242.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1242/head:pull/1242 PR: https://git.openjdk.java.net/jdk/pull/1242 From pchilanomate at openjdk.java.net Wed Nov 18 00:39:23 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 18 Nov 2020 00:39:23 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v2] In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 23:52:55 GMT, Daniel D. Daugherty wrote: > Your call on whether to fix the nits. I like the new test! > Most of the longer stress test runs happen in Tier7 and > Tier8 so you should also run those. Sounds good, I'll give it a run on tiers 7 and 8 then. Thanks for reviewing this Dan! Patricio > src/hotspot/share/runtime/mutex.cpp line 421: > >> 419: thread->print_owned_locks(); >> 420: assert(false, "Attempting to acquire lock %s/%d out of order with lock %s/%d -- " >> 421: "possible deadlock", this->name(), this->rank(),least->name(), least->rank()); > > nit - missing blank - s/this->rank(),/this->rank(), / Fixed. > src/hotspot/share/runtime/mutex.hpp line 91: > >> 89: Mutex* _next; // Used by a Thread to link up owned locks >> 90: Thread* _last_owner; // the last thread to own the lock >> 91: bool _skip_rank_check; // read only by owner whend doing rank checks > > nit - typo: s/whend/when/ Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From iklam at openjdk.java.net Wed Nov 18 00:42:10 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 18 Nov 2020 00:42:10 GMT Subject: RFR: 8256172: Clean up CDS handling of i2i_entry Message-ID: This PR is a prerequisite for [JDK-8250989](https://bugs.openjdk.java.net/browse/JDK-8250989) - Consolidate buffer allocation code for CDS static/dynamic archive dumping. - Move the allocation of the i2i buffer after all classes are loaded. This makes it possible to estimate the size of the CDS archive before we allocate the output space (this is what dynamic archive does now). - No need to generate the i2i trampoline code during -Xshare:dump - Clean up the CDS code in abstractInterpreter.cpp and add more comments. ------------- Commit messages: - 8256172: Clean up CDS handling of i2i_entry Changes: https://git.openjdk.java.net/jdk/pull/1280/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1280&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256172 Stats: 84 lines in 8 files changed: 24 ins; 39 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/1280.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1280/head:pull/1280 PR: https://git.openjdk.java.net/jdk/pull/1280 From dholmes at openjdk.java.net Wed Nov 18 01:30:11 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 Nov 2020 01:30:11 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 00:39:22 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch to add method Mutex::try_lock_without_rank_check(). >> >> The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. >> >> The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. >> >> Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. >> >> Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. >> >> I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. >> >> In summary the patch contains the following changes: >> - Add method Mutex::try_lock_without_rank_check() >> - Move rank checks before trying to lock/wait on the underlying PlatformMonitor >> - Clean up definitions for optimized/debug builds >> - Add a new gtest to test for different rank violations scenarios >> >> Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > address Dan's comments Hi Patricio, This looks good to me, modulo the overlap with JDK-8256383 (the try_lock bug). One query below. Thanks, David src/hotspot/share/runtime/mutex.cpp line 161: > 159: if (_owner == self) { > 160: return false; > 161: } This is being fixed by https://github.com/openjdk/jdk/pull/1247 src/hotspot/share/runtime/mutex.cpp line 220: > 218: JavaThread* const self = JavaThread::current(); > 219: // Safepoint checking logically implies an active JavaThread. > 220: guarantee(self->is_active_Java_thread(), "invariant"); Not clear why this is necessary here, and why it is a guarantee rather than assert ?? ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1242 From dholmes at openjdk.java.net Wed Nov 18 01:56:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 Nov 2020 01:56:10 GMT Subject: RFR: 8238174: migrate ObjectMonitor::_owner field away from C++ volatile semantics In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 22:44:11 GMT, Daniel D. Daugherty wrote: > Drop volatile from the ObjectMonitor::_owner field. Update all naked > field loads to use the new owner_raw() accessor or the existing > owner_is_DEFLATER_MARKER() accessor. Looks good! One nit and one suggestion for your consideration. Thanks, David src/hotspot/share/runtime/objectMonitor.inline.hpp line 58: > 56: // Returns NULL if DEFLATER_MARKER is observed. > 57: inline void* ObjectMonitor::owner() const { > 58: void* owner = owner_raw(); There is an inconsistency with `owner()` and `owner_is_DEFLATER_MARKER()` where one delegates to `owner_raw()` and the other repeats the `Atomic::load(&_owner)`. They should both do the same thing - probably better to use `owner_raw()`. src/hotspot/share/runtime/objectMonitor.inline.hpp line 34: > 32: > 33: inline intptr_t ObjectMonitor::is_entered(TRAPS) const { > 34: if (THREAD == owner_raw() || THREAD->is_lock_owned((address) owner_raw())) { Suggestion: add a local to avoid two calls to `owner_raw()`. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1278 From dcubed at openjdk.java.net Wed Nov 18 02:25:16 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 02:25:16 GMT Subject: RFR: 8238174: migrate ObjectMonitor::_owner field away from C++ volatile semantics [v2] In-Reply-To: References: Message-ID: > Drop volatile from the ObjectMonitor::_owner field. Update all naked > field loads to use the new owner_raw() accessor or the existing > owner_is_DEFLATER_MARKER() accessor. > > Testing: Mach5 Tier1,2,3 (2 & 3 are running) Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: @dholmes-ora CR - resolve David's comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1278/files - new: https://git.openjdk.java.net/jdk/pull/1278/files/0f375d67..bb28666a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1278&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1278&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1278.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1278/head:pull/1278 PR: https://git.openjdk.java.net/jdk/pull/1278 From dcubed at openjdk.java.net Wed Nov 18 02:25:18 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 02:25:18 GMT Subject: RFR: 8238174: migrate ObjectMonitor::_owner field away from C++ volatile semantics [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 01:52:58 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> @dholmes-ora CR - resolve David's comments. > > Looks good! > One nit and one suggestion for your consideration. > Thanks, > David @dholmes-ora - Thanks for the quick review! > src/hotspot/share/runtime/objectMonitor.inline.hpp line 58: > >> 56: // Returns NULL if DEFLATER_MARKER is observed. >> 57: inline void* ObjectMonitor::owner() const { >> 58: void* owner = owner_raw(); > > There is an inconsistency with `owner()` and `owner_is_DEFLATER_MARKER()` where one delegates to `owner_raw()` and the other repeats the `Atomic::load(&_owner)`. They should both do the same thing - probably better to use `owner_raw()`. Good catch! I changed owner_is_DEFLATER_MARKER() to use owner_raw(). > src/hotspot/share/runtime/objectMonitor.inline.hpp line 34: > >> 32: >> 33: inline intptr_t ObjectMonitor::is_entered(TRAPS) const { >> 34: if (THREAD == owner_raw() || THREAD->is_lock_owned((address) owner_raw())) { > > Suggestion: add a local to avoid two calls to `owner_raw()`. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/1278 From dholmes at openjdk.java.net Wed Nov 18 02:35:06 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 Nov 2020 02:35:06 GMT Subject: RFR: 8238174: migrate ObjectMonitor::_owner field away from C++ volatile semantics [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 02:25:16 GMT, Daniel D. Daugherty wrote: >> Drop volatile from the ObjectMonitor::_owner field. Update all naked >> field loads to use the new owner_raw() accessor or the existing >> owner_is_DEFLATER_MARKER() accessor. >> >> Testing: Mach5 Tier1,2,3 (2 & 3 are running) > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora CR - resolve David's comments. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1278 From pchilanomate at openjdk.java.net Wed Nov 18 03:14:07 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 18 Nov 2020 03:14:07 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 01:27:47 GMT, David Holmes wrote: > Hi Patricio, > This looks good to me, modulo the overlap with JDK-8256383 (the try_lock bug). > One query below. > Thanks, > David Hi David, Thanks for looking at this. > src/hotspot/share/runtime/mutex.cpp line 161: > >> 159: if (_owner == self) { >> 160: return false; >> 161: } > > This is being fixed by https://github.com/openjdk/jdk/pull/1247 I'll wait until you push and then I'll merge. I still have to check the owner here though, because if the thread already owns the lock, calling check_rank() from try_lock will do the wrong check (it will assume it's being called from wait()). An alternative would be to add a boolean parameter to check_rank(), set only from try_lock() so I can differentiate the two calls. > src/hotspot/share/runtime/mutex.cpp line 220: > >> 218: JavaThread* const self = JavaThread::current(); >> 219: // Safepoint checking logically implies an active JavaThread. >> 220: guarantee(self->is_active_Java_thread(), "invariant"); > > Not clear why this is necessary here, and why it is a guarantee rather than assert ?? I looked at the history of this check. The guarantee has been since day1 on the hg repo as "self->is_Java_thread()" and then changed in 8226228 to "self->is_active_Java_thread()". I moved it at the beginning of wait() since it seems the right place to check it just after retrieving self. It doesn't make sense to keep it as a guarantee when every other check is an assert so I will change it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From iklam at openjdk.java.net Wed Nov 18 03:48:06 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 18 Nov 2020 03:48:06 GMT Subject: RFR: 8256476: Assert in vmIntrinsics::flags_for with -XX:+Verbose In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 20:20:58 GMT, Claes Redestad wrote: >> Please review this trivial fix. >> >> The bug was introduced by [JDK-8254855](https://bugs.openjdk.java.net/browse/JDK-8254855). `log2_FLAG_LIMIT` [1] is changed from 4 to 3. So the hard-coded value 15 in `vmIntrinsics::flags_for()` should be changed to 7. >> >> Tests: passed tier-1 >> >> [1] https://github.com/openjdk/jdk/blame/0570cc10b579580f37b8978f2498459bdd4c870b/src/hotspot/share/classfile/vmIntrinsics.hpp#L1043 > > Looks good and trivial. Thanks @cl4es for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1270 From iklam at openjdk.java.net Wed Nov 18 03:48:07 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 18 Nov 2020 03:48:07 GMT Subject: Integrated: 8256476: Assert in vmIntrinsics::flags_for with -XX:+Verbose In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 19:19:55 GMT, Ioi Lam wrote: > Please review this trivial fix. > > The bug was introduced by [JDK-8254855](https://bugs.openjdk.java.net/browse/JDK-8254855). `log2_FLAG_LIMIT` [1] is changed from 4 to 3. So the hard-coded value 15 in `vmIntrinsics::flags_for()` should be changed to 7. > > Tests: passed tier-1 > > [1] https://github.com/openjdk/jdk/blame/0570cc10b579580f37b8978f2498459bdd4c870b/src/hotspot/share/classfile/vmIntrinsics.hpp#L1043 This pull request has now been integrated. Changeset: 7ecf070e Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/7ecf070e Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8256476: Assert in vmIntrinsics::flags_for with -XX:+Verbose Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/1270 From pchilanomate at openjdk.java.net Wed Nov 18 03:49:14 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 18 Nov 2020 03:49:14 GMT Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 Message-ID: Hi all, Please review the following change to defer biased-locking obsoletion to 18, as discussed in [1]. I updated the special_jvm_flags table and re-enabled gtest verify_special_flags. Thanks, Patricio [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/045454.html ------------- Commit messages: - v1 Changes: https://git.openjdk.java.net/jdk/pull/1281/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1281&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256253 Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/1281.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1281/head:pull/1281 PR: https://git.openjdk.java.net/jdk/pull/1281 From dholmes at openjdk.java.net Wed Nov 18 04:05:04 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 Nov 2020 04:05:04 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 03:10:21 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/mutex.cpp line 161: >> >>> 159: if (_owner == self) { >>> 160: return false; >>> 161: } >> >> This is being fixed by https://github.com/openjdk/jdk/pull/1247 > > I'll wait until you push and then I'll merge. I still have to check the owner here though, because if the thread already owns the lock, calling check_rank() from try_lock will do the wrong check (it will assume it's being called from wait()). An alternative would be to add a boolean parameter to check_rank(), set only from try_lock() so I can differentiate the two calls. I think a different refactoring will be needed here so that: try_lock() -> try_lock_inner(true); try_lock_without_rank_check() -> try_lock_inner(false); try_lock_inner(bool check_rank) { ... } That way code duplication is minimised. >> src/hotspot/share/runtime/mutex.cpp line 220: >> >>> 218: JavaThread* const self = JavaThread::current(); >>> 219: // Safepoint checking logically implies an active JavaThread. >>> 220: guarantee(self->is_active_Java_thread(), "invariant"); >> >> Not clear why this is necessary here, and why it is a guarantee rather than assert ?? > > I looked at the history of this check. The guarantee has been since day1 on the hg repo as "self->is_Java_thread()" and then changed in 8226228 to "self->is_active_Java_thread()". I moved it at the beginning of wait() since it seems the right place to check it just after retrieving self. It doesn't make sense to keep it as a guarantee when every other check is an assert so I will change it. Sorry I missed that this had simply been moved. ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From minqi at openjdk.java.net Wed Nov 18 04:32:18 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 18 Nov 2020 04:32:18 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v2] In-Reply-To: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: > Hi, Please review > Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. > > Tests: tier1,tier4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Use malloc/free for large log message buffer ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1246/files - new: https://git.openjdk.java.net/jdk/pull/1246/files/1819b8e2..46b58626 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1246&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1246&range=00-01 Stats: 34 lines in 3 files changed: 20 ins; 6 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1246/head:pull/1246 PR: https://git.openjdk.java.net/jdk/pull/1246 From dholmes at openjdk.java.net Wed Nov 18 04:46:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 Nov 2020 04:46:10 GMT Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 In-Reply-To: References: Message-ID: <2H-j63k_Z2htPepW0aiaBGRY9QWAGFW2bBY83W3iKZU=.8bad4c22-b231-4e9f-87a0-42555162b943@github.com> On Wed, 18 Nov 2020 03:26:41 GMT, Patricio Chilano Mateo wrote: > Hi all, > > Please review the following change to defer biased-locking obsoletion to 18, as discussed in [1]. > I updated the special_jvm_flags table and re-enabled gtest verify_special_flags. > > Thanks, > Patricio > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/045454.html Hi Patricio, One minor issue - see below. Thanks, David src/hotspot/share/runtime/arguments.cpp line 532: > 530: { "UseOptoBiasInlining", JDK_Version::jdk(15), JDK_Version::jdk(18), JDK_Version::jdk(19) }, > 531: { "PrintPreciseBiasedLockingStatistics", JDK_Version::jdk(15), JDK_Version::jdk(18), JDK_Version::jdk(19) }, > 532: { "CriticalJNINatives", JDK_Version::jdk(16), JDK_Version::jdk(17), JDK_Version::jdk(18) }, To maintain the table ordering this entry needs to move above the BL entries now. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1281 From dholmes at openjdk.java.net Wed Nov 18 05:22:04 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 Nov 2020 05:22:04 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v2] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Wed, 18 Nov 2020 04:32:18 GMT, Yumin Qi wrote: >> Hi, Please review >> Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. >> >> Tests: tier1,tier4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Use malloc/free for large log message buffer Hi Yumin, This basic change seems okay, but I'm still somewhat skeptical that this one location is all that needs changing to allow NMT to use UL without the UL code allocating anything tracked by NMT. For example, what if we have to grow the logMessageBuffer? Thanks, David src/hotspot/share/logging/logTagSet.cpp line 129: > 127: if ((size_t)ret >= sizeof(buf)) { > 128: size_t newbuf_len = prefix_len + ret + 1; > 129: char* newbuf = (char*)::calloc(newbuf_len, sizeof(char)); Do we need to zero the array with calloc? The `(char*)` cast shouldn't be needed. src/hotspot/share/logging/logTagSet.cpp line 131: > 129: char* newbuf = (char*)::calloc(newbuf_len, sizeof(char)); > 130: if (newbuf == nullptr) { > 131: tty->print_cr("Out of memory at logging, allocate " SIZE_FORMAT " bytes", newbuf_len); Suggestion: " Out of memory during lohging, trying to allocate XXX bytes" ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From stuefe at openjdk.java.net Wed Nov 18 05:51:05 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 18 Nov 2020 05:51:05 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v2] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: On Wed, 18 Nov 2020 04:32:18 GMT, Yumin Qi wrote: >> Hi, Please review >> Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. >> >> Tests: tier1,tier4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Use malloc/free for large log message buffer Hi Yumin, thanks. Sorry if this seems bikesheddy - I have a proposal about how to print in case of OOM, see below. Feel free to ignore it as you see fit, the patch is already good in its current form. Cheers, Thomas src/hotspot/share/logging/logTagSet.cpp line 130: > 128: size_t newbuf_len = prefix_len + ret + 1; > 129: char* newbuf = (char*)::calloc(newbuf_len, sizeof(char)); > 130: if (newbuf == nullptr) { Thinking about this, I see now another advantage of this patch: I don't like UL to go silent because of native OOM. About that, how about instead of printing to tty, we do this instead: if (newbuf == nullptr) { log(level, buf); log(level, "(Truncated, native OOM."); return; } instead? This would first print the truncated line, still in the static buffer, to the UL log - so we miss as little information as possible - followed by a truncation marker to show the reader that we truncated. (Alternatively we could stamp something like "..(truncated)" to the end of the static buffer and just print once). This proposal has one little beauty spot: in case the prefix did overflow the static buffer, we end up in line 124, and print the log line without prefix. I think that would be totally fine. The message content is more important than the prefix. Its a very rare case. But should that bother you, you could "dry print" at line 124: } else { // Buffer too small. Just call printf to find out the length for realloc below. // vv "dry-print" to find out length but dont change buffer content ret = os::vsnprintf(NULL, 0, fmt, args); } which would leave the buffer with the truncated prefix intact. (Side note, looking at logPrefix.hpp, I see that the code there asserts in case of buffer overflow. So why do we even handle it here. But since this is all templatized to oblivion I may be missing something). Thanks Thomas src/hotspot/share/logging/logTagSet.cpp line 129: > 127: if ((size_t)ret >= sizeof(buf)) { > 128: size_t newbuf_len = prefix_len + ret + 1; > 129: char* newbuf = (char*)::calloc(newbuf_len, sizeof(char)); Can you precede this with a little comment please: `// We use raw ::malloc to prevent circularities` ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From david.holmes at oracle.com Wed Nov 18 06:13:39 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Nov 2020 16:13:39 +1000 Subject: RFR: 8256256: UL should not use heap allocation for output string [v2] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: Hi Thomas, On 18/11/2020 3:51 pm, Thomas Stuefe wrote: > On Wed, 18 Nov 2020 04:32:18 GMT, Yumin Qi wrote: > >>> Hi, Please review >>> Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. >>> >>> Tests: tier1,tier4 >> >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Use malloc/free for large log message buffer > > Hi Yumin, > > thanks. Sorry if this seems bikesheddy - I have a proposal about how to print in case of OOM, see below. Feel free to ignore it as you see fit, the patch is already good in its current form. > > Cheers, Thomas > > src/hotspot/share/logging/logTagSet.cpp line 130: > >> 128: size_t newbuf_len = prefix_len + ret + 1; >> 129: char* newbuf = (char*)::calloc(newbuf_len, sizeof(char)); >> 130: if (newbuf == nullptr) { > > Thinking about this, I see now another advantage of this patch: I don't like UL to go silent because of native OOM. Yes I was surprised to see we used the aborting form of NEW_C_HEAP_ARRAY. > About that, how about instead of printing to tty, we do this instead: > > if (newbuf == nullptr) { > log(level, buf); > log(level, "(Truncated, native OOM."); > return; > } > instead? So this is basically trying to solve the same problem as "8256008: UL does not report anything if disk writing fails". :) How to log an error in logging. Your suggestion seems fine to me. David ----- > This would first print the truncated line, still in the static buffer, to the UL log - so we miss as little information as possible - followed by a truncation marker to show the reader that we truncated. > > (Alternatively we could stamp something like "..(truncated)" to the end of the static buffer and just print once). > > This proposal has one little beauty spot: in case the prefix did overflow the static buffer, we end up in line 124, and print the log line without prefix. I think that would be totally fine. The message content is more important than the prefix. Its a very rare case. But should that bother you, you could "dry print" at line 124: > > } else { > // Buffer too small. Just call printf to find out the length for realloc below. > // vv "dry-print" to find out length but dont change buffer content > ret = os::vsnprintf(NULL, 0, fmt, args); > } > > which would leave the buffer with the truncated prefix intact. > > (Side note, looking at logPrefix.hpp, I see that the code there asserts in case of buffer overflow. So why do we even handle it here. But since this is all templatized to oblivion I may be missing something). > > Thanks Thomas > > src/hotspot/share/logging/logTagSet.cpp line 129: > >> 127: if ((size_t)ret >= sizeof(buf)) { >> 128: size_t newbuf_len = prefix_len + ret + 1; >> 129: char* newbuf = (char*)::calloc(newbuf_len, sizeof(char)); > > Can you precede this with a little comment please: > `// We use raw ::malloc to prevent circularities` > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1246 > From coleenp at openjdk.java.net Wed Nov 18 12:55:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 18 Nov 2020 12:55:01 GMT Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 In-Reply-To: References: Message-ID: <--IwCB1yeJkwUCqgYH1Au_LckWptyGxuCIeQWcPy3uM=.589d3140-1e58-485f-8973-784227a23038@github.com> On Wed, 18 Nov 2020 03:26:41 GMT, Patricio Chilano Mateo wrote: > Hi all, > > Please review the following change to defer biased-locking obsoletion to 18, as discussed in [1]. > I updated the special_jvm_flags table and re-enabled gtest verify_special_flags. > > Thanks, > Patricio > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/045454.html Looks good. Amazing how many product options there are. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1281 From coleenp at openjdk.java.net Wed Nov 18 12:55:04 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 18 Nov 2020 12:55:04 GMT Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 In-Reply-To: <2H-j63k_Z2htPepW0aiaBGRY9QWAGFW2bBY83W3iKZU=.8bad4c22-b231-4e9f-87a0-42555162b943@github.com> References: <2H-j63k_Z2htPepW0aiaBGRY9QWAGFW2bBY83W3iKZU=.8bad4c22-b231-4e9f-87a0-42555162b943@github.com> Message-ID: On Wed, 18 Nov 2020 04:42:03 GMT, David Holmes wrote: >> Hi all, >> >> Please review the following change to defer biased-locking obsoletion to 18, as discussed in [1]. >> I updated the special_jvm_flags table and re-enabled gtest verify_special_flags. >> >> Thanks, >> Patricio >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/045454.html > > src/hotspot/share/runtime/arguments.cpp line 532: > >> 530: { "UseOptoBiasInlining", JDK_Version::jdk(15), JDK_Version::jdk(18), JDK_Version::jdk(19) }, >> 531: { "PrintPreciseBiasedLockingStatistics", JDK_Version::jdk(15), JDK_Version::jdk(18), JDK_Version::jdk(19) }, >> 532: { "CriticalJNINatives", JDK_Version::jdk(16), JDK_Version::jdk(17), JDK_Version::jdk(18) }, > > To maintain the table ordering this entry needs to move above the BL entries now. So these are ordered by the second field? ------------- PR: https://git.openjdk.java.net/jdk/pull/1281 From neliasso at openjdk.java.net Wed Nov 18 12:55:10 2020 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Wed, 18 Nov 2020 12:55:10 GMT Subject: RFR: 8256552: Let ReplayCompiles set UseDebuggerErgo Message-ID: When replaying compiles a lot of unnecessary threads are started. The new excellent UseDebuggerErgo flag is a perfect match for replay. ------------- Commit messages: - ReplayCompiles sets UseDebuggerErgo Changes: https://git.openjdk.java.net/jdk/pull/1289/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1289&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256552 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1289/head:pull/1289 PR: https://git.openjdk.java.net/jdk/pull/1289 From coleenp at openjdk.java.net Wed Nov 18 12:58:04 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 18 Nov 2020 12:58:04 GMT Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 In-Reply-To: <--IwCB1yeJkwUCqgYH1Au_LckWptyGxuCIeQWcPy3uM=.589d3140-1e58-485f-8973-784227a23038@github.com> References: <--IwCB1yeJkwUCqgYH1Au_LckWptyGxuCIeQWcPy3uM=.589d3140-1e58-485f-8973-784227a23038@github.com> Message-ID: On Wed, 18 Nov 2020 12:52:08 GMT, Coleen Phillimore wrote: >> Hi all, >> >> Please review the following change to defer biased-locking obsoletion to 18, as discussed in [1]. >> I updated the special_jvm_flags table and re-enabled gtest verify_special_flags. >> >> Thanks, >> Patricio >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/045454.html > > Looks good. Amazing how many product options there are. I have an alternate idea. I wonder if for LTS we should remove the BiasedLocking other options as planned, and leave the main option in place until JDK 18. Then we wouldn't have to test and support the variations of the code that the other options turn on and off. ------------- PR: https://git.openjdk.java.net/jdk/pull/1281 From david.holmes at oracle.com Wed Nov 18 13:17:25 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Nov 2020 23:17:25 +1000 Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 In-Reply-To: References: <2H-j63k_Z2htPepW0aiaBGRY9QWAGFW2bBY83W3iKZU=.8bad4c22-b231-4e9f-87a0-42555162b943@github.com> Message-ID: On 18/11/2020 10:55 pm, Coleen Phillimore wrote: > On Wed, 18 Nov 2020 04:42:03 GMT, David Holmes wrote: > >>> Hi all, >>> >>> Please review the following change to defer biased-locking obsoletion to 18, as discussed in [1]. >>> I updated the special_jvm_flags table and re-enabled gtest verify_special_flags. >>> >>> Thanks, >>> Patricio >>> >>> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/045454.html >> >> src/hotspot/share/runtime/arguments.cpp line 532: >> >>> 530: { "UseOptoBiasInlining", JDK_Version::jdk(15), JDK_Version::jdk(18), JDK_Version::jdk(19) }, >>> 531: { "PrintPreciseBiasedLockingStatistics", JDK_Version::jdk(15), JDK_Version::jdk(18), JDK_Version::jdk(19) }, >>> 532: { "CriticalJNINatives", JDK_Version::jdk(16), JDK_Version::jdk(17), JDK_Version::jdk(18) }, >> >> To maintain the table ordering this entry needs to move above the BL entries now. > > So these are ordered by the second field? Yes. // -------------- Deprecated Flags -------------- // --- Non-alias flags - sorted by obsolete_in then expired_in: David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1281 > From kim.barrett at oracle.com Wed Nov 18 13:21:14 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 18 Nov 2020 08:21:14 -0500 Subject: RFR: 8256256: UL should not use heap allocation for output string [v2] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: <1F0A0FA0-0FE0-47F2-92D4-B4B9DDA04EDB@oracle.com> > On Nov 17, 2020, at 11:32 PM, Yumin Qi wrote: > >> Hi, Please review >> Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. >> >> Tests: tier1,tier4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Use malloc/free for large log message buffer A drive-by comment rather than a review. An approach to this sort of problem that I've used in the past is something like: Assuming that logging while logging is fairly rare, and that most threads don't ever generate "large" log messages. Thread local free_log_buffer, initially null. When need a log buffer, first check free_log_buffer. If non-null, take it, setting free_log_buffer to null. If, while using a log buffer, run out of space, allocate a new one, copy, and free the old one. When done with a log buffer, first check free_log_buffer. If it's null, record the done-with log buffer there. If it's not null, record the larger of the existing value and the done-with buffer there and free the other. So each thread has a local high-water sized log buffer. This can be layered on with a relatively small stack buffer that usually gets used, with the allocated buffer only used when needed. Most threads never need it. From david.holmes at oracle.com Wed Nov 18 13:25:43 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Nov 2020 23:25:43 +1000 Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 In-Reply-To: References: <--IwCB1yeJkwUCqgYH1Au_LckWptyGxuCIeQWcPy3uM=.589d3140-1e58-485f-8973-784227a23038@github.com> Message-ID: On 18/11/2020 10:58 pm, Coleen Phillimore wrote: > On Wed, 18 Nov 2020 12:52:08 GMT, Coleen Phillimore wrote: > >>> Hi all, >>> >>> Please review the following change to defer biased-locking obsoletion to 18, as discussed in [1]. >>> I updated the special_jvm_flags table and re-enabled gtest verify_special_flags. >>> >>> Thanks, >>> Patricio >>> >>> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/045454.html >> >> Looks good. Amazing how many product options there are. > > I have an alternate idea. I wonder if for LTS we should remove the BiasedLocking other options as planned, and leave the main option in place until JDK 18. Then we wouldn't have to test and support the variations of the code that the other options turn on and off. The plan is to leave the code all as-is for now so there is no impact at all on users. This is what has been discussed and agreed upon. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1281 > From kbarrett at openjdk.java.net Wed Nov 18 13:37:10 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 18 Nov 2020 13:37:10 GMT Subject: RFR: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor [v4] In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 22:35:20 GMT, David Holmes wrote: >> This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. >> >> On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. >> >> Testing: >> - GH actions >> - mach5 tiers 1-3 >> - selected performance testing (guided by that used for JDK-8253064) >> >> Thanks, >> David > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Update power_of_2 static assertion placement. > - Merge branch 'master' into 8225631 > - Move static_assert as requested by Kim. > - Merge branch 'master' into 8225631 > - Feedback from Coleen, Kim and Dan. > - 8225631: Consider replacing muxAcquire/Release with PlatformMonitor Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1196 From stuefe at openjdk.java.net Wed Nov 18 13:38:07 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 18 Nov 2020 13:38:07 GMT Subject: RFR: JDK-8255885: Metaspace: freelist commit counter is not updated when purging In-Reply-To: References: Message-ID: <1WCU0u8P_aVHMDlRhxmR0qMqFJRCvMhDQnCKNXX1Uog=.10637883-442d-4565-996f-b20937e08116@github.com> On Wed, 4 Nov 2020 14:32:44 GMT, Thomas Stuefe wrote: > Metaspace chunks are uncommitted, under certain conditions, when being returned to the Metaspace by a dying class loader. > > There are two places where this happens: > 1) when individual chunks are returned (see ChunkManager::return_chunk_locked()) > 2) later, when CLDG::purge()->Metaspace::purge()->ChunkManager::purge() is called - all free chunks are again checked and potentially uncommitted. > > Free chunks are kept in FreeChunkList. FreeChunkList has a counter for words-comitted. That counter gets updated when chunks are added and removed. However, path (2) does not change the list, it just uncommits chunks residing in that list. That passes under the FreeChunkList's radar and now the counter is off. > > ----- > > Review note: `ChunkManager` keeps free chunks. It has an instance of `FreeChunkListVector`, which has a series (one per chunk size) of `FreeChunkList` instances. The commit counter value is handed up from `FreeChunkList` to, eventually, `ChunkManager`. > > What changed: > > - I removed the counter (_committed_word_size) from FreeChunkList. This seemed the simplest and safest measure. Keeping this counter up-to-date is a hassle, since chunks may get committed and uncommitted while being in this list. > > - Now we calculate the number of committed words on the fly if asked, by iterating all chunks in the list and accumulating. To reflect this change, I change the name of "FreeChunkList::committed_word_size()" to "FreeChunkList::calc_committed_word_size()". In metaspace, anything named "calc_" is potentially expensive. > > - Same renamings in FreeChunkListVector and ChunkManager::total_committed_word_size() - to ChunkManager::calc_committed_word_size() > > Now these functions always deliver the correct result. However, they are potentially slower and now require the central metaspace lock. That is not a problem: the only user of this function is when collecting the statistics for the "VM.metaspace" jcmd report, and that happens under lock protection and walks all kind of stuff anyway, so walking the freelists won't hurt. > > Just to be sure, I removed the use of these functions from ChunkManager::print_on(), even though that was just a debug function. > > ----- > > Tests: > > This patch has been tested in our nightlies for a week now. Tested in our systems for a week now on all platforms, no problems. ------------- PR: https://git.openjdk.java.net/jdk/pull/1057 From stuefe at openjdk.java.net Wed Nov 18 13:41:02 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 18 Nov 2020 13:41:02 GMT Subject: RFR: JDK-8255978: [windows] os::release_memory may not release the full range [v3] In-Reply-To: References: Message-ID: <8jREUPJM9q_uwo9unm1m4VMFQp_k5bkl5qmNvRiTQUc=.ff4d21df-6fd4-4d2c-b8cd-475a29951264@github.com> On Fri, 13 Nov 2020 06:16:50 GMT, Thomas Stuefe wrote: >>> LGTM. I am running on mach5 tiers 1-3 to make sure the new test cases don't have any surprises :-) >> >> mach5 tiers 1-3 finished with no failure. > > Great, thanks Ioi. > > May I please have a second review? This is tied to a P2 issue. Gentle ping. ------------- PR: https://git.openjdk.java.net/jdk/pull/1143 From coleen.phillimore at oracle.com Wed Nov 18 13:43:40 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Nov 2020 08:43:40 -0500 Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 In-Reply-To: References: <--IwCB1yeJkwUCqgYH1Au_LckWptyGxuCIeQWcPy3uM=.589d3140-1e58-485f-8973-784227a23038@github.com> Message-ID: On 11/18/20 8:25 AM, David Holmes wrote: > On 18/11/2020 10:58 pm, Coleen Phillimore wrote: >> On Wed, 18 Nov 2020 12:52:08 GMT, Coleen Phillimore >> wrote: >> >>>> Hi all, >>>> >>>> Please review the following change to defer biased-locking >>>> obsoletion to 18, as discussed in [1]. >>>> I updated the special_jvm_flags table and re-enabled gtest >>>> verify_special_flags. >>>> >>>> Thanks, >>>> Patricio >>>> >>>> [1] >>>> https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/045454.html >>> >>> Looks good.? Amazing how many product options there are. >> >> I have an alternate idea.? I wonder if for LTS we should remove the >> BiasedLocking other options as planned, and leave the main option in >> place until JDK 18.? Then we wouldn't have to test and support the >> variations of the code that the other options turn on and off. > > The plan is to leave the code all as-is for now so there is no impact > at all on users. This is what has been discussed and agreed upon. I know. This proposal is too late. Coleen > > Thanks, > David > >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/1281 >> From pchilanomate at openjdk.java.net Wed Nov 18 15:00:21 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 18 Nov 2020 15:00:21 GMT Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 [v2] In-Reply-To: References: Message-ID: > Hi all, > > Please review the following change to defer biased-locking obsoletion to 18, as discussed in [1]. > I updated the special_jvm_flags table and re-enabled gtest verify_special_flags. > > Thanks, > Patricio > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/045454.html Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: move CriticalJNINatives up in table ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1281/files - new: https://git.openjdk.java.net/jdk/pull/1281/files/b949dcd3..64e189c7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1281&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1281&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1281.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1281/head:pull/1281 PR: https://git.openjdk.java.net/jdk/pull/1281 From pchilanomate at openjdk.java.net Wed Nov 18 15:00:21 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 18 Nov 2020 15:00:21 GMT Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 [v2] In-Reply-To: <2H-j63k_Z2htPepW0aiaBGRY9QWAGFW2bBY83W3iKZU=.8bad4c22-b231-4e9f-87a0-42555162b943@github.com> References: <2H-j63k_Z2htPepW0aiaBGRY9QWAGFW2bBY83W3iKZU=.8bad4c22-b231-4e9f-87a0-42555162b943@github.com> Message-ID: On Wed, 18 Nov 2020 04:42:51 GMT, David Holmes wrote: > Hi Patricio, > > One minor issue - see below. > > Thanks, > David Hi David, Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1281 From pchilanomate at openjdk.java.net Wed Nov 18 15:00:21 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 18 Nov 2020 15:00:21 GMT Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 [v2] In-Reply-To: <--IwCB1yeJkwUCqgYH1Au_LckWptyGxuCIeQWcPy3uM=.589d3140-1e58-485f-8973-784227a23038@github.com> References: <--IwCB1yeJkwUCqgYH1Au_LckWptyGxuCIeQWcPy3uM=.589d3140-1e58-485f-8973-784227a23038@github.com> Message-ID: On Wed, 18 Nov 2020 12:52:08 GMT, Coleen Phillimore wrote: > Looks good. Amazing how many product options there are. Hi Coleen, Thanks for the review! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/1281 From pchilanomate at openjdk.java.net Wed Nov 18 15:00:22 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 18 Nov 2020 15:00:22 GMT Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 [v2] In-Reply-To: References: <2H-j63k_Z2htPepW0aiaBGRY9QWAGFW2bBY83W3iKZU=.8bad4c22-b231-4e9f-87a0-42555162b943@github.com> Message-ID: On Wed, 18 Nov 2020 12:50:43 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/arguments.cpp line 532: >> >>> 530: { "UseOptoBiasInlining", JDK_Version::jdk(15), JDK_Version::jdk(18), JDK_Version::jdk(19) }, >>> 531: { "PrintPreciseBiasedLockingStatistics", JDK_Version::jdk(15), JDK_Version::jdk(18), JDK_Version::jdk(19) }, >>> 532: { "CriticalJNINatives", JDK_Version::jdk(16), JDK_Version::jdk(17), JDK_Version::jdk(18) }, >> >> To maintain the table ordering this entry needs to move above the BL entries now. > > So these are ordered by the second field? Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1281 From dcubed at openjdk.java.net Wed Nov 18 15:08:02 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 15:08:02 GMT Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 15:00:21 GMT, Patricio Chilano Mateo wrote: >> Hi all, >> >> Please review the following change to defer biased-locking obsoletion to 18, as discussed in [1]. >> I updated the special_jvm_flags table and re-enabled gtest verify_special_flags. >> >> Thanks, >> Patricio >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/045454.html > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > move CriticalJNINatives up in table Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1281 From pchilanomate at openjdk.java.net Wed Nov 18 15:14:00 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 18 Nov 2020 15:14:00 GMT Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 [v2] In-Reply-To: References: Message-ID: <_LBvQhIyO5GT0iYdOj_fe9obV9zUWe9oixc4YYvzggY=.336ccb46-e991-46d8-a72e-b2a4b6f01c73@github.com> On Wed, 18 Nov 2020 15:05:02 GMT, Daniel D. Daugherty wrote: > Thumbs up. Thanks Dan! Patricio ------------- PR: https://git.openjdk.java.net/jdk/pull/1281 From dcubed at openjdk.java.net Wed Nov 18 16:02:01 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 16:02:01 GMT Subject: RFR: 8238174: migrate ObjectMonitor::_owner field away from C++ volatile semantics [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 02:32:44 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> @dholmes-ora CR - resolve David's comments. > > Marked as reviewed by dholmes (Reviewer). Ping! Looking for a second review... ------------- PR: https://git.openjdk.java.net/jdk/pull/1278 From mdoerr at openjdk.java.net Wed Nov 18 16:03:12 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 18 Nov 2020 16:03:12 GMT Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 15:00:21 GMT, Patricio Chilano Mateo wrote: >> Hi all, >> >> Please review the following change to defer biased-locking obsoletion to 18, as discussed in [1]. >> I updated the special_jvm_flags table and re-enabled gtest verify_special_flags. >> >> Thanks, >> Patricio >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/045454.html > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > move CriticalJNINatives up in table Thanks for doing this! ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1281 From thomas.stuefe at gmail.com Wed Nov 18 16:24:54 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Nov 2020 17:24:54 +0100 Subject: RFR: 8256256: UL should not use heap allocation for output string [v2] In-Reply-To: <1F0A0FA0-0FE0-47F2-92D4-B4B9DDA04EDB@oracle.com> References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> <1F0A0FA0-0FE0-47F2-92D4-B4B9DDA04EDB@oracle.com> Message-ID: On Wed, Nov 18, 2020 at 2:21 PM Kim Barrett wrote: > > On Nov 17, 2020, at 11:32 PM, Yumin Qi wrote: > > > >> Hi, Please review > >> Unified Logging uses 512 bytes buffer on stack for printing out > message, above that will allocate heap for extra space needed. This may > potentially may cause a circulation when we log the heap allocation and the > log message is over 512. The max logging buffer size now is increased to > 4096 and above that, output will be truncated. > >> > >> Tests: tier1,tier4 > > > > Yumin Qi has updated the pull request incrementally with one additional > commit since the last revision: > > > > Use malloc/free for large log message buffer > > A drive-by comment rather than a review. An approach to this sort of > problem that I've used in the past is something like: > > Assuming that logging while logging is fairly rare, and that most threads > don't ever generate "large" log messages. > > Thread local free_log_buffer, initially null. > > When need a log buffer, first check free_log_buffer. If non-null, take it, > setting free_log_buffer to null. > > If, while using a log buffer, run out of space, allocate a new one, copy, > and free the old one. > > When done with a log buffer, first check free_log_buffer. If it's null, > record the done-with log buffer there. If it's not null, record the larger > of the existing value and the done-with buffer there and free the other. > > So each thread has a local high-water sized log buffer. This can be > layered > on with a relatively small stack buffer that usually gets used, with the > allocated buffer only used when needed. Most threads never need it. > > That's not dumb :) Only counterpoint I see is that you never recover from spikes. The setting-to-null-and-compare-on-set handles recursive entry into logging? Here, we were less concerned with recursive entry into UL than with the logging system causing recursion in other subsystems. E.g. the logging system calling os::malloc while logging from under os::malloc. That had been the original problem (logging added to NMT). Cheers, Thomas From mdoerr at openjdk.java.net Wed Nov 18 16:46:08 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 18 Nov 2020 16:46:08 GMT Subject: RFR: 8238174: migrate ObjectMonitor::_owner field away from C++ volatile semantics [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 02:25:16 GMT, Daniel D. Daugherty wrote: >> Drop volatile from the ObjectMonitor::_owner field. Update all naked >> field loads to use the new owner_raw() accessor or the existing >> owner_is_DEFLATER_MARKER() accessor. >> >> Testing: Mach5 Tier1,2,3; only unrelated, known test failures. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora CR - resolve David's comments. LGTM ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1278 From dcubed at openjdk.java.net Wed Nov 18 16:51:01 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 16:51:01 GMT Subject: RFR: 8238174: migrate ObjectMonitor::_owner field away from C++ volatile semantics [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 16:43:17 GMT, Martin Doerr wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> @dholmes-ora CR - resolve David's comments. > > LGTM @TheRealMDoerr - Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1278 From dcubed at openjdk.java.net Wed Nov 18 16:51:02 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 16:51:02 GMT Subject: Integrated: 8238174: migrate ObjectMonitor::_owner field away from C++ volatile semantics In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 22:44:11 GMT, Daniel D. Daugherty wrote: > Drop volatile from the ObjectMonitor::_owner field. Update all naked > field loads to use the new owner_raw() accessor or the existing > owner_is_DEFLATER_MARKER() accessor. > > Testing: Mach5 Tier1,2,3; only unrelated, known test failures. This pull request has now been integrated. Changeset: 1707d5ca Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/1707d5ca Stats: 48 lines in 4 files changed: 6 ins; 0 del; 42 mod 8238174: migrate ObjectMonitor::_owner field away from C++ volatile semantics Reviewed-by: dholmes, mdoerr ------------- PR: https://git.openjdk.java.net/jdk/pull/1278 From dcubed at openjdk.java.net Wed Nov 18 17:07:08 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 17:07:08 GMT Subject: RFR: 8256565: ProblemList jdk/jfr/api/recording/event/TestReEnableName.java on windows Message-ID: <7uSm5PdHUH_Hd_mR_pnOD_CNEncMfp0iyyfV0GtFqUY=.e977769b-11b5-435f-afa5-4dfdc0b831c3@github.com> This is a trivial fix to ProblemList jdk/jfr/api/recording/event/TestReEnableName.java on windows. ------------- Commit messages: - 8256565: ProblemList jdk/jfr/api/recording/event/TestReEnableName.java on windows Changes: https://git.openjdk.java.net/jdk/pull/1295/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1295&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256565 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1295.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1295/head:pull/1295 PR: https://git.openjdk.java.net/jdk/pull/1295 From egahlin at openjdk.java.net Wed Nov 18 17:07:08 2020 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 18 Nov 2020 17:07:08 GMT Subject: RFR: 8256565: ProblemList jdk/jfr/api/recording/event/TestReEnableName.java on windows In-Reply-To: <7uSm5PdHUH_Hd_mR_pnOD_CNEncMfp0iyyfV0GtFqUY=.e977769b-11b5-435f-afa5-4dfdc0b831c3@github.com> References: <7uSm5PdHUH_Hd_mR_pnOD_CNEncMfp0iyyfV0GtFqUY=.e977769b-11b5-435f-afa5-4dfdc0b831c3@github.com> Message-ID: <0sdK0PkqTX4gIkR06_HIaNJNReuMsD9PrMUocdNUv0k=.6d04f649-a0c7-4817-b0a1-26aea2b88679@github.com> On Wed, 18 Nov 2020 16:59:31 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList jdk/jfr/api/recording/event/TestReEnableName.java on windows. Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1295 From dcubed at openjdk.java.net Wed Nov 18 17:20:06 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 17:20:06 GMT Subject: RFR: 8256565: ProblemList jdk/jfr/api/recording/event/TestReEnableName.java on windows In-Reply-To: <0sdK0PkqTX4gIkR06_HIaNJNReuMsD9PrMUocdNUv0k=.6d04f649-a0c7-4817-b0a1-26aea2b88679@github.com> References: <7uSm5PdHUH_Hd_mR_pnOD_CNEncMfp0iyyfV0GtFqUY=.e977769b-11b5-435f-afa5-4dfdc0b831c3@github.com> <0sdK0PkqTX4gIkR06_HIaNJNReuMsD9PrMUocdNUv0k=.6d04f649-a0c7-4817-b0a1-26aea2b88679@github.com> Message-ID: <0e3F0usZinBd3PX_f9_hoK3uFdACTca4jkIfPwsEGSU=.9381d1ec-fb65-4cdd-af2b-5ca318544d3e@github.com> On Wed, 18 Nov 2020 17:04:05 GMT, Erik Gahlin wrote: >> This is a trivial fix to ProblemList jdk/jfr/api/recording/event/TestReEnableName.java on windows. > > Marked as reviewed by egahlin (Reviewer). @egahlin - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1295 From dcubed at openjdk.java.net Wed Nov 18 17:20:08 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 17:20:08 GMT Subject: Integrated: 8256565: ProblemList jdk/jfr/api/recording/event/TestReEnableName.java on windows In-Reply-To: <7uSm5PdHUH_Hd_mR_pnOD_CNEncMfp0iyyfV0GtFqUY=.e977769b-11b5-435f-afa5-4dfdc0b831c3@github.com> References: <7uSm5PdHUH_Hd_mR_pnOD_CNEncMfp0iyyfV0GtFqUY=.e977769b-11b5-435f-afa5-4dfdc0b831c3@github.com> Message-ID: On Wed, 18 Nov 2020 16:59:31 GMT, Daniel D. Daugherty wrote: > This is a trivial fix to ProblemList jdk/jfr/api/recording/event/TestReEnableName.java on windows. This pull request has now been integrated. Changeset: 33d3918e Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/33d3918e Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8256565: ProblemList jdk/jfr/api/recording/event/TestReEnableName.java on windows Reviewed-by: egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/1295 From dcubed at openjdk.java.net Wed Nov 18 17:40:11 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 17:40:11 GMT Subject: RFR: 8256567: ProblemList java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java for Xcomp testing Message-ID: <1b6N3fJAqTuO1F78o8eGTl53rQMDwErM4LOmDp6iQCA=.b03e719f-bcde-4be9-afef-1b4533f500d7@github.com> A trivial fix to ProblemList java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java for Xcomp testing. ------------- Commit messages: - 8256567: ProblemList java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java for Xcomp testing Changes: https://git.openjdk.java.net/jdk/pull/1297/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1297&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256567 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1297.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1297/head:pull/1297 PR: https://git.openjdk.java.net/jdk/pull/1297 From dcubed at openjdk.java.net Wed Nov 18 17:40:12 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 17:40:12 GMT Subject: RFR: 8256567: ProblemList java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java for Xcomp testing In-Reply-To: <1b6N3fJAqTuO1F78o8eGTl53rQMDwErM4LOmDp6iQCA=.b03e719f-bcde-4be9-afef-1b4533f500d7@github.com> References: <1b6N3fJAqTuO1F78o8eGTl53rQMDwErM4LOmDp6iQCA=.b03e719f-bcde-4be9-afef-1b4533f500d7@github.com> Message-ID: On Wed, 18 Nov 2020 17:33:23 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java for Xcomp testing. @mcimadamore and Vladimir Ivanov, this ProblemListing should interest you folks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1297 From mcimadamore at openjdk.java.net Wed Nov 18 17:55:00 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 18 Nov 2020 17:55:00 GMT Subject: RFR: 8256567: ProblemList java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java for Xcomp testing In-Reply-To: <1b6N3fJAqTuO1F78o8eGTl53rQMDwErM4LOmDp6iQCA=.b03e719f-bcde-4be9-afef-1b4533f500d7@github.com> References: <1b6N3fJAqTuO1F78o8eGTl53rQMDwErM4LOmDp6iQCA=.b03e719f-bcde-4be9-afef-1b4533f500d7@github.com> Message-ID: <3KSak6Y3nJsdiueB19VdzgY-ZKZ0iC2ZPFAC59r8OGE=.1a42f488-8d4c-4249-a61d-ad0ab6396c6e@github.com> On Wed, 18 Nov 2020 17:33:23 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java for Xcomp testing. Looks good to me - we discovered some deep issues involving var handles which were only accidentally triggered by the recent Foreign Memory Access push. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1297 From pchilanomate at openjdk.java.net Wed Nov 18 17:57:06 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 18 Nov 2020 17:57:06 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 03:57:15 GMT, David Holmes wrote: >> I'll wait until you push and then I'll merge. I still have to check the owner here though, because if the thread already owns the lock, calling check_rank() from try_lock will do the wrong check (it will assume it's being called from wait()). An alternative would be to add a boolean parameter to check_rank(), set only from try_lock() so I can differentiate the two calls. > > I think a different refactoring will be needed here so that: > try_lock() -> try_lock_inner(true); > try_lock_without_rank_check() -> try_lock_inner(false); > try_lock_inner(bool check_rank) { ... } > That way code duplication is minimised. How about just: bool Mutex::try_lock() { Thread * const self = Thread::current(); DEBUG_ONLY(if (!owned_by_self()) check_rank();) return try_lock_inner(self); } keeping try_lock_without_rank_check() as is. Then I can merge try_lock_inner() with your patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From dcubed at openjdk.java.net Wed Nov 18 18:06:06 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 18:06:06 GMT Subject: Integrated: 8256567: ProblemList java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java for Xcomp testing In-Reply-To: <1b6N3fJAqTuO1F78o8eGTl53rQMDwErM4LOmDp6iQCA=.b03e719f-bcde-4be9-afef-1b4533f500d7@github.com> References: <1b6N3fJAqTuO1F78o8eGTl53rQMDwErM4LOmDp6iQCA=.b03e719f-bcde-4be9-afef-1b4533f500d7@github.com> Message-ID: On Wed, 18 Nov 2020 17:33:23 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java for Xcomp testing. This pull request has now been integrated. Changeset: c9c15733 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/c9c15733 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8256567: ProblemList java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java for Xcomp testing Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/1297 From dcubed at openjdk.java.net Wed Nov 18 18:06:05 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 18 Nov 2020 18:06:05 GMT Subject: RFR: 8256567: ProblemList java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java for Xcomp testing In-Reply-To: <3KSak6Y3nJsdiueB19VdzgY-ZKZ0iC2ZPFAC59r8OGE=.1a42f488-8d4c-4249-a61d-ad0ab6396c6e@github.com> References: <1b6N3fJAqTuO1F78o8eGTl53rQMDwErM4LOmDp6iQCA=.b03e719f-bcde-4be9-afef-1b4533f500d7@github.com> <3KSak6Y3nJsdiueB19VdzgY-ZKZ0iC2ZPFAC59r8OGE=.1a42f488-8d4c-4249-a61d-ad0ab6396c6e@github.com> Message-ID: On Wed, 18 Nov 2020 17:52:31 GMT, Maurizio Cimadamore wrote: >> A trivial fix to ProblemList java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTest.java for Xcomp testing. > > Looks good to me - we discovered some deep issues involving var handles which were only accidentally triggered by the recent Foreign Memory Access push. @mcimadamore - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1297 From iklam at openjdk.java.net Wed Nov 18 18:12:15 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 18 Nov 2020 18:12:15 GMT Subject: RFR: 8256172: Clean up CDS handling of i2i_entry [v2] In-Reply-To: References: Message-ID: > This PR is a prerequisite for [JDK-8250989](https://bugs.openjdk.java.net/browse/JDK-8250989) - Consolidate buffer allocation code for CDS static/dynamic archive dumping. > > - Move the allocation of the i2i buffer after all classes are loaded. This makes it possible to estimate the size of the CDS archive before we allocate the output space (this is what dynamic archive does now). > - No need to generate the i2i trampoline code during -Xshare:dump > - Clean up the CDS code in abstractInterpreter.cpp and add more comments. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - fixed merge - Merge branch 'master' into 8256172-cleanup-cds-i2i-entry - 8256172: Clean up CDS handling of i2i_entry ------------- Changes: https://git.openjdk.java.net/jdk/pull/1280/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1280&range=01 Stats: 85 lines in 8 files changed: 24 ins; 40 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/1280.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1280/head:pull/1280 PR: https://git.openjdk.java.net/jdk/pull/1280 From minqi at openjdk.java.net Wed Nov 18 18:30:03 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 18 Nov 2020 18:30:03 GMT Subject: RFR: 8256172: Clean up CDS handling of i2i_entry [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 18:12:15 GMT, Ioi Lam wrote: >> This PR is a prerequisite for [JDK-8250989](https://bugs.openjdk.java.net/browse/JDK-8250989) - Consolidate buffer allocation code for CDS static/dynamic archive dumping. >> >> - Move the allocation of the i2i buffer after all classes are loaded. This makes it possible to estimate the size of the CDS archive before we allocate the output space (this is what dynamic archive does now). >> - No need to generate the i2i trampoline code during -Xshare:dump >> - Clean up the CDS code in abstractInterpreter.cpp and add more comments. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - fixed merge > - Merge branch 'master' into 8256172-cleanup-cds-i2i-entry > - 8256172: Clean up CDS handling of i2i_entry Look good to me. src/hotspot/share/memory/metaspaceShared.cpp line 513: > 511: // We don't want any valid object to be at the very bottom of the archive. > 512: // See ArchivePtrMarker::mark_pointer(). > 513: MetaspaceShared::misc_code_space_alloc(16); 16 looks arbitrary number though we know it is minimal object alignment --- maybe we we can use object_alignment instead? up to you. ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1280 From minqi at openjdk.java.net Wed Nov 18 18:33:07 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 18 Nov 2020 18:33:07 GMT Subject: RFR: JDK-8255978: [windows] os::release_memory may not release the full range [v3] In-Reply-To: References: Message-ID: <5ioRg09FNXA-66x79xRn9xomGiGG46vqmo8Gv2oK4Lw=.3d3eb950-aeba-4fad-a5e1-281870b2df25@github.com> On Tue, 17 Nov 2020 07:15:11 GMT, Thomas Stuefe wrote: >> On Windows, os::release_memory(p,size) may not actually release the whole region if it contains multiple mappings. This may cause memory bloat or runaway leaks or errors which look like failed mappings to specific wish addresses. >> >> Background: >> >> On Windows, memory mappings are established with VirtualAlloc() [1] and released with VirtualFree() [2]. In constrast to POSIX munmap(), VirtualFree() can only release a single full range established with VirtualAlloc(). It cannot release multiple ranges, or parts of a range. >> >> The Windows implementation of os::release_memory(p, size) [3] calls VirtualFree(p, NULL, MEM_RELEASE) - it ignores the size parameter and releases whatever mapping happens to start at p: >> >> bool os::pd_release_memory(char* addr, size_t bytes) { >> return VirtualFree(addr, 0, MEM_RELEASE) != 0; >> } >> >> ... which assumes that the given range size corresponds to the size of a mapping starting at p. >> >> This may be incorrect: >> >> 1) For NUMA-friendly allocation, we allocate memory in stripes, each stripe individually allocated. >> 2) For +UseLargePagesIndividualAllocation we do the same >> 3) apart from that, the given region size may just be wrong. Since we never check these, we may never have noticed. I am currently running tests to find out if we have other mismatched releases. >> >> For cases (1) and (2), we would just release the first stripe in that striped range, leaving the rest of the mappings intact. This is not immediately noticeable, since VirtualFree() returns success. And even if it did not, we usually ignore the return code of os::release_memory(). >> >> The problem is aggrevated since, on Windows, we often employ an "optimistically-release-and-remap" approach: since mappings are undivisible, if one wants to change their size, split them or similar, one has to follow this sequence: >> >> a) release old allocation >> b) place into the now vacated address room one or more new allocations >> >> This is not guaranteed to work, since between (a) and (b) someone may have grabbed the address space. We live with that since there is no way to do this differently. >> >> When used on a range which contains multiple mappings, this technique is almost guaranteed to fail. In that case, (a) would only release the first mapping in the range. (b) would almost certainly fail since most of the original range would still be mapped. >> >> Examples of these technique in os_windows.cpp: >> - os::split_reseved_memory() (see also [4]) >> - map_or_reserve_memory_aligned() >> - os::replace_existing_mapping_with_file_mapping() >> >> This can manifest as small memory leak or inability to attach to a given wish address. It could also result in a viscous loop ([5], [6]) and result in ballooning and native OOMs. >> >> -- >> >> AFAICS this is an old issue, dating back to at least jdk 8. >> >> -- >> >> The change in detail: >> >> - os::release_memory() on Window now: >> - in LP/NUMA case we unmap all mappings in the given range. The mappings must match the range exactly, otherwise we assert. >> - In normal case we just check the given range and assert if it does not match. >> Note: in release builds I just print a warning and return false. Should this be a guarantee? I leave that up to the Reviewers. >> >> - Added gtests which test os::release_memory() with a variety of scenarios. Includes both positive and negative tests. The latter includes a death test for debug. >> >> - Added a helper function to find mappings, for now windows only (os::win32::find_mapping()), including gtests for that function. >> >> - Added a function to print mappings, for diagnostic purposes: os::print_memory_mappings(). Provided an implementation for linux and windows. >> >> >> -- >> [1] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc >> [2] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualfree >> [3] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3394 >> [4] https://bugs.openjdk.java.net/browse/JDK-8253649 >> [5] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3150 >> [6] https://bugs.openjdk.java.net/browse/JDK-8255954 > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge > - Merge > - Initial test/hotspot/gtest/runtime/test_os.cpp line 353: > 351: // Test that os::release_memory() can deal with areas containing multiple mappings. > 352: #define PRINT_MAPPINGS(s) { tty->print_cr("%s", s); os::print_memory_mappings((char*)p, total_range_len, tty); } > 353: //#define PRINT_MAPPINGS Can this comment be removed? ------------- PR: https://git.openjdk.java.net/jdk/pull/1143 From minqi at openjdk.java.net Wed Nov 18 18:43:04 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 18 Nov 2020 18:43:04 GMT Subject: RFR: JDK-8255978: [windows] os::release_memory may not release the full range [v3] In-Reply-To: References: Message-ID: <6fVIcmERi7BPUAHVESL0DG_XoPpv-r6FxNrXUFGk_qQ=.42db9e76-f2d4-4ca8-b538-d279851db37a@github.com> On Tue, 17 Nov 2020 07:15:11 GMT, Thomas Stuefe wrote: >> On Windows, os::release_memory(p,size) may not actually release the whole region if it contains multiple mappings. This may cause memory bloat or runaway leaks or errors which look like failed mappings to specific wish addresses. >> >> Background: >> >> On Windows, memory mappings are established with VirtualAlloc() [1] and released with VirtualFree() [2]. In constrast to POSIX munmap(), VirtualFree() can only release a single full range established with VirtualAlloc(). It cannot release multiple ranges, or parts of a range. >> >> The Windows implementation of os::release_memory(p, size) [3] calls VirtualFree(p, NULL, MEM_RELEASE) - it ignores the size parameter and releases whatever mapping happens to start at p: >> >> bool os::pd_release_memory(char* addr, size_t bytes) { >> return VirtualFree(addr, 0, MEM_RELEASE) != 0; >> } >> >> ... which assumes that the given range size corresponds to the size of a mapping starting at p. >> >> This may be incorrect: >> >> 1) For NUMA-friendly allocation, we allocate memory in stripes, each stripe individually allocated. >> 2) For +UseLargePagesIndividualAllocation we do the same >> 3) apart from that, the given region size may just be wrong. Since we never check these, we may never have noticed. I am currently running tests to find out if we have other mismatched releases. >> >> For cases (1) and (2), we would just release the first stripe in that striped range, leaving the rest of the mappings intact. This is not immediately noticeable, since VirtualFree() returns success. And even if it did not, we usually ignore the return code of os::release_memory(). >> >> The problem is aggrevated since, on Windows, we often employ an "optimistically-release-and-remap" approach: since mappings are undivisible, if one wants to change their size, split them or similar, one has to follow this sequence: >> >> a) release old allocation >> b) place into the now vacated address room one or more new allocations >> >> This is not guaranteed to work, since between (a) and (b) someone may have grabbed the address space. We live with that since there is no way to do this differently. >> >> When used on a range which contains multiple mappings, this technique is almost guaranteed to fail. In that case, (a) would only release the first mapping in the range. (b) would almost certainly fail since most of the original range would still be mapped. >> >> Examples of these technique in os_windows.cpp: >> - os::split_reseved_memory() (see also [4]) >> - map_or_reserve_memory_aligned() >> - os::replace_existing_mapping_with_file_mapping() >> >> This can manifest as small memory leak or inability to attach to a given wish address. It could also result in a viscous loop ([5], [6]) and result in ballooning and native OOMs. >> >> -- >> >> AFAICS this is an old issue, dating back to at least jdk 8. >> >> -- >> >> The change in detail: >> >> - os::release_memory() on Window now: >> - in LP/NUMA case we unmap all mappings in the given range. The mappings must match the range exactly, otherwise we assert. >> - In normal case we just check the given range and assert if it does not match. >> Note: in release builds I just print a warning and return false. Should this be a guarantee? I leave that up to the Reviewers. >> >> - Added gtests which test os::release_memory() with a variety of scenarios. Includes both positive and negative tests. The latter includes a death test for debug. >> >> - Added a helper function to find mappings, for now windows only (os::win32::find_mapping()), including gtests for that function. >> >> - Added a function to print mappings, for diagnostic purposes: os::print_memory_mappings(). Provided an implementation for linux and windows. >> >> >> -- >> [1] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc >> [2] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualfree >> [3] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3394 >> [4] https://bugs.openjdk.java.net/browse/JDK-8253649 >> [5] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3150 >> [6] https://bugs.openjdk.java.net/browse/JDK-8255954 > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge > - Merge > - Initial LGTM, very nice test case, thanks! ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1143 From ccheung at openjdk.java.net Wed Nov 18 18:46:03 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 18 Nov 2020 18:46:03 GMT Subject: RFR: 8256172: Clean up CDS handling of i2i_entry [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 18:12:15 GMT, Ioi Lam wrote: >> This PR is a prerequisite for [JDK-8250989](https://bugs.openjdk.java.net/browse/JDK-8250989) - Consolidate buffer allocation code for CDS static/dynamic archive dumping. >> >> - Move the allocation of the i2i buffer after all classes are loaded. This makes it possible to estimate the size of the CDS archive before we allocate the output space (this is what dynamic archive does now). >> - No need to generate the i2i trampoline code during -Xshare:dump >> - Clean up the CDS code in abstractInterpreter.cpp and add more comments. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - fixed merge > - Merge branch 'master' into 8256172-cleanup-cds-i2i-entry > - 8256172: Clean up CDS handling of i2i_entry Cleanup looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1280 From stuefe at openjdk.java.net Wed Nov 18 18:49:03 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 18 Nov 2020 18:49:03 GMT Subject: RFR: JDK-8255978: [windows] os::release_memory may not release the full range [v3] In-Reply-To: <6fVIcmERi7BPUAHVESL0DG_XoPpv-r6FxNrXUFGk_qQ=.42db9e76-f2d4-4ca8-b538-d279851db37a@github.com> References: <6fVIcmERi7BPUAHVESL0DG_XoPpv-r6FxNrXUFGk_qQ=.42db9e76-f2d4-4ca8-b538-d279851db37a@github.com> Message-ID: On Wed, 18 Nov 2020 18:40:29 GMT, Yumin Qi wrote: > LGTM, very nice test case, thanks! Thanks a lot Yumin! I'll change the comment before pushing. I'd like to leave that printing stuff in, but will disable it by default. That way we can switch it on when needed to look what is going on. ------------- PR: https://git.openjdk.java.net/jdk/pull/1143 From dholmes at openjdk.java.net Wed Nov 18 22:49:03 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 Nov 2020 22:49:03 GMT Subject: Integrated: 8225631: Consider replacing muxAcquire/Release with PlatformMonitor In-Reply-To: References: Message-ID: On Fri, 13 Nov 2020 00:51:02 GMT, David Holmes wrote: > This RFE was filed a while ago to see if we could get rid of `muxAcquire/release` to reduce overall code complexity. Initially some usages seemed to suffer some slight performance loss when I tried this. However, since then all but one usage have been removed and the final case, the `gInflationLock`'s in `ObjectSynchronizer read_stable_mark` does not suffer any performance degradation. It can also use `PlatformMutex` rather than `PlatformMonitor`. > > On the plus side we remove a large chunk of complex synchronization code, we delete a `ParkEvent` per thread, and an int field per `ParkEvent` - which is good for footprint. > > Testing: > - GH actions > - mach5 tiers 1-3 > - selected performance testing (guided by that used for JDK-8253064) > > Thanks, > David This pull request has now been integrated. Changeset: 99eac535 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/99eac535 Stats: 195 lines in 6 files changed: 12 ins; 169 del; 14 mod 8225631: Consider replacing muxAcquire/Release with PlatformMonitor Reviewed-by: coleenp, dcubed, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/1196 From dholmes at openjdk.java.net Wed Nov 18 22:52:05 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 Nov 2020 22:52:05 GMT Subject: Integrated: 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix In-Reply-To: References: Message-ID: <7J_AhDfLUojngGFAT1lTOeDXQEnoMMFJ3SDxLC0NP8w=.efaa086b-4e47-49ff-a513-c6301ff84e94@github.com> On Tue, 17 Nov 2020 05:41:44 GMT, David Holmes wrote: > Mutex::try_lock has to allow for the possibility that the PlatformMutex::try_lock allows recursive locking. > > Added additional commentary on the semantics provided by Mutex and the PlatformMutex classes. > > Testing: GHA, mach5 tiers 1-3 This pull request has now been integrated. Changeset: 2b155713 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/2b155713 Stats: 18 lines in 4 files changed: 14 ins; 1 del; 3 mod 8256383: PlatformMutex::try_lock has different semantics on Windows and Posix Reviewed-by: stuefe, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/1247 From dholmes at openjdk.java.net Wed Nov 18 22:56:03 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 Nov 2020 22:56:03 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 17:54:11 GMT, Patricio Chilano Mateo wrote: >> I think a different refactoring will be needed here so that: >> try_lock() -> try_lock_inner(true); >> try_lock_without_rank_check() -> try_lock_inner(false); >> try_lock_inner(bool check_rank) { ... } >> That way code duplication is minimised. > > How about just: > bool Mutex::try_lock() { > Thread * const self = Thread::current(); > DEBUG_ONLY(if (!owned_by_self()) check_rank(self);) > return try_lock_inner(self); > } > keeping try_lock_without_rank_check() as is. Then I can merge try_lock_inner() with your patch. If the existing try_lock become try_lock_inner then you are duplicating the owner check. My suggestion minimises code duplication allowing both try_lock and try_lock_without_rank_check to just be simple inline definitions. My changes just integrated so you can merge now. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From iklam at openjdk.java.net Wed Nov 18 23:29:06 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 18 Nov 2020 23:29:06 GMT Subject: RFR: 8256172: Clean up CDS handling of i2i_entry [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 18:26:44 GMT, Yumin Qi wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - fixed merge >> - Merge branch 'master' into 8256172-cleanup-cds-i2i-entry >> - 8256172: Clean up CDS handling of i2i_entry > > src/hotspot/share/memory/metaspaceShared.cpp line 513: > >> 511: // We don't want any valid object to be at the very bottom of the archive. >> 512: // See ArchivePtrMarker::mark_pointer(). >> 513: MetaspaceShared::misc_code_space_alloc(16); > > 16 looks arbitrary number though we know it is minimal object alignment --- maybe we we can use object_alignment instead? up to you. `16` is just an arbitrary small number. `MetaspaceShared::misc_code_space_alloc(16)` will round up the size to the appropriate alignment. So I think I'll keep the existing code. ------------- PR: https://git.openjdk.java.net/jdk/pull/1280 From suenaga at oss.nttdata.com Thu Nov 19 00:26:34 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 19 Nov 2020 09:26:34 +0900 Subject: PING: RFR: 8256178: Add RAII object for file lock In-Reply-To: References: Message-ID: <1c8684c8-11c4-1249-9223-e065aab59282@oss.nttdata.com> PING: Could you review it? > PR: https://git.openjdk.java.net/jdk/pull/1156 Yasumasa On 2020/11/11 16:17, Yasumasa Suenaga wrote: > This PR is subtask of [JDK-8256008](https://bugs.openjdk.java.net/browse/JDK-8256008) (#1106) > > `LogFileStreamOutput::write()` uses `os::flockfile()` and `os::funlockfile()` to serialize write ops. It is better to use RAII because we can ensure `os::funlockfile()` call. > > ------------- > > Commit messages: > - Add RAII object for file lock > > Changes: https://git.openjdk.java.net/jdk/pull/1156/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1156&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8256178 > Stats: 17 lines in 1 file changed: 14 ins; 0 del; 3 mod > Patch: https://git.openjdk.java.net/jdk/pull/1156.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1156/head:pull/1156 > > PR: https://git.openjdk.java.net/jdk/pull/1156 > From ccheung at openjdk.java.net Thu Nov 19 00:41:13 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 19 Nov 2020 00:41:13 GMT Subject: RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes Message-ID: Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set. This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically: - remove the above workaround; - capture the setting of the property in the archive header during CDS dump time; - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header. If the values don't match, the archived lambda proxy class won't be used. Tests: - [x] ran all cds tests locally on linux-x64 - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64 - [x] mach5 tiers 1,2,3 (in progress) ------------- Commit messages: - Merge branch 'master' into 8256487-disableEagerInit - 8256487: Handle disableEagerInitialization for archived lambda proxy classes Changes: https://git.openjdk.java.net/jdk/pull/1301/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1301&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256487 Stats: 263 lines in 15 files changed: 246 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/1301.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1301/head:pull/1301 PR: https://git.openjdk.java.net/jdk/pull/1301 From redestad at openjdk.java.net Thu Nov 19 00:54:02 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 19 Nov 2020 00:54:02 GMT Subject: RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 23:58:25 GMT, Calvin Cheung wrote: > Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set. > > This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically: > > - remove the above workaround; > > - capture the setting of the property in the archive header during CDS dump time; > > - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header. > If the values don't match, the archived lambda proxy class won't be used. > > Tests: > > - [x] ran all cds tests locally on linux-x64 > > - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64 > > - [x] mach5 tiers 1,2,3 (in progress) I'm not sure if this is a good idea, TBH. The disableEagerInitialization setting is for native-image pre-generation purposes and the less CDS cares about it, the better. I'd prefer it if there's no trace of the property in hotspot sources. ------------- PR: https://git.openjdk.java.net/jdk/pull/1301 From dholmes at openjdk.java.net Thu Nov 19 00:58:03 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 19 Nov 2020 00:58:03 GMT Subject: RFR: 8256178: Add RAII object for file lock [v2] In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 07:25:12 GMT, Yasumasa Suenaga wrote: >> This PR is subtask of [JDK-8256008](https://bugs.openjdk.java.net/browse/JDK-8256008) (#1106) >> >> `LogFileStreamOutput::write()` uses `os::flockfile()` and `os::funlockfile()` to serialize write ops. It is better to use RAII because we can ensure `os::funlockfile()` call. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Remove funlockfile() call This seems fine. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1156 From coleenp at openjdk.java.net Thu Nov 19 01:23:05 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 19 Nov 2020 01:23:05 GMT Subject: RFR: 8256178: Add RAII object for file lock [v2] In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 07:25:12 GMT, Yasumasa Suenaga wrote: >> This PR is subtask of [JDK-8256008](https://bugs.openjdk.java.net/browse/JDK-8256008) (#1106) >> >> `LogFileStreamOutput::write()` uses `os::flockfile()` and `os::funlockfile()` to serialize write ops. It is better to use RAII because we can ensure `os::funlockfile()` call. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Remove funlockfile() call Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1156 From dholmes at openjdk.java.net Thu Nov 19 01:26:08 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 19 Nov 2020 01:26:08 GMT Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 15:00:21 GMT, Patricio Chilano Mateo wrote: >> Hi all, >> >> Please review the following change to defer biased-locking obsoletion to 18, as discussed in [1]. >> I updated the special_jvm_flags table and re-enabled gtest verify_special_flags. >> >> Thanks, >> Patricio >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/045454.html > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > move CriticalJNINatives up in table Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1281 From ccheung at openjdk.java.net Thu Nov 19 02:12:02 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 19 Nov 2020 02:12:02 GMT Subject: RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: Message-ID: <2HAKrvsORLsNHOY10PyQ395snpigQ7t0ZhAKUVIoPlk=.0540d08a-e46a-4e80-9719-4f16acc943d2@github.com> On Thu, 19 Nov 2020 00:50:52 GMT, Claes Redestad wrote: >> Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set. >> >> This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically: >> >> - remove the above workaround; >> >> - capture the setting of the property in the archive header during CDS dump time; >> >> - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header. >> If the values don't match, the archived lambda proxy class won't be used. >> >> Tests: >> >> - [x] ran all cds tests locally on linux-x64 >> >> - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64 >> >> - [x] mach5 tiers 1,2,3 (in progress) > > I'm not sure if this is a good idea, TBH. The disableEagerInitialization setting is for native-image pre-generation purposes and the less CDS cares about it, the better. I'd prefer it if there's no trace of the property in hotspot sources. Hi Claes, Thanks for taking a look. So should I keep the following `!initialize` check in LambdaProxyClassArchive? 109 if (!loadedByBuiltinLoader(caller) || !initialize || 110 !CDS.isSharingEnabled() || isSerializable || markerInterfaces.length > 0 || additionalBridges.length > 0) 111 return null; If we keep the above code, I think we don't need to pass the `initialize` to `findFromArchive` and eventually to `JVM_LookupLambdaProxyClassFromArchive`. Let me know if the above is what you have in mind? thanks, Calvin ------------- PR: https://git.openjdk.java.net/jdk/pull/1301 From pchilanomate at openjdk.java.net Thu Nov 19 02:30:16 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 19 Nov 2020 02:30:16 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v3] In-Reply-To: References: Message-ID: <7Hr7CmHe2-TYMvnwD685HrI1yZeGjlFzhoTNyTCq-MU=.afb52ce8-2c81-4ca7-b808-2ed63c517663@github.com> > Please review the following patch to add method Mutex::try_lock_without_rank_check(). > > The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. > > The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. > > Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. > > Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. > > I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. > > In summary the patch contains the following changes: > - Add method Mutex::try_lock_without_rank_check() > - Move rank checks before trying to lock/wait on the underlying PlatformMonitor > - Clean up definitions for optimized/debug builds > - Add a new gtest to test for different rank violations scenarios > > Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - change guarantee to assert - Merge branch 'master' into 8255678-trylock - address Dan's comments - v1 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1242/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1242&range=02 Stats: 333 lines in 3 files changed: 249 ins; 69 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/1242.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1242/head:pull/1242 PR: https://git.openjdk.java.net/jdk/pull/1242 From pchilanomate at openjdk.java.net Thu Nov 19 02:35:17 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 19 Nov 2020 02:35:17 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v4] In-Reply-To: References: Message-ID: > Please review the following patch to add method Mutex::try_lock_without_rank_check(). > > The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. > > The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. > > Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. > > Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. > > I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. > > In summary the patch contains the following changes: > - Add method Mutex::try_lock_without_rank_check() > - Move rank checks before trying to lock/wait on the underlying PlatformMonitor > - Clean up definitions for optimized/debug builds > - Add a new gtest to test for different rank violations scenarios > > Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: fix whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1242/files - new: https://git.openjdk.java.net/jdk/pull/1242/files/51fb050d..385e64a2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1242&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1242&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1242.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1242/head:pull/1242 PR: https://git.openjdk.java.net/jdk/pull/1242 From pchilanomate at openjdk.java.net Thu Nov 19 02:58:02 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 19 Nov 2020 02:58:02 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v2] In-Reply-To: References: Message-ID: <_ZoA7bhawf1Qcs4RMQ2swVzfCQgcKHQX3m2fipvFxV0=.3444ef59-f56c-419a-aafc-40bfa85857a4@github.com> On Wed, 18 Nov 2020 22:53:22 GMT, David Holmes wrote: >> How about just: >> bool Mutex::try_lock() { >> Thread * const self = Thread::current(); >> DEBUG_ONLY(if (!owned_by_self()) check_rank(self);) >> return try_lock_inner(self); >> } >> keeping try_lock_without_rank_check() as is. Then I can merge try_lock_inner() with your patch. > > If the existing try_lock become try_lock_inner then you are duplicating the owner check. My suggestion minimises code duplication allowing both try_lock and try_lock_without_rank_check to just be simple inline definitions. > My changes just integrated so you can merge now. > Thanks. Ok, makes sense. I updated the code with the suggested change. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From coleenp at openjdk.java.net Thu Nov 19 03:28:04 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 19 Nov 2020 03:28:04 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 00:39:22 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch to add method Mutex::try_lock_without_rank_check(). >> >> The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. >> >> The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. >> >> Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. >> >> Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. >> >> I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. >> >> In summary the patch contains the following changes: >> - Add method Mutex::try_lock_without_rank_check() >> - Move rank checks before trying to lock/wait on the underlying PlatformMonitor >> - Clean up definitions for optimized/debug builds >> - Add a new gtest to test for different rank violations scenarios >> >> Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > address Dan's comments Changes requested by coleenp (Reviewer). src/hotspot/share/runtime/mutex.cpp line 400: > 398: if (owned_by_self()) { > 399: // wait() case > 400: Mutex* least = get_least_ranked_lock_besides_this(locks_owned); Wouldn't you want to test check_can_be_skipped before all this code and skip all of this? ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From coleenp at openjdk.java.net Thu Nov 19 03:28:06 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 19 Nov 2020 03:28:06 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v4] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 02:35:17 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch to add method Mutex::try_lock_without_rank_check(). >> >> The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. >> >> The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. >> >> Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. >> >> Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. >> >> I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. >> >> In summary the patch contains the following changes: >> - Add method Mutex::try_lock_without_rank_check() >> - Move rank checks before trying to lock/wait on the underlying PlatformMonitor >> - Clean up definitions for optimized/debug builds >> - Add a new gtest to test for different rank violations scenarios >> >> Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > fix whitespace test/hotspot/gtest/runtime/test_mutex_rank.cpp line 88: > 86: mutex_rankA_plus_one->unlock(); > 87: mutex_rankA->unlock(); > 88: mutex_rankA_plus_two->unlock(); I think you should add a test that _skip_rank_check is reset, ie. lock mutex_rankA_plus_one with plain try_lock and make sure it tests the rank. ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From pchilanomate at openjdk.java.net Thu Nov 19 03:40:07 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 19 Nov 2020 03:40:07 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v2] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 03:07:04 GMT, Coleen Phillimore wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> address Dan's comments > > src/hotspot/share/runtime/mutex.cpp line 400: > >> 398: if (owned_by_self()) { >> 399: // wait() case >> 400: Mutex* least = get_least_ranked_lock_besides_this(locks_owned); > > Wouldn't you want to test check_can_be_skipped before all this code and skip all of this? For the wait() case, today we always check that the thread doesn't wait while holding a Mutex/Monitor of rank less than or equal to special, and I didn't want to change that. But I could do it for the "lock()/lock_without_safepoint_check()/try_lock()" case, and return before calling get_least_ranked_lock(). ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From pchilanomate at openjdk.java.net Thu Nov 19 03:40:08 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 19 Nov 2020 03:40:08 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v4] In-Reply-To: References: Message-ID: <30lS-8wShtzkRQJFyrsSA2d5aHhaqhbAdP9AD38iIWc=.cc31c36d-6717-4632-b881-6b4cae04cc50@github.com> On Thu, 19 Nov 2020 03:24:13 GMT, Coleen Phillimore wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> fix whitespace > > test/hotspot/gtest/runtime/test_mutex_rank.cpp line 88: > >> 86: mutex_rankA_plus_one->unlock(); >> 87: mutex_rankA->unlock(); >> 88: mutex_rankA_plus_two->unlock(); > > I think you should add a test that _skip_rank_check is reset, ie. lock mutex_rankA_plus_one with plain try_lock and make sure it tests the rank. Sounds good, I'll add that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From pchilanomate at openjdk.java.net Thu Nov 19 04:06:18 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 19 Nov 2020 04:06:18 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v5] In-Reply-To: References: Message-ID: > Please review the following patch to add method Mutex::try_lock_without_rank_check(). > > The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. > > The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. > > Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. > > Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. > > I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. > > In summary the patch contains the following changes: > - Add method Mutex::try_lock_without_rank_check() > - Move rank checks before trying to lock/wait on the underlying PlatformMonitor > - Clean up definitions for optimized/debug builds > - Add a new gtest to test for different rank violations scenarios > > Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: early test check_can_be_skipped + extra try_lock test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1242/files - new: https://git.openjdk.java.net/jdk/pull/1242/files/385e64a2..c17a9c1c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1242&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1242&range=03-04 Stats: 22 lines in 2 files changed: 17 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1242.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1242/head:pull/1242 PR: https://git.openjdk.java.net/jdk/pull/1242 From ysuenaga at openjdk.java.net Thu Nov 19 04:13:02 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 19 Nov 2020 04:13:02 GMT Subject: Integrated: 8256178: Add RAII object for file lock In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 07:09:53 GMT, Yasumasa Suenaga wrote: > This PR is subtask of [JDK-8256008](https://bugs.openjdk.java.net/browse/JDK-8256008) (#1106) > > `LogFileStreamOutput::write()` uses `os::flockfile()` and `os::funlockfile()` to serialize write ops. It is better to use RAII because we can ensure `os::funlockfile()` call. This pull request has now been integrated. Changeset: cfa92a53 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/cfa92a53 Stats: 19 lines in 1 file changed: 14 ins; 2 del; 3 mod 8256178: Add RAII object for file lock Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1156 From ysuenaga at openjdk.java.net Thu Nov 19 05:26:13 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 19 Nov 2020 05:26:13 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails [v2] In-Reply-To: References: Message-ID: > If there are no disk space enough to write UL, it does not report. So the user cannot know lack of logs timely. > > `LogFileStreamOutput::write()` uses `jio_fprintf()` and `fflush()` to write log. However return values from them would not be checked. > We should check them, and should report what happened if error occurred. > > > How to reproduce on Linux: > > 1. Mount tmpfs with 512K > > $ mkdir /tmp/tmp > $ mount -t tmpfs -o size=512k tmpfs /tmp/tmp > > 2. Run `java` with `-Xlog` > > $ java -Xlog:all=trace:file=/tmp/tmp/all.log --version Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - refactoring - Merge branch 'master' into JDK-8256008 - Fix typo - 8256008: UL does not report anything if disk writing fails ------------- Changes: https://git.openjdk.java.net/jdk/pull/1106/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1106&range=01 Stats: 55 lines in 3 files changed: 37 ins; 2 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1106.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1106/head:pull/1106 PR: https://git.openjdk.java.net/jdk/pull/1106 From ysuenaga at openjdk.java.net Thu Nov 19 05:44:02 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 19 Nov 2020 05:44:02 GMT Subject: RFR: 8256008: UL does not report anything if disk writing fails [v2] In-Reply-To: <9FFZ2_lflMLIQgNDqNOAYVjFGDTq6dEMtYzf7Iv_uCY=.e6d9e449-1f17-4ece-ab44-c700a0e19959@github.com> References: <1K5zbwcC_LPNVUZmN4abFHyAnCe4Kkm5mM1tmNS7j2M=.1c23a3ac-9c7d-4598-ad61-75e25cd6a5e1@github.com> <3cwv2rmGojtsvDcQXWdfCx8tqrRjbx9Fe-rnMoUazqY=.254ef493-a888-4955-a50c-122dedec8772@github.com> <9FFZ2_lflMLIQgNDqNOAYVjFGDTq6dEMtYzf7Iv_uCY=.e6d9e449-1f17-4ece-ab44-c700a0e19959@github.com> Message-ID: On Wed, 11 Nov 2020 08:16:59 GMT, Thomas Stuefe wrote: >>> > > > * If you handle errors from writing, make sure you handle intermittend write errors correctly. You probably want to handle EINTR by re-trying to write. >>> > > >>> > > >>> > > `LogFileStreamOutput::write()` uses `jio_fprintf()` (wrapper of `vfprintf()` ) and `fflush()`. In case of `fflush()`, we can retry, however `jio_fprintf()` can be done in the same way? `vfprintf()` might not set `errno` if error happens. (I'm not sure) >>> > >>> > >>> > Hmm. Thinking about this some more: >>> > Without reading your patch closely, what is the strategy you propose if a write error happens? >>> > >>> > 1. Will you write a message, then refuse further log attempts? >>> > 2. Will you write a message, but continue logging? Writing a message each time an error happens? >>> > 3. Will you write a message only for the first write error and then not refuse further log attempts? >>> > >>> > Depending on this we should handle intermittent errors (EINTR and maybe EAGAIN) or can continute to ignore them. >>> > With (1) we should handle (ignore) intermittent errors to prevent one spurious write error from stoppng the log. >>> > With (2) we don't have to handle them since we do essentially what we do today, but a bad IO device may now cause a flood of messages. >>> > With (3) we don't have to either but will only see the first UL writing problem. >>> > Not sure what I like best. What did you propose? >>> >>> I've proposed (3) on this patch. I want to notice log writing is failed due to some error when log file is strange. >>> >>> Error message would be shown only the first time an error occurs, however logger would not be disabled because someone might make free disk space without rebooting JVM. >>> I thought (1) at first, but I didn't do so because it requires operator to resume logging (e.g. `jcmd VM.log`) when the problem is fixed. >> >> This makes sense. Its what I would have done too. >> >>> >>> > > > * I see you make an RAII object to handle flock. Could you leave this out please to make this change easier to review? I am not against it, but would prefer this in a separate cleanup change. >>> > > >>> > > >>> > > If `FileLocker` is removed from this change, I want to add it on another RFE before this because this change makes to return from several locations in `LogFileStreamOutput::write()`. >>> > > Do you agree create subtask (RFE) to add `FileLocker`? >>> > >>> > >>> > Yes. But on second thought, I don't want to cause you unnecessary work. So if that is all the cleanup you'll do in this patch, I am fine with it too. >>> >>> No problem, I will add it as RFE to JBS. >> >> Thanks. I'll review the patch in detail in the next days. >> >> Cheers, Thomas > >> Thanks @tstuefe ! I've sent PR for RAII object in #1156 . I will update this PR after #1156 is pushed. > > Okay I'll wait Hi @tstuefe , could you review the new change? > > * I would like it if we could attempt to write some final words into the log stream. Because that may still work, even if the larger output does not (I really hope we do not print characters individually, don't we?). Something like `("write failed (%d)", errno)`. That may or may not work but if it does its helpful when looking at the logfile. > > Agree, I will add log message. I added error message to stderr when `jio_fprintf()` or `fflush()` is failed, but I can't have confidence whether we can write error message without UL format (without decorators) in here. It might break log parser for UL. I could not use `log_error()` because LogOutput happens dead lock, and also the error might happen on LogOutput which is not set `logging` tag. ------------- PR: https://git.openjdk.java.net/jdk/pull/1106 From iklam at openjdk.java.net Thu Nov 19 07:35:07 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 19 Nov 2020 07:35:07 GMT Subject: RFR: 8256172: Clean up CDS handling of i2i_entry [v2] In-Reply-To: References: Message-ID: <1hZU3JXOPCOLKl67IlVUVxA7TovJmUuF-cOeEnob8lc=.37a61531-47c4-4aa4-9b18-4f90e1e8ff8b@github.com> On Wed, 18 Nov 2020 18:42:56 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - fixed merge >> - Merge branch 'master' into 8256172-cleanup-cds-i2i-entry >> - 8256172: Clean up CDS handling of i2i_entry > > Cleanup looks good. Thanks @calvinccheung and @yminqi for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1280 From iklam at openjdk.java.net Thu Nov 19 07:35:08 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 19 Nov 2020 07:35:08 GMT Subject: Integrated: 8256172: Clean up CDS handling of i2i_entry In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 00:35:16 GMT, Ioi Lam wrote: > This PR is a prerequisite for [JDK-8250989](https://bugs.openjdk.java.net/browse/JDK-8250989) - Consolidate buffer allocation code for CDS static/dynamic archive dumping. > > - Move the allocation of the i2i buffer after all classes are loaded. This makes it possible to estimate the size of the CDS archive before we allocate the output space (this is what dynamic archive does now). > - No need to generate the i2i trampoline code during -Xshare:dump > - Clean up the CDS code in abstractInterpreter.cpp and add more comments. This pull request has now been integrated. Changeset: 4178834d Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/4178834d Stats: 85 lines in 8 files changed: 24 ins; 40 del; 21 mod 8256172: Clean up CDS handling of i2i_entry Reviewed-by: minqi, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/1280 From dholmes at openjdk.java.net Thu Nov 19 07:50:09 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 19 Nov 2020 07:50:09 GMT Subject: RFR: 8256594: Unexpected warning: SIGSEGV handler flags expected:SA_RESTART|SA_SIGINFO found:SA_RESTART|SA_SIGINFO Message-ID: In the recent POSIX signal code cleanup (JDK-8253742) I misunderstood the role of the SIGNIFICANT_SIGNAL_MASK and removing its application causes -Xcheck:jni to report errors with the signal handler due to an unexpected bit in the sigaction.sa_flags field. This fix restores the masking of that flag, for Linux only, and more clearly indicating what it is. I also augmented the flag printing code to show when an unexpected flag is present (and so avoid the mysterious "expected X found X" message). See bug report for more details. Thanks. ------------- Commit messages: - 8256594: Unexpected warning: SIGSEGV handler flags expected:SA_RESTART|SA_SIGINFO found:SA_RESTART|SA_SIGINFO Changes: https://git.openjdk.java.net/jdk/pull/1309/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1309&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256594 Stats: 31 lines in 1 file changed: 28 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1309/head:pull/1309 PR: https://git.openjdk.java.net/jdk/pull/1309 From dholmes at openjdk.java.net Thu Nov 19 08:03:08 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 19 Nov 2020 08:03:08 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v5] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 04:06:18 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch to add method Mutex::try_lock_without_rank_check(). >> >> The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. >> >> The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. >> >> Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. >> >> Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. >> >> I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. >> >> In summary the patch contains the following changes: >> - Add method Mutex::try_lock_without_rank_check() >> - Move rank checks before trying to lock/wait on the underlying PlatformMonitor >> - Clean up definitions for optimized/debug builds >> - Add a new gtest to test for different rank violations scenarios >> >> Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > early test check_can_be_skipped + extra try_lock test A couple of minor nits but otherwise I'm good with this. Thanks, David src/hotspot/share/runtime/mutex.cpp line 148: > 146: // Checking the owner hides the potential difference in recursive locking behaviour > 147: // on some platforms. > 148: if(owned_by_self(self)) { Need space after if src/hotspot/share/runtime/mutex.cpp line 152: > 150: } > 151: > 152: if(do_rank_checks) { need space after if src/hotspot/share/runtime/mutex.cpp line 310: > 308: Mutex(Rank, name, allow_vm_block, safepoint_check_required) {} > 309: > 310: bool Mutex::owned_by_self(Thread* thread) const { Side comment: I'm not sure this is the right way to go versus just checking _owner directly. If you go this style then we end up with the potential for owned_by_self(self); owned_by_self(); not_owned() /* compares _owner == NULL */ and a similar range of assertions - rather than just comparing _owner directly (and with owned_by_self() convenience function). src/hotspot/share/runtime/mutex.hpp line 204: > 202: Thread* owner() const { return _owner; } > 203: void set_owner(Thread* owner) { set_owner_implementation(owner); } > 204: bool owned_by_self(Thread* thread) const; Does this need to be public? Arguably when passing in a thread this should just be owned_by(x) - unless you'd also like to assert that x == Thread::current() ? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1242 From stuefe at openjdk.java.net Thu Nov 19 08:27:05 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 19 Nov 2020 08:27:05 GMT Subject: RFR: 8256178: Add RAII object for file lock [v2] In-Reply-To: References: Message-ID: On Wed, 11 Nov 2020 07:25:12 GMT, Yasumasa Suenaga wrote: >> This PR is subtask of [JDK-8256008](https://bugs.openjdk.java.net/browse/JDK-8256008) (#1106) >> >> `LogFileStreamOutput::write()` uses `os::flockfile()` and `os::funlockfile()` to serialize write ops. It is better to use RAII because we can ensure `os::funlockfile()` call. > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Remove funlockfile() call Missed that one, sorry. Looks good (But I see you already pushed). ..Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1156 From shade at openjdk.java.net Thu Nov 19 08:30:15 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 19 Nov 2020 08:30:15 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails Message-ID: There is no os::workaround_expand_exec_shield_cs_limit symbol available: collect2: error: ld returned 1 exit status That symbol is defined in `os_linux_x86.cpp`, which is not available to Zero that builds `os_linux_zero.cpp`. [JDK-8248271](https://bugs.openjdk.java.net/browse/JDK-8248271) added the declaration to `os_linux_zero.hpp`, but that is not enough, because the definition is still missing. I propose we move the definition up the hierarchy, to `os_linux.cpp` and protect it firmly with `IA32`. Additional testing: - [x] Linux {x86_32, x86_64} server builds - [x] Linux {x86_32, x86_64} zero builds ------------- Commit messages: - 8256618: Zero: Linux x86_32 build still fails Changes: https://git.openjdk.java.net/jdk/pull/1310/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1310&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256618 Stats: 158 lines in 4 files changed: 80 ins; 77 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1310.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1310/head:pull/1310 PR: https://git.openjdk.java.net/jdk/pull/1310 From stuefe at openjdk.java.net Thu Nov 19 08:33:16 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 19 Nov 2020 08:33:16 GMT Subject: RFR: JDK-8255978: [windows] os::release_memory may not release the full range [v4] In-Reply-To: References: Message-ID: > On Windows, os::release_memory(p,size) may not actually release the whole region if it contains multiple mappings. This may cause memory bloat or runaway leaks or errors which look like failed mappings to specific wish addresses. > > Background: > > On Windows, memory mappings are established with VirtualAlloc() [1] and released with VirtualFree() [2]. In constrast to POSIX munmap(), VirtualFree() can only release a single full range established with VirtualAlloc(). It cannot release multiple ranges, or parts of a range. > > The Windows implementation of os::release_memory(p, size) [3] calls VirtualFree(p, NULL, MEM_RELEASE) - it ignores the size parameter and releases whatever mapping happens to start at p: > > bool os::pd_release_memory(char* addr, size_t bytes) { > return VirtualFree(addr, 0, MEM_RELEASE) != 0; > } > > ... which assumes that the given range size corresponds to the size of a mapping starting at p. > > This may be incorrect: > > 1) For NUMA-friendly allocation, we allocate memory in stripes, each stripe individually allocated. > 2) For +UseLargePagesIndividualAllocation we do the same > 3) apart from that, the given region size may just be wrong. Since we never check these, we may never have noticed. I am currently running tests to find out if we have other mismatched releases. > > For cases (1) and (2), we would just release the first stripe in that striped range, leaving the rest of the mappings intact. This is not immediately noticeable, since VirtualFree() returns success. And even if it did not, we usually ignore the return code of os::release_memory(). > > The problem is aggrevated since, on Windows, we often employ an "optimistically-release-and-remap" approach: since mappings are undivisible, if one wants to change their size, split them or similar, one has to follow this sequence: > > a) release old allocation > b) place into the now vacated address room one or more new allocations > > This is not guaranteed to work, since between (a) and (b) someone may have grabbed the address space. We live with that since there is no way to do this differently. > > When used on a range which contains multiple mappings, this technique is almost guaranteed to fail. In that case, (a) would only release the first mapping in the range. (b) would almost certainly fail since most of the original range would still be mapped. > > Examples of these technique in os_windows.cpp: > - os::split_reseved_memory() (see also [4]) > - map_or_reserve_memory_aligned() > - os::replace_existing_mapping_with_file_mapping() > > This can manifest as small memory leak or inability to attach to a given wish address. It could also result in a viscous loop ([5], [6]) and result in ballooning and native OOMs. > > -- > > AFAICS this is an old issue, dating back to at least jdk 8. > > -- > > The change in detail: > > - os::release_memory() on Window now: > - in LP/NUMA case we unmap all mappings in the given range. The mappings must match the range exactly, otherwise we assert. > - In normal case we just check the given range and assert if it does not match. > Note: in release builds I just print a warning and return false. Should this be a guarantee? I leave that up to the Reviewers. > > - Added gtests which test os::release_memory() with a variety of scenarios. Includes both positive and negative tests. The latter includes a death test for debug. > > - Added a helper function to find mappings, for now windows only (os::win32::find_mapping()), including gtests for that function. > > - Added a function to print mappings, for diagnostic purposes: os::print_memory_mappings(). Provided an implementation for linux and windows. > > > -- > [1] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc > [2] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualfree > [3] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3394 > [4] https://bugs.openjdk.java.net/browse/JDK-8253649 > [5] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3150 > [6] https://bugs.openjdk.java.net/browse/JDK-8255954 Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge - Merge - Merge - Initial ------------- Changes: https://git.openjdk.java.net/jdk/pull/1143/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1143&range=03 Stats: 491 lines in 7 files changed: 490 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1143.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1143/head:pull/1143 PR: https://git.openjdk.java.net/jdk/pull/1143 From stuefe at openjdk.java.net Thu Nov 19 10:36:05 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 19 Nov 2020 10:36:05 GMT Subject: RFR: 8256594: Unexpected warning: SIGSEGV handler flags expected:SA_RESTART|SA_SIGINFO found:SA_RESTART|SA_SIGINFO In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 07:45:03 GMT, David Holmes wrote: > In the recent POSIX signal code cleanup (JDK-8253742) I misunderstood the role of the SIGNIFICANT_SIGNAL_MASK and removing its application causes -Xcheck:jni to report errors with the signal handler due to an unexpected bit in the sigaction.sa_flags field. > > This fix restores the masking of that flag, for Linux only, and more clearly indicating what it is. I also augmented the flag printing code to show when an unexpected flag is present (and so avoid the mysterious "expected X found X" message). > > See bug report for more details. > > Thanks. LGTM. Note that a maybe more elegant approach - avoiding the double definition of known flags - would have been, in the print loop, to store the checked flags in a mask. And then test for ~mask at the final step. The numeric comparison of flags in check_jni - which requires this SA_RESTORER_FLAG_MASK workaround - is a bit grating. Would have been better to compare just known flags. But this is old coding. All idle nitpicking :) Patch is fine. ..Thomas src/hotspot/os/posix/signals_posix.cpp line 668: > 666: strncpy(buffer, "none", size); > 667: > 668: const unsigned int unknown_flag = ~(SA_NOCLDSTOP | Maybe name this "unknown_flag_mask" ? ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1309 From david.holmes at oracle.com Thu Nov 19 11:11:42 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Nov 2020 21:11:42 +1000 Subject: RFR: 8256594: Unexpected warning: SIGSEGV handler flags expected:SA_RESTART|SA_SIGINFO found:SA_RESTART|SA_SIGINFO In-Reply-To: References: Message-ID: On 19/11/2020 8:36 pm, Thomas Stuefe wrote: > On Thu, 19 Nov 2020 07:45:03 GMT, David Holmes wrote: > >> In the recent POSIX signal code cleanup (JDK-8253742) I misunderstood the role of the SIGNIFICANT_SIGNAL_MASK and removing its application causes -Xcheck:jni to report errors with the signal handler due to an unexpected bit in the sigaction.sa_flags field. >> >> This fix restores the masking of that flag, for Linux only, and more clearly indicating what it is. I also augmented the flag printing code to show when an unexpected flag is present (and so avoid the mysterious "expected X found X" message). >> >> See bug report for more details. >> >> Thanks. > > LGTM. > > Note that a maybe more elegant approach - avoiding the double definition of known flags - would have been, in the print loop, to store the checked flags in a mask. And then test for ~mask at the final step. > > The numeric comparison of flags in check_jni - which requires this SA_RESTORER_FLAG_MASK workaround - is a bit grating. Would have been better to compare just known flags. But this is old coding. > > All idle nitpicking :) Patch is fine. Thanks for the review Thomas. I tried to think of more clever schemes to do this but in the end ... Cheers, David ----- > ..Thomas > > src/hotspot/os/posix/signals_posix.cpp line 668: > >> 666: strncpy(buffer, "none", size); >> 667: >> 668: const unsigned int unknown_flag = ~(SA_NOCLDSTOP | > > Maybe name this "unknown_flag_mask" ? > > ------------- > > Marked as reviewed by stuefe (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1309 > From stuefe at openjdk.java.net Thu Nov 19 11:54:01 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 19 Nov 2020 11:54:01 GMT Subject: RFR: JDK-8255978: [windows] os::release_memory may not release the full range [v3] In-Reply-To: References: <6fVIcmERi7BPUAHVESL0DG_XoPpv-r6FxNrXUFGk_qQ=.42db9e76-f2d4-4ca8-b538-d279851db37a@github.com> Message-ID: <-_ffRcle_V0Bg6vHrZQHGbo_1quWDSRJQl1RAwADZ98=.87ea00cd-4b20-4281-a02b-29c826cbe016@github.com> On Wed, 18 Nov 2020 18:46:05 GMT, Thomas Stuefe wrote: >> LGTM, very nice test case, thanks! > >> LGTM, very nice test case, thanks! > > Thanks a lot Yumin! > > I'll change the comment before pushing. I'd like to leave that printing stuff in, but will disable it by default. That way we can switch it on when needed to look what is going on. I'll integrate now. The remaining error, a crash on Linux in HeapRegion::block_size, has nothing to do with this patch (I opened https://bugs.openjdk.java.net/browse/JDK-8256641 to track it). ------------- PR: https://git.openjdk.java.net/jdk/pull/1143 From stuefe at openjdk.java.net Thu Nov 19 11:54:02 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 19 Nov 2020 11:54:02 GMT Subject: Integrated: JDK-8255978: [windows] os::release_memory may not release the full range In-Reply-To: References: Message-ID: On Tue, 10 Nov 2020 13:55:54 GMT, Thomas Stuefe wrote: > On Windows, os::release_memory(p,size) may not actually release the whole region if it contains multiple mappings. This may cause memory bloat or runaway leaks or errors which look like failed mappings to specific wish addresses. > > Background: > > On Windows, memory mappings are established with VirtualAlloc() [1] and released with VirtualFree() [2]. In constrast to POSIX munmap(), VirtualFree() can only release a single full range established with VirtualAlloc(). It cannot release multiple ranges, or parts of a range. > > The Windows implementation of os::release_memory(p, size) [3] calls VirtualFree(p, NULL, MEM_RELEASE) - it ignores the size parameter and releases whatever mapping happens to start at p: > > bool os::pd_release_memory(char* addr, size_t bytes) { > return VirtualFree(addr, 0, MEM_RELEASE) != 0; > } > > ... which assumes that the given range size corresponds to the size of a mapping starting at p. > > This may be incorrect: > > 1) For NUMA-friendly allocation, we allocate memory in stripes, each stripe individually allocated. > 2) For +UseLargePagesIndividualAllocation we do the same > 3) apart from that, the given region size may just be wrong. Since we never check these, we may never have noticed. I am currently running tests to find out if we have other mismatched releases. > > For cases (1) and (2), we would just release the first stripe in that striped range, leaving the rest of the mappings intact. This is not immediately noticeable, since VirtualFree() returns success. And even if it did not, we usually ignore the return code of os::release_memory(). > > The problem is aggrevated since, on Windows, we often employ an "optimistically-release-and-remap" approach: since mappings are undivisible, if one wants to change their size, split them or similar, one has to follow this sequence: > > a) release old allocation > b) place into the now vacated address room one or more new allocations > > This is not guaranteed to work, since between (a) and (b) someone may have grabbed the address space. We live with that since there is no way to do this differently. > > When used on a range which contains multiple mappings, this technique is almost guaranteed to fail. In that case, (a) would only release the first mapping in the range. (b) would almost certainly fail since most of the original range would still be mapped. > > Examples of these technique in os_windows.cpp: > - os::split_reseved_memory() (see also [4]) > - map_or_reserve_memory_aligned() > - os::replace_existing_mapping_with_file_mapping() > > This can manifest as small memory leak or inability to attach to a given wish address. It could also result in a viscous loop ([5], [6]) and result in ballooning and native OOMs. > > -- > > AFAICS this is an old issue, dating back to at least jdk 8. > > -- > > The change in detail: > > - os::release_memory() on Window now: > - in LP/NUMA case we unmap all mappings in the given range. The mappings must match the range exactly, otherwise we assert. > - In normal case we just check the given range and assert if it does not match. > Note: in release builds I just print a warning and return false. Should this be a guarantee? I leave that up to the Reviewers. > > - Added gtests which test os::release_memory() with a variety of scenarios. Includes both positive and negative tests. The latter includes a death test for debug. > > - Added a helper function to find mappings, for now windows only (os::win32::find_mapping()), including gtests for that function. > > - Added a function to print mappings, for diagnostic purposes: os::print_memory_mappings(). Provided an implementation for linux and windows. > > > -- > [1] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc > [2] https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualfree > [3] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3394 > [4] https://bugs.openjdk.java.net/browse/JDK-8253649 > [5] https://github.com/openjdk/jdk/blob/5dfb42fc68099278cbc98e25fb8a91fd957c12e2/src/hotspot/os/windows/os_windows.cpp#L3150 > [6] https://bugs.openjdk.java.net/browse/JDK-8255954 This pull request has now been integrated. Changeset: f626ed6a Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/f626ed6a Stats: 491 lines in 7 files changed: 490 ins; 0 del; 1 mod 8255978: [windows] os::release_memory may not release the full range Reviewed-by: iklam, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/1143 From jiefu at openjdk.java.net Thu Nov 19 12:20:07 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 19 Nov 2020 12:20:07 GMT Subject: RFR: 8256640: assert(!m->is_old() || ik()->is_being_redefined()) failed: old methods should not be in vtable Message-ID: <184hAHQXaLG-XCg4KKek9mFcvdpSMHWZxauIvAkcny8=.ea6009a9-1bc3-4364-be4b-958994033890@github.com> Hi all, java/lang/instrument/IsModifiableClassAgent.java fails after JDK-8256365. The reason is that the newly added assert [1] doesn't consider the case when the super class had been redefined. Please review it. Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/klassVtable.cpp#L564 ------------- Commit messages: - 8256640: assert(!m->is_old() || ik()->is_being_redefined()) failed: old methods should not be in vtable Changes: https://git.openjdk.java.net/jdk/pull/1313/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1313&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256640 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1313.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1313/head:pull/1313 PR: https://git.openjdk.java.net/jdk/pull/1313 From coleenp at openjdk.java.net Thu Nov 19 13:11:12 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 19 Nov 2020 13:11:12 GMT Subject: RFR: 8256640: assert(!m->is_old() || ik()->is_being_redefined()) failed: old methods should not be in vtable In-Reply-To: <184hAHQXaLG-XCg4KKek9mFcvdpSMHWZxauIvAkcny8=.ea6009a9-1bc3-4364-be4b-958994033890@github.com> References: <184hAHQXaLG-XCg4KKek9mFcvdpSMHWZxauIvAkcny8=.ea6009a9-1bc3-4364-be4b-958994033890@github.com> Message-ID: On Thu, 19 Nov 2020 12:15:05 GMT, Jie Fu wrote: > Hi all, > > java/lang/instrument/IsModifiableClassAgent.java fails after JDK-8256365. > The reason is that the newly added assert [1] doesn't consider the case when the super class had been redefined. > > Please review it. > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/klassVtable.cpp#L564 I don't think this is right. We should never put old methods in the table. ------------- PR: https://git.openjdk.java.net/jdk/pull/1313 From coleenp at openjdk.java.net Thu Nov 19 13:24:07 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 19 Nov 2020 13:24:07 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v2] In-Reply-To: References: Message-ID: <5hnAwJg4Fc0NAldBICg-Lb-qseJvh1R_aPT3umx4saw=.9d486aab-caf6-44ab-bbff-e26f4d49d0db@github.com> On Thu, 19 Nov 2020 03:37:09 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/mutex.cpp line 400: >> >>> 398: if (owned_by_self()) { >>> 399: // wait() case >>> 400: Mutex* least = get_least_ranked_lock_besides_this(locks_owned); >> >> Wouldn't you want to test check_can_be_skipped before all this code and skip all of this? > > For the wait() case, today we always check that the thread doesn't wait while holding a Mutex/Monitor of rank less than or equal to special, and I didn't want to change that. > But I could do it for the "lock()/lock_without_safepoint_check()/try_lock()" case, and return before calling get_least_ranked_lock(). too many conditions! Now I see it. Okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From coleenp at openjdk.java.net Thu Nov 19 13:24:06 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 19 Nov 2020 13:24:06 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v5] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 04:06:18 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch to add method Mutex::try_lock_without_rank_check(). >> >> The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. >> >> The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. >> >> Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. >> >> Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. >> >> I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. >> >> In summary the patch contains the following changes: >> - Add method Mutex::try_lock_without_rank_check() >> - Move rank checks before trying to lock/wait on the underlying PlatformMonitor >> - Clean up definitions for optimized/debug builds >> - Add a new gtest to test for different rank violations scenarios >> >> Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > early test check_can_be_skipped + extra try_lock test Looks great. Thanks! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1242 From stuefe at openjdk.java.net Thu Nov 19 13:47:04 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 19 Nov 2020 13:47:04 GMT Subject: RFR: JDK-8255885: Metaspace: freelist commit counter is not updated when purging In-Reply-To: <1WCU0u8P_aVHMDlRhxmR0qMqFJRCvMhDQnCKNXX1Uog=.10637883-442d-4565-996f-b20937e08116@github.com> References: <1WCU0u8P_aVHMDlRhxmR0qMqFJRCvMhDQnCKNXX1Uog=.10637883-442d-4565-996f-b20937e08116@github.com> Message-ID: On Wed, 18 Nov 2020 13:35:39 GMT, Thomas Stuefe wrote: >> Metaspace chunks are uncommitted, under certain conditions, when being returned to the Metaspace by a dying class loader. >> >> There are two places where this happens: >> 1) when individual chunks are returned (see ChunkManager::return_chunk_locked()) >> 2) later, when CLDG::purge()->Metaspace::purge()->ChunkManager::purge() is called - all free chunks are again checked and potentially uncommitted. >> >> Free chunks are kept in FreeChunkList. FreeChunkList has a counter for words-comitted. That counter gets updated when chunks are added and removed. However, path (2) does not change the list, it just uncommits chunks residing in that list. That passes under the FreeChunkList's radar and now the counter is off. >> >> ----- >> >> Review note: `ChunkManager` keeps free chunks. It has an instance of `FreeChunkListVector`, which has a series (one per chunk size) of `FreeChunkList` instances. The commit counter value is handed up from `FreeChunkList` to, eventually, `ChunkManager`. >> >> What changed: >> >> - I removed the counter (_committed_word_size) from FreeChunkList. This seemed the simplest and safest measure. Keeping this counter up-to-date is a hassle, since chunks may get committed and uncommitted while being in this list. >> >> - Now we calculate the number of committed words on the fly if asked, by iterating all chunks in the list and accumulating. To reflect this change, I change the name of "FreeChunkList::committed_word_size()" to "FreeChunkList::calc_committed_word_size()". In metaspace, anything named "calc_" is potentially expensive. >> >> - Same renamings in FreeChunkListVector and ChunkManager::total_committed_word_size() - to ChunkManager::calc_committed_word_size() >> >> Now these functions always deliver the correct result. However, they are potentially slower and now require the central metaspace lock. That is not a problem: the only user of this function is when collecting the statistics for the "VM.metaspace" jcmd report, and that happens under lock protection and walks all kind of stuff anyway, so walking the freelists won't hurt. >> >> Just to be sure, I removed the use of these functions from ChunkManager::print_on(), even though that was just a debug function. >> >> ----- >> >> Tests: >> >> This patch has been tested in our nightlies for a week now. > > Tested in our systems for a week now on all platforms, no problems. Gentle ping... this has been quietly brewing in our test systems for two weeks now. I think this is safe. The issue blocks a follow up PR (https://bugs.openjdk.java.net/browse/JDK-8255884). Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1057 From pchilanomate at openjdk.java.net Thu Nov 19 14:17:04 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 19 Nov 2020 14:17:04 GMT Subject: RFR: 8256253: Defer Biased Locking obsoletion to JDK 18 [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 16:00:03 GMT, Martin Doerr wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> move CriticalJNINatives up in table > > Thanks for doing this! @TheRealMDoerr thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1281 From pchilanomate at openjdk.java.net Thu Nov 19 14:17:06 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 19 Nov 2020 14:17:06 GMT Subject: Integrated: 8256253: Defer Biased Locking obsoletion to JDK 18 In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 03:26:41 GMT, Patricio Chilano Mateo wrote: > Hi all, > > Please review the following change to defer biased-locking obsoletion to 18, as discussed in [1]. > I updated the special_jvm_flags table and re-enabled gtest verify_special_flags. > > Thanks, > Patricio > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-November/045454.html This pull request has now been integrated. Changeset: 342ccf69 Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/342ccf69 Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod 8256253: Defer Biased Locking obsoletion to JDK 18 Reviewed-by: dholmes, coleenp, dcubed, mdoerr ------------- PR: https://git.openjdk.java.net/jdk/pull/1281 From shade at openjdk.java.net Thu Nov 19 14:57:14 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 19 Nov 2020 14:57:14 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v2] In-Reply-To: References: Message-ID: <5s65roCasaADSjfJP1XD5L0kb2JDAvLKST6RrpdbbdA=.e8e924a0-5d09-4f89-b4fb-98a7b0c897d8@github.com> > There is no os::workaround_expand_exec_shield_cs_limit symbol available: > > > collect2: error: ld returned 1 exit status > > That symbol is defined in `os_linux_x86.cpp`, which is not available to Zero that builds `os_linux_zero.cpp`. > [JDK-8248271](https://bugs.openjdk.java.net/browse/JDK-8248271) added the declaration to `os_linux_zero.hpp`, but that is not enough, because the definition is still missing. I propose we move the definition up the hierarchy, to `os_linux.cpp` and protect it firmly with `IA32`. > > Additional testing: > - [x] Linux {x86_32, x86_64} server builds > - [x] Linux {x86_32, x86_64} zero builds Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Touchups after merge - Merge branch 'master' into JDK-8256618-zero-x86 - 8256618: Zero: Linux x86_32 build still fails ------------- Changes: https://git.openjdk.java.net/jdk/pull/1310/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1310&range=01 Stats: 158 lines in 4 files changed: 80 ins; 77 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1310.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1310/head:pull/1310 PR: https://git.openjdk.java.net/jdk/pull/1310 From coleenp at openjdk.java.net Thu Nov 19 15:27:04 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 19 Nov 2020 15:27:04 GMT Subject: RFR: 8256640: assert(!m->is_old() || ik()->is_being_redefined()) failed: old methods should not be in vtable In-Reply-To: References: <184hAHQXaLG-XCg4KKek9mFcvdpSMHWZxauIvAkcny8=.ea6009a9-1bc3-4364-be4b-958994033890@github.com> Message-ID: On Thu, 19 Nov 2020 13:08:41 GMT, Coleen Phillimore wrote: >> Hi all, >> >> java/lang/instrument/IsModifiableClassAgent.java fails after JDK-8256365. >> The reason is that the newly added assert [1] doesn't consider the case when the super class had been redefined. >> >> Please review it. >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/klassVtable.cpp#L564 > > I don't think this is right. We should never put old methods in the table. This is the patch for this failure but default methods could still get an old method if it's redefined while doing constraint checks. I'd like to take this bug. $ git diff diff --git a/src/hotspot/share/oops/instanceKlass.cpp b/src/hotspot/share/oops/instanceKlass.cpp index 4c720bb..fe7ac9e 100644 --- a/src/hotspot/share/oops/instanceKlass.cpp +++ b/src/hotspot/share/oops/instanceKlass.cpp @@ -2577,6 +2577,10 @@ void InstanceKlass::restore_unshareable_info(ClassLoaderData* loader_data, Handl // point to old or obsolete entries. RedefineClasses doesn't fix up // vtables in the shared system dictionary, only the main one. // It also redefines the itable too so fix that too. + // First fix any default methods that point to a super class that may + // have been redefined. + bool trace_name_printed = false; + adjust_default_methods(&trace_name_printed); vtable().initialize_vtable(false, CHECK); itable().initialize_itable(false, CHECK); } ------------- PR: https://git.openjdk.java.net/jdk/pull/1313 From redestad at openjdk.java.net Thu Nov 19 16:12:10 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 19 Nov 2020 16:12:10 GMT Subject: RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: <2HAKrvsORLsNHOY10PyQ395snpigQ7t0ZhAKUVIoPlk=.0540d08a-e46a-4e80-9719-4f16acc943d2@github.com> References: <2HAKrvsORLsNHOY10PyQ395snpigQ7t0ZhAKUVIoPlk=.0540d08a-e46a-4e80-9719-4f16acc943d2@github.com> Message-ID: On Thu, 19 Nov 2020 02:08:52 GMT, Calvin Cheung wrote: >> I'm not sure if this is a good idea, TBH. The disableEagerInitialization setting is for native-image pre-generation purposes and the less CDS cares about it, the better. I'd prefer it if there's no trace of the property in hotspot sources. > > Hi Claes, > > Thanks for taking a look. > > So should I keep the following `!initialize` check in LambdaProxyClassArchive? > 109 if (!loadedByBuiltinLoader(caller) || !initialize || > 110 !CDS.isSharingEnabled() || isSerializable || markerInterfaces.length > 0 || additionalBridges.length > 0) > 111 return null; > If we keep the above code, I think we don't need to pass the `initialize` to `findFromArchive` and eventually to `JVM_LookupLambdaProxyClassFromArchive`. > > Let me know if the above is what you have in mind? > > thanks, > Calvin Right, I'd drop that argument - I would go further and suggest making calls to both `LambdaProxyClassArchive.register` and `LambdaProxyClassArchive.find` conditional on `disableEagerInitialization` being `false` to avoid any accidental mix-up and reduce complexity of these orthogonal features/concerns. ------------- PR: https://git.openjdk.java.net/jdk/pull/1301 From aph at openjdk.java.net Thu Nov 19 16:50:05 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 Nov 2020 16:50:05 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v2] In-Reply-To: <5s65roCasaADSjfJP1XD5L0kb2JDAvLKST6RrpdbbdA=.e8e924a0-5d09-4f89-b4fb-98a7b0c897d8@github.com> References: <5s65roCasaADSjfJP1XD5L0kb2JDAvLKST6RrpdbbdA=.e8e924a0-5d09-4f89-b4fb-98a7b0c897d8@github.com> Message-ID: On Thu, 19 Nov 2020 14:57:14 GMT, Aleksey Shipilev wrote: >> There is no os::workaround_expand_exec_shield_cs_limit symbol available: >> >> >> collect2: error: ld returned 1 exit status >> >> That symbol is defined in `os_linux_x86.cpp`, which is not available to Zero that builds `os_linux_zero.cpp`. >> [JDK-8248271](https://bugs.openjdk.java.net/browse/JDK-8248271) added the declaration to `os_linux_zero.hpp`, but that is not enough, because the definition is still missing. I propose we move the definition up the hierarchy, to `os_linux.cpp` and protect it firmly with `IA32`. >> >> Additional testing: >> - [x] Linux {x86_32, x86_64} server builds >> - [x] Linux {x86_32, x86_64} zero builds > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Touchups after merge > - Merge branch 'master' into JDK-8256618-zero-x86 > - 8256618: Zero: Linux x86_32 build still fails Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1310 From mr at openjdk.java.net Thu Nov 19 16:55:12 2020 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 19 Nov 2020 16:55:12 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default Message-ID: Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396). Alan Bateman is the original author; I?ve credited him in the commit metadata. Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. ------------- Commit messages: - 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default Changes: https://git.openjdk.java.net/jdk/pull/1324/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256299 Stats: 161 lines in 6 files changed: 22 ins; 76 del; 63 mod Patch: https://git.openjdk.java.net/jdk/pull/1324.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1324/head:pull/1324 PR: https://git.openjdk.java.net/jdk/pull/1324 From alanb at openjdk.java.net Thu Nov 19 17:07:05 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 19 Nov 2020 17:07:05 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 16:49:30 GMT, Mark Reinhold wrote: > Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I?ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. test/lib-test/jdk/test/lib/hexdump/ASN1FormatterTest.java line 42: > 40: * @test > 41: * @summary ASN.1 formatting > 42: * @modules java.base/sun.security.util:open Roger has since fixed the test via JDK-8255394 so it no longer requires this package to be open. ------------- PR: https://git.openjdk.java.net/jdk/pull/1324 From mr at openjdk.java.net Thu Nov 19 17:16:22 2020 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 19 Nov 2020 17:16:22 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v2] In-Reply-To: References: Message-ID: > Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I?ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary @module :open from ASN1FormatterTest.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1324/files - new: https://git.openjdk.java.net/jdk/pull/1324/files/4c0e8887..baf34a19 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1324.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1324/head:pull/1324 PR: https://git.openjdk.java.net/jdk/pull/1324 From mr at openjdk.java.net Thu Nov 19 17:16:23 2020 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 19 Nov 2020 17:16:23 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v2] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 17:03:54 GMT, Alan Bateman wrote: >> Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary @module :open from ASN1FormatterTest.java > > test/lib-test/jdk/test/lib/hexdump/ASN1FormatterTest.java line 42: > >> 40: * @test >> 41: * @summary ASN.1 formatting >> 42: * @modules java.base/sun.security.util:open > > Roger has since fixed the test via JDK-8255394 so it no longer requires this package to be open. Thanks! I've removed that :open. ------------- PR: https://git.openjdk.java.net/jdk/pull/1324 From minqi at openjdk.java.net Thu Nov 19 17:31:17 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 19 Nov 2020 17:31:17 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v3] In-Reply-To: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: > Hi, Please review > Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. > > Tests: tier1,tier4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Use existing buffer to log the least message when OOM at expanding buffer ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1246/files - new: https://git.openjdk.java.net/jdk/pull/1246/files/46b58626..9ee27c40 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1246&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1246&range=01-02 Stats: 30 lines in 1 file changed: 17 ins; 7 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1246/head:pull/1246 PR: https://git.openjdk.java.net/jdk/pull/1246 From pchilanomate at openjdk.java.net Thu Nov 19 18:06:22 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 19 Nov 2020 18:06:22 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v6] In-Reply-To: References: Message-ID: > Please review the following patch to add method Mutex::try_lock_without_rank_check(). > > The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. > > The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. > > Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. > > Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. > > I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. > > In summary the patch contains the following changes: > - Add method Mutex::try_lock_without_rank_check() > - Move rank checks before trying to lock/wait on the underlying PlatformMonitor > - Clean up definitions for optimized/debug builds > - Add a new gtest to test for different rank violations scenarios > > Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: check owner directly + remove owned_by_self(Thread* thread) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1242/files - new: https://git.openjdk.java.net/jdk/pull/1242/files/c17a9c1c..030035e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1242&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1242&range=04-05 Stats: 8 lines in 2 files changed: 0 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1242.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1242/head:pull/1242 PR: https://git.openjdk.java.net/jdk/pull/1242 From pchilanomate at openjdk.java.net Thu Nov 19 18:06:24 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 19 Nov 2020 18:06:24 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v5] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 07:50:51 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> early test check_can_be_skipped + extra try_lock test > > src/hotspot/share/runtime/mutex.cpp line 148: > >> 146: // Checking the owner hides the potential difference in recursive locking behaviour >> 147: // on some platforms. >> 148: if(owned_by_self(self)) { > > Need space after if Fixed. > src/hotspot/share/runtime/mutex.cpp line 152: > >> 150: } >> 151: >> 152: if(do_rank_checks) { > > need space after if Fixed. > src/hotspot/share/runtime/mutex.cpp line 310: > >> 308: Mutex(Rank, name, allow_vm_block, safepoint_check_required) {} >> 309: >> 310: bool Mutex::owned_by_self(Thread* thread) const { > > Side comment: I'm not sure this is the right way to go versus just checking _owner directly. If you go this style then we end up with the potential for owned_by_self(self); owned_by_self(); not_owned() /* compares _owner == NULL */ and a similar range of assertions - rather than just comparing _owner directly (and with owned_by_self() convenience function). Right, I just changed it to check the owner directly. > src/hotspot/share/runtime/mutex.hpp line 204: > >> 202: Thread* owner() const { return _owner; } >> 203: void set_owner(Thread* owner) { set_owner_implementation(owner); } >> 204: bool owned_by_self(Thread* thread) const; > > Does this need to be public? Arguably when passing in a thread this should just be owned_by(x) - unless you'd also like to assert that x == Thread::current() ? I removed set_owner(Thread* owner). ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From pchilanomate at openjdk.java.net Thu Nov 19 18:17:06 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 19 Nov 2020 18:17:06 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v5] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 18:03:31 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/mutex.hpp line 204: >> >>> 202: Thread* owner() const { return _owner; } >>> 203: void set_owner(Thread* owner) { set_owner_implementation(owner); } >>> 204: bool owned_by_self(Thread* thread) const; >> >> Does this need to be public? Arguably when passing in a thread this should just be owned_by(x) - unless you'd also like to assert that x == Thread::current() ? > > I removed set_owner(Thread* owner). s/set_owner/owned_by_self ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From shade at openjdk.java.net Thu Nov 19 19:04:10 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 19 Nov 2020 19:04:10 GMT Subject: RFR: 8256670: Zero: enable compressed oops support back Message-ID: UseCompressedOops was disabled for C++ interpreter by JDK-6909153, and it eventually morphed to disabled UseCompressedOops for all Zero configurations. I see nothing that actually prevents Zero from using compressed oops: all local/stack operands are always unpacked (like they are in non-interpreted modes), all heap accesses are calling into utility methods that handle compressed oops, there are no raw accesses to oops anywhere. Additional testing: - [x] Ad-hoc benchmark tests - [x] `hotspot_gc_shenandoah` with Zero, now passing compressed oops tests ------------- Commit messages: - 8256670: Zero: enable compressed oops support back Changes: https://git.openjdk.java.net/jdk/pull/1320/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1320&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256670 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1320/head:pull/1320 PR: https://git.openjdk.java.net/jdk/pull/1320 From shade at openjdk.java.net Thu Nov 19 19:11:10 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 19 Nov 2020 19:11:10 GMT Subject: RFR: 8256675: Zero: purge biased locking support Message-ID: Biased locking support was always disabled for C++ interpreter. Zero seems to have inherited that, see block in `arguments.cpp`: #ifdef ZERO // Clear flags not supported on zero. FLAG_SET_DEFAULT(ProfileInterpreter, false); FLAG_SET_DEFAULT(UseBiasedLocking, false); LP64_ONLY(FLAG_SET_DEFAULT(UseCompressedOops, false)); LP64_ONLY(FLAG_SET_DEFAULT(UseCompressedClassPointers, false)); #endif // ZERO But `zero/bytecodeInterpreter.cpp` still has paths that imply biased locking support. Seeing that biased locking can go away, and the cost/benefit balance of supporting it in Zero, it makes more sense to purge the long-time-disabled biased locking support from Zero. Additional testing: - [x] Ad-hoc benchmark runs with `-XX:(-|+)UseBiasedLocking` (Zero is so slow that BL does not matter) ------------- Commit messages: - 8256675: Zero: purge biased locking support Changes: https://git.openjdk.java.net/jdk/pull/1322/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1322&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256675 Stats: 237 lines in 1 file changed: 1 ins; 201 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/1322.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1322/head:pull/1322 PR: https://git.openjdk.java.net/jdk/pull/1322 From minqi at openjdk.java.net Thu Nov 19 19:27:20 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 19 Nov 2020 19:27:20 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v4] In-Reply-To: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: > Hi, Please review > Unified Logging uses 512 bytes buffer on stack for printing out message, above that will allocate heap for extra space needed. This may potentially may cause a circulation when we log the heap allocation and the log message is over 512. The max logging buffer size now is increased to 4096 and above that, output will be truncated. > > Tests: tier1,tier4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fix Copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1246/files - new: https://git.openjdk.java.net/jdk/pull/1246/files/9ee27c40..9a2f7b79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1246&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1246&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1246.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1246/head:pull/1246 PR: https://git.openjdk.java.net/jdk/pull/1246 From coleenp at openjdk.java.net Thu Nov 19 19:35:10 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 19 Nov 2020 19:35:10 GMT Subject: RFR: JDK-8255885: Metaspace: freelist commit counter is not updated when purging In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 14:32:44 GMT, Thomas Stuefe wrote: > Metaspace chunks are uncommitted, under certain conditions, when being returned to the Metaspace by a dying class loader. > > There are two places where this happens: > 1) when individual chunks are returned (see ChunkManager::return_chunk_locked()) > 2) later, when CLDG::purge()->Metaspace::purge()->ChunkManager::purge() is called - all free chunks are again checked and potentially uncommitted. > > Free chunks are kept in FreeChunkList. FreeChunkList has a counter for words-comitted. That counter gets updated when chunks are added and removed. However, path (2) does not change the list, it just uncommits chunks residing in that list. That passes under the FreeChunkList's radar and now the counter is off. > > ----- > > Review note: `ChunkManager` keeps free chunks. It has an instance of `FreeChunkListVector`, which has a series (one per chunk size) of `FreeChunkList` instances. The commit counter value is handed up from `FreeChunkList` to, eventually, `ChunkManager`. > > What changed: > > - I removed the counter (_committed_word_size) from FreeChunkList. This seemed the simplest and safest measure. Keeping this counter up-to-date is a hassle, since chunks may get committed and uncommitted while being in this list. > > - Now we calculate the number of committed words on the fly if asked, by iterating all chunks in the list and accumulating. To reflect this change, I change the name of "FreeChunkList::committed_word_size()" to "FreeChunkList::calc_committed_word_size()". In metaspace, anything named "calc_" is potentially expensive. > > - Same renamings in FreeChunkListVector and ChunkManager::total_committed_word_size() - to ChunkManager::calc_committed_word_size() > > Now these functions always deliver the correct result. However, they are potentially slower and now require the central metaspace lock. That is not a problem: the only user of this function is when collecting the statistics for the "VM.metaspace" jcmd report, and that happens under lock protection and walks all kind of stuff anyway, so walking the freelists won't hurt. > > Just to be sure, I removed the use of these functions from ChunkManager::print_on(), even though that was just a debug function. > > ----- > > Tests: > > This patch has been tested in our nightlies for a week now. This seems good and more accurate to recalculate the size committed in each chunk by iterating through the chunks. For path 2 in your description, for Metaspace::purge() I thought that chunks are returned to the ChunkFreeList from the ChunkList on each metaspace. So they should be accounted for. Or is the issue that committed_words within each chunk varies and remove() only captures a snapshot in time? At any rate, it's good to not have this in the logging and printing if it's going to be expensive but accurate. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1057 From coleenp at openjdk.java.net Thu Nov 19 19:37:08 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 19 Nov 2020 19:37:08 GMT Subject: RFR: 8256670: Zero: enable compressed oops support back In-Reply-To: References: Message-ID: <5SmiGtOHfHzyeHRqiZqH92leJaZnsahnxkSBbr29z-w=.ba0c07e7-5f41-404b-b34b-944361419a78@github.com> On Thu, 19 Nov 2020 15:38:17 GMT, Aleksey Shipilev wrote: > UseCompressedOops was disabled for C++ interpreter by JDK-6909153, and it eventually morphed to disabled UseCompressedOops for all Zero configurations. I see nothing that actually prevents Zero from using compressed oops: all local/stack operands are always unpacked (like they are in non-interpreted modes), all heap accesses are calling into utility methods that handle compressed oops, there are no raw accesses to oops anywhere. > > Additional testing: > - [x] Ad-hoc benchmark tests > - [x] `hotspot_gc_shenandoah` with Zero, now passing compressed oops tests Seems okay to me. I can't think of why zero disabled compressed oops. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1320 From coleenp at openjdk.java.net Thu Nov 19 19:44:07 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 19 Nov 2020 19:44:07 GMT Subject: RFR: 8256675: Zero: purge biased locking support In-Reply-To: References: Message-ID: <_oAhTil7WuB0MXI5jW4yKcHoH0ps_z4ArUN4GcY1EmY=.9a5816b6-c293-48ed-906b-68b84b5386fb@github.com> On Thu, 19 Nov 2020 16:23:54 GMT, Aleksey Shipilev wrote: > Biased locking support was always disabled for C++ interpreter. Zero seems to have inherited that, see block in `arguments.cpp`: > > #ifdef ZERO > // Clear flags not supported on zero. > FLAG_SET_DEFAULT(ProfileInterpreter, false); > FLAG_SET_DEFAULT(UseBiasedLocking, false); > LP64_ONLY(FLAG_SET_DEFAULT(UseCompressedOops, false)); > LP64_ONLY(FLAG_SET_DEFAULT(UseCompressedClassPointers, false)); > #endif // ZERO > > But `zero/bytecodeInterpreter.cpp` still has paths that imply biased locking support. Seeing that biased locking can go away, and the cost/benefit balance of supporting it in Zero, it makes more sense to purge the long-time-disabled biased locking support from Zero. > > Additional testing: > - [x] Ad-hoc benchmark runs with `-XX:(-|+)UseBiasedLocking` (Zero is so slow that BL does not matter) Wow that was a lot of code. Looks good to me. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1322 From minqi at openjdk.java.net Thu Nov 19 19:46:08 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 19 Nov 2020 19:46:08 GMT Subject: RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 23:58:25 GMT, Calvin Cheung wrote: > Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set. > > This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically: > > - remove the above workaround; > > - capture the setting of the property in the archive header during CDS dump time; > > - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header. > If the values don't match, the archived lambda proxy class won't be used. > > Tests: > > - [x] ran all cds tests locally on linux-x64 > > - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64 > > - [x] mach5 tiers 1,2,3 (in progress) src/hotspot/share/memory/metaspaceShared.cpp line 76: > 74: #endif > 75: > 76: #include This include is strange, usually we do not include std head file in .cpp file. ------------- PR: https://git.openjdk.java.net/jdk/pull/1301 From mchung at openjdk.java.net Thu Nov 19 19:55:09 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 19 Nov 2020 19:55:09 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v2] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 17:16:22 GMT, Mark Reinhold wrote: >> Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396). >> Alan Bateman is the original author; I?ve credited him in the commit metadata. >> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. > > Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary @module :open from ASN1FormatterTest.java Marked as reviewed by mchung (Reviewer). test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java line 387: > 385: "--illegal-access=permit"); > 386: } > 387: I see `setAccessibleNonPublicMemberExportedPackage` test case testing with `--add-exports` and `--add-opens` and `Add-Opens` in JAR file manifest but not testing with `Add-Exports`. Is it worth to include the `Add-Exports` test case? Other than this, looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1324 From minqi at openjdk.java.net Thu Nov 19 19:57:04 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 19 Nov 2020 19:57:04 GMT Subject: RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 23:58:25 GMT, Calvin Cheung wrote: > Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set. > > This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically: > > - remove the above workaround; > > - capture the setting of the property in the archive header during CDS dump time; > > - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header. > If the values don't match, the archived lambda proxy class won't be used. > > Tests: > > - [x] ran all cds tests locally on linux-x64 > > - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64 > > - [x] mach5 tiers 1,2,3 (in progress) src/hotspot/share/memory/metaspaceShared.cpp line 1821: > 1819: } > 1820: > 1821: void MetaspaceShared::set_disable_eager_init(const char* value) { strcasecmp is not platform dependent, why not use it for all? It does not need included. test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaEagerInit.java line 35: > 33: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds > 34: * @compile ../../../../../../jdk/java/lang/invoke/lambda/LambdaEagerInitTest.java > 35: * @build sun.hotspot.WhiteBox Do we need WB here? ------------- PR: https://git.openjdk.java.net/jdk/pull/1301 From pchilanomate at openjdk.java.net Thu Nov 19 19:58:10 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 19 Nov 2020 19:58:10 GMT Subject: RFR: 8256675: Zero: purge biased locking support In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 16:23:54 GMT, Aleksey Shipilev wrote: > Biased locking support was always disabled for C++ interpreter. Zero seems to have inherited that, see block in `arguments.cpp`: > > #ifdef ZERO > // Clear flags not supported on zero. > FLAG_SET_DEFAULT(ProfileInterpreter, false); > FLAG_SET_DEFAULT(UseBiasedLocking, false); > LP64_ONLY(FLAG_SET_DEFAULT(UseCompressedOops, false)); > LP64_ONLY(FLAG_SET_DEFAULT(UseCompressedClassPointers, false)); > #endif // ZERO > > But `zero/bytecodeInterpreter.cpp` still has paths that imply biased locking support. Seeing that biased locking can go away, and the cost/benefit balance of supporting it in Zero, it makes more sense to purge the long-time-disabled biased locking support from Zero. > > Additional testing: > - [x] Ad-hoc benchmark runs with `-XX:(-|+)UseBiasedLocking` (Zero is so slow that BL does not matter) Hi Aleksey, Changes look good to me. There are 3 places left when unlocking the monitor where there is a has_bias_pattern() check. Maybe change them into an assert? (seems Github doesn't allow to add comments on collapsed lines). Thanks, Patricio ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk/pull/1322 From stuefe at openjdk.java.net Thu Nov 19 20:50:04 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 19 Nov 2020 20:50:04 GMT Subject: RFR: JDK-8255885: Metaspace: freelist commit counter is not updated when purging In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 19:32:45 GMT, Coleen Phillimore wrote: > This seems good and more accurate to recalculate the size committed in each chunk by iterating through the chunks. Thank you! > For path 2 in your description, for Metaspace::purge() I thought that chunks are returned to the ChunkFreeList from the ChunkList on each metaspace. So they should be accounted for. Or is the issue that committed_words within each chunk varies and remove() only captures a snapshot in time? Yes. We return chunks via this path: `~CLD -> ~ClassLoaderMetaspace -> ~MetaspaceArena -> (for each chunk) ChunkManager::return_chunk() -> .. -> FreeChunkList::add().` (a) Here, FreeChunkList::_committed_words gets updated from the added chunk's _committed_words. But chunks can be committed and uncommitted from anywhere really, and the containing list would not notice. This can happen in several places, one of which is when metaspace is purged some cylces later in (b) path 2: https://github.com/openjdk/jdk/blob/080c707aabcf1b2ed30009cb408ecf52bd1784fd/src/hotspot/share/memory/metaspace/chunkManager.cpp#L346 which uncommits chunks and the freelist would not notice. Rather than introduce some elaborate counter update mechanism, I just remove it. > At any rate, it's good to not have this in the logging and printing if it's going to be expensive but accurate. Yes I think so too. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1057 From mchung at openjdk.java.net Thu Nov 19 21:06:04 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 19 Nov 2020 21:06:04 GMT Subject: RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: <2HAKrvsORLsNHOY10PyQ395snpigQ7t0ZhAKUVIoPlk=.0540d08a-e46a-4e80-9719-4f16acc943d2@github.com> Message-ID: On Thu, 19 Nov 2020 16:09:41 GMT, Claes Redestad wrote: >> Hi Claes, >> >> Thanks for taking a look. >> >> So should I keep the following `!initialize` check in LambdaProxyClassArchive? >> 109 if (!loadedByBuiltinLoader(caller) || !initialize || >> 110 !CDS.isSharingEnabled() || isSerializable || markerInterfaces.length > 0 || additionalBridges.length > 0) >> 111 return null; >> If we keep the above code, I think we don't need to pass the `initialize` to `findFromArchive` and eventually to `JVM_LookupLambdaProxyClassFromArchive`. >> >> Let me know if the above is what you have in mind? >> >> thanks, >> Calvin > > Right, I'd drop that argument - I would go further and suggest making calls to both `LambdaProxyClassArchive.register` and `LambdaProxyClassArchive.find` conditional on `disableEagerInitialization` being `false` to avoid any accidental mix-up and reduce complexity of these orthogonal features/concerns. I agree with Claes that this is a wrong move to archive lambda proxies even if `disableEagerInitialization` is set. A simple fix would be: private Class spinInnerClass() throws LambdaConversionException { if (!disableEagerInitialization) { if (LambdaProxyClassArchive.isDumpArchive()) { ... } // load from CDS archive if present Class archiveClass = LambdaProxyClassArchive.find(targetClass, samMethodName, invokedType, samMethodType, implMethod, instantiatedMethodType, isSerializable, markerInterfaces, additionalBridges, true); if (archiveClass != null) return archiveClass; } return generateInnerClass(); } ------------- PR: https://git.openjdk.java.net/jdk/pull/1301 From coleenp at openjdk.java.net Thu Nov 19 21:32:04 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 19 Nov 2020 21:32:04 GMT Subject: RFR: JDK-8255885: Metaspace: freelist commit counter is not updated when purging In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 20:47:04 GMT, Thomas Stuefe wrote: > which uncommits chunks and the freelist would not notice. Rather than introduce some elaborate counter update mechanism, I just remove it. Sounds good! ------------- PR: https://git.openjdk.java.net/jdk/pull/1057 From dholmes at openjdk.java.net Thu Nov 19 21:58:09 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 19 Nov 2020 21:58:09 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v6] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 18:06:22 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch to add method Mutex::try_lock_without_rank_check(). >> >> The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. >> >> The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. >> >> Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. >> >> Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. >> >> I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. >> >> In summary the patch contains the following changes: >> - Add method Mutex::try_lock_without_rank_check() >> - Move rank checks before trying to lock/wait on the underlying PlatformMonitor >> - Clean up definitions for optimized/debug builds >> - Add a new gtest to test for different rank violations scenarios >> >> Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > check owner directly + remove owned_by_self(Thread* thread) LGTM! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1242 From dholmes at openjdk.java.net Thu Nov 19 22:01:03 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 19 Nov 2020 22:01:03 GMT Subject: RFR: 8256594: Unexpected warning: SIGSEGV handler flags expected:SA_RESTART|SA_SIGINFO found:SA_RESTART|SA_SIGINFO In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 10:33:39 GMT, Thomas Stuefe wrote: >> In the recent POSIX signal code cleanup (JDK-8253742) I misunderstood the role of the SIGNIFICANT_SIGNAL_MASK and removing its application causes -Xcheck:jni to report errors with the signal handler due to an unexpected bit in the sigaction.sa_flags field. >> >> This fix restores the masking of that flag, for Linux only, and more clearly indicating what it is. I also augmented the flag printing code to show when an unexpected flag is present (and so avoid the mysterious "expected X found X" message). >> >> See bug report for more details. >> >> Thanks. > > LGTM. > > Note that a maybe more elegant approach - avoiding the double definition of known flags - would have been, in the print loop, to store the checked flags in a mask. And then test for ~mask at the final step. > > The numeric comparison of flags in check_jni - which requires this SA_RESTORER_FLAG_MASK workaround - is a bit grating. Would have been better to compare just known flags. But this is old coding. > > All idle nitpicking :) Patch is fine. > > ..Thomas Can I get a second review ASAP please as this is causing quite a bit of noise in the testing. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1309 From dholmes at openjdk.java.net Thu Nov 19 22:25:19 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 19 Nov 2020 22:25:19 GMT Subject: RFR: 8256594: Unexpected warning: SIGSEGV handler flags expected:SA_RESTART|SA_SIGINFO found:SA_RESTART|SA_SIGINFO [v2] In-Reply-To: References: Message-ID: > In the recent POSIX signal code cleanup (JDK-8253742) I misunderstood the role of the SIGNIFICANT_SIGNAL_MASK and removing its application causes -Xcheck:jni to report errors with the signal handler due to an unexpected bit in the sigaction.sa_flags field. > > This fix restores the masking of that flag, for Linux only, and more clearly indicating what it is. I also augmented the flag printing code to show when an unexpected flag is present (and so avoid the mysterious "expected X found X" message). > > See bug report for more details. > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Added missing mask of VMError::get_resetted_sigflags(sig) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1309/files - new: https://git.openjdk.java.net/jdk/pull/1309/files/50ae0847..f7626ba1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1309&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1309&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1309/head:pull/1309 PR: https://git.openjdk.java.net/jdk/pull/1309 From dholmes at openjdk.java.net Thu Nov 19 22:25:19 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 19 Nov 2020 22:25:19 GMT Subject: RFR: 8256594: Unexpected warning: SIGSEGV handler flags expected:SA_RESTART|SA_SIGINFO found:SA_RESTART|SA_SIGINFO [v2] In-Reply-To: References: Message-ID: <97yW9RRrSeVfotaspfou2KVfyqy_XjhI_gfryxIdYa4=.7296d047-7228-402b-a449-96845b0c6989@github.com> On Thu, 19 Nov 2020 21:58:19 GMT, David Holmes wrote: >> LGTM. >> >> Note that a maybe more elegant approach - avoiding the double definition of known flags - would have been, in the print loop, to store the checked flags in a mask. And then test for ~mask at the final step. >> >> The numeric comparison of flags in check_jni - which requires this SA_RESTORER_FLAG_MASK workaround - is a bit grating. Would have been better to compare just known flags. But this is old coding. >> >> All idle nitpicking :) Patch is fine. >> >> ..Thomas > > Can I get a second review ASAP please as this is causing quite a bit of noise in the testing. > Thanks. When discussing with Coleen I realized I had omitted part of the fix - the masking of VMError::get_resetted_sigflags(sig). ------------- PR: https://git.openjdk.java.net/jdk/pull/1309 From coleenp at openjdk.java.net Thu Nov 19 22:32:05 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 19 Nov 2020 22:32:05 GMT Subject: RFR: 8256594: Unexpected warning: SIGSEGV handler flags expected:SA_RESTART|SA_SIGINFO found:SA_RESTART|SA_SIGINFO [v2] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 22:25:19 GMT, David Holmes wrote: >> In the recent POSIX signal code cleanup (JDK-8253742) I misunderstood the role of the SIGNIFICANT_SIGNAL_MASK and removing its application causes -Xcheck:jni to report errors with the signal handler due to an unexpected bit in the sigaction.sa_flags field. >> >> This fix restores the masking of that flag, for Linux only, and more clearly indicating what it is. I also augmented the flag printing code to show when an unexpected flag is present (and so avoid the mysterious "expected X found X" message). >> >> See bug report for more details. >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Added missing mask of VMError::get_resetted_sigflags(sig) So this looks like it matches the 3 places that 8253742 removed. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1309 From mr at openjdk.java.net Thu Nov 19 23:08:22 2020 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 19 Nov 2020 23:08:22 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 19:51:59 GMT, Mandy Chung wrote: >> Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: >> >> Add "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test > > test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java line 387: > >> 385: "--illegal-access=permit"); >> 386: } >> 387: > > I see `setAccessibleNonPublicMemberExportedPackage` test case testing with `--add-exports` and `--add-opens` and `Add-Opens` in JAR file manifest but not testing with `Add-Exports`. > > Is it worth to include the `Add-Exports` test case? > > Other than this, looks good. Good point -- case added. ------------- PR: https://git.openjdk.java.net/jdk/pull/1324 From mr at openjdk.java.net Thu Nov 19 23:08:21 2020 From: mr at openjdk.java.net (Mark Reinhold) Date: Thu, 19 Nov 2020 23:08:21 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3] In-Reply-To: References: Message-ID: > Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I?ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: Add "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1324/files - new: https://git.openjdk.java.net/jdk/pull/1324/files/baf34a19..a57e6065 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=01-02 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1324.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1324/head:pull/1324 PR: https://git.openjdk.java.net/jdk/pull/1324 From jiefu at openjdk.java.net Thu Nov 19 23:56:01 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 19 Nov 2020 23:56:01 GMT Subject: RFR: 8256640: assert(!m->is_old() || ik()->is_being_redefined()) failed: old methods should not be in vtable In-Reply-To: References: <184hAHQXaLG-XCg4KKek9mFcvdpSMHWZxauIvAkcny8=.ea6009a9-1bc3-4364-be4b-958994033890@github.com> Message-ID: On Thu, 19 Nov 2020 15:24:09 GMT, Coleen Phillimore wrote: > This is the patch for this failure but default methods could still get an old method if it's redefined while doing constraint checks. I'd like to take this bug. > > $ git diff > diff --git a/src/hotspot/share/oops/instanceKlass.cpp b/src/hotspot/share/oops/instanceKlass.cpp > index 4c720bb..fe7ac9e 100644 > --- a/src/hotspot/share/oops/instanceKlass.cpp > +++ b/src/hotspot/share/oops/instanceKlass.cpp > @@ -2577,6 +2577,10 @@ void InstanceKlass::restore_unshareable_info(ClassLoaderData* loader_data, Handl > // point to old or obsolete entries. RedefineClasses doesn't fix up > // vtables in the shared system dictionary, only the main one. > // It also redefines the itable too so fix that too. > > * // First fix any default methods that point to a super class that may > * // have been redefined. > * bool trace_name_printed = false; > * adjust_default_methods(&trace_name_printed); > vtable().initialize_vtable(false, CHECK); > itable().initialize_itable(false, CHECK); > } Thanks @coleenp for fixing this bug. Much have been learned. Best regards, Jie ------------- PR: https://git.openjdk.java.net/jdk/pull/1313 From jiefu at openjdk.java.net Thu Nov 19 23:56:02 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 19 Nov 2020 23:56:02 GMT Subject: Withdrawn: 8256640: assert(!m->is_old() || ik()->is_being_redefined()) failed: old methods should not be in vtable In-Reply-To: <184hAHQXaLG-XCg4KKek9mFcvdpSMHWZxauIvAkcny8=.ea6009a9-1bc3-4364-be4b-958994033890@github.com> References: <184hAHQXaLG-XCg4KKek9mFcvdpSMHWZxauIvAkcny8=.ea6009a9-1bc3-4364-be4b-958994033890@github.com> Message-ID: On Thu, 19 Nov 2020 12:15:05 GMT, Jie Fu wrote: > Hi all, > > java/lang/instrument/IsModifiableClassAgent.java fails after JDK-8256365. > The reason is that the newly added assert [1] doesn't consider the case when the super class had been redefined. > > Please review it. > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/klassVtable.cpp#L564 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1313 From mchung at openjdk.java.net Fri Nov 20 03:31:04 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 20 Nov 2020 03:31:04 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 23:03:54 GMT, Mark Reinhold wrote: >> test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java line 387: >> >>> 385: "--illegal-access=permit"); >>> 386: } >>> 387: >> >> I see `setAccessibleNonPublicMemberExportedPackage` test case testing with `--add-exports` and `--add-opens` and `Add-Opens` in JAR file manifest but not testing with `Add-Exports`. >> >> Is it worth to include the `Add-Exports` test case? >> >> Other than this, looks good. > > Good point -- case added. Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1324 From dcubed at openjdk.java.net Fri Nov 20 03:58:04 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 20 Nov 2020 03:58:04 GMT Subject: RFR: 8256594: Unexpected warning: SIGSEGV handler flags expected:SA_RESTART|SA_SIGINFO found:SA_RESTART|SA_SIGINFO [v2] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 22:25:19 GMT, David Holmes wrote: >> In the recent POSIX signal code cleanup (JDK-8253742) I misunderstood the role of the SIGNIFICANT_SIGNAL_MASK and removing its application causes -Xcheck:jni to report errors with the signal handler due to an unexpected bit in the sigaction.sa_flags field. >> >> This fix restores the masking of that flag, for Linux only, and more clearly indicating what it is. I also augmented the flag printing code to show when an unexpected flag is present (and so avoid the mysterious "expected X found X" message). >> >> See bug report for more details. >> >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Added missing mask of VMError::get_resetted_sigflags(sig) Changes match what you described. Thumbs up. src/hotspot/os/posix/signals_posix.cpp line 54: > 52: // in this flag and need to ignore it when checking our > 53: // own flag settings. > 54: // Note: SA_RESTORER is not exposed through signal.h so we Should this comment mention `SA_RESTORER` or `SA_RESTORER_FLAG_MASK`? ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1309 From dholmes at openjdk.java.net Fri Nov 20 04:21:13 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 20 Nov 2020 04:21:13 GMT Subject: RFR: 8256594: Unexpected warning: SIGSEGV handler flags expected:SA_RESTART|SA_SIGINFO found:SA_RESTART|SA_SIGINFO [v3] In-Reply-To: References: Message-ID: > In the recent POSIX signal code cleanup (JDK-8253742) I misunderstood the role of the SIGNIFICANT_SIGNAL_MASK and removing its application causes -Xcheck:jni to report errors with the signal handler due to an unexpected bit in the sigaction.sa_flags field. > > This fix restores the masking of that flag, for Linux only, and more clearly indicating what it is. I also augmented the flag printing code to show when an unexpected flag is present (and so avoid the mysterious "expected X found X" message). > > See bug report for more details. > > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Tweaked a comment. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1309/files - new: https://git.openjdk.java.net/jdk/pull/1309/files/f7626ba1..42847fe5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1309&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1309&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1309/head:pull/1309 PR: https://git.openjdk.java.net/jdk/pull/1309 From dholmes at openjdk.java.net Fri Nov 20 04:21:14 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 20 Nov 2020 04:21:14 GMT Subject: RFR: 8256594: Unexpected warning: SIGSEGV handler flags expected:SA_RESTART|SA_SIGINFO found:SA_RESTART|SA_SIGINFO [v2] In-Reply-To: References: Message-ID: <7lsCLh76EEnoyUtVhyluvVi9nmsSMLz6nc0mCNEhhqA=.3633a5ad-673d-4859-9854-cc374014c1f4@github.com> On Fri, 20 Nov 2020 03:55:42 GMT, Daniel D. Daugherty wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Added missing mask of VMError::get_resetted_sigflags(sig) > > Changes match what you described. Thumbs up. Thanks for the reviews. > src/hotspot/os/posix/signals_posix.cpp line 54: > >> 52: // in this flag and need to ignore it when checking our >> 53: // own flag settings. >> 54: // Note: SA_RESTORER is not exposed through signal.h so we > > Should this comment mention `SA_RESTORER` or `SA_RESTORER_FLAG_MASK`? I'll tweak the comment before pushing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1309 From dholmes at openjdk.java.net Fri Nov 20 04:21:15 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 20 Nov 2020 04:21:15 GMT Subject: Integrated: 8256594: Unexpected warning: SIGSEGV handler flags expected:SA_RESTART|SA_SIGINFO found:SA_RESTART|SA_SIGINFO In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 07:45:03 GMT, David Holmes wrote: > In the recent POSIX signal code cleanup (JDK-8253742) I misunderstood the role of the SIGNIFICANT_SIGNAL_MASK and removing its application causes -Xcheck:jni to report errors with the signal handler due to an unexpected bit in the sigaction.sa_flags field. > > This fix restores the masking of that flag, for Linux only, and more clearly indicating what it is. I also augmented the flag printing code to show when an unexpected flag is present (and so avoid the mysterious "expected X found X" message). > > See bug report for more details. > > Thanks. This pull request has now been integrated. Changeset: fa240f22 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/fa240f22 Stats: 33 lines in 1 file changed: 29 ins; 0 del; 4 mod 8256594: Unexpected warning: SIGSEGV handler flags expected:SA_RESTART|SA_SIGINFO found:SA_RESTART|SA_SIGINFO Reviewed-by: stuefe, coleenp, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/1309 From ccheung at openjdk.java.net Fri Nov 20 04:45:06 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 20 Nov 2020 04:45:06 GMT Subject: RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 19:42:51 GMT, Yumin Qi wrote: >> Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set. >> >> This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically: >> >> - remove the above workaround; >> >> - capture the setting of the property in the archive header during CDS dump time; >> >> - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header. >> If the values don't match, the archived lambda proxy class won't be used. >> >> Tests: >> >> - [x] ran all cds tests locally on linux-x64 >> >> - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64 >> >> - [x] mach5 tiers 1,2,3 (in progress) > > src/hotspot/share/memory/metaspaceShared.cpp line 76: > >> 74: #endif >> 75: >> 76: #include > > This include is strange, usually we do not include std head file in .cpp file. The include is needed for strcasecmp and _stricmp. If you do a grep like `find . -name "*.cpp" | xargs grep "#include <"`, you'll find many .cpp files include std header files. > src/hotspot/share/memory/metaspaceShared.cpp line 1821: > >> 1819: } >> 1820: >> 1821: void MetaspaceShared::set_disable_eager_init(const char* value) { > > strcasecmp is not platform dependent, why not use it for all? It does not need included. According to https://en.wikipedia.org/wiki/C_string_handling, strcasecmp is for POSIX, BSD, stricmp is for Windows. > test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaEagerInit.java line 35: > >> 33: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds >> 34: * @compile ../../../../../../jdk/java/lang/invoke/lambda/LambdaEagerInitTest.java >> 35: * @build sun.hotspot.WhiteBox > > Do we need WB here? Our current design is that every test under the `dynamicArchive` dir extends `DynamicArchiveTestBase` which depends on `sun.hotspot.WhiteBox`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1301 From ccheung at openjdk.java.net Fri Nov 20 04:50:04 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 20 Nov 2020 04:50:04 GMT Subject: Withdrawn: 8256487: Handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 23:58:25 GMT, Calvin Cheung wrote: > Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set. > > This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically: > > - remove the above workaround; > > - capture the setting of the property in the archive header during CDS dump time; > > - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header. > If the values don't match, the archived lambda proxy class won't be used. > > Tests: > > - [x] ran all cds tests locally on linux-x64 > > - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64 > > - [x] mach5 tiers 1,2,3 (in progress) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1301 From ccheung at openjdk.java.net Fri Nov 20 04:50:02 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 20 Nov 2020 04:50:02 GMT Subject: RFR: 8256487: Handle disableEagerInitialization for archived lambda proxy classes In-Reply-To: References: <2HAKrvsORLsNHOY10PyQ395snpigQ7t0ZhAKUVIoPlk=.0540d08a-e46a-4e80-9719-4f16acc943d2@github.com> Message-ID: On Thu, 19 Nov 2020 16:09:41 GMT, Claes Redestad wrote: >> Hi Claes, >> >> Thanks for taking a look. >> >> So should I keep the following `!initialize` check in LambdaProxyClassArchive? >> 109 if (!loadedByBuiltinLoader(caller) || !initialize || >> 110 !CDS.isSharingEnabled() || isSerializable || markerInterfaces.length > 0 || additionalBridges.length > 0) >> 111 return null; >> If we keep the above code, I think we don't need to pass the `initialize` to `findFromArchive` and eventually to `JVM_LookupLambdaProxyClassFromArchive`. >> >> Let me know if the above is what you have in mind? >> >> thanks, >> Calvin > > Right, I'd drop that argument - I would go further and suggest making calls to both `LambdaProxyClassArchive.register` and `LambdaProxyClassArchive.find` conditional on `disableEagerInitialization` being `false` to avoid any accidental mix-up and reduce complexity of these orthogonal features/concerns. Closing this pull request. I'll file another bug to address suggestions from @cl4es and @mlchung. ------------- PR: https://git.openjdk.java.net/jdk/pull/1301 From iklam at openjdk.java.net Fri Nov 20 06:45:02 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 20 Nov 2020 06:45:02 GMT Subject: RFR: JDK-8255885: Metaspace: freelist commit counter is not updated when purging In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 14:32:44 GMT, Thomas Stuefe wrote: > Metaspace chunks are uncommitted, under certain conditions, when being returned to the Metaspace by a dying class loader. > > There are two places where this happens: > 1) when individual chunks are returned (see ChunkManager::return_chunk_locked()) > 2) later, when CLDG::purge()->Metaspace::purge()->ChunkManager::purge() is called - all free chunks are again checked and potentially uncommitted. > > Free chunks are kept in FreeChunkList. FreeChunkList has a counter for words-comitted. That counter gets updated when chunks are added and removed. However, path (2) does not change the list, it just uncommits chunks residing in that list. That passes under the FreeChunkList's radar and now the counter is off. > > ----- > > Review note: `ChunkManager` keeps free chunks. It has an instance of `FreeChunkListVector`, which has a series (one per chunk size) of `FreeChunkList` instances. The commit counter value is handed up from `FreeChunkList` to, eventually, `ChunkManager`. > > What changed: > > - I removed the counter (_committed_word_size) from FreeChunkList. This seemed the simplest and safest measure. Keeping this counter up-to-date is a hassle, since chunks may get committed and uncommitted while being in this list. > > - Now we calculate the number of committed words on the fly if asked, by iterating all chunks in the list and accumulating. To reflect this change, I change the name of "FreeChunkList::committed_word_size()" to "FreeChunkList::calc_committed_word_size()". In metaspace, anything named "calc_" is potentially expensive. > > - Same renamings in FreeChunkListVector and ChunkManager::total_committed_word_size() - to ChunkManager::calc_committed_word_size() > > Now these functions always deliver the correct result. However, they are potentially slower and now require the central metaspace lock. That is not a problem: the only user of this function is when collecting the statistics for the "VM.metaspace" jcmd report, and that happens under lock protection and walks all kind of stuff anyway, so walking the freelists won't hurt. > > Just to be sure, I removed the use of these functions from ChunkManager::print_on(), even though that was just a debug function. > > ----- > > Tests: > > This patch has been tested in our nightlies for a week now. Looks good to me. I checked the current code and this function is used only during printing, etc. I just want to confirm -- there's no plan to use this function in the future for performance-critical stuff, right? ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1057 From stuefe at openjdk.java.net Fri Nov 20 06:55:02 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 20 Nov 2020 06:55:02 GMT Subject: RFR: JDK-8255885: Metaspace: freelist commit counter is not updated when purging In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 06:42:21 GMT, Ioi Lam wrote: >> Metaspace chunks are uncommitted, under certain conditions, when being returned to the Metaspace by a dying class loader. >> >> There are two places where this happens: >> 1) when individual chunks are returned (see ChunkManager::return_chunk_locked()) >> 2) later, when CLDG::purge()->Metaspace::purge()->ChunkManager::purge() is called - all free chunks are again checked and potentially uncommitted. >> >> Free chunks are kept in FreeChunkList. FreeChunkList has a counter for words-comitted. That counter gets updated when chunks are added and removed. However, path (2) does not change the list, it just uncommits chunks residing in that list. That passes under the FreeChunkList's radar and now the counter is off. >> >> ----- >> >> Review note: `ChunkManager` keeps free chunks. It has an instance of `FreeChunkListVector`, which has a series (one per chunk size) of `FreeChunkList` instances. The commit counter value is handed up from `FreeChunkList` to, eventually, `ChunkManager`. >> >> What changed: >> >> - I removed the counter (_committed_word_size) from FreeChunkList. This seemed the simplest and safest measure. Keeping this counter up-to-date is a hassle, since chunks may get committed and uncommitted while being in this list. >> >> - Now we calculate the number of committed words on the fly if asked, by iterating all chunks in the list and accumulating. To reflect this change, I change the name of "FreeChunkList::committed_word_size()" to "FreeChunkList::calc_committed_word_size()". In metaspace, anything named "calc_" is potentially expensive. >> >> - Same renamings in FreeChunkListVector and ChunkManager::total_committed_word_size() - to ChunkManager::calc_committed_word_size() >> >> Now these functions always deliver the correct result. However, they are potentially slower and now require the central metaspace lock. That is not a problem: the only user of this function is when collecting the statistics for the "VM.metaspace" jcmd report, and that happens under lock protection and walks all kind of stuff anyway, so walking the freelists won't hurt. >> >> Just to be sure, I removed the use of these functions from ChunkManager::print_on(), even though that was just a debug function. >> >> ----- >> >> Tests: >> >> This patch has been tested in our nightlies for a week now. > > Looks good to me. I checked the current code and this function is used only during printing, etc. I just want to confirm -- there's no plan to use this function in the future for performance-critical stuff, right? Hi Ioi, > Looks good to me. Thanks! > I checked the current code and this function is used only during printing, etc. I just want to confirm -- there's no plan to use this function in the future for performance-critical stuff, right? No. Should we need a quick estimate of committed-in-freelist (e.g. at some point for a better JFR statistic) there is a shortcut one could take by just assuming all chunks >= granule size are uncommitted in normal reclaim mode. This is in 98% of cases true. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1057 From stuefe at openjdk.java.net Fri Nov 20 06:55:04 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 20 Nov 2020 06:55:04 GMT Subject: Integrated: JDK-8255885: Metaspace: freelist commit counter is not updated when purging In-Reply-To: References: Message-ID: On Wed, 4 Nov 2020 14:32:44 GMT, Thomas Stuefe wrote: > Metaspace chunks are uncommitted, under certain conditions, when being returned to the Metaspace by a dying class loader. > > There are two places where this happens: > 1) when individual chunks are returned (see ChunkManager::return_chunk_locked()) > 2) later, when CLDG::purge()->Metaspace::purge()->ChunkManager::purge() is called - all free chunks are again checked and potentially uncommitted. > > Free chunks are kept in FreeChunkList. FreeChunkList has a counter for words-comitted. That counter gets updated when chunks are added and removed. However, path (2) does not change the list, it just uncommits chunks residing in that list. That passes under the FreeChunkList's radar and now the counter is off. > > ----- > > Review note: `ChunkManager` keeps free chunks. It has an instance of `FreeChunkListVector`, which has a series (one per chunk size) of `FreeChunkList` instances. The commit counter value is handed up from `FreeChunkList` to, eventually, `ChunkManager`. > > What changed: > > - I removed the counter (_committed_word_size) from FreeChunkList. This seemed the simplest and safest measure. Keeping this counter up-to-date is a hassle, since chunks may get committed and uncommitted while being in this list. > > - Now we calculate the number of committed words on the fly if asked, by iterating all chunks in the list and accumulating. To reflect this change, I change the name of "FreeChunkList::committed_word_size()" to "FreeChunkList::calc_committed_word_size()". In metaspace, anything named "calc_" is potentially expensive. > > - Same renamings in FreeChunkListVector and ChunkManager::total_committed_word_size() - to ChunkManager::calc_committed_word_size() > > Now these functions always deliver the correct result. However, they are potentially slower and now require the central metaspace lock. That is not a problem: the only user of this function is when collecting the statistics for the "VM.metaspace" jcmd report, and that happens under lock protection and walks all kind of stuff anyway, so walking the freelists won't hurt. > > Just to be sure, I removed the use of these functions from ChunkManager::print_on(), even though that was just a debug function. > > ----- > > Tests: > > This patch has been tested in our nightlies for a week now. This pull request has now been integrated. Changeset: 02adaa58 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/02adaa58 Stats: 60 lines in 6 files changed: 30 ins; 11 del; 19 mod 8255885: Metaspace: freelist commit counter is not updated when purging Reviewed-by: coleenp, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/1057 From dholmes at openjdk.java.net Fri Nov 20 07:36:07 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 20 Nov 2020 07:36:07 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 23:08:21 GMT, Mark Reinhold wrote: >> Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396). >> Alan Bateman is the original author; I?ve credited him in the commit metadata. >> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. > > Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: > > Add "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test The hostpot change is trivially fine. I'm somewhat surprised by the extent of the other changes given the basic change here is to deprecate the option and change its default. I literally expected to see only 2 simple changes to the functional code: the deprecation warning and the changing of the default value. ------------- PR: https://git.openjdk.java.net/jdk/pull/1324 From shade at openjdk.java.net Fri Nov 20 07:49:16 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 20 Nov 2020 07:49:16 GMT Subject: RFR: 8256675: Zero: purge biased locking support [v2] In-Reply-To: References: Message-ID: <3bQ_qyR6e8LkKy5vxwm8Ee6AUqlAXAx3_tkSjYFIFNI=.8cd72663-d250-4d14-b09d-6a18e2b0abac@github.com> > Biased locking support was always disabled for C++ interpreter. Zero seems to have inherited that, see block in `arguments.cpp`: > > #ifdef ZERO > // Clear flags not supported on zero. > FLAG_SET_DEFAULT(ProfileInterpreter, false); > FLAG_SET_DEFAULT(UseBiasedLocking, false); > LP64_ONLY(FLAG_SET_DEFAULT(UseCompressedOops, false)); > LP64_ONLY(FLAG_SET_DEFAULT(UseCompressedClassPointers, false)); > #endif // ZERO > > But `zero/bytecodeInterpreter.cpp` still has paths that imply biased locking support. Seeing that biased locking can go away, and the cost/benefit balance of supporting it in Zero, it makes more sense to purge the long-time-disabled biased locking support from Zero. > > Additional testing: > - [x] Ad-hoc benchmark runs with `-XX:(-|+)UseBiasedLocking` (Zero is so slow that BL does not matter) Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Remove more has_bias_pattern checks ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1322/files - new: https://git.openjdk.java.net/jdk/pull/1322/files/0a2c8487..f7fa09fa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1322&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1322&range=00-01 Stats: 34 lines in 1 file changed: 2 ins; 1 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/1322.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1322/head:pull/1322 PR: https://git.openjdk.java.net/jdk/pull/1322 From shade at openjdk.java.net Fri Nov 20 07:49:17 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 20 Nov 2020 07:49:17 GMT Subject: RFR: 8256675: Zero: purge biased locking support [v2] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 19:55:34 GMT, Patricio Chilano Mateo wrote: > There are 3 places left when unlocking the monitor where there is a has_bias_pattern() check. Maybe change them into an assert? (seems Github doesn't allow to add comments on collapsed lines). Right on, I missed them. See another commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/1322 From shade at redhat.com Fri Nov 20 08:01:43 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 20 Nov 2020 09:01:43 +0100 Subject: RFC: LogTouchedMethods Message-ID: <56204a43-8798-1d18-f0ad-fcdc888fad00@redhat.com> Hi, I am looking at some Zero failures in runtime/CommandLine/PrintTouchedMethods.java, and now I wonder if the whole LogTouchedMethod machinery is needed. As far as I can grasp from the JIRA, it was added here: https://bugs.openjdk.java.net/browse/JDK-8025692 ...to cater for CDS use cases. But then I see the actual CDS improvement that is supposed to use that machinery is not there, and it is actually "Won't Fix"-ed: https://bugs.openjdk.java.net/browse/JDK-8087354 So, are we still doing that CDS improvement in future? Otherwise, should we consider removing LogTouchedMethods machinery to avoid additional maintenance burden? -- Thanks, -Aleksey From alanb at openjdk.java.net Fri Nov 20 08:04:04 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 20 Nov 2020 08:04:04 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3] In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 07:33:50 GMT, David Holmes wrote: > I'm somewhat surprised by the extent of the other changes given the basic change here is to deprecate the option and change its default. I literally expected to see only 2 simple changes to the functional code: the deprecation warning and the changing of the default value. There are interactions with the archiving of the module graph and boot layer. Here's one of the mails from the review of JDK-8244778 that has more context: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068159.html The summary is that, as a short term measure until JEP 396 showed up, we agreed to have the maps to support exporting and opening packages for illegal reflective acces archived with the boot layer. Switching the default allows it goes away. ------------- PR: https://git.openjdk.java.net/jdk/pull/1324 From forax at univ-mlv.fr Fri Nov 20 08:18:28 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 20 Nov 2020 09:18:28 +0100 (CET) Subject: RFC: LogTouchedMethods In-Reply-To: <56204a43-8798-1d18-f0ad-fcdc888fad00@redhat.com> References: <56204a43-8798-1d18-f0ad-fcdc888fad00@redhat.com> Message-ID: <455543786.1038817.1605860308716.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Aleksey Shipilev" > ?: "hotspot-runtime-dev" > Envoy?: Vendredi 20 Novembre 2020 09:01:43 > Objet: RFC: LogTouchedMethods > Hi, Hi Aleksey, > > I am looking at some Zero failures in > runtime/CommandLine/PrintTouchedMethods.java, and now I wonder > if the whole LogTouchedMethod machinery is needed. As far as I can grasp from > the JIRA, it was added > here: > https://bugs.openjdk.java.net/browse/JDK-8025692 > > ...to cater for CDS use cases. But then I see the actual CDS improvement that is > supposed to use > that machinery is not there, and it is actually "Won't Fix"-ed: > https://bugs.openjdk.java.net/browse/JDK-8087354 > > So, are we still doing that CDS improvement in future? Otherwise, should we > consider removing > LogTouchedMethods machinery to avoid additional maintenance burden? Touched methods are the methods you need to have to run your application if you fully control all the inputs, I've use it several times to direct some static analysis when you want a more precise information/statistics than just, this jar is used or this class is used. > > -- > Thanks, > -Aleksey regards, R?mi From thartmann at openjdk.java.net Fri Nov 20 08:24:12 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 20 Nov 2020 08:24:12 GMT Subject: RFR: 8256719: C1 flags that should have expired are still present Message-ID: <3nTaNaFby0VpF6WEE7pvNwm55g4XeScPjfHGo6wZyts=.3980be88-8ef0-4f9f-a9ab-36d125954db7@github.com> [JDK-8235673](https://bugs.openjdk.java.net/browse/JDK-8235673) removed some flags from C1 and made them C2 only. They expired in JDK 16 and should simply be removed. Thanks, Tobias ------------- Commit messages: - 8256719: C1 flags that should have expired are still present Changes: https://git.openjdk.java.net/jdk/pull/1338/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1338&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256719 Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1338.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1338/head:pull/1338 PR: https://git.openjdk.java.net/jdk/pull/1338 From shade at openjdk.java.net Fri Nov 20 08:29:03 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 20 Nov 2020 08:29:03 GMT Subject: RFR: 8256719: C1 flags that should have expired are still present In-Reply-To: <3nTaNaFby0VpF6WEE7pvNwm55g4XeScPjfHGo6wZyts=.3980be88-8ef0-4f9f-a9ab-36d125954db7@github.com> References: <3nTaNaFby0VpF6WEE7pvNwm55g4XeScPjfHGo6wZyts=.3980be88-8ef0-4f9f-a9ab-36d125954db7@github.com> Message-ID: On Fri, 20 Nov 2020 08:18:38 GMT, Tobias Hartmann wrote: > [JDK-8235673](https://bugs.openjdk.java.net/browse/JDK-8235673) removed some flags from C1 and made them C2 only. They expired in JDK 16 and should simply be removed. > > Thanks, > Tobias Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1338 From neliasso at openjdk.java.net Fri Nov 20 08:35:05 2020 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Fri, 20 Nov 2020 08:35:05 GMT Subject: RFR: 8256719: C1 flags that should have expired are still present In-Reply-To: <3nTaNaFby0VpF6WEE7pvNwm55g4XeScPjfHGo6wZyts=.3980be88-8ef0-4f9f-a9ab-36d125954db7@github.com> References: <3nTaNaFby0VpF6WEE7pvNwm55g4XeScPjfHGo6wZyts=.3980be88-8ef0-4f9f-a9ab-36d125954db7@github.com> Message-ID: On Fri, 20 Nov 2020 08:18:38 GMT, Tobias Hartmann wrote: > [JDK-8235673](https://bugs.openjdk.java.net/browse/JDK-8235673) removed some flags from C1 and made them C2 only. They expired in JDK 16 and should simply be removed. > > Thanks, > Tobias Looks good. ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1338 From shade at openjdk.java.net Fri Nov 20 08:42:05 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 20 Nov 2020 08:42:05 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v2] In-Reply-To: References: <5s65roCasaADSjfJP1XD5L0kb2JDAvLKST6RrpdbbdA=.e8e924a0-5d09-4f89-b4fb-98a7b0c897d8@github.com> Message-ID: On Thu, 19 Nov 2020 16:47:44 GMT, Andrew Haley wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Touchups after merge >> - Merge branch 'master' into JDK-8256618-zero-x86 >> - 8256618: Zero: Linux x86_32 build still fails > > Marked as reviewed by aph (Reviewer). Thanks @theRealAph! Anyone else wants to chime in? ------------- PR: https://git.openjdk.java.net/jdk/pull/1310 From shade at openjdk.java.net Fri Nov 20 09:20:11 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 20 Nov 2020 09:20:11 GMT Subject: RFR: 8256726: Zero: print proper message in ArrayIndexOutOfBoundException Message-ID: Manifests on tier1 test: $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ test ArrayIndexOutOfBoundsExceptionTest.testAIOOBMessages(): failure java.lang.AssertionError: expected [Index -5 out of bounds for length 0] but found [-5] Fix does similar thing to what `Runtime1::throw_range_check_exception` does, but using a safer `jio_snprintf`. Additional testing: - [x] AIOBB tests on Linux x86_64 Zero fastdebug ------------- Commit messages: - Use safer jio_snprintf - 8256726: Zero: print proper message in ArrayIndexOutOfBoundException Changes: https://git.openjdk.java.net/jdk/pull/1341/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1341&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256726 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1341.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1341/head:pull/1341 PR: https://git.openjdk.java.net/jdk/pull/1341 From david.holmes at oracle.com Fri Nov 20 09:29:39 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Nov 2020 19:29:39 +1000 Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3] In-Reply-To: References: Message-ID: Hi Alan, On 20/11/2020 6:04 pm, Alan Bateman wrote: > On Fri, 20 Nov 2020 07:33:50 GMT, David Holmes wrote: > >> I'm somewhat surprised by the extent of the other changes given the basic change here is to deprecate the option and change its default. I literally expected to see only 2 simple changes to the functional code: the deprecation warning and the changing of the default value. > > There are interactions with the archiving of the module graph and boot layer. Here's one of the mails from the review of JDK-8244778 that has more context: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068159.html > The summary is that, as a short term measure until JEP 396 showed up, we agreed to have the maps to support exporting and opening packages for illegal reflective acces archived with the boot layer. Switching the default allows it goes away. Thanks for the information. I don't understand enough to know why this is the case. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1324 > From stuefe at openjdk.java.net Fri Nov 20 10:06:14 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 20 Nov 2020 10:06:14 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts Message-ID: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> Hi, may I have reviews please for this small change. To analyze JDK-8256572, I'd like to see more information in asserts for binlist and blocktree. This patch: - beefs up assertion messages when verifying binlist and blocktree - adds a canary to the blocktree node to detect overwriters - improves the blocktree printing - adds a gtest death test to test the overwrite detection. Thanks! ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/1339/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1339&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256725 Stats: 120 lines in 5 files changed: 92 ins; 9 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/1339.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1339/head:pull/1339 PR: https://git.openjdk.java.net/jdk/pull/1339 From shade at openjdk.java.net Fri Nov 20 10:14:21 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 20 Nov 2020 10:14:21 GMT Subject: RFR: 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory Message-ID: Looks like memory is badly initialized when `-XX:+ZeroTLAB` is specified. Manifests like this: $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/memoryinitialization/ZeroTLABTest.java command: main -Xcomp -XX:+UseTLAB -XX:+ZeroTLAB compiler.memoryinitialization.ZeroTLABTest reason: User specified action: run main/othervm -Xcomp -XX:+UseTLAB -XX:+ZeroTLAB compiler.memoryinitialization.ZeroTLABTest Mode: othervm [/othervm specified] elapsed time (seconds): 0.098 configuration: STDOUT: Error occurred during initialization of VM java.lang.NullPointerException at java.lang.System.getProperty(java.base/System.java:836) The cause is simple: Zero calls this method: if (UseTLAB) { result = (oop) THREAD->tlab().allocate(obj_size); } ...which says: // Allocate size HeapWords. The memory is NOT initialized to zero. inline HeapWord* allocate(size_t size); So if we do `+ZeroTLAB`, then Zero skips zeroing the object body, and gets bad uninitialized memory for non-zeroed TLAB. Since `ZeroTLAB` is "false" by default, I believe just doing the object body initialization unconditionally is fine. ------------- Commit messages: - 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory Changes: https://git.openjdk.java.net/jdk/pull/1343/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1343&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256732 Stats: 19 lines in 1 file changed: 10 ins; 8 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1343.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1343/head:pull/1343 PR: https://git.openjdk.java.net/jdk/pull/1343 From shade at openjdk.java.net Fri Nov 20 10:25:25 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 20 Nov 2020 10:25:25 GMT Subject: RFR: 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory [v2] In-Reply-To: References: Message-ID: > Looks like memory is badly initialized when `-XX:+ZeroTLAB` is specified. > > Manifests like this: > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/memoryinitialization/ZeroTLABTest.java > > command: main -Xcomp -XX:+UseTLAB -XX:+ZeroTLAB compiler.memoryinitialization.ZeroTLABTest > reason: User specified action: run main/othervm -Xcomp -XX:+UseTLAB -XX:+ZeroTLAB compiler.memoryinitialization.ZeroTLABTest > Mode: othervm [/othervm specified] > elapsed time (seconds): 0.098 > configuration: > STDOUT: > Error occurred during initialization of VM > java.lang.NullPointerException > at java.lang.System.getProperty(java.base/System.java:836) > > The cause is simple: Zero calls this method: > > if (UseTLAB) { > result = (oop) THREAD->tlab().allocate(obj_size); > } > > ...which says: > > // Allocate size HeapWords. The memory is NOT initialized to zero. > inline HeapWord* allocate(size_t size); > So if we do `+ZeroTLAB`, then Zero skips zeroing the object body, and gets bad uninitialized memory for non-zeroed TLAB. Since `ZeroTLAB` is "false" by default, I believe just doing the object body initialization unconditionally is fine. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Maintain the body/header initialization order ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1343/files - new: https://git.openjdk.java.net/jdk/pull/1343/files/bca31060..8200d894 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1343&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1343&range=00-01 Stats: 18 lines in 1 file changed: 9 ins; 9 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1343.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1343/head:pull/1343 PR: https://git.openjdk.java.net/jdk/pull/1343 From shade at openjdk.java.net Fri Nov 20 10:34:07 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 20 Nov 2020 10:34:07 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts In-Reply-To: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> Message-ID: On Fri, 20 Nov 2020 08:34:18 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews please for this small change. > > To analyze JDK-8256572, I'd like to see more information in asserts for binlist and blocktree. > > This patch: > > - beefs up assertion messages when verifying binlist and blocktree > - adds a canary to the blocktree node to detect overwriters > - improves the blocktree printing > - adds a gtest death test to test the overwrite detection. > > Thanks! Stylistic drive-by comments. src/hotspot/share/memory/metaspace/binList.hpp line 189: > 187: const size_t s = MinWordSize + i; > 188: int pos = 0; > 189: for (Block* b = _blocks[i]; b != NULL; b = b->_next, pos ++) { `pos++` seems to be more in-style here. src/hotspot/share/memory/metaspace/blockTree.cpp line 44: > 42: ": canary: " INTPTR_FORMAT \ > 43: ", parent " PTR_FORMAT \ > 44: ", left " PTR_FORMAT \ So, is this message with ":" (like `canary:`), or without it (like all other fields)? src/hotspot/share/memory/metaspace/blockTree.cpp line 55: > 53: p2i((n) ? (n)->_left : NULL), \ > 54: p2i((n) ? (n)->_right : NULL), \ > 55: p2i((n) ? (n)->_next : 0), \ This is still pointer, right, judging by `p2i`? So it should return `NULL` in the ternary op? src/hotspot/share/memory/metaspace/blockTree.cpp line 63: > 61: > 62: // This assert prints the tree, then stops (generic message) > 63: #define assrt0(cond, format, ...) \ The names get hard to read. I thought it was as typo initially :) Suggestion: `tree_assert`? src/hotspot/share/memory/metaspace/blockTree.cpp line 89: > 87: // assert a condition with information about node "n" > 88: #define assrt0n(cond, failure_node) assrt0(cond, "Invalid node: " NODE_FORMAT, NODE_FORMAT_ARGS(failure_node)) > 89: Do you think this assert is only usable in this method? I would probably be cleaner to move it next to the assertion it chains with. ------------- PR: https://git.openjdk.java.net/jdk/pull/1339 From stuefe at openjdk.java.net Fri Nov 20 12:56:17 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 20 Nov 2020 12:56:17 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts [v2] In-Reply-To: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> Message-ID: > Hi, > > may I have reviews please for this small change. > > To analyze JDK-8256572, I'd like to see more information in asserts for binlist and blocktree. > > This patch: > > - beefs up assertion messages when verifying binlist and blocktree > - adds a canary to the blocktree node to detect overwriters > - improves the blocktree printing > - adds a gtest death test to test the overwrite detection. > > Thanks! Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Alexey ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1339/files - new: https://git.openjdk.java.net/jdk/pull/1339/files/2a038bc4..491f9782 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1339&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1339&range=00-01 Stats: 30 lines in 2 files changed: 4 ins; 6 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/1339.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1339/head:pull/1339 PR: https://git.openjdk.java.net/jdk/pull/1339 From stuefe at openjdk.java.net Fri Nov 20 12:56:17 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 20 Nov 2020 12:56:17 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts [v2] In-Reply-To: References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> Message-ID: <3kBfn2ZpoKAkirT6YjCY3b57QCZahpNWRPEDHkqePE4=.1d900069-320b-47ca-8ea6-1e81676ebd56@github.com> On Fri, 20 Nov 2020 10:31:09 GMT, Aleksey Shipilev wrote: > Stylistic drive-by comments. Thanks Aleksey! All valid, all fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1339 From alanb at openjdk.java.net Fri Nov 20 13:11:05 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 20 Nov 2020 13:11:05 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3] In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 03:27:54 GMT, Mandy Chung wrote: >> Good point -- case added. > > Looks good. testWithAddExportsInManifest create an executable JAR with "Add-Exports: java.base/sun.security.x509" in the manifest. It runs it twice, once without any options, the second with --illegal-access=permit, and checks there are no warnings in both cases. To test attempted deep reflection here would need the equivalent of setAccessibleNonPublicMemberNonExportedPackage that tries to access some privates in sun.security.x509. It's okay to use setAccessibleNonPublicMemberNonExportedPackage to test that privates in sun.nio.ch aren't accessible but it's not connected to the Add-Exports attribute in the JAR file. ------------- PR: https://git.openjdk.java.net/jdk/pull/1324 From coleenp at openjdk.java.net Fri Nov 20 16:15:08 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 20 Nov 2020 16:15:08 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts [v2] In-Reply-To: <3kBfn2ZpoKAkirT6YjCY3b57QCZahpNWRPEDHkqePE4=.1d900069-320b-47ca-8ea6-1e81676ebd56@github.com> References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> <3kBfn2ZpoKAkirT6YjCY3b57QCZahpNWRPEDHkqePE4=.1d900069-320b-47ca-8ea6-1e81676ebd56@github.com> Message-ID: On Fri, 20 Nov 2020 12:53:13 GMT, Thomas Stuefe wrote: >> Stylistic drive-by comments. > >> Stylistic drive-by comments. > > Thanks Aleksey! All valid, all fixed. Can you add the hotspot-dev mailing list to these RFRs? ------------- PR: https://git.openjdk.java.net/jdk/pull/1339 From dcubed at openjdk.java.net Fri Nov 20 17:36:13 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 20 Nov 2020 17:36:13 GMT Subject: RFR: 8256803: ProblemList runtime/ReservedStack/ReservedStackTestCompiler.java on linux-aarch64 Message-ID: A trivial fix to ProblemList runtime/ReservedStack/ReservedStackTestCompiler.java on linux-aarch64. ------------- Commit messages: - 8256803: ProblemList runtime/ReservedStack/ReservedStackTestCompiler.java on linux-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/1356/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1356&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256803 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1356.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1356/head:pull/1356 PR: https://git.openjdk.java.net/jdk/pull/1356 From mikael at openjdk.java.net Fri Nov 20 17:49:07 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 20 Nov 2020 17:49:07 GMT Subject: RFR: 8256803: ProblemList runtime/ReservedStack/ReservedStackTestCompiler.java on linux-aarch64 In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 17:29:51 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList runtime/ReservedStack/ReservedStackTestCompiler.java on linux-aarch64. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1356 From dcubed at openjdk.java.net Fri Nov 20 18:02:08 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 20 Nov 2020 18:02:08 GMT Subject: Integrated: 8256803: ProblemList runtime/ReservedStack/ReservedStackTestCompiler.java on linux-aarch64 In-Reply-To: References: Message-ID: <0ZBaWJErw5EYMePhS4uuydx5CnFSNI5lEDtJFOM-oyc=.e8d6ec9e-8328-4d67-a8e2-fedca3f0e7eb@github.com> On Fri, 20 Nov 2020 17:29:51 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList runtime/ReservedStack/ReservedStackTestCompiler.java on linux-aarch64. This pull request has now been integrated. Changeset: 4dd71ae1 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/4dd71ae1 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8256803: ProblemList runtime/ReservedStack/ReservedStackTestCompiler.java on linux-aarch64 Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/1356 From dcubed at openjdk.java.net Fri Nov 20 18:02:06 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 20 Nov 2020 18:02:06 GMT Subject: RFR: 8256803: ProblemList runtime/ReservedStack/ReservedStackTestCompiler.java on linux-aarch64 In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 17:45:55 GMT, Mikael Vidstedt wrote: >> A trivial fix to ProblemList runtime/ReservedStack/ReservedStackTestCompiler.java on linux-aarch64. > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1356 From dcubed at openjdk.java.net Sat Nov 21 04:50:15 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 21 Nov 2020 04:50:15 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v6] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 18:06:22 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch to add method Mutex::try_lock_without_rank_check(). >> >> The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. >> >> The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. >> >> Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. >> >> Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. >> >> I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. >> >> In summary the patch contains the following changes: >> - Add method Mutex::try_lock_without_rank_check() >> - Move rank checks before trying to lock/wait on the underlying PlatformMonitor >> - Clean up definitions for optimized/debug builds >> - Add a new gtest to test for different rank violations scenarios >> >> Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > check owner directly + remove owned_by_self(Thread* thread) Still good. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1242 From thomas.stuefe at gmail.com Sat Nov 21 05:57:58 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 21 Nov 2020 06:57:58 +0100 Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts In-Reply-To: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> Message-ID: Coleen did ask me to crosspost this to hs-dev. I added the label to the gh issue but skara does not seem to pick it up, so here the manual crosspost. ...Thomas On Fri, Nov 20, 2020 at 11:06 AM Thomas Stuefe wrote: > Hi, > > may I have reviews please for this small change. > > To analyze JDK-8256572, I'd like to see more information in asserts for > binlist and blocktree. > > This patch: > > - beefs up assertion messages when verifying binlist and blocktree > - adds a canary to the blocktree node to detect overwriters > - improves the blocktree printing > - adds a gtest death test to test the overwrite detection. > > Thanks! > > ------------- > > Commit messages: > - Initial > > Changes: https://git.openjdk.java.net/jdk/pull/1339/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1339&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8256725 > Stats: 120 lines in 5 files changed: 92 ins; 9 del; 19 mod > Patch: https://git.openjdk.java.net/jdk/pull/1339.diff > Fetch: git fetch https://git.openjdk.java.net/jdk > pull/1339/head:pull/1339 > > PR: https://git.openjdk.java.net/jdk/pull/1339 > From stuefe at openjdk.java.net Sat Nov 21 09:31:31 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 21 Nov 2020 09:31:31 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts [v3] In-Reply-To: References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> <3kBfn2ZpoKAkirT6YjCY3b57QCZahpNWRPEDHkqePE4=.1d900069-320b-47ca-8ea6-1e81676ebd56@github.com> Message-ID: On Fri, 20 Nov 2020 16:12:18 GMT, Coleen Phillimore wrote: >>> Stylistic drive-by comments. >> >> Thanks Aleksey! All valid, all fixed. > > Can you add the hotspot-dev mailing list to these RFRs? I added some more checks - which should be very quick - for all passed nodes when inserting or removing into the BlockTree. Similar for BinList. ------------- PR: https://git.openjdk.java.net/jdk/pull/1339 From stuefe at openjdk.java.net Sat Nov 21 09:31:30 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 21 Nov 2020 09:31:30 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts [v3] In-Reply-To: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> Message-ID: <6AJXvjkfpqDcqQgn9wUjqAUSQe5l1LLqQRxcgKbx1rw=.af8022d5-2283-47ed-b270-1f3a6c3fd8e0@github.com> > Hi, > > may I have reviews please for this small change. > > To analyze JDK-8256572, I'd like to see more information in asserts for binlist and blocktree. > > This patch: > > - beefs up assertion messages when verifying binlist and blocktree > - adds a canary to the blocktree node to detect overwriters > - improves the blocktree printing > - adds a gtest death test to test the overwrite detection. > > Thanks! Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Quick node checks in blocktree on insert/removal ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1339/files - new: https://git.openjdk.java.net/jdk/pull/1339/files/491f9782..4e85fe65 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1339&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1339&range=01-02 Stats: 30 lines in 2 files changed: 19 ins; 5 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1339.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1339/head:pull/1339 PR: https://git.openjdk.java.net/jdk/pull/1339 From coleenp at openjdk.java.net Sat Nov 21 19:40:35 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Sat, 21 Nov 2020 19:40:35 GMT Subject: RFR: 8256822: runtime/logging/RedefineClasses.java fails with "Error: VM option 'Verbose' is develop and is available only in debug version of VM." Message-ID: Remove -XX:+Verbose from this test. I could leave it on and add -XX:+IgnoreUnrecognizedVMOptions if people prefer that. The runtime/logging/TestMethodHandlesVerbose.java also tested JDK-8246378, but this one has some output that I was verifying manually. thanks Coleen ------------- Commit messages: - 8256822: runtime/logging/RedefineClasses.java fails with "Error: VM option 'Verbose' is develop and is available only in debug version of VM." Changes: https://git.openjdk.java.net/jdk/pull/1368/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1368&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256822 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1368/head:pull/1368 PR: https://git.openjdk.java.net/jdk/pull/1368 From stuefe at openjdk.java.net Sat Nov 21 19:59:31 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 21 Nov 2020 19:59:31 GMT Subject: RFR: 8256822: runtime/logging/RedefineClasses.java fails with "Error: VM option 'Verbose' is develop and is available only in debug version of VM." In-Reply-To: References: Message-ID: On Sat, 21 Nov 2020 19:26:02 GMT, Coleen Phillimore wrote: > Remove -XX:+Verbose from this test. > I could leave it on and add -XX:+IgnoreUnrecognizedVMOptions if people prefer that. The runtime/logging/TestMethodHandlesVerbose.java also tested JDK-8246378, but this one has some output that I was verifying manually. > thanks > Coleen Seems fine and trivial. Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1368 From coleenp at openjdk.java.net Sat Nov 21 22:19:31 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Sat, 21 Nov 2020 22:19:31 GMT Subject: RFR: 8256822: runtime/logging/RedefineClasses.java fails with "Error: VM option 'Verbose' is develop and is available only in debug version of VM." In-Reply-To: References: Message-ID: On Sat, 21 Nov 2020 19:57:06 GMT, Thomas Stuefe wrote: >> Remove -XX:+Verbose from this test. >> I could leave it on and add -XX:+IgnoreUnrecognizedVMOptions if people prefer that. The runtime/logging/TestMethodHandlesVerbose.java also tested JDK-8246378, but this one has some output that I was verifying manually. >> thanks >> Coleen > > Seems fine and trivial. > > Cheers, Thomas Thanks Thomas! ------------- PR: https://git.openjdk.java.net/jdk/pull/1368 From coleenp at openjdk.java.net Sat Nov 21 22:19:43 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Sat, 21 Nov 2020 22:19:43 GMT Subject: Integrated: 8256822: runtime/logging/RedefineClasses.java fails with "Error: VM option 'Verbose' is develop and is available only in debug version of VM." In-Reply-To: References: Message-ID: On Sat, 21 Nov 2020 19:26:02 GMT, Coleen Phillimore wrote: > Remove -XX:+Verbose from this test. > I could leave it on and add -XX:+IgnoreUnrecognizedVMOptions if people prefer that. The runtime/logging/TestMethodHandlesVerbose.java also tested JDK-8246378, but this one has some output that I was verifying manually. > thanks > Coleen This pull request has now been integrated. Changeset: 1aa90ac6 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/1aa90ac6 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8256822: runtime/logging/RedefineClasses.java fails with "Error: VM option 'Verbose' is develop and is available only in debug version of VM." Reviewed-by: stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1368 From shade at openjdk.java.net Sun Nov 22 18:09:25 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 22 Nov 2020 18:09:25 GMT Subject: RFR: 8256670: Zero: enable compressed oops support back In-Reply-To: <5SmiGtOHfHzyeHRqiZqH92leJaZnsahnxkSBbr29z-w=.ba0c07e7-5f41-404b-b34b-944361419a78@github.com> References: <5SmiGtOHfHzyeHRqiZqH92leJaZnsahnxkSBbr29z-w=.ba0c07e7-5f41-404b-b34b-944361419a78@github.com> Message-ID: On Thu, 19 Nov 2020 19:34:30 GMT, Coleen Phillimore wrote: >> UseCompressedOops was disabled for C++ interpreter by JDK-6909153, and it eventually morphed to disabled UseCompressedOops for all Zero configurations. I see nothing that actually prevents Zero from using compressed oops: all local/stack operands are always unpacked (like they are in non-interpreted modes), all heap accesses are calling into utility methods that handle compressed oops, there are no raw accesses to oops anywhere. >> >> Additional testing: >> - [x] Ad-hoc benchmark tests >> - [x] `hotspot_gc_shenandoah` with Zero, now passing compressed oops tests > > Seems okay to me. I can't think of why zero disabled compressed oops. This patch survived more rounds of testing, including quite aggressive Shenandoah tests, so it should be good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1320 From shade at openjdk.java.net Sun Nov 22 18:09:26 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 22 Nov 2020 18:09:26 GMT Subject: Integrated: 8256670: Zero: enable compressed oops support back In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 15:38:17 GMT, Aleksey Shipilev wrote: > UseCompressedOops was disabled for C++ interpreter by JDK-6909153, and it eventually morphed to disabled UseCompressedOops for all Zero configurations. I see nothing that actually prevents Zero from using compressed oops: all local/stack operands are always unpacked (like they are in non-interpreted modes), all heap accesses are calling into utility methods that handle compressed oops, there are no raw accesses to oops anywhere. > > Additional testing: > - [x] Ad-hoc benchmark tests > - [x] `hotspot_gc_shenandoah` with Zero, now passing compressed oops tests This pull request has now been integrated. Changeset: 037e49cf Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/037e49cf Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod 8256670: Zero: enable compressed oops support back Reviewed-by: coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1320 From shade at openjdk.java.net Sun Nov 22 18:31:40 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 22 Nov 2020 18:31:40 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v3] In-Reply-To: References: Message-ID: <5d-1wqHvNbHPpUe63z1C0t2dBqa4nuuA9b3gxj8FfPI=.d998616e-3db1-4a2e-9d1b-d015606083a4@github.com> > There is no os::workaround_expand_exec_shield_cs_limit symbol available: > > > collect2: error: ld returned 1 exit status > > That symbol is defined in `os_linux_x86.cpp`, which is not available to Zero that builds `os_linux_zero.cpp`. > [JDK-8248271](https://bugs.openjdk.java.net/browse/JDK-8248271) added the declaration to `os_linux_zero.hpp`, but that is not enough, because the definition is still missing. I propose we move the definition up the hierarchy, to `os_linux.cpp` and protect it firmly with `IA32`. > > Additional testing: > - [x] Linux {x86_32, x86_64} server builds > - [x] Linux {x86_32, x86_64} zero builds Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into JDK-8256618-zero-x86 - Touchups after merge - Merge branch 'master' into JDK-8256618-zero-x86 - 8256618: Zero: Linux x86_32 build still fails ------------- Changes: https://git.openjdk.java.net/jdk/pull/1310/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1310&range=02 Stats: 158 lines in 4 files changed: 80 ins; 77 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1310.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1310/head:pull/1310 PR: https://git.openjdk.java.net/jdk/pull/1310 From shade at openjdk.java.net Sun Nov 22 18:43:45 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 22 Nov 2020 18:43:45 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v4] In-Reply-To: References: Message-ID: > There is no os::workaround_expand_exec_shield_cs_limit symbol available: > > > collect2: error: ld returned 1 exit status > > That symbol is defined in `os_linux_x86.cpp`, which is not available to Zero that builds `os_linux_zero.cpp`. > [JDK-8248271](https://bugs.openjdk.java.net/browse/JDK-8248271) added the declaration to `os_linux_zero.hpp`, but that is not enough, because the definition is still missing. I propose we move the definition up the hierarchy, to `os_linux.cpp` and protect it firmly with `IA32`. > > Additional testing: > - [x] Linux {x86_32, x86_64} server builds > - [x] Linux {x86_32, x86_64} zero builds Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Put the #ifdef to protect the comment too ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1310/files - new: https://git.openjdk.java.net/jdk/pull/1310/files/a72ee0a1..57ffe333 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1310&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1310&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1310.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1310/head:pull/1310 PR: https://git.openjdk.java.net/jdk/pull/1310 From shade at openjdk.java.net Sun Nov 22 18:43:45 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 22 Nov 2020 18:43:45 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v2] In-Reply-To: References: <5s65roCasaADSjfJP1XD5L0kb2JDAvLKST6RrpdbbdA=.e8e924a0-5d09-4f89-b4fb-98a7b0c897d8@github.com> Message-ID: On Fri, 20 Nov 2020 08:38:52 GMT, Aleksey Shipilev wrote: >> Marked as reviewed by aph (Reviewer). > > Thanks @theRealAph! Anyone else wants to chime in? Did a minor touch-up, would appreciate another reviewer. ------------- PR: https://git.openjdk.java.net/jdk/pull/1310 From dholmes at openjdk.java.net Sun Nov 22 22:56:50 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 22 Nov 2020 22:56:50 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v4] In-Reply-To: References: Message-ID: On Sun, 22 Nov 2020 18:43:45 GMT, Aleksey Shipilev wrote: >> There is no os::workaround_expand_exec_shield_cs_limit symbol available: >> >> >> collect2: error: ld returned 1 exit status >> >> That symbol is defined in `os_linux_x86.cpp`, which is not available to Zero that builds `os_linux_zero.cpp`. >> [JDK-8248271](https://bugs.openjdk.java.net/browse/JDK-8248271) added the declaration to `os_linux_zero.hpp`, but that is not enough, because the definition is still missing. I propose we move the definition up the hierarchy, to `os_linux.cpp` and protect it firmly with `IA32`. >> >> Additional testing: >> - [x] Linux {x86_32, x86_64} server builds >> - [x] Linux {x86_32, x86_64} zero builds > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Put the #ifdef to protect the comment too I guess I'm somewhat surprised that Zero doesn't need anything that is in os_linux_x86.cpp when building for x86. It sets a bad precedent to move CPU specific code to shared code just because zero doesn't conform to the expected use of cpu specific code. Does Zero actually need this code, or could we make the call conditional? Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1310 From dholmes at openjdk.java.net Sun Nov 22 23:06:44 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 22 Nov 2020 23:06:44 GMT Subject: RFR: 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 10:07:39 GMT, Aleksey Shipilev wrote: > Looks like memory is badly initialized when `-XX:+ZeroTLAB` is specified. > > Manifests like this: > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/memoryinitialization/ZeroTLABTest.java > > command: main -Xcomp -XX:+UseTLAB -XX:+ZeroTLAB compiler.memoryinitialization.ZeroTLABTest > reason: User specified action: run main/othervm -Xcomp -XX:+UseTLAB -XX:+ZeroTLAB compiler.memoryinitialization.ZeroTLABTest > Mode: othervm [/othervm specified] > elapsed time (seconds): 0.098 > configuration: > STDOUT: > Error occurred during initialization of VM > java.lang.NullPointerException > at java.lang.System.getProperty(java.base/System.java:836) > > The cause is simple: Zero calls this method: > > if (UseTLAB) { > result = (oop) THREAD->tlab().allocate(obj_size); > } > > ...which says: > > // Allocate size HeapWords. The memory is NOT initialized to zero. > inline HeapWord* allocate(size_t size); > So if we do `+ZeroTLAB`, then Zero skips zeroing the object body, and gets bad uninitialized memory for non-zeroed TLAB. Since `ZeroTLAB` is "false" by default, I believe just doing the object body initialization unconditionally is fine. But isn't the memory returned by ThreadLocalAllocBuffer::allocate implicitly already zeroed when ZeroTLAB is specified? ------------- PR: https://git.openjdk.java.net/jdk/pull/1343 From kbarrett at openjdk.java.net Mon Nov 23 05:50:57 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 23 Nov 2020 05:50:57 GMT Subject: RFR: 8256746: gc/CriticalNativeArgs.java fails without -XX:-CriticalJNINatives In-Reply-To: <4jrK4pCQ5Ij70flgWIh3YBPbRF1fjMooSJAoexQxB5U=.9a23e21b-69a3-4a8b-a187-fa685ca67397@github.com> References: <4jrK4pCQ5Ij70flgWIh3YBPbRF1fjMooSJAoexQxB5U=.9a23e21b-69a3-4a8b-a187-fa685ca67397@github.com> Message-ID: On Fri, 20 Nov 2020 14:23:55 GMT, Aleksey Shipilev wrote: > Found this with Zero testing, but the failure is not Zero-specific. It affects platforms that do not have `CriticalJNINatives` enabled. The issue is that the [fallback (non-critical)](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gc/libCriticalNative.c#L124) native version of the code calls `GetArrayLength` on [known `NULL` array](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gc/CriticalNativeArgs.java#L71). > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=gc/CriticalNativeArgs.java > # > # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/jniHandles.inline.hpp:91), pid=1909139, tid=1909217 > # assert(handle != __null) failed: JNI handle should not be null > > It was exposed by [JDK-8233343](https://bugs.openjdk.java.net/browse/JDK-8233343) that added the generic test configuration, and then by [JDK-8256499](https://bugs.openjdk.java.net/browse/JDK-8256499) that enabled Zero+Epsilon. Before that, the test was only enabled for specific GCs and arches where `CriticalJNINatives` are known to work, and thus we never took that (broken) fallback in this test. > > Note that `CriticalJNINatives` is a deprecated flag, and I expect the test to go away together with the flag later. Meanwhile, let's make sure it runs properly. I also reformatted the run configs a bit to make them more readable, and added `-XX:-CriticalJNINatives` to expose the affected path in most configurations. > > Additional testing: > - [x] Affected test with Zero (+Epsilon, +Shenandoah) > - [x] Affected test with Server (+Epsilon, +Shenandoah) Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1349 From thartmann at openjdk.java.net Mon Nov 23 07:11:57 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 23 Nov 2020 07:11:57 GMT Subject: Integrated: 8256719: C1 flags that should have expired are still present In-Reply-To: <3nTaNaFby0VpF6WEE7pvNwm55g4XeScPjfHGo6wZyts=.3980be88-8ef0-4f9f-a9ab-36d125954db7@github.com> References: <3nTaNaFby0VpF6WEE7pvNwm55g4XeScPjfHGo6wZyts=.3980be88-8ef0-4f9f-a9ab-36d125954db7@github.com> Message-ID: On Fri, 20 Nov 2020 08:18:38 GMT, Tobias Hartmann wrote: > [JDK-8235673](https://bugs.openjdk.java.net/browse/JDK-8235673) removed some flags from C1 and made them C2 only. They expired in JDK 16 and should simply be removed. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 659aec80 Author: Tobias Hartmann URL: https://git.openjdk.java.net/jdk/commit/659aec80 Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod 8256719: C1 flags that should have expired are still present Reviewed-by: shade, neliasso ------------- PR: https://git.openjdk.java.net/jdk/pull/1338 From thartmann at openjdk.java.net Mon Nov 23 07:11:55 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 23 Nov 2020 07:11:55 GMT Subject: RFR: 8256719: C1 flags that should have expired are still present In-Reply-To: References: <3nTaNaFby0VpF6WEE7pvNwm55g4XeScPjfHGo6wZyts=.3980be88-8ef0-4f9f-a9ab-36d125954db7@github.com> Message-ID: On Fri, 20 Nov 2020 08:25:59 GMT, Aleksey Shipilev wrote: >> [JDK-8235673](https://bugs.openjdk.java.net/browse/JDK-8235673) removed some flags from C1 and made them C2 only. They expired in JDK 16 and should simply be removed. >> >> Thanks, >> Tobias > > Looks fine. @shipilev, @neliasso thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/1338 From fmatte at openjdk.java.net Mon Nov 23 07:24:08 2020 From: fmatte at openjdk.java.net (Fairoz Matte) Date: Mon, 23 Nov 2020 07:24:08 GMT Subject: RFR: 8256722: handle VC++:1927 VS2019 in abstract_vm_version Message-ID: The C++ compiler handling coding in abstract_vm_version.cpp currently misses handling nicely for VC++:1927 VS2019. Source: https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B ------------- Commit messages: - 8256722: handle VC++:1927 VS2019 in abstract_vm_version Changes: https://git.openjdk.java.net/jdk/pull/1377/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1377&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256722 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1377.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1377/head:pull/1377 PR: https://git.openjdk.java.net/jdk/pull/1377 From stuefe at openjdk.java.net Mon Nov 23 07:38:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 23 Nov 2020 07:38:56 GMT Subject: RFR: 8256822: runtime/logging/RedefineClasses.java fails with "Error: VM option 'Verbose' is develop and is available only in debug version of VM." In-Reply-To: References: Message-ID: On Sat, 21 Nov 2020 21:53:28 GMT, Coleen Phillimore wrote: >> Seems fine and trivial. >> >> Cheers, Thomas > > Thanks Thomas! Sorry, on second thoughts, maybe it would have been better to just disable Verbose on release builds. I found crashes on ppc from Saturday which went away this night, I guess because +Verbose was missing (https://bugs.openjdk.java.net/browse/JDK-8256843). ------------- PR: https://git.openjdk.java.net/jdk/pull/1368 From shade at openjdk.java.net Mon Nov 23 07:39:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 07:39:58 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v4] In-Reply-To: References: Message-ID: On Sun, 22 Nov 2020 22:53:34 GMT, David Holmes wrote: > I guess I'm somewhat surprised that Zero doesn't need anything that is in os_linux_x86.cpp when building for x86. It sets a bad precedent to move CPU specific code to shared code just because zero doesn't conform to the expected use of cpu specific code. The way current sources are structured, Zero is the "cpu" unto itself. See that we have `os_cpu/linux_x86` and `os_cpu/linux_zero`, `os/linux` and `os/zero`, etc. I agree it is awkward and have consequences like this patch; it has even more consequences for error handling that wants to do arch-specific decoding... That said, the current patch just moves the IA32 definition to `os_linux.cpp`, where the IA32 use already is, and this IMO makes it a tad more consistent than it was before. > Does Zero actually need this code, or could we make the call conditional? I think this code applies to all x86 variants. As the alternative, we can skip it for Zero, hoping that Zero x86 would never face a bug like this code tries to work around. ------------- PR: https://git.openjdk.java.net/jdk/pull/1310 From shade at openjdk.java.net Mon Nov 23 08:23:02 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 08:23:02 GMT Subject: RFR: 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory In-Reply-To: References: Message-ID: On Sun, 22 Nov 2020 23:03:57 GMT, David Holmes wrote: > But isn't the memory returned by ThreadLocalAllocBuffer::allocate implicitly already zeroed when ZeroTLAB is specified? No! That tripped me too! The comment at `ThreadLocalAllocBuffer::allocate` actually says: `// Allocate size HeapWords. The memory is NOT initialized to zero.` ------------- PR: https://git.openjdk.java.net/jdk/pull/1343 From mdoerr at openjdk.java.net Mon Nov 23 09:48:57 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 23 Nov 2020 09:48:57 GMT Subject: RFR: 8256719: C1 flags that should have expired are still present In-Reply-To: References: <3nTaNaFby0VpF6WEE7pvNwm55g4XeScPjfHGo6wZyts=.3980be88-8ef0-4f9f-a9ab-36d125954db7@github.com> Message-ID: On Mon, 23 Nov 2020 07:09:03 GMT, Tobias Hartmann wrote: >> Looks fine. > > @shipilev, @neliasso thanks for the reviews! Thanks for removing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1338 From shade at openjdk.java.net Mon Nov 23 10:04:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 10:04:58 GMT Subject: RFR: 8256722: handle VC++:1927 VS2019 in abstract_vm_version In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 07:19:45 GMT, Fairoz Matte wrote: > The C++ compiler handling coding in abstract_vm_version.cpp currently misses handling nicely for VC++:1927 VS2019. > Source: > https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B This addition looks fine to me. I see that CDS generates the seed based on VM version strings, might be good to run at least `runtime/cds` tests. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1377 From rrich at openjdk.java.net Mon Nov 23 10:26:02 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 23 Nov 2020 10:26:02 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts [v3] In-Reply-To: <6AJXvjkfpqDcqQgn9wUjqAUSQe5l1LLqQRxcgKbx1rw=.af8022d5-2283-47ed-b270-1f3a6c3fd8e0@github.com> References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> <6AJXvjkfpqDcqQgn9wUjqAUSQe5l1LLqQRxcgKbx1rw=.af8022d5-2283-47ed-b270-1f3a6c3fd8e0@github.com> Message-ID: On Sat, 21 Nov 2020 09:31:30 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I have reviews please for this small change. >> >> To analyze JDK-8256572, I'd like to see more information in asserts for binlist and blocktree. >> >> This patch: >> >> - beefs up assertion messages when verifying binlist and blocktree >> - adds a canary to the blocktree node to detect overwriters >> - improves the blocktree printing >> - adds a gtest death test to test the overwrite detection. >> >> Thanks! > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Quick node checks in blocktree on insert/removal Just a few minor points. In general looks good. src/hotspot/share/memory/metaspace/binList.hpp line 161: > 159: assert(b->_word_size >= word_size && > 160: b->_word_size == real_word_size, > 161: "bad block size in list[%u] (" BLOCK_FORMAT ")", index, BLOCK_FORMAT_ARGS(b)); index is signed but you use %u in the format. src/hotspot/share/memory/metaspace/binList.hpp line 189: > 187: for (Block* b = _blocks[i]; b != NULL; b = b->_next, pos++) { > 188: assert(b->_word_size == s, > 189: "bad block size in list[%u] at pos %d (" BLOCK_FORMAT ")", index is signed but you use %u in the format. src/hotspot/share/memory/metaspace/blockTree.cpp line 112: > 110: // Assume a (ridiculously large) edge limit to catch cases > 111: // of badly degenerated or circular trees. > 112: tree_assert(info.depth < 10000, "too deep (%u)", info.depth); info.depth is signed but in the format you use %u. src/hotspot/share/memory/metaspace/blockTree.cpp line 56: > 54: p2i((n) ? (n)->_right : NULL), \ > 55: p2i((n) ? (n)->_next : NULL), \ > 56: ((n) ? (n)->_word_size : 0) The null check is with one exception redundant as n is dereferenced before. Also the check does not help if n is a random invalid address. I think it would be better to print the node only if the canary check was successfull and otherwise try a safe hexdump. ------------- PR: https://git.openjdk.java.net/jdk/pull/1339 From lkorinth at openjdk.java.net Mon Nov 23 10:42:01 2020 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Mon, 23 Nov 2020 10:42:01 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts [v3] In-Reply-To: <6AJXvjkfpqDcqQgn9wUjqAUSQe5l1LLqQRxcgKbx1rw=.af8022d5-2283-47ed-b270-1f3a6c3fd8e0@github.com> References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> <6AJXvjkfpqDcqQgn9wUjqAUSQe5l1LLqQRxcgKbx1rw=.af8022d5-2283-47ed-b270-1f3a6c3fd8e0@github.com> Message-ID: On Sat, 21 Nov 2020 09:31:30 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I have reviews please for this small change. >> >> To analyze JDK-8256572, I'd like to see more information in asserts for binlist and blocktree. >> >> This patch: >> >> - beefs up assertion messages when verifying binlist and blocktree >> - adds a canary to the blocktree node to detect overwriters >> - improves the blocktree printing >> - adds a gtest death test to test the overwrite detection. >> >> Thanks! > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Quick node checks in blocktree on insert/removal Looks good. I like the canary in Node. I have three minor comments you should take a look at. src/hotspot/share/memory/metaspace/binList.hpp line 162: > 160: b->_word_size == real_word_size, > 161: "bad block size in list[%u] (" BLOCK_FORMAT ")", index, BLOCK_FORMAT_ARGS(b)); > 162: MetaWord* const p = (MetaWord*)b; I suggest not creating a `p` variable and just casting the `b` variable at return. After your change, they have the same value and just differs in type. src/hotspot/share/memory/metaspace/binList.hpp line 189: > 187: for (Block* b = _blocks[i]; b != NULL; b = b->_next, pos++) { > 188: assert(b->_word_size == s, > 189: "bad block size in list[%u] at pos %d (" BLOCK_FORMAT ")", Both `i` and `pos` are signed integers, why not print them as such. I am a little surprised that the compiler did not catch it, so maybe I am missing something. src/hotspot/share/memory/metaspace/blockTree.cpp line 126: > 124: // check size and ordering > 125: tree_assert_invalid_node(n->_word_size >= MinWordSize && > 126: n->_word_size <= chunklevel::MAX_CHUNK_WORD_SIZE, n); I prefer one assert per line (that is, not using `&&` in asserts). In this case it does not matter as much, as we can deduce which sub-expression failed from the tree printout, but I think it is a better style, because in _general_ you do not want such an assert to fail. ------------- Changes requested by lkorinth (Committer). PR: https://git.openjdk.java.net/jdk/pull/1339 From aph at openjdk.java.net Mon Nov 23 10:46:58 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 23 Nov 2020 10:46:58 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v4] In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 07:37:33 GMT, Aleksey Shipilev wrote: > > I think this code applies to all x86 variants. As the alternative, we can skip it for Zero, hoping that Zero x86 would never face a bug like this code tries to work around. Well, if we assume Zero will never be used on x86, which seems reasonable, then it doesn't matter. But if it will be used, then there is a real problem with the invocation interface. ------------- PR: https://git.openjdk.java.net/jdk/pull/1310 From rschmelter at openjdk.java.net Mon Nov 23 10:47:08 2020 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Mon, 23 Nov 2020 10:47:08 GMT Subject: RFR: 8256489: Make gtest for long path names on Windows more resilient in the presence of virus scanners Message-ID: Hi, a virus scanner can keep a file open on Windows, so that a DeleteFile command returns successful, but the file is actually not removed when the call returns. In the gtest for long path names on Windows this can lead to failures when a directory is tried to be removed, but the file inside it is still kept by the virus scanner. Since this is an error which only occurs very infrequently, we just retry the deletion a few times. Best regards, Ralf ------------- Commit messages: - Make directory removal in path test more resilient Changes: https://git.openjdk.java.net/jdk/pull/1380/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1380&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256489 Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1380.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1380/head:pull/1380 PR: https://git.openjdk.java.net/jdk/pull/1380 From jvernee at openjdk.java.net Mon Nov 23 12:17:12 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 Nov 2020 12:17:12 GMT Subject: RFR: 8256485: Zero VM build broken after JDK-8254231 Message-ID: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> JDK-8254231 breaks the Zero VM build. This PR contains fixes to get it working again. Testing: Building zero VM variant on Linux. ------------- Commit messages: - Make zero VM build work Changes: https://git.openjdk.java.net/jdk/pull/1265/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1265&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256485 Stats: 135 lines in 8 files changed: 135 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1265.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1265/head:pull/1265 PR: https://git.openjdk.java.net/jdk/pull/1265 From shade at openjdk.java.net Mon Nov 23 12:17:12 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 12:17:12 GMT Subject: RFR: 8256485: Zero VM build broken after JDK-8254231 In-Reply-To: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> References: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> Message-ID: On Tue, 17 Nov 2020 17:12:30 GMT, Jorn Vernee wrote: > JDK-8254231 breaks the Zero VM build. This PR contains fixes to get it working again. > > Testing: Building zero VM variant on Linux. I am going to approve this even in the draft form. The draft patch fixes x86_64 Zero builds for me, and this unblocks pending Zero work. Of course, it does not make new `java/foreign` tests pass, but that is something we can deal with later. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1265 From shade at openjdk.java.net Mon Nov 23 12:49:55 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 12:49:55 GMT Subject: RFR: 8256485: Zero VM build broken after JDK-8254231 In-Reply-To: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> References: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> Message-ID: On Tue, 17 Nov 2020 17:12:30 GMT, Jorn Vernee wrote: > JDK-8254231 breaks the Zero VM build. This PR contains fixes to get it working again. > > Testing: Building zero VM variant on Linux. Marked as reviewed by shade (Reviewer). src/hotspot/cpu/zero/foreign_globals_zero.hpp line 25: > 23: > 24: #ifndef CPU_ZERO_VM_FOREIGN_GLOBALS_X86_HPP > 25: #define CPU_ZERO_VM_FOREIGN_GLOBALS_X86_HPP Maybe include guards should be `CPU_ZERO_VM_FOREIGN_GLOBALS_ZERO_HPP`, dropping `X86` for `ZERO`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1265 From jvernee at openjdk.java.net Mon Nov 23 12:49:57 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 Nov 2020 12:49:57 GMT Subject: RFR: 8256485: Zero VM build broken after JDK-8254231 In-Reply-To: References: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> Message-ID: On Mon, 23 Nov 2020 12:46:03 GMT, Aleksey Shipilev wrote: >> JDK-8254231 breaks the Zero VM build. This PR contains fixes to get it working again. >> >> Testing: Building zero VM variant on Linux. > > src/hotspot/cpu/zero/foreign_globals_zero.hpp line 25: > >> 23: >> 24: #ifndef CPU_ZERO_VM_FOREIGN_GLOBALS_X86_HPP >> 25: #define CPU_ZERO_VM_FOREIGN_GLOBALS_X86_HPP > > Maybe include guards should be `CPU_ZERO_VM_FOREIGN_GLOBALS_ZERO_HPP`, dropping `X86` for `ZERO`. Ah, good catch. I only changed the first one ------------- PR: https://git.openjdk.java.net/jdk/pull/1265 From jvernee at openjdk.java.net Mon Nov 23 12:53:20 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 Nov 2020 12:53:20 GMT Subject: RFR: 8256485: Zero VM build broken after JDK-8254231 [v2] In-Reply-To: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> References: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> Message-ID: <7UmJZZaO8LxyJ-4-awKSPPh5F0DdXEvVNHwoIXk9Ghs=.d60de84f-4a3a-471b-ab4c-fa75baf2bcfc@github.com> > JDK-8254231 breaks the Zero VM build. This PR contains fixes to get it working again. > > Testing: Building zero VM variant on Linux. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Rename foreign_globals_zero.hpp include guard ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1265/files - new: https://git.openjdk.java.net/jdk/pull/1265/files/833dc618..bd3e0fb9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1265&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1265&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1265.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1265/head:pull/1265 PR: https://git.openjdk.java.net/jdk/pull/1265 From shade at openjdk.java.net Mon Nov 23 13:08:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 13:08:58 GMT Subject: RFR: 8256485: Zero VM build broken after JDK-8254231 [v2] In-Reply-To: <7UmJZZaO8LxyJ-4-awKSPPh5F0DdXEvVNHwoIXk9Ghs=.d60de84f-4a3a-471b-ab4c-fa75baf2bcfc@github.com> References: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> <7UmJZZaO8LxyJ-4-awKSPPh5F0DdXEvVNHwoIXk9Ghs=.d60de84f-4a3a-471b-ab4c-fa75baf2bcfc@github.com> Message-ID: On Mon, 23 Nov 2020 12:53:20 GMT, Jorn Vernee wrote: >> JDK-8254231 breaks the Zero VM build. This PR contains fixes to get it working again. >> >> Testing: Building zero VM variant on Linux. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Rename foreign_globals_zero.hpp include guard Changes requested by shade (Reviewer). src/hotspot/cpu/zero/methodHandles_zero.cpp line 211: > 209: case vmIntrinsics::_invokeGeneric: > 210: case vmIntrinsics::_compiledLambdaForm: > 211: case vmIntrinsics::_linkToNative: Sorry, another issue. What is this? Do we need this to compile Zero? Does it even make sense to have it for `method_handle_entry`? ------------- PR: https://git.openjdk.java.net/jdk/pull/1265 From jvernee at openjdk.java.net Mon Nov 23 13:12:08 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 Nov 2020 13:12:08 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 Message-ID: JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. Testing: `make images` on Linux and Windows x86_32 platforms. ------------- Commit messages: - Remove UnsupportedPlatform test - Remove unneeded cast - Remove Stuff that makes the jdk_foreign tests pass - fix test warnings - - Fix 32-bit build errors and tests Changes: https://git.openjdk.java.net/jdk/pull/1266/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256486 Stats: 95 lines in 11 files changed: 55 ins; 26 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/1266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266 PR: https://git.openjdk.java.net/jdk/pull/1266 From jvernee at openjdk.java.net Mon Nov 23 13:14:59 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 Nov 2020 13:14:59 GMT Subject: RFR: 8256485: Zero VM build broken after JDK-8254231 [v2] In-Reply-To: References: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> <7UmJZZaO8LxyJ-4-awKSPPh5F0DdXEvVNHwoIXk9Ghs=.d60de84f-4a3a-471b-ab4c-fa75baf2bcfc@github.com> Message-ID: On Mon, 23 Nov 2020 13:05:42 GMT, Aleksey Shipilev wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename foreign_globals_zero.hpp include guard > > src/hotspot/cpu/zero/methodHandles_zero.cpp line 211: > >> 209: case vmIntrinsics::_invokeGeneric: >> 210: case vmIntrinsics::_compiledLambdaForm: >> 211: case vmIntrinsics::_linkToNative: > > Sorry, another issue. What is this? Do we need this to compile Zero? Does it even make sense to have it for `method_handle_entry`? This function gets called during the build. If the case for linkToNative is not added it falls through to ShouldNotReachHere() in the default case. Pointing it to method_handle_entry_invalid seemed like the best way to fix it, since the interpreter entry never gets used any ways. See method.cpp: if (iid == vmIntrinsics::_linkToNative) { m->set_interpreter_entry(m->adapter()->get_i2c_entry()); } ------------- PR: https://git.openjdk.java.net/jdk/pull/1265 From jvernee at openjdk.java.net Mon Nov 23 13:23:57 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 Nov 2020 13:23:57 GMT Subject: RFR: 8256485: Zero VM build broken after JDK-8254231 [v2] In-Reply-To: References: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> <7UmJZZaO8LxyJ-4-awKSPPh5F0DdXEvVNHwoIXk9Ghs=.d60de84f-4a3a-471b-ab4c-fa75baf2bcfc@github.com> Message-ID: On Mon, 23 Nov 2020 13:11:33 GMT, Jorn Vernee wrote: >> src/hotspot/cpu/zero/methodHandles_zero.cpp line 211: >> >>> 209: case vmIntrinsics::_invokeGeneric: >>> 210: case vmIntrinsics::_compiledLambdaForm: >>> 211: case vmIntrinsics::_linkToNative: >> >> Sorry, another issue. What is this? Do we need this to compile Zero? Does it even make sense to have it for `method_handle_entry`? > > This function gets called during the build. If the case for linkToNative is not added it falls through to ShouldNotReachHere() in the default case. > > Pointing it to method_handle_entry_invalid seemed like the best way to fix it, since the interpreter entry never gets used any ways. See method.cpp: > > if (iid == vmIntrinsics::_linkToNative) { > m->set_interpreter_entry(m->adapter()->get_i2c_entry()); > } (Though, I suppose in general the entry never gets used because we don't have a CLinker implementation for Zero) ------------- PR: https://git.openjdk.java.net/jdk/pull/1265 From shade at openjdk.java.net Mon Nov 23 13:31:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 13:31:57 GMT Subject: RFR: 8256485: Zero VM build broken after JDK-8254231 [v2] In-Reply-To: References: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> <7UmJZZaO8LxyJ-4-awKSPPh5F0DdXEvVNHwoIXk9Ghs=.d60de84f-4a3a-471b-ab4c-fa75baf2bcfc@github.com> Message-ID: On Mon, 23 Nov 2020 13:21:09 GMT, Jorn Vernee wrote: >> This function gets called during the build. If the case for linkToNative is not added it falls through to ShouldNotReachHere() in the default case. >> >> Pointing it to method_handle_entry_invalid seemed like the best way to fix it, since the interpreter entry never gets used any ways. See method.cpp: >> >> if (iid == vmIntrinsics::_linkToNative) { >> m->set_interpreter_entry(m->adapter()->get_i2c_entry()); >> } > > (Though, I suppose in general the entry never gets used because we don't have a CLinker implementation for Zero) Then I suggest doing what `ZeroInterpreterGenerator::generate_abstract_entry` does and generate the entry that "calls" `ShouldNotCallThisEntry()`. Which means the build would succeed, but the attempt to actually call through `_linkToNative` would fail in a proper place. ------------- PR: https://git.openjdk.java.net/jdk/pull/1265 From shade at openjdk.java.net Mon Nov 23 13:35:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 13:35:59 GMT Subject: RFR: 8256485: Zero VM build broken after JDK-8254231 [v2] In-Reply-To: <7UmJZZaO8LxyJ-4-awKSPPh5F0DdXEvVNHwoIXk9Ghs=.d60de84f-4a3a-471b-ab4c-fa75baf2bcfc@github.com> References: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> <7UmJZZaO8LxyJ-4-awKSPPh5F0DdXEvVNHwoIXk9Ghs=.d60de84f-4a3a-471b-ab4c-fa75baf2bcfc@github.com> Message-ID: <3BfjiZVYt8DwUi3ozhcjyWVZTBap_qk5XaWMup7AETY=.b5f5eeaa-0802-4c0f-87f3-9a159d92fb00@github.com> On Mon, 23 Nov 2020 12:53:20 GMT, Jorn Vernee wrote: >> JDK-8254231 breaks the Zero VM build. This PR contains fixes to get it working again. >> >> Testing: Building zero VM variant on Linux. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Rename foreign_globals_zero.hpp include guard Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1265 From shade at openjdk.java.net Mon Nov 23 13:36:00 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 13:36:00 GMT Subject: RFR: 8256485: Zero VM build broken after JDK-8254231 [v2] In-Reply-To: References: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> <7UmJZZaO8LxyJ-4-awKSPPh5F0DdXEvVNHwoIXk9Ghs=.d60de84f-4a3a-471b-ab4c-fa75baf2bcfc@github.com> Message-ID: On Mon, 23 Nov 2020 13:29:03 GMT, Aleksey Shipilev wrote: >> (Though, I suppose in general the entry never gets used because we don't have a CLinker implementation for Zero) > > Then I suggest doing what `ZeroInterpreterGenerator::generate_abstract_entry` does and generate the entry that "calls" `ShouldNotCallThisEntry()`. Which means the build would succeed, but the attempt to actually call through `_linkToNative` would fail in a proper place. In fact, I think right before this method, there is `method_handle_entry_invalid` that you can target for `_linkToNative` case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1265 From shade at openjdk.java.net Mon Nov 23 13:36:01 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 13:36:01 GMT Subject: RFR: 8256485: Zero VM build broken after JDK-8254231 [v2] In-Reply-To: References: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> <7UmJZZaO8LxyJ-4-awKSPPh5F0DdXEvVNHwoIXk9Ghs=.d60de84f-4a3a-471b-ab4c-fa75baf2bcfc@github.com> Message-ID: On Mon, 23 Nov 2020 13:32:16 GMT, Aleksey Shipilev wrote: >> Then I suggest doing what `ZeroInterpreterGenerator::generate_abstract_entry` does and generate the entry that "calls" `ShouldNotCallThisEntry()`. Which means the build would succeed, but the attempt to actually call through `_linkToNative` would fail in a proper place. > > In fact, I think right before this method, there is `method_handle_entry_invalid` that you can target for `_linkToNative` case. ...which you already use! Argh! Good then. Please disregard this noise. Ship it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1265 From shade at openjdk.java.net Mon Nov 23 08:34:04 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 08:34:04 GMT Subject: RFR: 8256832: Zero: micro-optimize safepoint handling after JDK-8255384 Message-ID: Now that [JDK-8255384](https: //bugs.openjdk.java.net/browse/JDK-8255384) effectively made the safepoints conditional for Zero, we can do `HandleMarkCleaner` under the safepoint check. This seems to improve Linux x86_64 Zero release `make bootcycle-images`: from 33.0m to 32.5m. ------------- Commit messages: - 8256832: Zero: micro-optimize safepoint handling after JDK-8255384 Changes: https://git.openjdk.java.net/jdk/pull/1378/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1378&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256832 Stats: 9 lines in 1 file changed: 0 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1378.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1378/head:pull/1378 PR: https://git.openjdk.java.net/jdk/pull/1378 From stuefe at openjdk.java.net Mon Nov 23 14:17:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 23 Nov 2020 14:17:11 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts [v4] In-Reply-To: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> Message-ID: > Hi, > > may I have reviews please for this small change. > > To analyze JDK-8256572, I'd like to see more information in asserts for binlist and blocktree. > > This patch: > > - beefs up assertion messages when verifying binlist and blocktree > - adds a canary to the blocktree node to detect overwriters > - improves the blocktree printing > - adds a gtest death test to test the overwrite detection. > > Thanks! Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Review feedback Richard+Leo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1339/files - new: https://git.openjdk.java.net/jdk/pull/1339/files/4e85fe65..386550bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1339&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1339&range=02-03 Stats: 49 lines in 3 files changed: 27 ins; 6 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1339.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1339/head:pull/1339 PR: https://git.openjdk.java.net/jdk/pull/1339 From stuefe at openjdk.java.net Mon Nov 23 14:20:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 23 Nov 2020 14:20:59 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts [v3] In-Reply-To: References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> <6AJXvjkfpqDcqQgn9wUjqAUSQe5l1LLqQRxcgKbx1rw=.af8022d5-2283-47ed-b270-1f3a6c3fd8e0@github.com> Message-ID: On Mon, 23 Nov 2020 10:39:06 GMT, Leo Korinth wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Quick node checks in blocktree on insert/removal > > Looks good. I like the canary in Node. I have three minor comments you should take a look at. Richard, Leo, thanks for reviewing! I fixed your remarks. Changes in the last commit: - %d -> %u - split multiline assert into two asserts - simplified NODE_FORMAT_ARGS - When verifying a tree, I have now special handling for unreadable node pointers and node pointers whose canaries are invalid. In the former case I assert right away, in the latter I print the node as hex dump (I considered doing further analysis like "is in metaspace" which would be trivial but this class is earmarked as a potential future generic class so I did not want to add deps to metaspace). - When an error is detected, the whole tree is printed; now tree printing tippytoes around invalid pointers. ------------- PR: https://git.openjdk.java.net/jdk/pull/1339 From lkorinth at openjdk.java.net Mon Nov 23 14:36:00 2020 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Mon, 23 Nov 2020 14:36:00 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts [v4] In-Reply-To: References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> Message-ID: On Mon, 23 Nov 2020 14:17:11 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I have reviews please for this small change. >> >> To analyze JDK-8256572, I'd like to see more information in asserts for binlist and blocktree. >> >> This patch: >> >> - beefs up assertion messages when verifying binlist and blocktree >> - adds a canary to the blocktree node to detect overwriters >> - improves the blocktree printing >> - adds a gtest death test to test the overwrite detection. >> >> Thanks! > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback Richard+Leo Looks good to me. ------------- Marked as reviewed by lkorinth (Committer). PR: https://git.openjdk.java.net/jdk/pull/1339 From jvernee at openjdk.java.net Mon Nov 23 14:45:58 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 Nov 2020 14:45:58 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 17:19:13 GMT, Jorn Vernee wrote: > JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. > > Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. > > However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. > > Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. > > Testing: `make images` on Linux and Windows x86_32 platforms. Filed https://bugs.openjdk.java.net/browse/JDK-8256862 to fix the test failures separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From redestad at openjdk.java.net Mon Nov 23 15:14:00 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 23 Nov 2020 15:14:00 GMT Subject: RFR: 8256485: Zero VM build broken after JDK-8254231 [v2] In-Reply-To: <7UmJZZaO8LxyJ-4-awKSPPh5F0DdXEvVNHwoIXk9Ghs=.d60de84f-4a3a-471b-ab4c-fa75baf2bcfc@github.com> References: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> <7UmJZZaO8LxyJ-4-awKSPPh5F0DdXEvVNHwoIXk9Ghs=.d60de84f-4a3a-471b-ab4c-fa75baf2bcfc@github.com> Message-ID: On Mon, 23 Nov 2020 12:53:20 GMT, Jorn Vernee wrote: >> JDK-8254231 breaks the Zero VM build. This PR contains fixes to get it working again. >> >> Testing: Building zero VM variant on Linux. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Rename foreign_globals_zero.hpp include guard Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1265 From redestad at openjdk.java.net Mon Nov 23 15:18:00 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 23 Nov 2020 15:18:00 GMT Subject: RFR: 8256485: Zero VM build broken after JDK-8254231 [v2] In-Reply-To: References: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> <7UmJZZaO8LxyJ-4-awKSPPh5F0DdXEvVNHwoIXk9Ghs=.d60de84f-4a3a-471b-ab4c-fa75baf2bcfc@github.com> Message-ID: On Mon, 23 Nov 2020 15:10:47 GMT, Claes Redestad wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename foreign_globals_zero.hpp include guard > > Marked as reviewed by redestad (Reviewer). The changes outside of zero code is trivial, and since zero doesn't build without this I think you should count this as trivial and push at will. ------------- PR: https://git.openjdk.java.net/jdk/pull/1265 From jvernee at openjdk.java.net Mon Nov 23 15:18:02 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 Nov 2020 15:18:02 GMT Subject: Integrated: 8256485: Zero VM build broken after JDK-8254231 In-Reply-To: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> References: <6jx3VghbdStsct5j5Sc8vay3fasmP7bhT7S0f-cKN3E=.7b1c08e8-4ca4-4857-bc97-e8d197f371a8@github.com> Message-ID: On Tue, 17 Nov 2020 17:12:30 GMT, Jorn Vernee wrote: > JDK-8254231 breaks the Zero VM build. This PR contains fixes to get it working again. > > Testing: Building zero VM variant on Linux. This pull request has now been integrated. Changeset: 884b9ff2 Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/884b9ff2 Stats: 135 lines in 8 files changed: 135 ins; 0 del; 0 mod 8256485: Zero VM build broken after JDK-8254231 Reviewed-by: shade, redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/1265 From rrich at openjdk.java.net Mon Nov 23 15:24:02 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 23 Nov 2020 15:24:02 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts [v4] In-Reply-To: References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> Message-ID: On Mon, 23 Nov 2020 14:17:11 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I have reviews please for this small change. >> >> To analyze JDK-8256572, I'd like to see more information in asserts for binlist and blocktree. >> >> This patch: >> >> - beefs up assertion messages when verifying binlist and blocktree >> - adds a canary to the blocktree node to detect overwriters >> - improves the blocktree printing >> - adds a gtest death test to test the overwrite detection. >> >> Thanks! > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback Richard+Leo Looks good. ------------- Marked as reviewed by rrich (Committer). PR: https://git.openjdk.java.net/jdk/pull/1339 From pchilanomate at openjdk.java.net Mon Nov 23 15:45:01 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 23 Nov 2020 15:45:01 GMT Subject: RFR: 8255678: Add Mutex::try_lock version without rank checks [v6] In-Reply-To: References: Message-ID: On Sat, 21 Nov 2020 04:47:17 GMT, Daniel D. Daugherty wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> check owner directly + remove owned_by_self(Thread* thread) > > Still good. Thanks @dcubed-ojdk, @dholmes-ora and @coleenp for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From pchilanomate at openjdk.java.net Mon Nov 23 15:45:03 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 23 Nov 2020 15:45:03 GMT Subject: Integrated: 8255678: Add Mutex::try_lock version without rank checks In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 22:58:35 GMT, Patricio Chilano Mateo wrote: > Please review the following patch to add method Mutex::try_lock_without_rank_check(). > > The ranking system is used to prevent deadlocks while trying to acquire ownership of a Mutex/Monitor. It does so by preventing circular waits. For that we assign a rank to each Mutex/Monitor and we enforce that ownership?is acquired in order of decreasing rank. Today we validate this order everytime we acquire ownership of a Mutex/Monitor. We can relax this validation for try_lock() in cases where failure to acquire ownership will not block the thread's progress, i.e. cases where the action can just be skipped (e.g. see JDK-8254877). For those cases, even if the Mutex/Monitor is out of rank order the thread will not block if it already has an owner, so circular waits are not possible. > > The patch adds method Mutex::try_lock_without_rank_check() which behaves just like the normal try_lock() but skips rank checks. If the call is successful the method sets field _skip_rank_check for that Mutex/Monitor, so that future rank validations (in case the thread acquires another Mutex/Monitor) will not fail when traversing the list of already acquired locks and checking they are in increasing rank order. The field is reset back on unlock(). For Monitors we still validate that wait() is done on the lock with less rank from all the owned locks. > > Today rank checks are executed after locking the underlying PlatformMutex/PlatforMonitor. This means that we might end up in an actual deadlock before asserting it. For the wait() case there is a similar situation, where we check that a thread waits on the Monitor with less rank from all the locks it owns after the underlying PlatformMonitor wait() call returns. Since doing those checks there might be already too late I moved them to the beginning of the respective lock/wait methods. > > Also, all these rank checks are skipped under certain conditions (Mutex/Monitor of rank native or suspend_resume, or at safepoint) and I didn't change any of that. I realized there are inconsistencies though in skipping the rank check when acquiring a Mutex/Monitor of rank suspend_resume but not when traversing the list of owned locks and checking that those are in increasing rank order. > > I noticed the rank related fields are defined within an "#ifndef PRODUCT" macro (optimized and debug) but the code that uses them is defined within "#ifdef ASSERT" macros (debug only), so I did a little clean up there too. Basically from that non PRODUCT block I moved everything to an ASSERT block, except for _allow_vm_block, and consolidated it with the ASSERT block defined at the end of the class definition. > > In summary the patch contains the following changes: > - Add method Mutex::try_lock_without_rank_check() > - Move rank checks before trying to lock/wait on the underlying PlatformMonitor > - Clean up definitions for optimized/debug builds > - Add a new gtest to test for different rank violations scenarios > > Tested it in mach5 tier1-6. I also checked it builds for release/optimized/fastdebug cases. > > Thanks, > Patricio This pull request has now been integrated. Changeset: aabc9ca2 Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/aabc9ca2 Stats: 342 lines in 3 files changed: 260 ins; 69 del; 13 mod 8255678: Add Mutex::try_lock version without rank checks Reviewed-by: dcubed, dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1242 From stuefe at openjdk.java.net Mon Nov 23 18:00:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 23 Nov 2020 18:00:59 GMT Subject: Withdrawn: JDK-8256725: Metaspace: better blocktree and binlist asserts In-Reply-To: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> Message-ID: On Fri, 20 Nov 2020 08:34:18 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews please for this small change. > > To analyze JDK-8256572, I'd like to see more information in asserts for binlist and blocktree. > > This patch: > > - beefs up assertion messages when verifying binlist and blocktree > - adds a canary to the blocktree node to detect overwriters > - improves the blocktree printing > - adds a gtest death test to test the overwrite detection. > > Thanks! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1339 From stuefe at openjdk.java.net Mon Nov 23 18:35:04 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 23 Nov 2020 18:35:04 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts Message-ID: This is a re-post of https://github.com/openjdk/jdk/pull/1339. It was approved and I integrated, but apparently deleted the branch too soon and interrupted the integration. May I have approvals again please? Patch is unchanged from the final version of https://github.com/openjdk/jdk/pull/1339. Thanks! ------------- Commit messages: - JDK-8256725-better-blocktree-asserts-2 Changes: https://git.openjdk.java.net/jdk/pull/1398/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1398&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256725 Stats: 175 lines in 5 files changed: 131 ins; 15 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/1398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1398/head:pull/1398 PR: https://git.openjdk.java.net/jdk/pull/1398 From shade at openjdk.java.net Mon Nov 23 18:35:04 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 18:35:04 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 18:30:32 GMT, Thomas Stuefe wrote: > This is a re-post of https://github.com/openjdk/jdk/pull/1339. It was approved and I integrated, but apparently deleted the branch too soon and interrupted the integration. > > May I have approvals again please? Patch is unchanged from the final version of https://github.com/openjdk/jdk/pull/1339. > > Thanks! In our old PR, isn't there a "Restore branch" button? It might just restore the PR to pre-integration state. ------------- PR: https://git.openjdk.java.net/jdk/pull/1398 From stuefe at openjdk.java.net Mon Nov 23 18:43:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 23 Nov 2020 18:43:56 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 18:32:14 GMT, Aleksey Shipilev wrote: > In our old PR, isn't there a "Restore branch" button? It might just restore the PR to pre-integration state. Oh, there is. Great, thank you. I restored the old one and tried integrate again. ------------- PR: https://git.openjdk.java.net/jdk/pull/1398 From stuefe at openjdk.java.net Mon Nov 23 18:43:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 23 Nov 2020 18:43:57 GMT Subject: Withdrawn: JDK-8256725: Metaspace: better blocktree and binlist asserts In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 18:30:32 GMT, Thomas Stuefe wrote: > This is a re-post of https://github.com/openjdk/jdk/pull/1339. It was approved and I integrated, but apparently deleted the branch too soon and interrupted the integration. > > May I have approvals again please? Patch is unchanged from the final version of https://github.com/openjdk/jdk/pull/1339. > > Thanks! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1398 From shade at openjdk.java.net Mon Nov 23 18:43:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 18:43:58 GMT Subject: RFR: JDK-8256725: Metaspace: better blocktree and binlist asserts [v4] In-Reply-To: References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> Message-ID: On Mon, 23 Nov 2020 14:17:11 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I have reviews please for this small change. >> >> To analyze JDK-8256572, I'd like to see more information in asserts for binlist and blocktree. >> >> This patch: >> >> - beefs up assertion messages when verifying binlist and blocktree >> - adds a canary to the blocktree node to detect overwriters >> - improves the blocktree printing >> - adds a gtest death test to test the overwrite detection. >> >> Thanks! > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback Richard+Leo I guess you miss a formal Reviewer ack. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1339 From stuefe at openjdk.java.net Mon Nov 23 18:52:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 23 Nov 2020 18:52:56 GMT Subject: Integrated: JDK-8256725: Metaspace: better blocktree and binlist asserts In-Reply-To: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> References: <6DX2ZpqTMWMl__Tbi636rONPiWW8f8sJXZ66mXpehT8=.c1776be5-1a83-4eab-942e-d7f6646e4a24@github.com> Message-ID: On Fri, 20 Nov 2020 08:34:18 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews please for this small change. > > To analyze JDK-8256572, I'd like to see more information in asserts for binlist and blocktree. > > This patch: > > - beefs up assertion messages when verifying binlist and blocktree > - adds a canary to the blocktree node to detect overwriters > - improves the blocktree printing > - adds a gtest death test to test the overwrite detection. > > Thanks! This pull request has now been integrated. Changeset: fa75ad69 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/fa75ad69 Stats: 175 lines in 5 files changed: 131 ins; 15 del; 29 mod 8256725: Metaspace: better blocktree and binlist asserts Reviewed-by: shade, rrich, lkorinth ------------- PR: https://git.openjdk.java.net/jdk/pull/1339 From stuefe at openjdk.java.net Mon Nov 23 18:56:03 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 23 Nov 2020 18:56:03 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors Message-ID: To analyze JDK-8256729 further, we need more tracing: 1) We should print all mappings inside the split area if os::split_reserved_memory() fails 2) The print-mapping code on windows has some shortcomings: - should not probe for mappings outside of what we know are valid address ranges for Windows - should handle wrap-arounds - it should be possible to print the whole address space - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) - should be printed in a more compact manner - base address should be on the same line as the first region - maybe adorned with some basic range info, e.g. library mappings ------------- Commit messages: - Initial patch Changes: https://git.openjdk.java.net/jdk/pull/1390/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256864 Stats: 89 lines in 4 files changed: 75 ins; 2 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/1390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1390/head:pull/1390 PR: https://git.openjdk.java.net/jdk/pull/1390 From jvernee at openjdk.java.net Mon Nov 23 18:58:15 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 Nov 2020 18:58:15 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v2] In-Reply-To: References: Message-ID: <2SRn2T5HZSmC1xnRvJc42Z8wtfwxJdzep2gR_LyrgC0=.7b89023f-3f2e-45f9-853e-af73bb04b47f@github.com> > JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. > > Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. > > However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. > > Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. > > Testing: `make images` on Linux and Windows x86_32 platforms. Jorn Vernee 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 Linker_32bit-fixes_New-Master - - Add negative test for 32-bit platform. - Added note to CLinker about failure to initialize on unsupported platforms - Remove UnsupportedPlatform test - Remove unneeded cast - Remove Stuff that makes the jdk_foreign tests pass - fix test warnings - - Fix 32-bit build errors and tests - Add negative test for 32-bit platform. - Change CABI to fail more lazily when running on an unsupported platform. - Change CLinker layouts to be null on unsupported platforms, instead of failing when initializing the class - Added note to CLinker about failure to initialize on unsupported platforms ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1266/files - new: https://git.openjdk.java.net/jdk/pull/1266/files/f0fed210..df5e65c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=00-01 Stats: 1085 lines in 51 files changed: 903 ins; 125 del; 57 mod Patch: https://git.openjdk.java.net/jdk/pull/1266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266 PR: https://git.openjdk.java.net/jdk/pull/1266 From shade at openjdk.java.net Mon Nov 23 18:59:00 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 18:59:00 GMT Subject: RFR: 8256675: Zero: purge biased locking support [v2] In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 19:55:34 GMT, Patricio Chilano Mateo wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove more has_bias_pattern checks > > Hi Aleksey, > > Changes look good to me. > There are 3 places left when unlocking the monitor where there is a has_bias_pattern() check. Maybe change them into an assert? (seems Github doesn't allow to add comments on collapsed lines). > > Thanks, > Patricio That another commit that removes all `has_bias_pattern()`-s looks fine to you, @pchilano? ------------- PR: https://git.openjdk.java.net/jdk/pull/1322 From rkennke at openjdk.java.net Mon Nov 23 19:08:58 2020 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 23 Nov 2020 19:08:58 GMT Subject: RFR: 8256746: gc/CriticalNativeArgs.java fails without -XX:-CriticalJNINatives In-Reply-To: <4jrK4pCQ5Ij70flgWIh3YBPbRF1fjMooSJAoexQxB5U=.9a23e21b-69a3-4a8b-a187-fa685ca67397@github.com> References: <4jrK4pCQ5Ij70flgWIh3YBPbRF1fjMooSJAoexQxB5U=.9a23e21b-69a3-4a8b-a187-fa685ca67397@github.com> Message-ID: On Fri, 20 Nov 2020 14:23:55 GMT, Aleksey Shipilev wrote: > Found this with Zero testing, but the failure is not Zero-specific. It affects platforms that do not have `CriticalJNINatives` enabled. The issue is that the [fallback (non-critical)](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gc/libCriticalNative.c#L124) native version of the code calls `GetArrayLength` on [known `NULL` array](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gc/CriticalNativeArgs.java#L71). > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=gc/CriticalNativeArgs.java > # > # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/jniHandles.inline.hpp:91), pid=1909139, tid=1909217 > # assert(handle != __null) failed: JNI handle should not be null > > It was exposed by [JDK-8233343](https://bugs.openjdk.java.net/browse/JDK-8233343) that added the generic test configuration, and then by [JDK-8256499](https://bugs.openjdk.java.net/browse/JDK-8256499) that enabled Zero+Epsilon. Before that, the test was only enabled for specific GCs and arches where `CriticalJNINatives` are known to work, and thus we never took that (broken) fallback in this test. > > Note that `CriticalJNINatives` is a deprecated flag, and I expect the test to go away together with the flag later. Meanwhile, let's make sure it runs properly. I also reformatted the run configs a bit to make them more readable, and added `-XX:-CriticalJNINatives` to expose the affected path in most configurations. > > Additional testing: > - [x] Affected test with Zero (+Epsilon, +Shenandoah) > - [x] Affected test with Server (+Epsilon, +Shenandoah) Looks good to me! Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1349 From coleenp at openjdk.java.net Mon Nov 23 19:08:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 23 Nov 2020 19:08:57 GMT Subject: RFR: 8256746: gc/CriticalNativeArgs.java fails without -XX:-CriticalJNINatives In-Reply-To: <4jrK4pCQ5Ij70flgWIh3YBPbRF1fjMooSJAoexQxB5U=.9a23e21b-69a3-4a8b-a187-fa685ca67397@github.com> References: <4jrK4pCQ5Ij70flgWIh3YBPbRF1fjMooSJAoexQxB5U=.9a23e21b-69a3-4a8b-a187-fa685ca67397@github.com> Message-ID: <2dYPpAAbrCZGSIqZeuF5fxeIwGS89PO6axZxbKViVLs=.da7b3479-1b9e-4567-bba2-fdd1c5bab11e@github.com> On Fri, 20 Nov 2020 14:23:55 GMT, Aleksey Shipilev wrote: > Found this with Zero testing, but the failure is not Zero-specific. It affects platforms that do not have `CriticalJNINatives` enabled. The issue is that the [fallback (non-critical)](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gc/libCriticalNative.c#L124) native version of the code calls `GetArrayLength` on [known `NULL` array](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gc/CriticalNativeArgs.java#L71). > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=gc/CriticalNativeArgs.java > # > # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/jniHandles.inline.hpp:91), pid=1909139, tid=1909217 > # assert(handle != __null) failed: JNI handle should not be null > > It was exposed by [JDK-8233343](https://bugs.openjdk.java.net/browse/JDK-8233343) that added the generic test configuration, and then by [JDK-8256499](https://bugs.openjdk.java.net/browse/JDK-8256499) that enabled Zero+Epsilon. Before that, the test was only enabled for specific GCs and arches where `CriticalJNINatives` are known to work, and thus we never took that (broken) fallback in this test. > > Note that `CriticalJNINatives` is a deprecated flag, and I expect the test to go away together with the flag later. Meanwhile, let's make sure it runs properly. I also reformatted the run configs a bit to make them more readable, and added `-XX:-CriticalJNINatives` to expose the affected path in most configurations. > > Additional testing: > - [x] Affected test with Zero (+Epsilon, +Shenandoah) > - [x] Affected test with Server (+Epsilon, +Shenandoah) Looks good! thank you for fixing it. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1349 From pchilanomate at openjdk.java.net Mon Nov 23 19:13:58 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 23 Nov 2020 19:13:58 GMT Subject: RFR: 8256675: Zero: purge biased locking support [v2] In-Reply-To: References: Message-ID: <8JijG3endLs_O82jFIaqauMWd438dztHD-ec-aTlVDk=.144af04b-eba8-4a50-bf19-f166ae3b1e42@github.com> On Thu, 19 Nov 2020 19:55:34 GMT, Patricio Chilano Mateo wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove more has_bias_pattern checks > > Hi Aleksey, > > Changes look good to me. > There are 3 places left when unlocking the monitor where there is a has_bias_pattern() check. Maybe change them into an assert? (seems Github doesn't allow to add comments on collapsed lines). > > Thanks, > Patricio > That another commit that removes all `has_bias_pattern()`-s looks fine to you, @pchilano? Yes, looks good. (Not sure why I thought you already pushed). My suggestion was actually to assert that at monitorexit the markword cannot be biased, but still good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1322 From shade at openjdk.java.net Mon Nov 23 19:14:56 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 19:14:56 GMT Subject: RFR: 8256746: gc/CriticalNativeArgs.java fails without -XX:-CriticalJNINatives In-Reply-To: References: <4jrK4pCQ5Ij70flgWIh3YBPbRF1fjMooSJAoexQxB5U=.9a23e21b-69a3-4a8b-a187-fa685ca67397@github.com> Message-ID: On Mon, 23 Nov 2020 19:06:21 GMT, Roman Kennke wrote: >> Found this with Zero testing, but the failure is not Zero-specific. It affects platforms that do not have `CriticalJNINatives` enabled. The issue is that the [fallback (non-critical)](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gc/libCriticalNative.c#L124) native version of the code calls `GetArrayLength` on [known `NULL` array](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gc/CriticalNativeArgs.java#L71). >> >> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=gc/CriticalNativeArgs.java >> # >> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/jniHandles.inline.hpp:91), pid=1909139, tid=1909217 >> # assert(handle != __null) failed: JNI handle should not be null >> >> It was exposed by [JDK-8233343](https://bugs.openjdk.java.net/browse/JDK-8233343) that added the generic test configuration, and then by [JDK-8256499](https://bugs.openjdk.java.net/browse/JDK-8256499) that enabled Zero+Epsilon. Before that, the test was only enabled for specific GCs and arches where `CriticalJNINatives` are known to work, and thus we never took that (broken) fallback in this test. >> >> Note that `CriticalJNINatives` is a deprecated flag, and I expect the test to go away together with the flag later. Meanwhile, let's make sure it runs properly. I also reformatted the run configs a bit to make them more readable, and added `-XX:-CriticalJNINatives` to expose the affected path in most configurations. >> >> Additional testing: >> - [x] Affected test with Zero (+Epsilon, +Shenandoah) >> - [x] Affected test with Server (+Epsilon, +Shenandoah) > > Looks good to me! Thanks! Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1349 From shade at openjdk.java.net Mon Nov 23 19:14:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 19:14:57 GMT Subject: Integrated: 8256746: gc/CriticalNativeArgs.java fails without -XX:-CriticalJNINatives In-Reply-To: <4jrK4pCQ5Ij70flgWIh3YBPbRF1fjMooSJAoexQxB5U=.9a23e21b-69a3-4a8b-a187-fa685ca67397@github.com> References: <4jrK4pCQ5Ij70flgWIh3YBPbRF1fjMooSJAoexQxB5U=.9a23e21b-69a3-4a8b-a187-fa685ca67397@github.com> Message-ID: On Fri, 20 Nov 2020 14:23:55 GMT, Aleksey Shipilev wrote: > Found this with Zero testing, but the failure is not Zero-specific. It affects platforms that do not have `CriticalJNINatives` enabled. The issue is that the [fallback (non-critical)](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gc/libCriticalNative.c#L124) native version of the code calls `GetArrayLength` on [known `NULL` array](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/gc/CriticalNativeArgs.java#L71). > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=gc/CriticalNativeArgs.java > # > # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/jniHandles.inline.hpp:91), pid=1909139, tid=1909217 > # assert(handle != __null) failed: JNI handle should not be null > > It was exposed by [JDK-8233343](https://bugs.openjdk.java.net/browse/JDK-8233343) that added the generic test configuration, and then by [JDK-8256499](https://bugs.openjdk.java.net/browse/JDK-8256499) that enabled Zero+Epsilon. Before that, the test was only enabled for specific GCs and arches where `CriticalJNINatives` are known to work, and thus we never took that (broken) fallback in this test. > > Note that `CriticalJNINatives` is a deprecated flag, and I expect the test to go away together with the flag later. Meanwhile, let's make sure it runs properly. I also reformatted the run configs a bit to make them more readable, and added `-XX:-CriticalJNINatives` to expose the affected path in most configurations. > > Additional testing: > - [x] Affected test with Zero (+Epsilon, +Shenandoah) > - [x] Affected test with Server (+Epsilon, +Shenandoah) This pull request has now been integrated. Changeset: d9ae0db6 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/d9ae0db6 Stats: 46 lines in 2 files changed: 36 ins; 2 del; 8 mod 8256746: gc/CriticalNativeArgs.java fails without -XX:-CriticalJNINatives Reviewed-by: kbarrett, coleenp, rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/1349 From shade at openjdk.java.net Mon Nov 23 19:21:00 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 19:21:00 GMT Subject: RFR: 8256675: Zero: purge biased locking support [v2] In-Reply-To: <8JijG3endLs_O82jFIaqauMWd438dztHD-ec-aTlVDk=.144af04b-eba8-4a50-bf19-f166ae3b1e42@github.com> References: <8JijG3endLs_O82jFIaqauMWd438dztHD-ec-aTlVDk=.144af04b-eba8-4a50-bf19-f166ae3b1e42@github.com> Message-ID: On Mon, 23 Nov 2020 19:11:07 GMT, Patricio Chilano Mateo wrote: >> Hi Aleksey, >> >> Changes look good to me. >> There are 3 places left when unlocking the monitor where there is a has_bias_pattern() check. Maybe change them into an assert? (seems Github doesn't allow to add comments on collapsed lines). >> >> Thanks, >> Patricio > >> That another commit that removes all `has_bias_pattern()`-s looks fine to you, @pchilano? > Yes, looks good. (Not sure why I thought you already pushed). > My suggestion was actually to assert that at monitorexit the markword cannot be biased, but still good. Thanks! I think we can believe that `!UseBiasedLocking` means no one else biases the object, or can bias it later. ------------- PR: https://git.openjdk.java.net/jdk/pull/1322 From shade at openjdk.java.net Mon Nov 23 19:21:10 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 19:21:10 GMT Subject: RFR: 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory [v3] In-Reply-To: References: Message-ID: <99u2Ke41vwJoLHAs4lyGDlnajXAY_Jegvg1hzkL04xA=.13493253-d81c-47f6-99ae-dd348dfd329d@github.com> > Looks like memory is badly initialized when `-XX:+ZeroTLAB` is specified. > > Manifests like this: > > $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/memoryinitialization/ZeroTLABTest.java > > command: main -Xcomp -XX:+UseTLAB -XX:+ZeroTLAB compiler.memoryinitialization.ZeroTLABTest > reason: User specified action: run main/othervm -Xcomp -XX:+UseTLAB -XX:+ZeroTLAB compiler.memoryinitialization.ZeroTLABTest > Mode: othervm [/othervm specified] > elapsed time (seconds): 0.098 > configuration: > STDOUT: > Error occurred during initialization of VM > java.lang.NullPointerException > at java.lang.System.getProperty(java.base/System.java:836) > > The cause is simple: Zero calls `ThreadLocalAllocBuffer::allocate`: > > if (UseTLAB) { > result = (oop) THREAD->tlab().allocate(obj_size); > } > > ...which actually says: > > // Allocate size HeapWords. The memory is NOT initialized to zero. > inline HeapWord* allocate(size_t size); > So if we do `+ZeroTLAB`, then Zero skips zeroing the object body, and gets bad uninitialized memory for non-zeroed TLAB. Since `ZeroTLAB` is "false" by default, I believe just doing the object body initialization unconditionally is fine. Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into JDK-8256732-zero-zerotlab-broken - Maintain the body/header initialization order - 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory ------------- Changes: https://git.openjdk.java.net/jdk/pull/1343/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1343&range=02 Stats: 11 lines in 1 file changed: 3 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1343.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1343/head:pull/1343 PR: https://git.openjdk.java.net/jdk/pull/1343 From shade at openjdk.java.net Mon Nov 23 19:21:02 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 19:21:02 GMT Subject: Integrated: 8256675: Zero: purge biased locking support In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 16:23:54 GMT, Aleksey Shipilev wrote: > Biased locking support was always disabled for C++ interpreter. Zero seems to have inherited that, see block in `arguments.cpp`: > > #ifdef ZERO > // Clear flags not supported on zero. > FLAG_SET_DEFAULT(ProfileInterpreter, false); > FLAG_SET_DEFAULT(UseBiasedLocking, false); > LP64_ONLY(FLAG_SET_DEFAULT(UseCompressedOops, false)); > LP64_ONLY(FLAG_SET_DEFAULT(UseCompressedClassPointers, false)); > #endif // ZERO > > But `zero/bytecodeInterpreter.cpp` still has paths that imply biased locking support. Seeing that biased locking can go away, and the cost/benefit balance of supporting it in Zero, it makes more sense to purge the long-time-disabled biased locking support from Zero. > > Additional testing: > - [x] Ad-hoc benchmark runs with `-XX:(-|+)UseBiasedLocking` (Zero is so slow that BL does not matter) This pull request has now been integrated. Changeset: 7551c680 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/7551c680 Stats: 271 lines in 1 file changed: 3 ins; 202 del; 66 mod 8256675: Zero: purge biased locking support Reviewed-by: coleenp, pchilanomate ------------- PR: https://git.openjdk.java.net/jdk/pull/1322 From shade at openjdk.java.net Mon Nov 23 19:31:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 19:31:59 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v2] In-Reply-To: <2SRn2T5HZSmC1xnRvJc42Z8wtfwxJdzep2gR_LyrgC0=.7b89023f-3f2e-45f9-853e-af73bb04b47f@github.com> References: <2SRn2T5HZSmC1xnRvJc42Z8wtfwxJdzep2gR_LyrgC0=.7b89023f-3f2e-45f9-853e-af73bb04b47f@github.com> Message-ID: <3Qmhyjvnm2vDo4vg4LH0Pxn3c1UdZFwvxEiGCUYgEsQ=.c4e5e91b-6e90-445f-bf57-bce4bf95b301@github.com> On Mon, 23 Nov 2020 18:58:15 GMT, Jorn Vernee wrote: >> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. >> >> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. >> >> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. >> >> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. >> >> Testing: `make images` on Linux and Windows x86_32 platforms. > > Jorn Vernee 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 Linker_32bit-fixes_New-Master > - - Add negative test for 32-bit platform. > - Added note to CLinker about failure to initialize on unsupported platforms > - Remove UnsupportedPlatform test > - Remove unneeded cast > - Remove Stuff that makes the jdk_foreign tests pass > - fix test warnings > - - Fix 32-bit build errors and tests > - Add negative test for 32-bit platform. > - Change CABI to fail more lazily when running on an unsupported platform. > - Change CLinker layouts to be null on unsupported platforms, instead of failing when initializing the class > - Added note to CLinker about failure to initialize on unsupported platforms Some minor comments before looking more closely. src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp line 132: > 130: __ ret(0); > 131: #else > 132: __ hlt(); // NYI "Not Implemented Yet" is "NIY". But then there is a macro you can use here: `Unimplemented()`. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/PlatformLayouts.java line 144: > 142: * The {@code T*} native type. > 143: */ > 144: public static final ValueLayout C_POINTER = ofPointer(LITTLE_ENDIAN, 64); I somewhat get the change in `Win64()` and `AArch64()`, but why here at `SysV()`? Surely x86_32 is the platform with 32-bit pointers? ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From stuefe at openjdk.java.net Mon Nov 23 19:52:03 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 23 Nov 2020 19:52:03 GMT Subject: RFR: JDK-8255884: Metaspace: chunk local commit counter may be stale Message-ID: The detailed metaspace report (`jcmd VM.metaspace`) shows the ChunkManager statistics. In these statistics, the commit counter for chunk levels < granule size may be wrong. Note that this is not a big deal. It does not affect the total commit counter, which is directly taken from the virtual memory layer, and which is always right. But it can be confusing for analysts. Background: The "truth" about the commit state of granules is kept inside VirtualSpaceNode in a bitmask ("commit mask"). Since this is a global resource and access to it is synchronized, each chunk keeps a commit watermark to know the size of the range which is guaranteed to be committed and which can be used without checking that bitmap. This watermark is checked when allocating from the chunk. This chunk-local watermark can get stale if the granule underneath the chunk gets committed without the chunk noticing. The only way this can happen is if the chunk is smaller than a granule and some in-granule neighbor was committed. That in itself works as designed and is totally benign. The chunk-local commit watermark will get silently corrected on the next allocation. But it messes up statistics a bit. Example: jcmd xxx VM.metaspace Chunk freelists: Both: 4m: (none) 2m: 2, capacity=4,00 MB, committed=0 bytes ( 0%) 1m: 1, capacity=1,00 MB, committed=0 bytes ( 0%) 512k: (none) 256k: 2, capacity=512,00 KB, committed=0 bytes ( 0%) 128k: 1, capacity=128,00 KB, committed=0 bytes ( 0%) 64k: 2, capacity=128,00 KB, committed=0 bytes ( 0%) 32k: 2, capacity=64,00 KB, committed=0 bytes ( 0%) <<<<< actually, these are committed 16k: 1, capacity=16,00 KB, committed=0 bytes ( 0%) <<<<< these too 8k: (none) 4k: (none) 2k: (none) 1k: (none) Total word size: 5,83 MB, committed: 0 bytes ( 0%) In this example, the 32K and 16K chunks in the freelist had been committed as a side effect of comitting a neighboring chunk. Their watermarks are still at zero though and therefore they appear uncommitted here. The solution would be to - when a small chunk gets committed - adjust the watermarks of his in-granule neighbors. Then it looks like this: Both: 4m: (none) 2m: 3, capacity=6,00 MB, committed=0 bytes ( 0%) 1m: 2, capacity=2,00 MB, committed=0 bytes ( 0%) 512k: 1, capacity=512,00 KB, committed=0 bytes ( 0%) 256k: (none) 128k: 1, capacity=128,00 KB, committed=0 bytes ( 0%) 64k: 1, capacity=64,00 KB, committed=0 bytes ( 0%) 32k: 2, capacity=64,00 KB, committed=64,00 KB (100%) <<<<< good 16k: 2, capacity=32,00 KB, committed=32,00 KB (100%) <<<<< good 8k: (none) 4k: (none) 2k: (none) 1k: (none) Total word size: 8,78 MB, committed: 96,00 KB ( 1%) Thanks, Thomas ------------- Commit messages: - Add gtest for Vsn::is_range_fully_committed - Initial Changes: https://git.openjdk.java.net/jdk/pull/1291/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1291&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255884 Stats: 226 lines in 6 files changed: 199 ins; 14 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/1291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1291/head:pull/1291 PR: https://git.openjdk.java.net/jdk/pull/1291 From jvernee at openjdk.java.net Mon Nov 23 20:02:15 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 Nov 2020 20:02:15 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v2] In-Reply-To: <3Qmhyjvnm2vDo4vg4LH0Pxn3c1UdZFwvxEiGCUYgEsQ=.c4e5e91b-6e90-445f-bf57-bce4bf95b301@github.com> References: <2SRn2T5HZSmC1xnRvJc42Z8wtfwxJdzep2gR_LyrgC0=.7b89023f-3f2e-45f9-853e-af73bb04b47f@github.com> <3Qmhyjvnm2vDo4vg4LH0Pxn3c1UdZFwvxEiGCUYgEsQ=.c4e5e91b-6e90-445f-bf57-bce4bf95b301@github.com> Message-ID: On Mon, 23 Nov 2020 19:25:31 GMT, Aleksey Shipilev wrote: >> Jorn Vernee 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 Linker_32bit-fixes_New-Master >> - - Add negative test for 32-bit platform. >> - Added note to CLinker about failure to initialize on unsupported platforms >> - Remove UnsupportedPlatform test >> - Remove unneeded cast >> - Remove Stuff that makes the jdk_foreign tests pass >> - fix test warnings >> - - Fix 32-bit build errors and tests >> - Add negative test for 32-bit platform. >> - Change CABI to fail more lazily when running on an unsupported platform. >> - Change CLinker layouts to be null on unsupported platforms, instead of failing when initializing the class >> - Added note to CLinker about failure to initialize on unsupported platforms > > src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/PlatformLayouts.java line 144: > >> 142: * The {@code T*} native type. >> 143: */ >> 144: public static final ValueLayout C_POINTER = ofPointer(LITTLE_ENDIAN, 64); > > I somewhat get the change in `Win64()` and `AArch64()`, but why here at `SysV()`? Surely x86_32 is the platform with 32-bit pointers? SysV here is the 64-bit SysV ABI, not 32. Perhaps this needs to be disambiguated yet, but we can cross that bridge when adding 32-bit support. Any way, I pushed the wrong thing here. This is supposed to go in another PR. Will fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From jvernee at openjdk.java.net Mon Nov 23 20:02:13 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 Nov 2020 20:02:13 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v3] In-Reply-To: References: Message-ID: > JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. > > Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. > > However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. > > Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. > > Testing: `make images` on Linux and Windows x86_32 platforms. Jorn Vernee 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: Merge branch 'master' into Linker_32bit-fixes_Simpler ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1266/files - new: https://git.openjdk.java.net/jdk/pull/1266/files/df5e65c1..9dcbb58c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=01-02 Stats: 94 lines in 20 files changed: 0 ins; 83 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266 PR: https://git.openjdk.java.net/jdk/pull/1266 From jvernee at openjdk.java.net Mon Nov 23 20:07:08 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 Nov 2020 20:07:08 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v3] In-Reply-To: <3Qmhyjvnm2vDo4vg4LH0Pxn3c1UdZFwvxEiGCUYgEsQ=.c4e5e91b-6e90-445f-bf57-bce4bf95b301@github.com> References: <2SRn2T5HZSmC1xnRvJc42Z8wtfwxJdzep2gR_LyrgC0=.7b89023f-3f2e-45f9-853e-af73bb04b47f@github.com> <3Qmhyjvnm2vDo4vg4LH0Pxn3c1UdZFwvxEiGCUYgEsQ=.c4e5e91b-6e90-445f-bf57-bce4bf95b301@github.com> Message-ID: On Mon, 23 Nov 2020 13:19:23 GMT, Aleksey Shipilev wrote: >> Jorn Vernee has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp line 132: > >> 130: __ ret(0); >> 131: #else >> 132: __ hlt(); // NYI > > "Not Implemented Yet" is "NIY". But then there is a macro you can use here: `Unimplemented()`. Was going for "Not Yet Implemented" (this seems to be more common in existing code) I'll change it to use `Unimplemented();` ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From jvernee at openjdk.java.net Mon Nov 23 20:36:11 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 Nov 2020 20:36:11 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4] In-Reply-To: References: Message-ID: > JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. > > Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. > > However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. > > Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. > > Testing: `make images` on Linux and Windows x86_32 platforms. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Use the Unimplemented() macro instead of hlt() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1266/files - new: https://git.openjdk.java.net/jdk/pull/1266/files/9dcbb58c..4f0c6ef9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266 PR: https://git.openjdk.java.net/jdk/pull/1266 From mr at openjdk.java.net Mon Nov 23 23:06:13 2020 From: mr at openjdk.java.net (Mark Reinhold) Date: Mon, 23 Nov 2020 23:06:13 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v4] In-Reply-To: References: Message-ID: <5LdSUcXZ92UZSYCj-x2EHaIoSPlQBaNNwGh0P4ysMFk=.65abff58-68fe-47a6-923d-5ddce18f33e8@github.com> > Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I?ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: Fix "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1324/files - new: https://git.openjdk.java.net/jdk/pull/1324/files/a57e6065..6a4d4792 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1324.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1324/head:pull/1324 PR: https://git.openjdk.java.net/jdk/pull/1324 From dholmes at openjdk.java.net Mon Nov 23 23:13:03 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 23 Nov 2020 23:13:03 GMT Subject: RFR: 8256474: Migrate Mutex _owner accesses to use Atomic operations Message-ID: Simple update to move away from volatile fields and use Atomic::load/store on racy accesses. Thanks, David ------------- Commit messages: - 8256474: Migrate Mutex _owner accesses to use Atomic operations Changes: https://git.openjdk.java.net/jdk/pull/1402/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1402&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256474 Stats: 25 lines in 2 files changed: 8 ins; 1 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1402/head:pull/1402 PR: https://git.openjdk.java.net/jdk/pull/1402 From mr at openjdk.java.net Mon Nov 23 23:14:11 2020 From: mr at openjdk.java.net (Mark Reinhold) Date: Mon, 23 Nov 2020 23:14:11 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v5] In-Reply-To: References: Message-ID: <91KldHNqIOZI9hHedlD3QKW-EtpnRVP_116OqwUqmc4=.9d1f189d-2dda-42cb-b9d2-8b4d48ae279e@github.com> > Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I?ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: Revert: Fix "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test This reverts commit 6a4d4792261f54b014336d1907b0040b15fdb467. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1324/files - new: https://git.openjdk.java.net/jdk/pull/1324/files/6a4d4792..1a7ab4e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1324.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1324/head:pull/1324 PR: https://git.openjdk.java.net/jdk/pull/1324 From coleenp at openjdk.java.net Mon Nov 23 23:23:59 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 23 Nov 2020 23:23:59 GMT Subject: RFR: 8256474: Migrate Mutex _owner accesses to use Atomic operations In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 23:08:28 GMT, David Holmes wrote: > Simple update to move away from volatile fields and use Atomic::load/store on racy accesses. > > Thanks, > David Looks good to me. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1402 From david.holmes at oracle.com Tue Nov 24 00:05:54 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Nov 2020 10:05:54 +1000 Subject: RFR: 8256474: Migrate Mutex _owner accesses to use Atomic operations In-Reply-To: References: Message-ID: <44d7752c-88b1-9f4e-e27b-3434736fbdd5@oracle.com> On 24/11/2020 9:23 am, Coleen Phillimore wrote: > On Mon, 23 Nov 2020 23:08:28 GMT, David Holmes wrote: > >> Simple update to move away from volatile fields and use Atomic::load/store on racy accesses. >> >> Thanks, >> David > > Looks good to me. Thanks for the Review Coleen! David ----- > ------------- > > Marked as reviewed by coleenp (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1402 > From dholmes at openjdk.java.net Tue Nov 24 01:19:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 Nov 2020 01:19:58 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4] In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 20:36:11 GMT, Jorn Vernee wrote: >> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. >> >> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. >> >> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. >> >> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. >> >> Testing: `make images` on Linux and Windows x86_32 platforms. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Use the Unimplemented() macro instead of hlt() Hi Jorn, Sorry but I don't agree with the addition of JNI_ENTRY_CPP_NOENV. I think there is a flaw in the way these methods are exposed/structured. See comment below. Thanks, David src/hotspot/share/prims/universalUpcallHandler.cpp line 36: > 34: extern struct JavaVM_ main_vm; > 35: > 36: JNI_ENTRY_CPP_NOENV(void, ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff)) I do not like this. I think you have a design flaw here. We should not be directly calling member functions like this from other native code! The entry point should be a simple C-linkage function that is a normal JNI_ENTRY (assuming it actually should be a JNI_ENTRY and not JVM_ENTRY?) and that can then call the true target. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1266 From dholmes at openjdk.java.net Tue Nov 24 01:27:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 Nov 2020 01:27:58 GMT Subject: RFR: 8256489: Make gtest for long path names on Windows more resilient in the presence of virus scanners In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 10:41:47 GMT, Ralf Schmelter wrote: > Hi, > > a virus scanner can keep a file open on Windows, so that a DeleteFile command returns successful, but the file is actually not removed when the call returns. In the gtest for long path names on Windows this can lead to failures when a directory is tried to be removed, but the file inside it is still kept by the virus scanner. > > Since this is an error which only occurs very infrequently, we just retry the deletion a few times. > > Best regards, > Ralf Seems a problem that will exist in a few places e.g. ./logging/logTestUtils.inline.hpp A couple of minor nits below. Thanks, David test/hotspot/gtest/runtime/test_os_windows.cpp line 138: > 136: WITH_ABS_PATH(path); > 137: EXPECT_TRUE(file_exists_w(abs_path)) << "Can't delete directory: \"" << path << "\" does not exists"; > 138: const int max_wait_time = 20; This isn't a "wait time" it is a retry count. test/hotspot/gtest/runtime/test_os_windows.cpp line 141: > 139: > 140: // If the directory cannot be deleted directly, a file in it might be > 141: // kept by a virus scanner. Try a few times, since this should be temporary. s/kept/kept open/ ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1380 From dholmes at openjdk.java.net Tue Nov 24 01:43:00 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 Nov 2020 01:43:00 GMT Subject: RFR: 8256732: Zero: broken +ZeroTLAB exposes badly initialized memory In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 08:08:27 GMT, Aleksey Shipilev wrote: > > > > But isn't the memory returned by ThreadLocalAllocBuffer::allocate implicitly already zeroed when ZeroTLAB is specified? > > No! That tripped me too! The comment at `ThreadLocalAllocBuffer::allocate` actually says: `// Allocate size HeapWords. The memory is NOT initialized to zero.` But is that comment true? Does it really mean "The memory is NOT initialized (unless ZeroTLAB has been set)" ? If ZeroTLAB is not actually zeroing all memory returned via TLAB then something seems far more broken than just Zero! ------------- PR: https://git.openjdk.java.net/jdk/pull/1343 From david.holmes at oracle.com Tue Nov 24 01:47:00 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Nov 2020 11:47:00 +1000 Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v4] In-Reply-To: References: Message-ID: On 23/11/2020 5:39 pm, Aleksey Shipilev wrote: > On Sun, 22 Nov 2020 22:53:34 GMT, David Holmes wrote: > >> I guess I'm somewhat surprised that Zero doesn't need anything that is in os_linux_x86.cpp when building for x86. It sets a bad precedent to move CPU specific code to shared code just because zero doesn't conform to the expected use of cpu specific code. > > The way current sources are structured, Zero is the "cpu" unto itself. See that we have `os_cpu/linux_x86` and `os_cpu/linux_zero`, `os/linux` and `os/zero`, etc. I agree it is awkward and have consequences like this patch; it has even more consequences for error handling that wants to do arch-specific decoding... That tends to argue for everything zero needs being explicitly in linux_zero.*. While that may lead to code duplication of the cpu specific code, I don't think a general solution is to pretend the code isn't cpu-specific and to shove it out to os_linux.*. > That said, the current patch just moves the IA32 definition to `os_linux.cpp`, where the IA32 use already is, and this IMO makes it a tad more consistent than it was before. I'm not seeing the consistency argument here. os_linux.cpp is not completely cpu agnostic (unfortunately) but this proposed change seems far more significant than the pre-existing cases IMO. > >> Does Zero actually need this code, or could we make the call conditional? > > I think this code applies to all x86 variants. As the alternative, we can skip it for Zero, hoping that Zero x86 would never face a bug like this code tries to work around. Hasn't zero functioned without this to-date? Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1310 > From dholmes at openjdk.java.net Tue Nov 24 02:08:59 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 Nov 2020 02:08:59 GMT Subject: RFR: 8256722: handle VC++:1927 VS2019 in abstract_vm_version In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 07:19:45 GMT, Fairoz Matte wrote: > The C++ compiler handling coding in abstract_vm_version.cpp currently misses handling nicely for VC++:1927 VS2019. > Source: > https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B Looks good - and trivial IMO. As usual with these updates I lament the need for them in the first place - if only MSVC++ exported a version string directly. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1377 From kbarrett at openjdk.java.net Tue Nov 24 02:16:56 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 24 Nov 2020 02:16:56 GMT Subject: RFR: 8256474: Migrate Mutex _owner accesses to use Atomic operations In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 23:08:28 GMT, David Holmes wrote: > Simple update to move away from volatile fields and use Atomic::load/store on racy accesses. > > Thanks, > David Changes requested by kbarrett (Reviewer). src/hotspot/share/runtime/mutex.hpp line 89: > 87: // the low-level _lock, or to NULL after it has released the _lock. Accesses by any thread other > 88: // than the lock owner are inherently racy. > 89: Thread* _owner; My understanding of the idiom of using Atomic always rather than relying on any semantics for volatile is that the volatile qualifier is left on the variable, as a marker/indicator/clue that it is interesting. This will also help us find such if/when we adopt some kind of atomic class for encapsulation (whether std::atomic or something like what was proposed for JDK-8247213) and help track adoption progress. So I think the volatile qualifier should be retained. src/hotspot/share/runtime/mutex.hpp line 87: > 85: private: > 86: // The _owner field is only set by the current thread, either to itself after it has acquired > 87: // the low-level _lock, or to NULL after it has released the _lock. Accesses by any thread other s/after/before/ ------------- PR: https://git.openjdk.java.net/jdk/pull/1402 From kbarrett at openjdk.java.net Tue Nov 24 02:56:58 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 24 Nov 2020 02:56:58 GMT Subject: RFR: 8256474: Migrate Mutex _owner accesses to use Atomic operations In-Reply-To: References: Message-ID: <2_Cz015zSUMSuaS2qDSghtz11eOEbZPfyf55rXcp7sI=.6ee442ae-8869-4ae9-81e1-70c8a1c3f886@github.com> On Tue, 24 Nov 2020 02:10:09 GMT, Kim Barrett wrote: >> Simple update to move away from volatile fields and use Atomic::load/store on racy accesses. >> >> Thanks, >> David > > src/hotspot/share/runtime/mutex.hpp line 87: > >> 85: private: >> 86: // The _owner field is only set by the current thread, either to itself after it has acquired >> 87: // the low-level _lock, or to NULL after it has released the _lock. Accesses by any thread other > > s/after/before/ More specifically, since there are two "after", this is about the release of the lock. ------------- PR: https://git.openjdk.java.net/jdk/pull/1402 From fmatte at openjdk.java.net Tue Nov 24 04:04:56 2020 From: fmatte at openjdk.java.net (Fairoz Matte) Date: Tue, 24 Nov 2020 04:04:56 GMT Subject: RFR: 8256722: handle VC++:1927 VS2019 in abstract_vm_version In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 02:05:49 GMT, David Holmes wrote: >> The C++ compiler handling coding in abstract_vm_version.cpp currently misses handling nicely for VC++:1927 VS2019. >> Source: >> https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B > > Looks good - and trivial IMO. > > As usual with these updates I lament the need for them in the first place - if only MSVC++ exported a version string directly. > > Thanks, > David Thanks Aleksey and David for the reviews. I have executed basic testing and runtime/cds and didn't find any issues. Thanks, Fairoz ------------- PR: https://git.openjdk.java.net/jdk/pull/1377 From david.holmes at oracle.com Tue Nov 24 04:27:01 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Nov 2020 14:27:01 +1000 Subject: RFR: 8256474: Migrate Mutex _owner accesses to use Atomic operations In-Reply-To: References: Message-ID: <37d346ba-82ec-d833-a738-1ea2ed18a7e5@oracle.com> Hi Kim, On 24/11/2020 12:16 pm, Kim Barrett wrote: > On Mon, 23 Nov 2020 23:08:28 GMT, David Holmes wrote: > >> Simple update to move away from volatile fields and use Atomic::load/store on racy accesses. >> >> Thanks, >> David > > Changes requested by kbarrett (Reviewer). > > src/hotspot/share/runtime/mutex.hpp line 89: > >> 87: // the low-level _lock, or to NULL after it has released the _lock. Accesses by any thread other >> 88: // than the lock owner are inherently racy. >> 89: Thread* _owner; > > My understanding of the idiom of using Atomic always rather than relying on any semantics for volatile is that the volatile qualifier is left on the variable, as a marker/indicator/clue that it is interesting. This will also help us find such if/when we adopt some kind of atomic class for encapsulation (whether std::atomic or something like what was proposed for JDK-8247213) and help track adoption progress. So I think the volatile qualifier should be retained. That was not my understanding. See for example Dan's very recent fix in this area for "8238174: migrate ObjectMonitor::_owner field away from C++ volatile semantics". But after checking some recent code from the people I thought favoured the "no volatile" use, I still see volatile being used. So I'm somewhat confused as to what we think we're supposed to be doing here. The description in: https://bugs.openjdk.java.net/browse/JDK-8234192 does not make it clear how we are to proceed, but my comment from a year ago did summarise what I thought was the current thinking: "As an interim step there are moves afoot to transition away from using volatile variables and plain loads/stores that we expect/require to be atomic (not torn) accesses (for aligned 32-bit and 64-bit variables at least), and to use our own Atomic::load and Atomic::store (which themselves rely on the same undefined semantics of volatile but at least it is more localised)". This was, to the best of my recollection, based on comments from Stefan K., Erik O, and Robbin E.. But now I see recent code from Erik that doesn't do this, but keeps the volatile. I don't really care one way or the other but we need to all be on the same page here. > src/hotspot/share/runtime/mutex.hpp line 87: > >> 85: private: >> 86: // The _owner field is only set by the current thread, either to itself after it has acquired >> 87: // the low-level _lock, or to NULL after it has released the _lock. Accesses by any thread other > > s/after/before/ Good catch! Fixed. Thanks, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1402 > From dholmes at openjdk.java.net Tue Nov 24 04:28:09 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 Nov 2020 04:28:09 GMT Subject: RFR: 8256474: Migrate Mutex _owner accesses to use Atomic operations [v2] In-Reply-To: References: Message-ID: > Simple update to move away from volatile fields and use Atomic::load/store on racy accesses. > > Thanks, > David David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Fixed comment typo - Merge branch 'master' into 8256474 - 8256474: Migrate Mutex _owner accesses to use Atomic operations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1402/files - new: https://git.openjdk.java.net/jdk/pull/1402/files/175e5954..fa203cb5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1402&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1402&range=00-01 Stats: 1337 lines in 38 files changed: 648 ins; 397 del; 292 mod Patch: https://git.openjdk.java.net/jdk/pull/1402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1402/head:pull/1402 PR: https://git.openjdk.java.net/jdk/pull/1402 From fmatte at openjdk.java.net Tue Nov 24 04:51:56 2020 From: fmatte at openjdk.java.net (Fairoz Matte) Date: Tue, 24 Nov 2020 04:51:56 GMT Subject: Integrated: 8256722: handle VC++:1927 VS2019 in abstract_vm_version In-Reply-To: References: Message-ID: <2JYHwT5koUxayL09lwppwj8ltzhFpTeLqZqLeiioBwY=.695e6887-c207-4b8b-83c2-39c5b5c9c19c@github.com> On Mon, 23 Nov 2020 07:19:45 GMT, Fairoz Matte wrote: > The C++ compiler handling coding in abstract_vm_version.cpp currently misses handling nicely for VC++:1927 VS2019. > Source: > https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B This pull request has now been integrated. Changeset: e838d71d Author: Fairoz Matte Committer: David Holmes URL: https://git.openjdk.java.net/jdk/commit/e838d71d Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod 8256722: handle VC++:1927 VS2019 in abstract_vm_version Reviewed-by: shade, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1377 From dholmes at openjdk.java.net Tue Nov 24 06:15:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 Nov 2020 06:15:58 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 01:14:20 GMT, David Holmes wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Use the Unimplemented() macro instead of hlt() > > src/hotspot/share/prims/universalUpcallHandler.cpp line 36: > >> 34: extern struct JavaVM_ main_vm; >> 35: >> 36: JNI_ENTRY_CPP_NOENV(void, ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff)) > > I do not like this. I think you have a design flaw here. We should not be directly calling member functions like this from other native code! The entry point should be a simple C-linkage function that is a normal JNI_ENTRY (assuming it actually should be a JNI_ENTRY and not JVM_ENTRY?) and that can then call the true target. Looking closer at this and the potential call-chain I don't think this is really either a JNI_ENTRY nor a JVM_ENTRY as we would normally define them. The upcall_stub seems to allow a thread to "tunnel" its way into the VM for a Java call, rather than going through the normal exported interfaces (i.e. JNI). I suspect that earlier in the review process it was requested that this be made some kind of ENTRY but I'm really not sure that fits at all. It may be cleaner, simpler and clearer to just declare a non-exported method that use `ThreadInVMFromNative` directly. ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From stuefe at openjdk.java.net Tue Nov 24 07:04:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 24 Nov 2020 07:04:58 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v4] In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 10:43:42 GMT, Andrew Haley wrote: >>> I guess I'm somewhat surprised that Zero doesn't need anything that is in os_linux_x86.cpp when building for x86. It sets a bad precedent to move CPU specific code to shared code just because zero doesn't conform to the expected use of cpu specific code. >> >> The way current sources are structured, Zero is the "cpu" unto itself. See that we have `os_cpu/linux_x86` and `os_cpu/linux_zero`, `os/linux` and `os/zero`, etc. I agree it is awkward and have consequences like this patch; it has even more consequences for error handling that wants to do arch-specific decoding... >> >> That said, the current patch just moves the IA32 definition to `os_linux.cpp`, where the IA32 use already is, and this IMO makes it a tad more consistent than it was before. >> >>> Does Zero actually need this code, or could we make the call conditional? >> >> I think this code applies to all x86 variants. As the alternative, we can skip it for Zero, hoping that Zero x86 would never face a bug like this code tries to work around. > >> >> I think this code applies to all x86 variants. As the alternative, we can skip it for Zero, hoping that Zero x86 would never face a bug like this code tries to work around. > > Well, if we assume Zero will never be used on x86, which seems reasonable, then it doesn't matter. But if it will be used, then there is a real problem with the invocation interface. I don't think Zero x86 is widely built or tested so no-one may have noticed until now. I prefer this to be fixed too. Why leave this unfixed if we can fix it. If we do not want code duplication but putting it into os_linux.cpp is an eyesore, I'd suggest to move it into an own implementation file, e.g. "os/linux/x86_exec_shield_workaround.cpp", with a clear comment that this is needed for zero. ------------- PR: https://git.openjdk.java.net/jdk/pull/1310 From shade at openjdk.java.net Tue Nov 24 08:54:04 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 24 Nov 2020 08:54:04 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v5] In-Reply-To: References: Message-ID: > There is no os::workaround_expand_exec_shield_cs_limit symbol available: > > > collect2: error: ld returned 1 exit status > > That symbol is defined in `os_linux_x86.cpp`, which is not available to Zero that builds `os_linux_zero.cpp`. > [JDK-8248271](https://bugs.openjdk.java.net/browse/JDK-8248271) added the declaration to `os_linux_zero.hpp`, but that is not enough, because the definition is still missing. I propose we move the definition up the hierarchy, to `os_linux.cpp` and protect it firmly with `IA32`. > > Additional testing: > - [x] Linux {x86_32, x86_64} server builds > - [x] Linux {x86_32, x86_64} zero builds Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Just disable the workaround for Zero - Merge branch 'master' into JDK-8256618-zero-x86 - Put the #ifdef to protect the comment too - Merge branch 'master' into JDK-8256618-zero-x86 - Touchups after merge - Merge branch 'master' into JDK-8256618-zero-x86 - 8256618: Zero: Linux x86_32 build still fails ------------- Changes: https://git.openjdk.java.net/jdk/pull/1310/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1310&range=04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1310.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1310/head:pull/1310 PR: https://git.openjdk.java.net/jdk/pull/1310 From shade at openjdk.java.net Tue Nov 24 08:54:04 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 24 Nov 2020 08:54:04 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v4] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 07:01:49 GMT, Thomas Stuefe wrote: >>> >>> I think this code applies to all x86 variants. As the alternative, we can skip it for Zero, hoping that Zero x86 would never face a bug like this code tries to work around. >> >> Well, if we assume Zero will never be used on x86, which seems reasonable, then it doesn't matter. But if it will be used, then there is a real problem with the invocation interface. > > I don't think Zero x86 is widely built or tested so no-one may have noticed until now. > > I prefer this to be fixed too. Why leave this unfixed if we can fix it. > > If we do not want code duplication but putting it into os_linux.cpp is an eyesore, I'd suggest to move it into an own implementation file, e.g. "os/linux/x86_exec_shield_workaround.cpp", with a clear comment that this is needed for zero. Zero had suffered from years of neglect, and I believe the last time anyone tried to build Zero x86_32 was when Gary Benson did significant work on it back in 2009. The workaround for IA32 landed in 2013. So it stands to reason Zero x86_32 was broken ever since. In fact, even after this workaround, I see the unrelated Zero-specific IA32_ONLY assertions on Hello World. Zero x86_32 seems to be the only Zero config that fails to build at the moment. So, at this point I am willing to make a concession and just disable the workaround for Zero to get it to build. If we discover the workaround is needed, then we can revisit how Zero uses `os_linux_*` code. That is what new commit does. ------------- PR: https://git.openjdk.java.net/jdk/pull/1310 From rschmelter at openjdk.java.net Tue Nov 24 09:32:18 2020 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Tue, 24 Nov 2020 09:32:18 GMT Subject: RFR: 8256489: Make gtest for long path names on Windows more resilient in the presence of virus scanners [v2] In-Reply-To: References: Message-ID: > Hi, > > a virus scanner can keep a file open on Windows, so that a DeleteFile command returns successful, but the file is actually not removed when the call returns. In the gtest for long path names on Windows this can lead to failures when a directory is tried to be removed, but the file inside it is still kept by the virus scanner. > > Since this is an error which only occurs very infrequently, we just retry the deletion a few times. > > Best regards, > Ralf Ralf Schmelter 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 two additional commits since the last revision: - Incorporated review findings from David Holmes - Make directory removal in path test more resilient ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1380/files - new: https://git.openjdk.java.net/jdk/pull/1380/files/36c88be1..853bd30c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1380&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1380&range=00-01 Stats: 72406 lines in 365 files changed: 69913 ins; 1587 del; 906 mod Patch: https://git.openjdk.java.net/jdk/pull/1380.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1380/head:pull/1380 PR: https://git.openjdk.java.net/jdk/pull/1380 From rschmelter at openjdk.java.net Tue Nov 24 09:36:02 2020 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Tue, 24 Nov 2020 09:36:02 GMT Subject: RFR: 8256489: Make gtest for long path names on Windows more resilient in the presence of virus scanners [v2] In-Reply-To: References: Message-ID: <8w9P1zTeJclNaYb19TQZa2HCZwt5Y7F7BLH1GqGVgko=.3565de30-a1ec-487f-9ca6-7ce10c468952@github.com> On Tue, 24 Nov 2020 01:20:11 GMT, David Holmes wrote: >> Ralf Schmelter 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 two additional commits since the last revision: >> >> - Incorporated review findings from David Holmes >> - Make directory removal in path test more resilient > > test/hotspot/gtest/runtime/test_os_windows.cpp line 138: > >> 136: WITH_ABS_PATH(path); >> 137: EXPECT_TRUE(file_exists_w(abs_path)) << "Can't delete directory: \"" << path << "\" does not exists"; >> 138: const int max_wait_time = 20; > > This isn't a "wait time" it is a retry count. Right, I've changed it to retry_count. ------------- PR: https://git.openjdk.java.net/jdk/pull/1380 From shade at openjdk.java.net Tue Nov 24 10:32:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 24 Nov 2020 10:32:59 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4] In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 20:36:11 GMT, Jorn Vernee wrote: >> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. >> >> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. >> >> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. >> >> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. >> >> Testing: `make images` on Linux and Windows x86_32 platforms. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Use the Unimplemented() macro instead of hlt() I have a few minor comments, in addition to what David is saying about `JNI_ENTRY_CPP_NOENV`. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 497: > 495: void MacroAssembler::reset_last_Java_frame(bool clear_fp) { > 496: reset_last_Java_frame(r15_thread, clear_fp); > 497: } I see that before the Foreign Linker integration, this method was between `MacroAssembler::pushptr` and `MacroAssembler::set_last_Java_frame`. Please move it back there. ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1266 From stuefe at openjdk.java.net Tue Nov 24 11:14:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 24 Nov 2020 11:14:00 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v5] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 08:54:04 GMT, Aleksey Shipilev wrote: >> There is no os::workaround_expand_exec_shield_cs_limit symbol available: >> >> >> collect2: error: ld returned 1 exit status >> >> That symbol is defined in `os_linux_x86.cpp`, which is not available to Zero that builds `os_linux_zero.cpp`. >> [JDK-8248271](https://bugs.openjdk.java.net/browse/JDK-8248271) added the declaration to `os_linux_zero.hpp`, but that is not enough, because the definition is still missing. I propose we move the definition up the hierarchy, to `os_linux.cpp` and protect it firmly with `IA32`. >> >> Additional testing: >> - [x] Linux {x86_32, x86_64} server builds >> - [x] Linux {x86_32, x86_64} zero builds > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Just disable the workaround for Zero > - Merge branch 'master' into JDK-8256618-zero-x86 > - Put the #ifdef to protect the comment too > - Merge branch 'master' into JDK-8256618-zero-x86 > - Touchups after merge > - Merge branch 'master' into JDK-8256618-zero-x86 > - 8256618: Zero: Linux x86_32 build still fails Pity but LGTM. I assume you build zero with a non-zero build VM right? Due to horrific build times? So it does not need to come up to get built. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1310 From shade at openjdk.java.net Tue Nov 24 11:19:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 24 Nov 2020 11:19:59 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v5] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 11:10:44 GMT, Thomas Stuefe wrote: > I assume you build zero with a non-zero build VM right? Due to horrific build times? So it does not need to come up to get built. Linux x86_32 bits -- yes, they are effectively cross-compiled, so we first compile Linux x86_64 server (technically, my CI as well as GH actions reuse that binary from the dependent jobs), and then use it as build JDK during Linux x86_32 Zero compilation. `make bootcycle-images` is the go-to test to verify Zero works, as it uses the Zero binary as buildjdk on the second pass. The bootcycle times are bad, but not horrible after all the work I did over the last few weeks ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/1310 From jvernee at openjdk.java.net Tue Nov 24 11:38:59 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 24 Nov 2020 11:38:59 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 06:12:55 GMT, David Holmes wrote: >> src/hotspot/share/prims/universalUpcallHandler.cpp line 36: >> >>> 34: extern struct JavaVM_ main_vm; >>> 35: >>> 36: JNI_ENTRY_CPP_NOENV(void, ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff)) >> >> I do not like this. I think you have a design flaw here. We should not be directly calling member functions like this from other native code! The entry point should be a simple C-linkage function that is a normal JNI_ENTRY (assuming it actually should be a JNI_ENTRY and not JVM_ENTRY?) and that can then call the true target. > > Looking closer at this and the potential call-chain I don't think this is really either a JNI_ENTRY nor a JVM_ENTRY as we would normally define them. The upcall_stub seems to allow a thread to "tunnel" its way into the VM for a Java call, rather than going through the normal exported interfaces (i.e. JNI). I suspect that earlier in the review process it was requested that this be made some kind of ENTRY but I'm really not sure that fits at all. It may be cleaner, simpler and clearer to just declare a non-exported method that use `ThreadInVMFromNative` directly. Ok, that seems like a good idea to me as well. Since this code is different from normal JNI/JVM entries, I'd rather add things like exception marks or vm entry traces as needed manually, than relying on the existing macros, so that the need for each item can be re-evaluated and explained in this context. ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From alanb at openjdk.java.net Tue Nov 24 11:39:02 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 24 Nov 2020 11:39:02 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v5] In-Reply-To: <91KldHNqIOZI9hHedlD3QKW-EtpnRVP_116OqwUqmc4=.9d1f189d-2dda-42cb-b9d2-8b4d48ae279e@github.com> References: <91KldHNqIOZI9hHedlD3QKW-EtpnRVP_116OqwUqmc4=.9d1f189d-2dda-42cb-b9d2-8b4d48ae279e@github.com> Message-ID: On Mon, 23 Nov 2020 23:14:11 GMT, Mark Reinhold wrote: >> Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396). >> Alan Bateman is the original author; I?ve credited him in the commit metadata. >> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. > > Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: > > Revert: Fix "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test > > This reverts commit 6a4d4792261f54b014336d1907b0040b15fdb467. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1324 From dholmes at openjdk.java.net Tue Nov 24 12:10:59 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 Nov 2020 12:10:59 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v5] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 08:54:04 GMT, Aleksey Shipilev wrote: >> There is no os::workaround_expand_exec_shield_cs_limit symbol available: >> >> >> collect2: error: ld returned 1 exit status >> >> That symbol is defined in `os_linux_x86.cpp`, which is not available to Zero that builds `os_linux_zero.cpp`. >> [JDK-8248271](https://bugs.openjdk.java.net/browse/JDK-8248271) added the declaration to `os_linux_zero.hpp`, but that is not enough, because the definition is still missing. I propose we move the definition up the hierarchy, to `os_linux.cpp` and protect it firmly with `IA32`. >> >> Additional testing: >> - [x] Linux {x86_32, x86_64} server builds >> - [x] Linux {x86_32, x86_64} zero builds > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Just disable the workaround for Zero > - Merge branch 'master' into JDK-8256618-zero-x86 > - Put the #ifdef to protect the comment too > - Merge branch 'master' into JDK-8256618-zero-x86 > - Touchups after merge > - Merge branch 'master' into JDK-8256618-zero-x86 > - 8256618: Zero: Linux x86_32 build still fails Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1310 From dholmes at openjdk.java.net Tue Nov 24 12:15:01 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 Nov 2020 12:15:01 GMT Subject: RFR: 8256489: Make gtest for long path names on Windows more resilient in the presence of virus scanners [v2] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 09:32:18 GMT, Ralf Schmelter wrote: >> Hi, >> >> a virus scanner can keep a file open on Windows, so that a DeleteFile command returns successful, but the file is actually not removed when the call returns. In the gtest for long path names on Windows this can lead to failures when a directory is tried to be removed, but the file inside it is still kept by the virus scanner. >> >> Since this is an error which only occurs very infrequently, we just retry the deletion a few times. >> >> Best regards, >> Ralf > > Ralf Schmelter 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 two additional commits since the last revision: > > - Incorporated review findings from David Holmes > - Make directory removal in path test more resilient Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1380 From dholmes at openjdk.java.net Tue Nov 24 12:15:02 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 Nov 2020 12:15:02 GMT Subject: RFR: 8256489: Make gtest for long path names on Windows more resilient in the presence of virus scanners In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 10:41:47 GMT, Ralf Schmelter wrote: > Hi, > > a virus scanner can keep a file open on Windows, so that a DeleteFile command returns successful, but the file is actually not removed when the call returns. In the gtest for long path names on Windows this can lead to failures when a directory is tried to be removed, but the file inside it is still kept by the virus scanner. > > Since this is an error which only occurs very infrequently, we just retry the deletion a few times. > > Best regards, > Ralf @schmelter-sap please do not force-push changes as it breaks the commit history and the PR review history. I can't now examine what you actually changed between the two commits, only look afresh at the whole thing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1380 From coleenp at openjdk.java.net Tue Nov 24 12:30:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 24 Nov 2020 12:30:01 GMT Subject: RFR: 8256474: Migrate Mutex _owner accesses to use Atomic operations [v2] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 02:07:19 GMT, Kim Barrett wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Fixed comment typo >> - Merge branch 'master' into 8256474 >> - 8256474: Migrate Mutex _owner accesses to use Atomic operations > > src/hotspot/share/runtime/mutex.hpp line 89: > >> 87: // the low-level _lock, or to NULL after it has released the _lock. Accesses by any thread other >> 88: // than the lock owner are inherently racy. >> 89: Thread* _owner; > > My understanding of the idiom of using Atomic always rather than relying on any semantics for volatile is that the volatile qualifier is left on the variable, as a marker/indicator/clue that it is interesting. This will also help us find such if/when we adopt some kind of atomic class for encapsulation (whether std::atomic or something like what was proposed for JDK-8247213) and help track adoption progress. So I think the volatile qualifier should be retained. Yes, sorry. I thought we'd decided what Kim said. ------------- PR: https://git.openjdk.java.net/jdk/pull/1402 From shade at openjdk.java.net Tue Nov 24 12:30:01 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 24 Nov 2020 12:30:01 GMT Subject: RFR: 8256618: Zero: Linux x86_32 build still fails [v5] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 12:07:48 GMT, David Holmes wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Just disable the workaround for Zero >> - Merge branch 'master' into JDK-8256618-zero-x86 >> - Put the #ifdef to protect the comment too >> - Merge branch 'master' into JDK-8256618-zero-x86 >> - Touchups after merge >> - Merge branch 'master' into JDK-8256618-zero-x86 >> - 8256618: Zero: Linux x86_32 build still fails > > Marked as reviewed by dholmes (Reviewer). Okay then, let's go with this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1310 From shade at openjdk.java.net Tue Nov 24 12:30:03 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 24 Nov 2020 12:30:03 GMT Subject: Integrated: 8256618: Zero: Linux x86_32 build still fails In-Reply-To: References: Message-ID: On Thu, 19 Nov 2020 08:24:44 GMT, Aleksey Shipilev wrote: > There is no os::workaround_expand_exec_shield_cs_limit symbol available: > > > collect2: error: ld returned 1 exit status > > That symbol is defined in `os_linux_x86.cpp`, which is not available to Zero that builds `os_linux_zero.cpp`. > [JDK-8248271](https://bugs.openjdk.java.net/browse/JDK-8248271) added the declaration to `os_linux_zero.hpp`, but that is not enough, because the definition is still missing. I propose we move the definition up the hierarchy, to `os_linux.cpp` and protect it firmly with `IA32`. > > Additional testing: > - [x] Linux {x86_32, x86_64} server builds > - [x] Linux {x86_32, x86_64} zero builds This pull request has now been integrated. Changeset: 7b3d0958 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/7b3d0958 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8256618: Zero: Linux x86_32 build still fails Reviewed-by: aph, dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1310 From david.holmes at oracle.com Tue Nov 24 12:35:21 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Nov 2020 22:35:21 +1000 Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4] In-Reply-To: References: Message-ID: <826e0618-b8bc-9deb-c580-898d16ff8006@oracle.com> On 24/11/2020 9:38 pm, Jorn Vernee wrote: > On Tue, 24 Nov 2020 06:12:55 GMT, David Holmes wrote: > >>> src/hotspot/share/prims/universalUpcallHandler.cpp line 36: >>> >>>> 34: extern struct JavaVM_ main_vm; >>>> 35: >>>> 36: JNI_ENTRY_CPP_NOENV(void, ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff)) >>> >>> I do not like this. I think you have a design flaw here. We should not be directly calling member functions like this from other native code! The entry point should be a simple C-linkage function that is a normal JNI_ENTRY (assuming it actually should be a JNI_ENTRY and not JVM_ENTRY?) and that can then call the true target. >> >> Looking closer at this and the potential call-chain I don't think this is really either a JNI_ENTRY nor a JVM_ENTRY as we would normally define them. The upcall_stub seems to allow a thread to "tunnel" its way into the VM for a Java call, rather than going through the normal exported interfaces (i.e. JNI). I suspect that earlier in the review process it was requested that this be made some kind of ENTRY but I'm really not sure that fits at all. It may be cleaner, simpler and clearer to just declare a non-exported method that use `ThreadInVMFromNative` directly. > > Ok, that seems like a good idea to me as well. > > Since this code is different from normal JNI/JVM entries, I'd rather add things like exception marks or vm entry traces as needed manually, than relying on the existing macros, so that the need for each item can be re-evaluated and explained in this context. Glad you mentioned ExceptionMark! Exactly what is the design philosophy with respect to exceptions from the called Java method in this API? At present they are simply ignored. If the thread were then to make JNI calls that could break rules about not being able to call most JNI methods with a pending exception. If it makes another upcall does that immediately "abort" with the pending exception? If we have a case where the thread auto-detaches what happens then? Will it trigger the Thread uncaughtExceptionHandler? David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1266 > From jvernee at openjdk.java.net Tue Nov 24 13:21:08 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 24 Nov 2020 13:21:08 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v5] In-Reply-To: References: Message-ID: > JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. > > Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. > > However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. > > Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. > > Testing: `make images` on Linux and Windows x86_32 platforms. Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - Remove JNI_ENTRY_CPP_NOENV - - Move reset_last_Java_frame ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1266/files - new: https://git.openjdk.java.net/jdk/pull/1266/files/4f0c6ef9..6ea9b3e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=03-04 Stats: 26 lines in 3 files changed: 6 ins; 13 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266 PR: https://git.openjdk.java.net/jdk/pull/1266 From mcimadamore at openjdk.java.net Tue Nov 24 13:21:09 2020 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 24 Nov 2020 13:21:09 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 10:30:33 GMT, Aleksey Shipilev wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Use the Unimplemented() macro instead of hlt() > > I have a few minor comments, in addition to what David is saying about `JNI_ENTRY_CPP_NOENV`. > Glad you mentioned ExceptionMark! Exactly what is the design philosophy > with respect to exceptions from the called Java method in this API? At > present they are simply ignored. If the thread were then to make JNI > calls that could break rules about not being able to call most JNI > methods with a pending exception. If it makes another upcall does that > immediately "abort" with the pending exception? If we have a case where > the thread auto-detaches what happens then? Will it trigger the Thread > uncaughtExceptionHandler? This is a very good point David - if an exception is issued during an upcall, there's not a lot we can do on native side to recover. We have plans here (Jorn suggested to just wrap the upcall method handle in a "catch-all" which catches all exceptions and then just exits the VM). But, at the same time, I'd like to "steer" the discussion in this PR towards the stated goal of the PR - namely, fix build issues in x86. ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From jorn.vernee at oracle.com Tue Nov 24 12:58:33 2020 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Tue, 24 Nov 2020 13:58:33 +0100 Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v4] In-Reply-To: <826e0618-b8bc-9deb-c580-898d16ff8006@oracle.com> References: <826e0618-b8bc-9deb-c580-898d16ff8006@oracle.com> Message-ID: The main assumption is that calling code is fully foreign, and that it does not know how to Java handle exceptions at all. So, if an exception is thrown at this point, we should probably just crash, and make it the callee's responsibility to handle exception if they need/want to. Looking at this now, I think I'll switch the upcall itself to use CATCH, and then see what we can do on the Java side to crash in a more friendly way if there is an active exception when we return from the upcall (such as invoking the default uncaught exception handler). How does that sound? Jorn On 24/11/2020 13:35, David Holmes wrote: > On 24/11/2020 9:38 pm, Jorn Vernee wrote: >> On Tue, 24 Nov 2020 06:12:55 GMT, David Holmes >> wrote: >> >>>> src/hotspot/share/prims/universalUpcallHandler.cpp line 36: >>>> >>>>> 34: extern struct JavaVM_ main_vm; >>>>> 35: >>>>> 36: JNI_ENTRY_CPP_NOENV(void, >>>>> ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff)) >>>> >>>> I do not like this. I think you have a design flaw here. We should >>>> not be directly calling member functions like this from other >>>> native code! The entry point should be a simple C-linkage function >>>> that is a normal JNI_ENTRY (assuming it actually should be a >>>> JNI_ENTRY and not JVM_ENTRY?) and that can then call the true target. >>> >>> Looking closer at this and the potential call-chain I don't think >>> this is really either a JNI_ENTRY nor a JVM_ENTRY as we would >>> normally define them. The upcall_stub seems to allow a thread to >>> "tunnel" its way into the VM for a Java call, rather than going >>> through the normal exported interfaces (i.e. JNI). I suspect that >>> earlier in the review process it was requested that this be made >>> some kind of ENTRY but I'm really not sure that fits at all. It may >>> be cleaner, simpler and clearer to just declare a non-exported >>> method that use `ThreadInVMFromNative` directly. >> >> Ok, that seems like a good idea to me as well. >> >> Since this code is different from normal JNI/JVM entries, I'd rather >> add things like exception marks or vm entry traces as needed >> manually, than relying on the existing macros, so that the need for >> each item can be re-evaluated and explained in this context. > > Glad you mentioned ExceptionMark! Exactly what is the design > philosophy with respect to exceptions from the called Java method in > this API? At present they are simply ignored. If the thread were then > to make JNI calls that could break rules about not being able to call > most JNI methods with a pending exception. If it makes another upcall > does that immediately "abort" with the pending exception? If we have a > case where the thread auto-detaches what happens then? Will it trigger > the Thread uncaughtExceptionHandler? > > David > ----- > >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/1266 >> From jvernee at openjdk.java.net Tue Nov 24 13:35:17 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 24 Nov 2020 13:35:17 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v6] In-Reply-To: References: Message-ID: <8t9K2ZBTJu1RRsWncao3E7LHxKYnOvfwC2GigKsel1g=.970833fb-2560-4a13-9984-9082c4b40157@github.com> > JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. > > Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. > > However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. > > Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. > > Testing: `make images` on Linux and Windows x86_32 platforms. Jorn Vernee 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 10 additional commits since the last revision: - Merge branch 'master' into Linker_32bit-fixes_Simpler - Remove JNI_ENTRY_CPP_NOENV - - Move reset_last_Java_frame - Use the Unimplemented() macro instead of hlt() - Merge branch 'master' into Linker_32bit-fixes_Simpler - Remove UnsupportedPlatform test - Remove unneeded cast - Remove Stuff that makes the jdk_foreign tests pass - fix test warnings - - Fix 32-bit build errors and tests - Add negative test for 32-bit platform. - Change CABI to fail more lazily when running on an unsupported platform. - Change CLinker layouts to be null on unsupported platforms, instead of failing when initializing the class - Added note to CLinker about failure to initialize on unsupported platforms ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1266/files - new: https://git.openjdk.java.net/jdk/pull/1266/files/6ea9b3e3..960021ba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=04-05 Stats: 2931 lines in 100 files changed: 1501 ins; 855 del; 575 mod Patch: https://git.openjdk.java.net/jdk/pull/1266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266 PR: https://git.openjdk.java.net/jdk/pull/1266 From shade at openjdk.java.net Tue Nov 24 13:35:18 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 24 Nov 2020 13:35:18 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v5] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 13:21:08 GMT, Jorn Vernee wrote: >> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. >> >> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. >> >> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. >> >> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. >> >> Testing: `make images` on Linux and Windows x86_32 platforms. > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - Remove JNI_ENTRY_CPP_NOENV > - - Move reset_last_Java_frame This looks fine to me. PIty to see `CATCH` on the exception recovery path, but that seems okay for the incubating code. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1266 From jvernee at openjdk.java.net Tue Nov 24 14:01:57 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 24 Nov 2020 14:01:57 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v5] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 13:31:17 GMT, Aleksey Shipilev wrote: >> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove JNI_ENTRY_CPP_NOENV >> - - Move reset_last_Java_frame > > This looks fine to me. PIty to see `CATCH` on the exception recovery path, but that seems okay for the incubating code. Discussing this with Maurizio as well; FWIW, after we change the Java code that gets called, to handle all exceptions, the CATCH should never trigger. It will just be there as a sanity check. ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From lgxbslgx at gmail.com Tue Nov 24 16:39:50 2020 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Wed, 25 Nov 2020 00:39:50 +0800 Subject: runtime/handshake/HandshakeWalkStackTest.java failed occasionally at Linux-x64 Message-ID: Hi all, I accidentally found runtime/handshake/HandshakeWalkStackTest.java failed at Linux-x64 when I tested another bug in my own branch. Then I rerun this test and it passed which confused me. In order to identify that my own code is right, I rerun all the tests of the branch master instead of my own branch at Linux-x64 many times to reproduce the failed test. Finally, I reproduce the failed test in branch master. The failed test log is shown in the following link. complete log: https://github.com/lgxbslgx/jdk/actions/runs/379035778 concrete location: https://github.com/lgxbslgx/jdk/runs/1442650519?check_suite_focus=true And the passed test log is shown in the following link for you if needed. https://github.com/lgxbslgx/jdk/actions/runs/379224900 Hope these logs could help diagnose the bug. Best Regards. From dholmes at openjdk.java.net Tue Nov 24 22:39:08 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 Nov 2020 22:39:08 GMT Subject: RFR: 8256474: Migrate Mutex _owner accesses to use Atomic operations [v3] In-Reply-To: References: Message-ID: > Simple update to move away from volatile fields and use Atomic::load/store on racy accesses. > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Restore volatile modifier ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1402/files - new: https://git.openjdk.java.net/jdk/pull/1402/files/fa203cb5..0b9351ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1402&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1402&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1402/head:pull/1402 PR: https://git.openjdk.java.net/jdk/pull/1402 From clanger at openjdk.java.net Tue Nov 24 23:42:05 2020 From: clanger at openjdk.java.net (Christoph Langer) Date: Tue, 24 Nov 2020 23:42:05 GMT Subject: RFR: 8256489: Make gtest for long path names on Windows more resilient in the presence of virus scanners [v2] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 09:32:18 GMT, Ralf Schmelter wrote: >> Hi, >> >> a virus scanner can keep a file open on Windows, so that a DeleteFile command returns successful, but the file is actually not removed when the call returns. In the gtest for long path names on Windows this can lead to failures when a directory is tried to be removed, but the file inside it is still kept by the virus scanner. >> >> Since this is an error which only occurs very infrequently, we just retry the deletion a few times. >> >> Best regards, >> Ralf > > Ralf Schmelter 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 two additional commits since the last revision: > > - Incorporated review findings from David Holmes > - Make directory removal in path test more resilient Marked as reviewed by clanger (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1380 From dholmes at openjdk.java.net Wed Nov 25 00:05:00 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 25 Nov 2020 00:05:00 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v6] In-Reply-To: <8t9K2ZBTJu1RRsWncao3E7LHxKYnOvfwC2GigKsel1g=.970833fb-2560-4a13-9984-9082c4b40157@github.com> References: <8t9K2ZBTJu1RRsWncao3E7LHxKYnOvfwC2GigKsel1g=.970833fb-2560-4a13-9984-9082c4b40157@github.com> Message-ID: On Tue, 24 Nov 2020 13:35:17 GMT, Jorn Vernee wrote: >> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. >> >> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. >> >> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. >> >> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. >> >> Testing: `make images` on Linux and Windows x86_32 platforms. > > Jorn Vernee 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 10 additional commits since the last revision: > > - Merge branch 'master' into Linker_32bit-fixes_Simpler > - Remove JNI_ENTRY_CPP_NOENV > - - Move reset_last_Java_frame > - Use the Unimplemented() macro instead of hlt() > - Merge branch 'master' into Linker_32bit-fixes_Simpler > - Remove UnsupportedPlatform test > - Remove unneeded cast > - Remove Stuff that makes the jdk_foreign tests pass > - fix test warnings > - - Fix 32-bit build errors and tests > - Add negative test for 32-bit platform. > - Change CABI to fail more lazily when running on an unsupported platform. > - Change CLinker layouts to be null on unsupported platforms, instead of failing when initializing the class > - Added note to CLinker about failure to initialize on unsupported platforms The VM "entry" changes seem better now. Thanks. The use of CATCH as a safety-net is also good. src/hotspot/share/prims/universalUpcallHandler.cpp line 37: > 35: > 36: void ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff) { > 37: JavaThread* THREAD = JavaThread::current(); You could pass the current thread in rather than re-manifesting it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From david.holmes at oracle.com Wed Nov 25 01:26:15 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Nov 2020 11:26:15 +1000 Subject: runtime/handshake/HandshakeWalkStackTest.java failed occasionally at Linux-x64 In-Reply-To: References: Message-ID: Hi, Thanks for the report. This is a known issue: https://bugs.openjdk.java.net/browse/JDK-8256641 Cheers, David On 25/11/2020 2:39 am, Guoxiong Li wrote: > Hi all, > > I accidentally found runtime/handshake/HandshakeWalkStackTest.java failed > at Linux-x64 when I tested another bug in my own branch. Then I rerun this > test and it passed which confused me. > > In order to identify that my own code is right, I rerun all the tests of > the branch master instead of my own branch at Linux-x64 many times to > reproduce the failed test. > > Finally, I reproduce the failed test in branch master. The failed test log > is shown in the following link. > complete log: https://github.com/lgxbslgx/jdk/actions/runs/379035778 > concrete location: > https://github.com/lgxbslgx/jdk/runs/1442650519?check_suite_focus=true > > And the passed test log is shown in the following link for you if needed. > https://github.com/lgxbslgx/jdk/actions/runs/379224900 > > Hope these logs could help diagnose the bug. > > Best Regards. > From stuefe at openjdk.java.net Wed Nov 25 08:04:01 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 25 Nov 2020 08:04:01 GMT Subject: RFR: JDK-8257042: [aix] Disable os.release_one_mapping_multi_commits_vm gtest Message-ID: On AIX, os::release_memory() cannot release multi-mappings since os::reserve_memory() may return system V shared memory instead of the usual mmapped memory. This makes a new gtest fail. This is very difficult to fix, therefore lets just disable this test for now. For details about the underlying issue, see https://bugs.openjdk.java.net/browse/JDK-8257041. -- patch disables the test for AIX, and also needs to disable the local reserve helper function to avoid an "unused symbol" warning. ------------- Commit messages: - disable multi map test on aix Changes: https://git.openjdk.java.net/jdk/pull/1426/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1426&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257042 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1426.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1426/head:pull/1426 PR: https://git.openjdk.java.net/jdk/pull/1426 From shade at openjdk.java.net Wed Nov 25 08:25:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 25 Nov 2020 08:25:57 GMT Subject: RFR: JDK-8257042: [aix] Disable os.release_one_mapping_multi_commits_vm gtest In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 07:59:05 GMT, Thomas Stuefe wrote: > On AIX, os::release_memory() cannot release multi-mappings since os::reserve_memory() may return system V shared memory instead of the usual mmapped memory. This makes a new gtest fail. > > This is very difficult to fix, therefore lets just disable this test for now. > > For details about the underlying issue, see https://bugs.openjdk.java.net/browse/JDK-8257041. > > -- > > patch disables the test for AIX, and also needs to disable the local reserve helper function to avoid an "unused symbol" warning. Looks fine. I guess you don't actually need to `ifndef` the `reserve_multiple`, which is not a test in itself. But omitting that `ifndef` probably sets you up for "unused method" warnings on AIX? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1426 From stuefe at openjdk.java.net Wed Nov 25 08:31:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 25 Nov 2020 08:31:58 GMT Subject: RFR: JDK-8257042: [aix] Disable os.release_one_mapping_multi_commits_vm gtest In-Reply-To: References: Message-ID: <8MysbqfF_B_zx00pSLGuvlBfQC5LwYGOBulBHMG4oDg=.74d9b5e9-a527-416f-bd01-f90d1e8faa0b@github.com> On Wed, 25 Nov 2020 08:22:54 GMT, Aleksey Shipilev wrote: > Looks fine. Thanks. > I guess you don't actually need to `ifndef` the `reserve_multiple`, which is not a test in itself. But omitting that `ifndef` probably sets you up for "unused method" warnings on AIX? Yes, exactly. ------------- PR: https://git.openjdk.java.net/jdk/pull/1426 From shade at openjdk.java.net Wed Nov 25 08:31:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 25 Nov 2020 08:31:59 GMT Subject: RFR: JDK-8257042: [aix] Disable os.release_one_mapping_multi_commits_vm gtest In-Reply-To: <8MysbqfF_B_zx00pSLGuvlBfQC5LwYGOBulBHMG4oDg=.74d9b5e9-a527-416f-bd01-f90d1e8faa0b@github.com> References: <8MysbqfF_B_zx00pSLGuvlBfQC5LwYGOBulBHMG4oDg=.74d9b5e9-a527-416f-bd01-f90d1e8faa0b@github.com> Message-ID: On Wed, 25 Nov 2020 08:29:02 GMT, Thomas Stuefe wrote: >> Looks fine. I guess you don't actually need to `ifndef` the `reserve_multiple`, which is not a test in itself. But omitting that `ifndef` probably sets you up for "unused method" warnings on AIX? > >> Looks fine. > > Thanks. > >> I guess you don't actually need to `ifndef` the `reserve_multiple`, which is not a test in itself. But omitting that `ifndef` probably sets you up for "unused method" warnings on AIX? > > Yes, exactly. Ok, looks trivial to me then. Ship it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1426 From stuefe at openjdk.java.net Wed Nov 25 08:49:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 25 Nov 2020 08:49:55 GMT Subject: RFR: JDK-8257042: [aix] Disable os.release_one_mapping_multi_commits_vm gtest In-Reply-To: References: <8MysbqfF_B_zx00pSLGuvlBfQC5LwYGOBulBHMG4oDg=.74d9b5e9-a527-416f-bd01-f90d1e8faa0b@github.com> Message-ID: On Wed, 25 Nov 2020 08:29:48 GMT, Aleksey Shipilev wrote: >>> Looks fine. >> >> Thanks. >> >>> I guess you don't actually need to `ifndef` the `reserve_multiple`, which is not a test in itself. But omitting that `ifndef` probably sets you up for "unused method" warnings on AIX? >> >> Yes, exactly. > > Ok, looks trivial to me then. Ship it. I'll wait until the gh actions show some resemblance of sanity... :( ------------- PR: https://git.openjdk.java.net/jdk/pull/1426 From jvernee at openjdk.java.net Wed Nov 25 10:41:02 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 25 Nov 2020 10:41:02 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v6] In-Reply-To: References: <8t9K2ZBTJu1RRsWncao3E7LHxKYnOvfwC2GigKsel1g=.970833fb-2560-4a13-9984-9082c4b40157@github.com> Message-ID: On Tue, 24 Nov 2020 23:59:11 GMT, David Holmes wrote: >> Jorn Vernee 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 10 additional commits since the last revision: >> >> - Merge branch 'master' into Linker_32bit-fixes_Simpler >> - Remove JNI_ENTRY_CPP_NOENV >> - - Move reset_last_Java_frame >> - Use the Unimplemented() macro instead of hlt() >> - Merge branch 'master' into Linker_32bit-fixes_Simpler >> - Remove UnsupportedPlatform test >> - Remove unneeded cast >> - Remove Stuff that makes the jdk_foreign tests pass >> - fix test warnings >> - - Fix 32-bit build errors and tests >> - Add negative test for 32-bit platform. >> - Change CABI to fail more lazily when running on an unsupported platform. >> - Change CLinker layouts to be null on unsupported platforms, instead of failing when initializing the class >> - Added note to CLinker about failure to initialize on unsupported platforms > > src/hotspot/share/prims/universalUpcallHandler.cpp line 37: > >> 35: >> 36: void ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff) { >> 37: JavaThread* THREAD = JavaThread::current(); > > You could pass the current thread in rather than re-manifesting it. Ah, of course. Will fix ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From jvernee at openjdk.java.net Wed Nov 25 12:09:07 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 25 Nov 2020 12:09:07 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v7] In-Reply-To: References: Message-ID: > JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. > > Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. > > However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. > > Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. > > Testing: `make images` on Linux and Windows x86_32 platforms. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Pass in thread instead of rematerializing it. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1266/files - new: https://git.openjdk.java.net/jdk/pull/1266/files/960021ba..c76286cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=05-06 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266 PR: https://git.openjdk.java.net/jdk/pull/1266 From vlivanov at openjdk.java.net Wed Nov 25 12:19:01 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 25 Nov 2020 12:19:01 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v7] In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 12:09:07 GMT, Jorn Vernee wrote: >> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. >> >> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. >> >> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. >> >> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. >> >> Testing: `make images` on Linux and Windows x86_32 platforms. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Pass in thread instead of rematerializing it. src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp line 33: > 31: > 32: void ProgrammableInvoker::Generator::generate() { > 33: #ifdef _LP64 Instead of introducing ifdefs, I'd prefer to see `universalNativeInvoker_x86.cpp` split into `universalNativeInvoker_x86_64.cpp` (current code) and `universalNativeInvoker_x86_32.cpp` (populated with dummy impelmentations). ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From jvernee at openjdk.java.net Wed Nov 25 12:31:59 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 25 Nov 2020 12:31:59 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v7] In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 12:16:01 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Pass in thread instead of rematerializing it. > > src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp line 33: > >> 31: >> 32: void ProgrammableInvoker::Generator::generate() { >> 33: #ifdef _LP64 > > Instead of introducing ifdefs, I'd prefer to see `universalNativeInvoker_x86.cpp` split into `universalNativeInvoker_x86_64.cpp` (current code) and `universalNativeInvoker_x86_32.cpp` (populated with dummy impelmentations). Yeah, makes sense. The old code had ifdefs, but splitting seems cleaner to me as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From jvernee at openjdk.java.net Wed Nov 25 13:04:18 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 25 Nov 2020 13:04:18 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v8] In-Reply-To: References: Message-ID: > JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. > > Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. > > However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. > > Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. > > Testing: `make images` on Linux and Windows x86_32 platforms. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Split out 32-bit impl from native invoker and upcall handler ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1266/files - new: https://git.openjdk.java.net/jdk/pull/1266/files/c76286cd..b0edea8d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=06-07 Stats: 72 lines in 4 files changed: 64 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266 PR: https://git.openjdk.java.net/jdk/pull/1266 From rschmelter at openjdk.java.net Wed Nov 25 13:19:56 2020 From: rschmelter at openjdk.java.net (Ralf Schmelter) Date: Wed, 25 Nov 2020 13:19:56 GMT Subject: Integrated: 8256489: Make gtest for long path names on Windows more resilient in the presence of virus scanners In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 10:41:47 GMT, Ralf Schmelter wrote: > Hi, > > a virus scanner can keep a file open on Windows, so that a DeleteFile command returns successful, but the file is actually not removed when the call returns. In the gtest for long path names on Windows this can lead to failures when a directory is tried to be removed, but the file inside it is still kept by the virus scanner. > > Since this is an error which only occurs very infrequently, we just retry the deletion a few times. > > Best regards, > Ralf This pull request has now been integrated. Changeset: 26e6cb3e Author: Ralf Schmelter URL: https://git.openjdk.java.net/jdk/commit/26e6cb3e Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod 8256489: Make gtest for long path names on Windows more resilient in the presence of virus scanners Reviewed-by: dholmes, clanger ------------- PR: https://git.openjdk.java.net/jdk/pull/1380 From jvernee at openjdk.java.net Wed Nov 25 16:33:01 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 25 Nov 2020 16:33:01 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v6] In-Reply-To: References: <8t9K2ZBTJu1RRsWncao3E7LHxKYnOvfwC2GigKsel1g=.970833fb-2560-4a13-9984-9082c4b40157@github.com> Message-ID: On Wed, 25 Nov 2020 00:01:47 GMT, David Holmes wrote: >> Jorn Vernee 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 10 additional commits since the last revision: >> >> - Merge branch 'master' into Linker_32bit-fixes_Simpler >> - Remove JNI_ENTRY_CPP_NOENV >> - - Move reset_last_Java_frame >> - Use the Unimplemented() macro instead of hlt() >> - Merge branch 'master' into Linker_32bit-fixes_Simpler >> - Remove UnsupportedPlatform test >> - Remove unneeded cast >> - Remove Stuff that makes the jdk_foreign tests pass >> - fix test warnings >> - - Fix 32-bit build errors and tests >> - Add negative test for 32-bit platform. >> - Change CABI to fail more lazily when running on an unsupported platform. >> - Change CLinker layouts to be null on unsupported platforms, instead of failing when initializing the class >> - Added note to CLinker about failure to initialize on unsupported platforms > > The VM "entry" changes seem better now. Thanks. > > The use of CATCH as a safety-net is also good. I've applied open comments. Please let me know if this is ok to merge. ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From shade at openjdk.java.net Wed Nov 25 17:07:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 25 Nov 2020 17:07:57 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v6] In-Reply-To: References: <8t9K2ZBTJu1RRsWncao3E7LHxKYnOvfwC2GigKsel1g=.970833fb-2560-4a13-9984-9082c4b40157@github.com> Message-ID: On Wed, 25 Nov 2020 16:30:16 GMT, Jorn Vernee wrote: >> The VM "entry" changes seem better now. Thanks. >> >> The use of CATCH as a safety-net is also good. > > I've applied open comments. Please let me know if this is ok to merge. Still looks fine to me. Merge from master to get the fixes for GH actions failures, #1427 ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From jvernee at openjdk.java.net Wed Nov 25 17:14:08 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 25 Nov 2020 17:14:08 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v9] In-Reply-To: References: Message-ID: > JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. > > Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. > > However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. > > Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. > > Testing: `make images` on Linux and Windows x86_32 platforms. Jorn Vernee 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 Linker_32bit-fixes_New-Master - Split out 32-bit impl from native invoker and upcall handler - Pass in thread instead of rematerializing it. - Merge branch 'master' into Linker_32bit-fixes_Simpler - Remove JNI_ENTRY_CPP_NOENV - - Move reset_last_Java_frame - Use the Unimplemented() macro instead of hlt() - Merge branch 'master' into Linker_32bit-fixes_Simpler - Remove UnsupportedPlatform test - Remove unneeded cast - ... and 3 more: https://git.openjdk.java.net/jdk/compare/461c5fc6...5e664033 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1266/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=08 Stats: 88 lines in 12 files changed: 45 ins; 27 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1266.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266 PR: https://git.openjdk.java.net/jdk/pull/1266 From vlivanov at openjdk.java.net Wed Nov 25 17:32:58 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 25 Nov 2020 17:32:58 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v6] In-Reply-To: References: <8t9K2ZBTJu1RRsWncao3E7LHxKYnOvfwC2GigKsel1g=.970833fb-2560-4a13-9984-9082c4b40157@github.com> Message-ID: On Wed, 25 Nov 2020 17:05:15 GMT, Aleksey Shipilev wrote: >> I've applied open comments. Please let me know if this is ok to merge. > > Still looks fine to me. Merge from master to get the fixes for GH actions failures, #1427 Thanks, Jorn. The split looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From shade at openjdk.java.net Wed Nov 25 17:37:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 25 Nov 2020 17:37:57 GMT Subject: RFR: JDK-8257042: [aix] Disable os.release_one_mapping_multi_commits_vm gtest In-Reply-To: References: <8MysbqfF_B_zx00pSLGuvlBfQC5LwYGOBulBHMG4oDg=.74d9b5e9-a527-416f-bd01-f90d1e8faa0b@github.com> Message-ID: On Wed, 25 Nov 2020 08:47:05 GMT, Thomas Stuefe wrote: >> Ok, looks trivial to me then. Ship it. > > I'll wait until the gh actions show some resemblance of sanity... :( #1427 is fixed, you can pull. ------------- PR: https://git.openjdk.java.net/jdk/pull/1426 From jvernee at openjdk.java.net Wed Nov 25 18:13:00 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 25 Nov 2020 18:13:00 GMT Subject: Integrated: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 17:19:13 GMT, Jorn Vernee wrote: > JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. > > Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. > > However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. > > Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. > > Testing: `make images` on Linux and Windows x86_32 platforms. This pull request has now been integrated. Changeset: 7c73fff3 Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/7c73fff3 Stats: 88 lines in 12 files changed: 45 ins; 27 del; 16 mod 8256486: Linux/Windows-x86 builds broken after JDK-8254231 Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From stuefe at openjdk.java.net Wed Nov 25 21:29:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 25 Nov 2020 21:29:55 GMT Subject: RFR: JDK-8257042: [aix] Disable os.release_one_mapping_multi_commits_vm gtest In-Reply-To: References: <8MysbqfF_B_zx00pSLGuvlBfQC5LwYGOBulBHMG4oDg=.74d9b5e9-a527-416f-bd01-f90d1e8faa0b@github.com> Message-ID: On Wed, 25 Nov 2020 17:35:03 GMT, Aleksey Shipilev wrote: >> I'll wait until the gh actions show some resemblance of sanity... :( > > #1427 is fixed, you can pull. Local tests went through. ------------- PR: https://git.openjdk.java.net/jdk/pull/1426 From stuefe at openjdk.java.net Wed Nov 25 21:29:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 25 Nov 2020 21:29:56 GMT Subject: Integrated: JDK-8257042: [aix] Disable os.release_one_mapping_multi_commits_vm gtest In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 07:59:05 GMT, Thomas Stuefe wrote: > On AIX, os::release_memory() cannot release multi-mappings since os::reserve_memory() may return system V shared memory instead of the usual mmapped memory. This makes a new gtest fail. > > This is very difficult to fix, therefore lets just disable this test for now. > > For details about the underlying issue, see https://bugs.openjdk.java.net/browse/JDK-8257041. > > -- > > patch disables the test for AIX, and also needs to disable the local reserve helper function to avoid an "unused symbol" warning. This pull request has now been integrated. Changeset: e56a8df8 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/e56a8df8 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8257042: [aix] Disable os.release_one_mapping_multi_commits_vm gtest Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1426 From mr at openjdk.java.net Wed Nov 25 23:50:14 2020 From: mr at openjdk.java.net (Mark Reinhold) Date: Wed, 25 Nov 2020 23:50:14 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v6] In-Reply-To: References: Message-ID: > Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I?ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: Fix "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test (v2) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1324/files - new: https://git.openjdk.java.net/jdk/pull/1324/files/1a7ab4e0..0c9654a0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=04-05 Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1324.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1324/head:pull/1324 PR: https://git.openjdk.java.net/jdk/pull/1324 From mr at openjdk.java.net Wed Nov 25 23:50:14 2020 From: mr at openjdk.java.net (Mark Reinhold) Date: Wed, 25 Nov 2020 23:50:14 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v6] In-Reply-To: References: Message-ID: <0b3G2kuAXY2BpvNt5c6jYGJZvZZj-GWk6007iXMYOEo=.2a26649c-9b3f-4b6f-9576-02a4fee84911@github.com> On Fri, 20 Nov 2020 13:08:11 GMT, Alan Bateman wrote: >> Looks good. > > testWithAddExportsInManifest create an executable JAR with "Add-Exports: java.base/sun.security.x509" in the manifest. It runs it twice, once without any options, the second with --illegal-access=permit, and checks there are no warnings in both cases. To test attempted deep reflection here would need the equivalent of setAccessibleNonPublicMemberNonExportedPackage that tries to access some privates in sun.security.x509. It's okay to use setAccessibleNonPublicMemberNonExportedPackage to test that privates in sun.nio.ch aren't accessible but it's not connected to the Add-Exports attribute in the JAR file. Thanks for pointing that out. I fixed it by arranging for the `Add-Exports` test to export both `sun.security.x509` and `sun.nio.ch`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1324 From alanb at openjdk.java.net Thu Nov 26 07:34:00 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 26 Nov 2020 07:34:00 GMT Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v6] In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 23:50:14 GMT, Mark Reinhold wrote: >> Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396). >> Alan Bateman is the original author; I?ve credited him in the commit metadata. >> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. > > Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision: > > Fix "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test (v2) Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1324 From vlivanov at openjdk.java.net Thu Nov 26 13:49:01 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 26 Nov 2020 13:49:01 GMT Subject: RFR: 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers Message-ID: Method linkage of `invokehandle` instructions involve an upcall into Java (`MethodHandleNatives::linkMethod`), but the result is not cached. Unless the upcall behaves idempotently (which is highly desirable, but not guaranteed), repeated invokehandle resolution attempts enter a vicious cycle in tiered mode: switching to a higher tier involves call site re-resolution in generated code, but re-resolution installs a fresh method which puts execution back into interpreter. (Another prerequisite is no inlining through a `invokehandle` which doesn't normally happen in practice - relevant methods are marked w/ `@ForceInline` - except some testing modes, `-Xcomp` in particular.) Proposed fix is to inspect `ConstantPoolCache` first. Previous resolution attempts from interpreter and C1 records their results there and it stabilises the execution. Testing: - failing test - tier1-4 ------------- Commit messages: - Remove affected test from the problem list - Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers. Changes: https://git.openjdk.java.net/jdk/pull/1453/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1453&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256368 Stats: 51 lines in 5 files changed: 26 ins; 12 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/1453.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1453/head:pull/1453 PR: https://git.openjdk.java.net/jdk/pull/1453 From rkennke at openjdk.java.net Thu Nov 26 17:52:05 2020 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 26 Nov 2020 17:52:05 GMT Subject: RFR: 8257180: Prevent resurrection of final/phantom refs through JNI weak refs Message-ID: It is currently possible to resurrect finalizable objects or even phantom references after they have been finalized: - Create JNI weak reference to object - Create phantom reference to object/ use object with finalize() method, so that a FinalReference is created. As soon as the object is no longer strongly reachable, the Finalizer will invoke finalize() on the object, or, if it has been wrapped in a PhantomReference, that PR will be enqueued in its ReferenceQueue. With some luck, it is still possible to get hold of the original object via the JNI weak reference. This is actually specified in JNI specification: https://docs.oracle.com/en/java/javase/11/docs/specs/jni/functions.html#weak-global-references "The weak global reference is weaker than other types of weak references (Java objects of the SoftReference or WeakReference classes). A weak global reference to a specific object will not become functionally equivalent to NULL until after SoftReference or WeakReference objects referring to that same specific object have had their references cleared. The weak global reference is weaker than Java's internal references to objects requiring finalization. A weak global reference will not become functionally equivalent to NULL until after the completion of the finalizer for the referenced object, if present. Interactions between weak global references and PhantomReferences are undefined. In particular, implementations of a Java VM may (or may not) process weak global references after PhantomReferences, and it may (or may not) be possible to use weak global references to hold on to objects which are also referred to by PhantomReference objects." The implementation in referenceProcessor.cpp even has a comment about it: // Weak global JNI references. It would make more sense (semantically) to // traverse these simultaneously with the regular weak references above, but // that is not how the JDK1.2 specification is. See #4126360. Native code can // thus use JNI weak references to circumvent the phantom references and // resurrect a "post-mortem" object. (Notice: I don't have access to bug#4126360, I cannot tell if there is any interesting discussion about the usefulness there.) However, it turns out that the above clarification to JNI weak reference specification has been removed since Java 13: https://docs.oracle.com/en/java/javase/13/docs/specs/jni/functions.html#weak-global-references Which means that we are, strictly speaking, now free to rectify the situation. And since this 'feature' doesn't seem to have any useful applications, and only serves to shoot oneself into its own foot, I propose that we go ahead and do that. This PR addresses the situation for ZGC and Shenandoah. I am not sure if we should try and do the other GCs too (in referenceProcessor.cpp). What do you think? Testing: - [x] hotspot_gc_shenandoah - [x] tier1 with +ShenandoahGC +ShenandoahVerify - [x] tier2 with +ShenandoahGC +ShenandoahVerify ------------- Commit messages: - 8257180: Prevent resurrection of final/phantom refs through JNI weak refs Changes: https://git.openjdk.java.net/jdk/pull/1464/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1464&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257180 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1464.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1464/head:pull/1464 PR: https://git.openjdk.java.net/jdk/pull/1464 From kbarrett at openjdk.java.net Thu Nov 26 19:11:00 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 26 Nov 2020 19:11:00 GMT Subject: RFR: 8257180: Prevent resurrection of final/phantom refs through JNI weak refs In-Reply-To: References: Message-ID: <-O7gB9UHR2PF6PQ_rnM5LZgzuuXV4HHOrPZGhEUKErQ=.cb661a93-1c99-4083-812c-d12207dffabb@github.com> On Thu, 26 Nov 2020 17:47:23 GMT, Roman Kennke wrote: > It is currently possible to resurrect finalizable objects or even phantom references after they have been finalized: > - Create JNI weak reference to object > - Create phantom reference to object/ use object with finalize() method, so that a FinalReference is created. > > As soon as the object is no longer strongly reachable, the Finalizer will invoke finalize() on the object, or, if it has been wrapped in a PhantomReference, that PR will be enqueued in its ReferenceQueue. With some luck, it is still possible to get hold of the original object via the JNI weak reference. > > This is actually specified in JNI specification: > https://docs.oracle.com/en/java/javase/11/docs/specs/jni/functions.html#weak-global-references > > "The weak global reference is weaker than other types of weak references (Java objects of the SoftReference or WeakReference classes). A weak global reference to a specific object will not become functionally equivalent to NULL until after SoftReference or WeakReference objects referring to that same specific object have had their references cleared. > > The weak global reference is weaker than Java's internal references to objects requiring finalization. A weak global reference will not become functionally equivalent to NULL until after the completion of the finalizer for the referenced object, if present. > > Interactions between weak global references and PhantomReferences are undefined. In particular, implementations of a Java VM may (or may not) process weak global references after PhantomReferences, and it may (or may not) be possible to use weak global references to hold on to objects which are also referred to by PhantomReference objects." > > The implementation in referenceProcessor.cpp even has a comment about it: > > // Weak global JNI references. It would make more sense (semantically) to > // traverse these simultaneously with the regular weak references above, but > // that is not how the JDK1.2 specification is. See #4126360. Native code can > // thus use JNI weak references to circumvent the phantom references and > // resurrect a "post-mortem" object. > > (Notice: I don't have access to bug#4126360, I cannot tell if there is any interesting discussion about the usefulness there.) > > However, it turns out that the above clarification to JNI weak reference specification has been removed since Java 13: > > https://docs.oracle.com/en/java/javase/13/docs/specs/jni/functions.html#weak-global-references > > Which means that we are, strictly speaking, now free to rectify the situation. And since this 'feature' doesn't seem to have any useful applications, and only serves to shoot oneself into its own foot, I propose that we go ahead and do that. > > This PR addresses the situation for ZGC and Shenandoah. I am not sure if we should try and do the other GCs too (in referenceProcessor.cpp). > > What do you think? > > Testing: > - [x] hotspot_gc_shenandoah > - [x] tier1 with +ShenandoahGC +ShenandoahVerify > - [x] tier2 with +ShenandoahGC +ShenandoahVerify src/hotspot/share/runtime/jniHandles.inline.hpp line 58: > 56: oop result; > 57: if (is_jweak(handle)) { // Unlikely > 58: result = NativeAccess::oop_load(jweak_ptr(handle)); This is incorrect. JNI weak references have phantom strength, not weak strength. This changes is incorrect. ------------- PR: https://git.openjdk.java.net/jdk/pull/1464 From rkennke at openjdk.java.net Thu Nov 26 19:16:56 2020 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 26 Nov 2020 19:16:56 GMT Subject: RFR: 8257180: Prevent resurrection of final/phantom refs through JNI weak refs In-Reply-To: <-O7gB9UHR2PF6PQ_rnM5LZgzuuXV4HHOrPZGhEUKErQ=.cb661a93-1c99-4083-812c-d12207dffabb@github.com> References: <-O7gB9UHR2PF6PQ_rnM5LZgzuuXV4HHOrPZGhEUKErQ=.cb661a93-1c99-4083-812c-d12207dffabb@github.com> Message-ID: <1GTnCpZOibL4ECkBxC-gdrm-5vyZ1QSeO1dswxnsae4=.b650353e-0e21-4c77-b636-2aea8ba49b1d@github.com> On Thu, 26 Nov 2020 19:08:30 GMT, Kim Barrett wrote: >> It is currently possible to resurrect finalizable objects or even phantom references after they have been finalized: >> - Create JNI weak reference to object >> - Create phantom reference to object/ use object with finalize() method, so that a FinalReference is created. >> >> As soon as the object is no longer strongly reachable, the Finalizer will invoke finalize() on the object, or, if it has been wrapped in a PhantomReference, that PR will be enqueued in its ReferenceQueue. With some luck, it is still possible to get hold of the original object via the JNI weak reference. >> >> This is actually specified in JNI specification: >> https://docs.oracle.com/en/java/javase/11/docs/specs/jni/functions.html#weak-global-references >> >> "The weak global reference is weaker than other types of weak references (Java objects of the SoftReference or WeakReference classes). A weak global reference to a specific object will not become functionally equivalent to NULL until after SoftReference or WeakReference objects referring to that same specific object have had their references cleared. >> >> The weak global reference is weaker than Java's internal references to objects requiring finalization. A weak global reference will not become functionally equivalent to NULL until after the completion of the finalizer for the referenced object, if present. >> >> Interactions between weak global references and PhantomReferences are undefined. In particular, implementations of a Java VM may (or may not) process weak global references after PhantomReferences, and it may (or may not) be possible to use weak global references to hold on to objects which are also referred to by PhantomReference objects." >> >> The implementation in referenceProcessor.cpp even has a comment about it: >> >> // Weak global JNI references. It would make more sense (semantically) to >> // traverse these simultaneously with the regular weak references above, but >> // that is not how the JDK1.2 specification is. See #4126360. Native code can >> // thus use JNI weak references to circumvent the phantom references and >> // resurrect a "post-mortem" object. >> >> (Notice: I don't have access to bug#4126360, I cannot tell if there is any interesting discussion about the usefulness there.) >> >> However, it turns out that the above clarification to JNI weak reference specification has been removed since Java 13: >> >> https://docs.oracle.com/en/java/javase/13/docs/specs/jni/functions.html#weak-global-references >> >> Which means that we are, strictly speaking, now free to rectify the situation. And since this 'feature' doesn't seem to have any useful applications, and only serves to shoot oneself into its own foot, I propose that we go ahead and do that. >> >> This PR addresses the situation for ZGC and Shenandoah. I am not sure if we should try and do the other GCs too (in referenceProcessor.cpp). >> >> What do you think? >> >> Testing: >> - [x] hotspot_gc_shenandoah >> - [x] tier1 with +ShenandoahGC +ShenandoahVerify >> - [x] tier2 with +ShenandoahGC +ShenandoahVerify > > src/hotspot/share/runtime/jniHandles.inline.hpp line 58: > >> 56: oop result; >> 57: if (is_jweak(handle)) { // Unlikely >> 58: result = NativeAccess::oop_load(jweak_ptr(handle)); > > This is incorrect. JNI weak references have phantom strength, not weak strength. This changes is incorrect. Can you explain why? I believe I have pointed out the relevant sections in the specification, their changes, and also in the previous implementation. The current behavious is not only unintuitive, it also may lead to unintentional resurrection of finalized final or phantom references. ------------- PR: https://git.openjdk.java.net/jdk/pull/1464 From kbarrett at openjdk.java.net Thu Nov 26 19:22:57 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 26 Nov 2020 19:22:57 GMT Subject: RFR: 8257180: Prevent resurrection of final/phantom refs through JNI weak refs In-Reply-To: <1GTnCpZOibL4ECkBxC-gdrm-5vyZ1QSeO1dswxnsae4=.b650353e-0e21-4c77-b636-2aea8ba49b1d@github.com> References: <-O7gB9UHR2PF6PQ_rnM5LZgzuuXV4HHOrPZGhEUKErQ=.cb661a93-1c99-4083-812c-d12207dffabb@github.com> <1GTnCpZOibL4ECkBxC-gdrm-5vyZ1QSeO1dswxnsae4=.b650353e-0e21-4c77-b636-2aea8ba49b1d@github.com> Message-ID: On Thu, 26 Nov 2020 19:11:08 GMT, Roman Kennke wrote: >> src/hotspot/share/runtime/jniHandles.inline.hpp line 58: >> >>> 56: oop result; >>> 57: if (is_jweak(handle)) { // Unlikely >>> 58: result = NativeAccess::oop_load(jweak_ptr(handle)); >> >> This is incorrect. JNI weak references have phantom strength, not weak strength. This changes is incorrect. > > Can you explain why? I believe I have pointed out the relevant sections in the specification, their changes, and also in the previous implementation. The current behavious is not only unintuitive, it also may lead to unintentional resurrection of finalized final or phantom references. I'm working on a longer reply. I wanted to get a stake in the ground to block this change while I work on that. It *is* a holiday here in the US. ------------- PR: https://git.openjdk.java.net/jdk/pull/1464 From rkennke at openjdk.java.net Thu Nov 26 20:04:55 2020 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 26 Nov 2020 20:04:55 GMT Subject: RFR: 8257180: Prevent resurrection of final/phantom refs through JNI weak refs In-Reply-To: References: <-O7gB9UHR2PF6PQ_rnM5LZgzuuXV4HHOrPZGhEUKErQ=.cb661a93-1c99-4083-812c-d12207dffabb@github.com> <1GTnCpZOibL4ECkBxC-gdrm-5vyZ1QSeO1dswxnsae4=.b650353e-0e21-4c77-b636-2aea8ba49b1d@github.com> Message-ID: On Thu, 26 Nov 2020 19:19:59 GMT, Kim Barrett wrote: >> Can you explain why? I believe I have pointed out the relevant sections in the specification, their changes, and also in the previous implementation. The current behavious is not only unintuitive, it also may lead to unintentional resurrection of finalized final or phantom references. > > I'm working on a longer reply. I wanted to get a stake in the ground to block this change while I work on that. It *is* a holiday here in the US. Sure, I am not in a rush. I guess I'm posting that mostly so that I can learn why we are in the situation that we're in, and see if it can be improved. Enjoy your thanksgiving! ------------- PR: https://git.openjdk.java.net/jdk/pull/1464 From kim.barrett at oracle.com Thu Nov 26 22:04:54 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 26 Nov 2020 17:04:54 -0500 Subject: RFR: 8257180: Prevent resurrection of final/phantom refs through JNI weak refs In-Reply-To: References: Message-ID: <759EAD7F-F14C-40C5-BC39-77E205C0A6C0@oracle.com> [hotspot-runtime-dev was the wrong mailing list for this PR.] > On Nov 26, 2020, at 12:52 PM, Roman Kennke wrote: > > It is currently possible to resurrect finalizable objects or even phantom references after they have been finalized: > - Create JNI weak reference to object > - Create phantom reference to object/ use object with finalize() method, so that a FinalReference is created. It is true that JNI weak references can be used to resurrect finalizable objects. It has "always" been so. (I think the JNI spec was silent on the matter so implicitly vague prior to the 6/2001 Clarification; I couldn't find a copy of the spec from prior to that to be sure though.) 8071507 (JDK 9) made it impossible for JNI weak references to access the referent of a PhantomReference after it has been determined to be phantom reachable. https://bugs.openjdk.java.net/browse/JDK-8071507 > As soon as the object is no longer strongly reachable, the Finalizer will invoke finalize() on the object, or, if it has been wrapped in a PhantomReference, that PR will be enqueued in its ReferenceQueue. With some luck, it is still possible to get hold of the original object via the JNI weak reference. > > This is actually specified in JNI specification: > https://docs.oracle.com/en/java/javase/11/docs/specs/jni/functions.html#weak-global-references > > [?] > > The implementation in referenceProcessor.cpp even has a comment about it: > > // Weak global JNI references. [?] [That stale comment was removed as part of 8189359 (JDK 10). It should have been removed by 8071507, but was missed.] https://bugs.openjdk.java.net/browse/JDK-8189359 > (Notice: I don't have access to bug#4126360, I cannot tell if there is any interesting discussion about the usefulness there.) I can't go into too much detail, and definitely can't open that bug. But I can give some information. There was discussion of changing the strength of JNI weak to be equivalent to WeakReference, so stronger than finalization. This was found to break some applications and frameworks. There was also discussion of specifying the relative strengths of JNI weak references and PhantomReference, making PhantomReference explicitly the weakest. That could have been done, but it was decided to instead make the order explicitly vague in the JNI specification; hence the 6/2001 addition. It was also noted that with native code you can do anything, so being able to mess with finalization or PhantomReferences isn't a big deal; untrusted native code can wreak all kinds of havoc. > However, it turns out that the above clarification to JNI weak reference specification has been removed since Java 13: > > https://docs.oracle.com/en/java/javase/13/docs/specs/jni/functions.html#weak-global-references > > Which means that we are, strictly speaking, now free to rectify the situation. And since this 'feature' doesn't seem to have any useful applications, and only serves to shoot oneself into its own foot, I propose that we go ahead and do that. The spec update in JDK 13 https://bugs.openjdk.java.net/browse/JDK-8188066 only removed the explicit vagueness about the relationship between JNI weak references and PhantomReferences. Instead, JNI weak references are defined to have the same strength as PhantomReference. The relationship between them and other reference types and finalization remained unchanged. That spec update should have happened in conjunction with 8071507, but we (I) forgot, and didn't get around to it for a while. Mea culpa. > This PR addresses the situation for ZGC and Shenandoah. I am not sure if we should try and do the other GCs too (in referenceProcessor.cpp). Even if we wanted to make such a change to the behavior of JNI weak references, the proposed code change is insufficient. The backing implementation of JNI weak references is weak OopStorage, and all weak OopStorages are treated by all collectors as having phantom strength. Apparently none of the tests you ran detect that problem. We really do want the other weak OopStorage-based references to be phantom strength. Making JNI weak references different from the others would certainly be implementationally possible, but annoying. What is being proposed (making JNI weak references have the same strength as WeakReference) is also a spec change, so would need a lot more formality than this PR; at least a CSR, and likely a JEP (because of the potential wide-spread compatibility impact.) The right fix for the problem that JNI weak references can be used to resurrect finalizable objects is to remove finalization. (Finalization has been denigrated "forever", and was formally deprecated in JDK 9: https://bugs.openjdk.java.net/browse/JDK-8165641.) > What do you think? No, don?t make this change. From rkennke at openjdk.java.net Thu Nov 26 22:21:55 2020 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 26 Nov 2020 22:21:55 GMT Subject: RFR: 8257180: Prevent resurrection of final/phantom refs through JNI weak refs In-Reply-To: References: Message-ID: <6ZYo4TOxUlLth4HqxoVd_9R6WgctPm1fGzA2WQFljYs=.cf98dcb6-3363-4ece-805d-79d3c8b20c0f@github.com> On Thu, 26 Nov 2020 17:47:23 GMT, Roman Kennke wrote: > It is currently possible to resurrect finalizable objects or even phantom references after they have been finalized: > - Create JNI weak reference to object > - Create phantom reference to object/ use object with finalize() method, so that a FinalReference is created. > > As soon as the object is no longer strongly reachable, the Finalizer will invoke finalize() on the object, or, if it has been wrapped in a PhantomReference, that PR will be enqueued in its ReferenceQueue. With some luck, it is still possible to get hold of the original object via the JNI weak reference. > > This is actually specified in JNI specification: > https://docs.oracle.com/en/java/javase/11/docs/specs/jni/functions.html#weak-global-references > > "The weak global reference is weaker than other types of weak references (Java objects of the SoftReference or WeakReference classes). A weak global reference to a specific object will not become functionally equivalent to NULL until after SoftReference or WeakReference objects referring to that same specific object have had their references cleared. > > The weak global reference is weaker than Java's internal references to objects requiring finalization. A weak global reference will not become functionally equivalent to NULL until after the completion of the finalizer for the referenced object, if present. > > Interactions between weak global references and PhantomReferences are undefined. In particular, implementations of a Java VM may (or may not) process weak global references after PhantomReferences, and it may (or may not) be possible to use weak global references to hold on to objects which are also referred to by PhantomReference objects." > > The implementation in referenceProcessor.cpp even has a comment about it: > > // Weak global JNI references. It would make more sense (semantically) to > // traverse these simultaneously with the regular weak references above, but > // that is not how the JDK1.2 specification is. See #4126360. Native code can > // thus use JNI weak references to circumvent the phantom references and > // resurrect a "post-mortem" object. > > (Notice: I don't have access to bug#4126360, I cannot tell if there is any interesting discussion about the usefulness there.) > > However, it turns out that the above clarification to JNI weak reference specification has been removed since Java 13: > > https://docs.oracle.com/en/java/javase/13/docs/specs/jni/functions.html#weak-global-references > > Which means that we are, strictly speaking, now free to rectify the situation. And since this 'feature' doesn't seem to have any useful applications, and only serves to shoot oneself into its own foot, I propose that we go ahead and do that. > > This PR addresses the situation for ZGC and Shenandoah. I am not sure if we should try and do the other GCs too (in referenceProcessor.cpp). > > What do you think? > > Testing: > - [x] hotspot_gc_shenandoah > - [x] tier1 with +ShenandoahGC +ShenandoahVerify > - [x] tier2 with +ShenandoahGC +ShenandoahVerify > [hotspot-runtime-dev was the wrong mailing list for this PR.] Oops. That was github bots adding their labels on their own. > > On Nov 26, 2020, at 12:52 PM, Roman Kennke wrote: > > It is currently possible to resurrect finalizable objects or even phantom references after they have been finalized: > > - Create JNI weak reference to object > > - Create phantom reference to object/ use object with finalize() method, so that a FinalReference is created. > > It is true that JNI weak references can be used to resurrect > finalizable objects. It has "always" been so. (I think the JNI spec > was silent on the matter so implicitly vague prior to the 6/2001 > Clarification; I couldn't find a copy of the spec from prior to that > to be sure though.) > > 8071507 (JDK 9) made it impossible for JNI weak references to access > the referent of a PhantomReference after it has been determined to be > phantom reachable. > https://bugs.openjdk.java.net/browse/JDK-8071507 Ah ok, good to know. > > As soon as the object is no longer strongly reachable, the Finalizer will invoke finalize() on the object, or, if it has been wrapped in a PhantomReference, that PR will be enqueued in its ReferenceQueue. With some luck, it is still possible to get hold of the original object via the JNI weak reference. > > This is actually specified in JNI specification: > > https://docs.oracle.com/en/java/javase/11/docs/specs/jni/functions.html#weak-global-references > > [?] > > The implementation in referenceProcessor.cpp even has a comment about it: > > // Weak global JNI references. [?] > > [That stale comment was removed as part of 8189359 (JDK 10). It > should have been removed by 8071507, but was missed.] > https://bugs.openjdk.java.net/browse/JDK-8189359 Yes. I digged that up in a JDK8 source tree. > > (Notice: I don't have access to bug#4126360, I cannot tell if there is any interesting discussion about the usefulness there.) > > I can't go into too much detail, and definitely can't open that bug. > But I can give some information. > > There was discussion of changing the strength of JNI weak to be > equivalent to WeakReference, so stronger than finalization. This was > found to break some applications and frameworks. Oh dear. My opinion on that matter would be any program logic depending on this exact strength ordering deserve it :-) > There was also discussion of specifying the relative strengths of JNI > weak references and PhantomReference, making PhantomReference > explicitly the weakest. That could have been done, but it was decided > to instead make the order explicitly vague in the JNI specification; > hence the 6/2001 addition. Ok. > It was also noted that with native code you can do anything, so being > able to mess with finalization or PhantomReferences isn't a big deal; > untrusted native code can wreak all kinds of havoc. Yeah... :-/ > > However, it turns out that the above clarification to JNI weak reference specification has been removed since Java 13: > > https://docs.oracle.com/en/java/javase/13/docs/specs/jni/functions.html#weak-global-references > > Which means that we are, strictly speaking, now free to rectify the situation. And since this 'feature' doesn't seem to have any useful applications, and only serves to shoot oneself into its own foot, I propose that we go ahead and do that. > > The spec update in JDK 13 > https://bugs.openjdk.java.net/browse/JDK-8188066 > only removed the explicit vagueness about the relationship between JNI > weak references and PhantomReferences. Instead, JNI weak references > are defined to have the same strength as PhantomReference. The > relationship between them and other reference types and finalization > remained unchanged. Right. Thanks for clarification. > > This PR addresses the situation for ZGC and Shenandoah. I am not sure if we should try and do the other GCs too (in referenceProcessor.cpp). > > Even if we wanted to make such a change to the behavior of JNI weak > references, the proposed code change is insufficient. The backing > implementation of JNI weak references is weak OopStorage, and all weak > OopStorages are treated by all collectors as having phantom strength. > Apparently none of the tests you ran detect that problem. > > We really do want the other weak OopStorage-based references to be > phantom strength. Making JNI weak references different from the > others would certainly be implementationally possible, but annoying. > > What is being proposed (making JNI weak references have the same > strength as WeakReference) is also a spec change, so would need a lot > more formality than this PR; at least a CSR, and likely a JEP (because > of the potential wide-spread compatibility impact.) > > The right fix for the problem that JNI weak references can be used to > resurrect finalizable objects is to remove finalization. > (Finalization has been denigrated "forever", and was formally > deprecated in JDK 9: https://bugs.openjdk.java.net/browse/JDK-8165641.) That would be great, but is it likely to ever happen? > > What do you think? > > No, don?t make this change. Yeah. I posted this mostly for the exact discussion that we're having. Thanks for the clarifications! ------------- PR: https://git.openjdk.java.net/jdk/pull/1464 From dholmes at openjdk.java.net Fri Nov 27 02:08:59 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 27 Nov 2020 02:08:59 GMT Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231 [v7] In-Reply-To: References: Message-ID: On Wed, 25 Nov 2020 12:09:07 GMT, Jorn Vernee wrote: >> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again. >> >> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions. >> >> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller. >> >> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks. >> >> Testing: `make images` on Linux and Windows x86_32 platforms. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Pass in thread instead of rematerializing it. src/hotspot/share/prims/universalUpcallHandler.cpp line 37: > 35: > 36: void ProgrammableUpcallHandler::upcall_helper(JavaThread* thread, jobject rec, address buff) { > 37: JavaThread* THREAD = thread; You could have just named the parameter THREAD. ------------- PR: https://git.openjdk.java.net/jdk/pull/1266 From stuefe at openjdk.java.net Fri Nov 27 06:25:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 27 Nov 2020 06:25:58 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 15:26:45 GMT, Thomas Stuefe wrote: > To analyze JDK-8256729 further, we need more tracing: > > 1) We should print all mappings inside the split area if os::split_reserved_memory() fails > > 2) The print-mapping code on windows has some shortcomings: > - should not probe for mappings outside of what we know are valid address ranges for Windows > - should handle wrap-arounds - it should be possible to print the whole address space > - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) > - should be printed in a more compact manner - base address should be on the same line as the first region > - maybe adorned with some basic range info, e.g. library mappings Gentle ping. This is needed to get further information on the CDS/Metaspace initialization errors (https://bugs.openjdk.java.net/browse/JDK-8256729) ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Fri Nov 27 06:29:12 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 27 Nov 2020 06:29:12 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v2] In-Reply-To: References: Message-ID: > To analyze JDK-8256729 further, we need more tracing: > > 1) We should print all mappings inside the split area if os::split_reserved_memory() fails > > 2) The print-mapping code on windows has some shortcomings: > - should not probe for mappings outside of what we know are valid address ranges for Windows > - should handle wrap-arounds - it should be possible to print the whole address space > - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) > - should be printed in a more compact manner - base address should be on the same line as the first region > - maybe adorned with some basic range info, e.g. library mappings Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge - Initial patch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1390/files - new: https://git.openjdk.java.net/jdk/pull/1390/files/7bba557d..71d8ef99 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=00-01 Stats: 13570 lines in 396 files changed: 5223 ins; 2162 del; 6185 mod Patch: https://git.openjdk.java.net/jdk/pull/1390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1390/head:pull/1390 PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Fri Nov 27 06:35:16 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 27 Nov 2020 06:35:16 GMT Subject: RFR: JDK-8255884: Metaspace: chunk local commit counter may be stale [v2] In-Reply-To: References: Message-ID: <_Zpz_-LWLOzOmBqTkqjcUKLSTKCn7GveBpuSrn830No=.b7bb5d20-f428-4751-b285-03811726dd76@github.com> > The detailed metaspace report (`jcmd VM.metaspace`) shows the ChunkManager statistics. In these statistics, the commit counter for chunk levels < granule size may be wrong. > > Note that this is not a big deal. It does not affect the total commit counter, which is directly taken from the virtual memory layer, and which is always right. But it can be confusing for analysts. > > Background: > > The "truth" about the commit state of granules is kept inside VirtualSpaceNode in a bitmask ("commit mask"). Since this is a global resource and access to it is synchronized, each chunk keeps a commit watermark to know the size of the range which is guaranteed to be committed and which can be used without checking that bitmap. This watermark is checked when allocating from the chunk. > > This chunk-local watermark can get stale if the granule underneath the chunk gets committed without the chunk noticing. The only way this can happen is if the chunk is smaller than a granule and some in-granule neighbor was committed. > > That in itself works as designed and is totally benign. The chunk-local commit watermark will get silently corrected on the next allocation. > > But it messes up statistics a bit. Example: > > jcmd xxx VM.metaspace > > > > Chunk freelists: > > Both: > > 4m: (none) > 2m: 2, capacity=4,00 MB, committed=0 bytes ( 0%) > 1m: 1, capacity=1,00 MB, committed=0 bytes ( 0%) > 512k: (none) > 256k: 2, capacity=512,00 KB, committed=0 bytes ( 0%) > 128k: 1, capacity=128,00 KB, committed=0 bytes ( 0%) > 64k: 2, capacity=128,00 KB, committed=0 bytes ( 0%) > 32k: 2, capacity=64,00 KB, committed=0 bytes ( 0%) <<<<< actually, these are committed > 16k: 1, capacity=16,00 KB, committed=0 bytes ( 0%) <<<<< these too > 8k: (none) > 4k: (none) > 2k: (none) > 1k: (none) > Total word size: 5,83 MB, committed: 0 bytes ( 0%) > > > In this example, the 32K and 16K chunks in the freelist had been committed as a side effect of comitting a neighboring chunk. Their watermarks are still at zero though and therefore they appear uncommitted here. > > The solution would be to - when a small chunk gets committed - adjust the watermarks of his in-granule neighbors. Then it looks like this: > > Both: > > 4m: (none) > 2m: 3, capacity=6,00 MB, committed=0 bytes ( 0%) > 1m: 2, capacity=2,00 MB, committed=0 bytes ( 0%) > 512k: 1, capacity=512,00 KB, committed=0 bytes ( 0%) > 256k: (none) > 128k: 1, capacity=128,00 KB, committed=0 bytes ( 0%) > 64k: 1, capacity=64,00 KB, committed=0 bytes ( 0%) > 32k: 2, capacity=64,00 KB, committed=64,00 KB (100%) <<<<< good > 16k: 2, capacity=32,00 KB, committed=32,00 KB (100%) <<<<< good > 8k: (none) > 4k: (none) > 2k: (none) > 1k: (none) > Total word size: 8,78 MB, committed: 96,00 KB ( 1%) > > Thanks, Thomas Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge - Add gtest for Vsn::is_range_fully_committed - Initial ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1291/files - new: https://git.openjdk.java.net/jdk/pull/1291/files/f433fe70..037d3b2e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1291&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1291&range=00-01 Stats: 83546 lines in 637 files changed: 74001 ins; 2961 del; 6584 mod Patch: https://git.openjdk.java.net/jdk/pull/1291.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1291/head:pull/1291 PR: https://git.openjdk.java.net/jdk/pull/1291 From shade at openjdk.java.net Fri Nov 27 07:08:56 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 27 Nov 2020 07:08:56 GMT Subject: RFR: 8256726: Zero: print proper message in ArrayIndexOutOfBoundException In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 09:14:13 GMT, Aleksey Shipilev wrote: > Manifests on tier1 test: > > $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ > test ArrayIndexOutOfBoundsExceptionTest.testAIOOBMessages(): failure > java.lang.AssertionError: expected [Index -5 out of bounds for length 0] but found [-5] > > Fix does similar thing to what `Runtime1::throw_range_check_exception` does, but using a safer `jio_snprintf`. > > Additional testing: > - [x] AIOBB tests on Linux x86_64 Zero fastdebug Friendly reminder. ------------- PR: https://git.openjdk.java.net/jdk/pull/1341 From kbarrett at openjdk.java.net Fri Nov 27 08:50:00 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 27 Nov 2020 08:50:00 GMT Subject: RFR: 8256474: Migrate Mutex _owner accesses to use Atomic operations [v3] In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 22:39:08 GMT, David Holmes wrote: >> Simple update to move away from volatile fields and use Atomic::load/store on racy accesses. >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Restore volatile modifier Marked as reviewed by kbarrett (Reviewer). src/hotspot/share/runtime/mutex.hpp line 90: > 88: // than the lock owner are inherently racy. > 89: Thread* volatile _owner; > 90: void raw_set_owner(Thread* new_owner) { Atomic::store(&_owner, new_owner); } set_owner_relaxed might be a better name. Your call... ------------- PR: https://git.openjdk.java.net/jdk/pull/1402 From vlivanov at openjdk.java.net Fri Nov 27 08:50:06 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 27 Nov 2020 08:50:06 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor Message-ID: `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. Proposed fix is to run Mutex destructor right away. Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. Testing: - [x] verified that no memory leak observed with the reported test - [x] tier1-4 [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html ------------- Commit messages: - Fix native memory leak in ciMethodData ctor Changes: https://git.openjdk.java.net/jdk/pull/1478/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1478&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252049 Stats: 20 lines in 4 files changed: 15 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1478/head:pull/1478 PR: https://git.openjdk.java.net/jdk/pull/1478 From dholmes at openjdk.java.net Fri Nov 27 09:01:54 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 27 Nov 2020 09:01:54 GMT Subject: RFR: 8256726: Zero: print proper message in ArrayIndexOutOfBoundException In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 09:14:13 GMT, Aleksey Shipilev wrote: > Manifests on tier1 test: > > $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ > test ArrayIndexOutOfBoundsExceptionTest.testAIOOBMessages(): failure > java.lang.AssertionError: expected [Index -5 out of bounds for length 0] but found [-5] > > Fix does similar thing to what `Runtime1::throw_range_check_exception` does, but using a safer `jio_snprintf`. > > Additional testing: > - [x] AIOBB tests on Linux x86_64 Zero fastdebug I counted 32 characters needed for the string in addition to the two numeric values, but 35 is fine. :) ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1341 From sgehwolf at openjdk.java.net Fri Nov 27 09:06:56 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 27 Nov 2020 09:06:56 GMT Subject: RFR: 8256726: Zero: print proper message in ArrayIndexOutOfBoundException In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 09:14:13 GMT, Aleksey Shipilev wrote: > Manifests on tier1 test: > > $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ > test ArrayIndexOutOfBoundsExceptionTest.testAIOOBMessages(): failure > java.lang.AssertionError: expected [Index -5 out of bounds for length 0] but found [-5] > > Fix does similar thing to what `Runtime1::throw_range_check_exception` does, but using a safer `jio_snprintf`. > > Additional testing: > - [x] AIOBB tests on Linux x86_64 Zero fastdebug src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 1504: > 1502: arrayOop arrObj = (arrayOop)STACK_OBJECT(arrayOff); \ > 1503: jint index = STACK_INT(arrayOff + 1); \ > 1504: char message[2 * jintAsStringSize + 35]; \ What's this magic `35` here? `strlen("Index A out of bounds for length B") + 1 == 35`. Isn't this counting the integers twice? Consider adding a comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/1341 From shade at openjdk.java.net Fri Nov 27 09:10:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 27 Nov 2020 09:10:58 GMT Subject: RFR: 8256726: Zero: print proper message in ArrayIndexOutOfBoundException In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 09:03:58 GMT, Severin Gehwolf wrote: >> Manifests on tier1 test: >> >> $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ >> test ArrayIndexOutOfBoundsExceptionTest.testAIOOBMessages(): failure >> java.lang.AssertionError: expected [Index -5 out of bounds for length 0] but found [-5] >> >> Fix does similar thing to what `Runtime1::throw_range_check_exception` does, but using a safer `jio_snprintf`. >> >> Additional testing: >> - [x] AIOBB tests on Linux x86_64 Zero fastdebug > > src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 1504: > >> 1502: arrayOop arrObj = (arrayOop)STACK_OBJECT(arrayOff); \ >> 1503: jint index = STACK_INT(arrayOff + 1); \ >> 1504: char message[2 * jintAsStringSize + 35]; \ > > What's this magic `35` here? `strlen("Index A out of bounds for length B") + 1 == 35`. Isn't this counting the integers twice? > > Consider adding a comment. Seems OK to overestimate a bit. That's what `Runtime1::throw_range_check_exception` does in C1, so I have not challenged it: https://github.com/openjdk/jdk/blob/2f06893a29fba3b40cc1cf03095b75b217d1bb93/src/hotspot/share/c1/c1_Runtime1.cpp#L668-L671 It should count the integers twice, because there are two integers in the string. ------------- PR: https://git.openjdk.java.net/jdk/pull/1341 From dholmes at openjdk.java.net Fri Nov 27 09:14:02 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 27 Nov 2020 09:14:02 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor In-Reply-To: References: Message-ID: <5jmPyMo3L6Z7ESUTxDCH_PMuOhEVePoy2_xn5lFswxc=.b76a5438-1822-4c39-a44b-bbbbe3bcfe52@github.com> On Fri, 27 Nov 2020 08:05:09 GMT, Vladimir Ivanov wrote: > `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. > But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. > The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. > > Proposed fix is to run Mutex destructor right away. > > Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. > > In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. > > Testing: > - [x] verified that no memory leak observed with the reported test > - [x] tier1-4 > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html I can't say this looks pretty. It is also very hard to be able to determine when the mutex was last used and whether this running of the destructor is guaranteed to be safe. What is the lifecycle of the original MethodData? ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From david.holmes at oracle.com Fri Nov 27 09:14:50 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Nov 2020 19:14:50 +1000 Subject: RFR: 8256726: Zero: print proper message in ArrayIndexOutOfBoundException In-Reply-To: References: Message-ID: <20883e0d-28ac-6fee-fb03-0fec087fe5cb@oracle.com> On 27/11/2020 7:10 pm, Aleksey Shipilev wrote: > On Fri, 27 Nov 2020 09:03:58 GMT, Severin Gehwolf wrote: > >>> Manifests on tier1 test: >>> >>> $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ >>> test ArrayIndexOutOfBoundsExceptionTest.testAIOOBMessages(): failure >>> java.lang.AssertionError: expected [Index -5 out of bounds for length 0] but found [-5] >>> >>> Fix does similar thing to what `Runtime1::throw_range_check_exception` does, but using a safer `jio_snprintf`. >>> >>> Additional testing: >>> - [x] AIOBB tests on Linux x86_64 Zero fastdebug >> >> src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 1504: >> >>> 1502: arrayOop arrObj = (arrayOop)STACK_OBJECT(arrayOff); \ >>> 1503: jint index = STACK_INT(arrayOff + 1); \ >>> 1504: char message[2 * jintAsStringSize + 35]; \ >> >> What's this magic `35` here? `strlen("Index A out of bounds for length B") + 1 == 35`. Isn't this counting the integers twice? >> >> Consider adding a comment. > > Seems OK to overestimate a bit. That's what `Runtime1::throw_range_check_exception` does in C1, so I have not challenged it: > https://github.com/openjdk/jdk/blob/2f06893a29fba3b40cc1cf03095b75b217d1bb93/src/hotspot/share/c1/c1_Runtime1.cpp#L668-L671 > > It should count the integers twice, because there are two integers in the string. They are "counted twice" in the sense that the 35 allows for two single digit integers, but you separately allowed for arbitrary valued integers. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1341 > From shade at openjdk.java.net Fri Nov 27 09:21:19 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 27 Nov 2020 09:21:19 GMT Subject: RFR: 8256726: Zero: print proper message in ArrayIndexOutOfBoundException [v2] In-Reply-To: References: Message-ID: > Manifests on tier1 test: > > $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ > test ArrayIndexOutOfBoundsExceptionTest.testAIOOBMessages(): failure > java.lang.AssertionError: expected [Index -5 out of bounds for length 0] but found [-5] > > Fix does similar thing to what `Runtime1::throw_range_check_exception` does, but using a safer `jio_snprintf`. > > Additional testing: > - [x] AIOBB tests on Linux x86_64 Zero fastdebug 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 four additional commits since the last revision: - Count the additional message length exactly - Merge branch 'master' into JDK-8256726-zero-aioob - Use safer jio_snprintf - 8256726: Zero: print proper message in ArrayIndexOutOfBoundException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1341/files - new: https://git.openjdk.java.net/jdk/pull/1341/files/3e4e1615..bd0e0830 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1341&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1341&range=00-01 Stats: 143520 lines in 940 files changed: 117419 ins; 8488 del; 17613 mod Patch: https://git.openjdk.java.net/jdk/pull/1341.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1341/head:pull/1341 PR: https://git.openjdk.java.net/jdk/pull/1341 From shade at openjdk.java.net Fri Nov 27 09:21:19 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 27 Nov 2020 09:21:19 GMT Subject: RFR: 8256726: Zero: print proper message in ArrayIndexOutOfBoundException [v2] In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 09:07:47 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 1504: >> >>> 1502: arrayOop arrObj = (arrayOop)STACK_OBJECT(arrayOff); \ >>> 1503: jint index = STACK_INT(arrayOff + 1); \ >>> 1504: char message[2 * jintAsStringSize + 35]; \ >> >> What's this magic `35` here? `strlen("Index A out of bounds for length B") + 1 == 35`. Isn't this counting the integers twice? >> >> Consider adding a comment. > > Seems OK to overestimate a bit. That's what `Runtime1::throw_range_check_exception` does in C1, so I have not challenged it: > https://github.com/openjdk/jdk/blob/2f06893a29fba3b40cc1cf03095b75b217d1bb93/src/hotspot/share/c1/c1_Runtime1.cpp#L668-L671 > > It should count the integers twice, because there are two integers in the string. Well, fine, I'll count them exactly and `STATIC_ASSERT` it ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/1341 From shade at openjdk.java.net Fri Nov 27 09:21:20 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 27 Nov 2020 09:21:20 GMT Subject: RFR: 8256726: Zero: print proper message in ArrayIndexOutOfBoundException [v2] In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 09:16:21 GMT, Aleksey Shipilev wrote: >> Seems OK to overestimate a bit. That's what `Runtime1::throw_range_check_exception` does in C1, so I have not challenged it: >> https://github.com/openjdk/jdk/blob/2f06893a29fba3b40cc1cf03095b75b217d1bb93/src/hotspot/share/c1/c1_Runtime1.cpp#L668-L671 >> >> It should count the integers twice, because there are two integers in the string. > > Well, fine, I'll count them exactly and `STATIC_ASSERT` it ;) Done in new revision. ------------- PR: https://git.openjdk.java.net/jdk/pull/1341 From shade at openjdk.java.net Fri Nov 27 09:30:10 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 27 Nov 2020 09:30:10 GMT Subject: RFR: 8256726: Zero: print proper message in ArrayIndexOutOfBoundException [v3] In-Reply-To: References: Message-ID: > Manifests on tier1 test: > > $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ > test ArrayIndexOutOfBoundsExceptionTest.testAIOOBMessages(): failure > java.lang.AssertionError: expected [Index -5 out of bounds for length 0] but found [-5] > > Fix does similar thing to what `Runtime1::throw_range_check_exception` does, but using a safer `jio_snprintf`. > > Additional testing: > - [x] AIOBB tests on Linux x86_64 Zero fastdebug Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Even cleaner, with comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1341/files - new: https://git.openjdk.java.net/jdk/pull/1341/files/bd0e0830..e6c5c54c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1341&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1341&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1341.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1341/head:pull/1341 PR: https://git.openjdk.java.net/jdk/pull/1341 From sgehwolf at openjdk.java.net Fri Nov 27 09:30:10 2020 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 27 Nov 2020 09:30:10 GMT Subject: RFR: 8256726: Zero: print proper message in ArrayIndexOutOfBoundException [v3] In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 09:27:04 GMT, Aleksey Shipilev wrote: >> Manifests on tier1 test: >> >> $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ >> test ArrayIndexOutOfBoundsExceptionTest.testAIOOBMessages(): failure >> java.lang.AssertionError: expected [Index -5 out of bounds for length 0] but found [-5] >> >> Fix does similar thing to what `Runtime1::throw_range_check_exception` does, but using a safer `jio_snprintf`. >> >> Additional testing: >> - [x] AIOBB tests on Linux x86_64 Zero fastdebug > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Even cleaner, with comments Looks good. Thanks for the clean-up. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1341 From vlivanov at openjdk.java.net Fri Nov 27 10:24:57 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 27 Nov 2020 10:24:57 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor In-Reply-To: <5jmPyMo3L6Z7ESUTxDCH_PMuOhEVePoy2_xn5lFswxc=.b76a5438-1822-4c39-a44b-bbbbe3bcfe52@github.com> References: <5jmPyMo3L6Z7ESUTxDCH_PMuOhEVePoy2_xn5lFswxc=.b76a5438-1822-4c39-a44b-bbbbe3bcfe52@github.com> Message-ID: On Fri, 27 Nov 2020 09:11:23 GMT, David Holmes wrote: >> `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. >> But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. >> The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. >> >> Proposed fix is to run Mutex destructor right away. >> >> Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. >> >> In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. >> >> Testing: >> - [x] verified that no memory leak observed with the reported test >> - [x] tier1-4 >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html > > I can't say this looks pretty. It is also very hard to be able to determine when the mutex was last used and whether this running of the destructor is guaranteed to be safe. What is the lifecycle of the original MethodData? I agree that it's not pretty. I'd like to stress that the destruction happens on the freshly allocated `Mutex` and it is not related/copied from original `MethodData`: MethodData::MethodData(ciMethodData& data) : _extra_data_lock(Mutex::leaf, "unused") { _extra_data_lock.~Mutex(); // release allocated resources before zeroing So, I don't see any evident issues related to concurrent usage (since it shouldn't happen). Original `MethodData` lifecycle is tied to the `Method` it relates to. (But I don't see how it can matter here.) `ciMethodData` is allocated in compiler arena on per-compilarion task basis and is deallocated en masse when compilation finishes. The alternative fix would be to introduce new ctors on `Mutex` and `os::PlatformMonitor` which omit allocation of native condition variable, but that is more intrusive IMO. Let me know what you prefer. ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From rkennke at openjdk.java.net Fri Nov 27 13:24:58 2020 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 27 Nov 2020 13:24:58 GMT Subject: Withdrawn: 8257180: Prevent resurrection of final/phantom refs through JNI weak refs In-Reply-To: References: Message-ID: <52QrQWruqvRgXsNYG_qoD0UVYxQYPj8by8gH_rxgGEc=.f0619cb2-d769-4b52-9d17-35ea4ae16e58@github.com> On Thu, 26 Nov 2020 17:47:23 GMT, Roman Kennke wrote: > It is currently possible to resurrect finalizable objects or even phantom references after they have been finalized: > - Create JNI weak reference to object > - Create phantom reference to object/ use object with finalize() method, so that a FinalReference is created. > > As soon as the object is no longer strongly reachable, the Finalizer will invoke finalize() on the object, or, if it has been wrapped in a PhantomReference, that PR will be enqueued in its ReferenceQueue. With some luck, it is still possible to get hold of the original object via the JNI weak reference. > > This is actually specified in JNI specification: > https://docs.oracle.com/en/java/javase/11/docs/specs/jni/functions.html#weak-global-references > > "The weak global reference is weaker than other types of weak references (Java objects of the SoftReference or WeakReference classes). A weak global reference to a specific object will not become functionally equivalent to NULL until after SoftReference or WeakReference objects referring to that same specific object have had their references cleared. > > The weak global reference is weaker than Java's internal references to objects requiring finalization. A weak global reference will not become functionally equivalent to NULL until after the completion of the finalizer for the referenced object, if present. > > Interactions between weak global references and PhantomReferences are undefined. In particular, implementations of a Java VM may (or may not) process weak global references after PhantomReferences, and it may (or may not) be possible to use weak global references to hold on to objects which are also referred to by PhantomReference objects." > > The implementation in referenceProcessor.cpp even has a comment about it: > > // Weak global JNI references. It would make more sense (semantically) to > // traverse these simultaneously with the regular weak references above, but > // that is not how the JDK1.2 specification is. See #4126360. Native code can > // thus use JNI weak references to circumvent the phantom references and > // resurrect a "post-mortem" object. > > (Notice: I don't have access to bug#4126360, I cannot tell if there is any interesting discussion about the usefulness there.) > > However, it turns out that the above clarification to JNI weak reference specification has been removed since Java 13: > > https://docs.oracle.com/en/java/javase/13/docs/specs/jni/functions.html#weak-global-references > > Which means that we are, strictly speaking, now free to rectify the situation. And since this 'feature' doesn't seem to have any useful applications, and only serves to shoot oneself into its own foot, I propose that we go ahead and do that. > > This PR addresses the situation for ZGC and Shenandoah. I am not sure if we should try and do the other GCs too (in referenceProcessor.cpp). > > What do you think? > > Testing: > - [x] hotspot_gc_shenandoah > - [x] tier1 with +ShenandoahGC +ShenandoahVerify > - [x] tier2 with +ShenandoahGC +ShenandoahVerify This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1464 From rehn at openjdk.java.net Fri Nov 27 13:43:55 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 27 Nov 2020 13:43:55 GMT Subject: RFR: 8256832: Zero: micro-optimize safepoint handling after JDK-8255384 In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 08:20:14 GMT, Aleksey Shipilev wrote: > Now that [JDK-8255384](https://bugs.openjdk.java.net/browse/JDK-8255384) effectively made the safepoints conditional for Zero, we can do `HandleMarkCleaner` under the safepoint check. This seems to improve Linux x86_64 Zero release `make bootcycle-images`: from 33.0m to 32.5m. Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1378 From redestad at openjdk.java.net Fri Nov 27 15:09:54 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 27 Nov 2020 15:09:54 GMT Subject: RFR: 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers In-Reply-To: References: Message-ID: <5VboXx5wXUazSyIunD0gAU8sSVXjYDvt1FShPWNh5Qs=.018d058b-9883-445b-bf2f-763a7f8b1149@github.com> On Thu, 26 Nov 2020 13:10:02 GMT, Vladimir Ivanov wrote: > Method linkage of `invokehandle` instructions involve an upcall into Java (`MethodHandleNatives::linkMethod`), but the result is not cached. Unless the upcall behaves idempotently (which is highly desirable, but not guaranteed), repeated invokehandle resolution attempts enter a vicious cycle in tiered mode: switching to a higher tier involves call site re-resolution in generated code, but re-resolution installs a fresh method which puts execution back into interpreter. > > (Another prerequisite is no inlining through a `invokehandle` which doesn't normally happen in practice - relevant methods are marked w/ `@ForceInline` - except some testing modes, `-Xcomp` in particular.) > > Proposed fix is to inspect `ConstantPoolCache` first. Previous resolution attempts from interpreter and C1 records their results there and it stabilises the execution. > > Testing: > - failing test > - tier1-4 Nice! ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1453 From coleenp at openjdk.java.net Fri Nov 27 19:06:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 27 Nov 2020 19:06:01 GMT Subject: RFR: 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers In-Reply-To: References: Message-ID: On Thu, 26 Nov 2020 13:10:02 GMT, Vladimir Ivanov wrote: > Method linkage of `invokehandle` instructions involve an upcall into Java (`MethodHandleNatives::linkMethod`), but the result is not cached. Unless the upcall behaves idempotently (which is highly desirable, but not guaranteed), repeated invokehandle resolution attempts enter a vicious cycle in tiered mode: switching to a higher tier involves call site re-resolution in generated code, but re-resolution installs a fresh method which puts execution back into interpreter. > > (Another prerequisite is no inlining through a `invokehandle` which doesn't normally happen in practice - relevant methods are marked w/ `@ForceInline` - except some testing modes, `-Xcomp` in particular.) > > Proposed fix is to inspect `ConstantPoolCache` first. Previous resolution attempts from interpreter and C1 records their results there and it stabilises the execution. > > Testing: > - failing test > - tier1-4 Looks great. I had one question in the code. src/hotspot/share/interpreter/linkResolver.cpp line 1705: > 1703: int cache_index = ConstantPool::decode_cpcache_index(index, true); > 1704: ConstantPoolCacheEntry* cpce = pool->cache()->entry_at(cache_index); > 1705: if (!cpce->is_f1_null()) { If f1 is non-null any racing resolution is complete. Can you double check if that's also the case for indy_resolution_failed? ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1453 From dholmes at openjdk.java.net Sat Nov 28 12:48:55 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 28 Nov 2020 12:48:55 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor In-Reply-To: References: <5jmPyMo3L6Z7ESUTxDCH_PMuOhEVePoy2_xn5lFswxc=.b76a5438-1822-4c39-a44b-bbbbe3bcfe52@github.com> Message-ID: <3tBpkqtJc4u02udB4Ba34DSlB1mPaVgOfrh-EFIG8_A=.4452852f-dafb-459f-be76-e482cacfb9bb@github.com> On Fri, 27 Nov 2020 10:21:55 GMT, Vladimir Ivanov wrote: >> I can't say this looks pretty. It is also very hard to be able to determine when the mutex was last used and whether this running of the destructor is guaranteed to be safe. What is the lifecycle of the original MethodData? > > I agree that it's not pretty. > > I'd like to stress that the destruction happens on the freshly allocated `Mutex` and it is not related/copied from original `MethodData`: > MethodData::MethodData(ciMethodData& data) > : _extra_data_lock(Mutex::leaf, "unused") { > _extra_data_lock.~Mutex(); // release allocated resources before zeroing > > So, I don't see any evident issues related to concurrent usage (since it shouldn't happen). Original `MethodData` lifecycle is tied to the `Method` it relates to. (But I don't see how it can matter here.) `ciMethodData` is allocated in compiler arena on per-compilarion task basis and is deallocated en masse when compilation finishes. > > The alternative fix would be to introduce new ctors on `Mutex` and `os::PlatformMonitor` which omit allocation of native condition variable, but that is more intrusive IMO. Let me know what you prefer. Ah now I understand a bit better. The code creates a copy of the MethodData to preserve the data and gets the Mutex in the process. The Mutex is not wanted/needed and so it is immediately "destructed". Okay that works. A possible alternative might be to refactor MethodData so that the data is in MethodDataBase, and the Mutex added in MethodData, then only snapshot the MethodDataBase part in ciMethodData. But I don't know if that is feasible, nor worth the effort. ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From dholmes at openjdk.java.net Sat Nov 28 13:00:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 28 Nov 2020 13:00:58 GMT Subject: RFR: 8256726: Zero: print proper message in ArrayIndexOutOfBoundException [v3] In-Reply-To: References: Message-ID: <27kAzsOzfGtZ3rlSambt_CXu2_A4uaZrF7k9Xg2tRvI=.150b4f37-a260-443f-aecb-69df1cc4260e@github.com> On Fri, 27 Nov 2020 09:30:10 GMT, Aleksey Shipilev wrote: >> Manifests on tier1 test: >> >> $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ >> test ArrayIndexOutOfBoundsExceptionTest.testAIOOBMessages(): failure >> java.lang.AssertionError: expected [Index -5 out of bounds for length 0] but found [-5] >> >> Fix does similar thing to what `Runtime1::throw_range_check_exception` does, but using a safer `jio_snprintf`. >> >> Additional testing: >> - [x] AIOBB tests on Linux x86_64 Zero fastdebug > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Even cleaner, with comments Marked as reviewed by dholmes (Reviewer). src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 1377: > 1375: jint index = STACK_INT(arrayOff + 1); \ > 1376: const int add_len = 32; \ > 1377: STATIC_ASSERT(add_len == strlen("Index out of bounds for length ")); \ The double-space there is a bit subtle. I'm not sure static_asserting the length of a different string literal really aids the reader here at all. A simple comment would have sufficed in my view. ------------- PR: https://git.openjdk.java.net/jdk/pull/1341 From jiefu at openjdk.java.net Sat Nov 28 13:14:03 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 28 Nov 2020 13:14:03 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes Message-ID: Hi all, Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator. For example, this assert [1] fired on our testing boxes. It can be reproduced by the following two steps on Linux-64: 1) ulimit -v 8388608 2) java -XX:MinHeapSize=5g -version The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize. One more important fact is that this bug can be more common on Linux-32 systems. Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M. Testing: - tier1 ~ tier3 on Linux/x64 Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcArguments.cpp#L96 [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 ------------- Commit messages: - 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes Changes: https://git.openjdk.java.net/jdk/pull/1492/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1492&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257230 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1492.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1492/head:pull/1492 PR: https://git.openjdk.java.net/jdk/pull/1492 From shade at openjdk.java.net Sat Nov 28 13:58:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sat, 28 Nov 2020 13:58:58 GMT Subject: RFR: 8256726: Zero: print proper message in ArrayIndexOutOfBoundException [v3] In-Reply-To: <27kAzsOzfGtZ3rlSambt_CXu2_A4uaZrF7k9Xg2tRvI=.150b4f37-a260-443f-aecb-69df1cc4260e@github.com> References: <27kAzsOzfGtZ3rlSambt_CXu2_A4uaZrF7k9Xg2tRvI=.150b4f37-a260-443f-aecb-69df1cc4260e@github.com> Message-ID: On Sat, 28 Nov 2020 12:58:14 GMT, David Holmes wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Even cleaner, with comments > > src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 1377: > >> 1375: jint index = STACK_INT(arrayOff + 1); \ >> 1376: const int add_len = 32; \ >> 1377: STATIC_ASSERT(add_len == strlen("Index out of bounds for length ")); \ > > The double-space there is a bit subtle. I'm not sure static_asserting the length of a different string literal really aids the reader here at all. A simple comment would have sufficed in my view. I think it captures the intent well enough. The code in `Runtime1` uses a similar assert, and it helped me to get the gist of the "35" as the length. So, I prefer to static assert it here. ------------- PR: https://git.openjdk.java.net/jdk/pull/1341 From kbarrett at openjdk.java.net Sat Nov 28 19:50:54 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 28 Nov 2020 19:50:54 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 08:05:09 GMT, Vladimir Ivanov wrote: > `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. > But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. > The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. > > Proposed fix is to run Mutex destructor right away. > > Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. > > In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. > > Testing: > - [x] verified that no memory leak observed with the reported test > - [x] tier1-4 > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html I agree this fixes the immediate problem of a native memory leak. But it all seems pretty horrible from a code understanding and maintenance POV. So while I'm approving this change, I think there is followup work to be done, for which an RFE should be filed. For the specific case of ciMethodData::_orig it seems like it would be better to separate the mutex from the data and have _orig be just the data. That might take some significant refactoring. But more generally, I question the embedded mutex in an MDO. >From the quoted email (https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html) Coleen tried heap managing the mutex rather than having it embedded directly, and found this caused some performace regressions. But does there really need to be a mutex per MDO? Would a single immortal mutex, shared by all MDOs, be adequate for this purpose? If not, maybe the trick used by ObjectMonitor(?) -- have a set of immortal mutexes and "randomly" choose one per MDO. This would also eliminate this part of the walk of metadata objects to release heap resources when dropping them. And it avoids constructing and destructing lots of mutexes (which isn't free, even if not heap managed). ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1478 From shade at openjdk.java.net Sun Nov 29 08:05:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 29 Nov 2020 08:05:57 GMT Subject: Integrated: 8256726: Zero: print proper message in ArrayIndexOutOfBoundException In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 09:14:13 GMT, Aleksey Shipilev wrote: > Manifests on tier1 test: > > $ CONF=linux-x86_64-zero-fastdebug make run-test TEST=runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ > test ArrayIndexOutOfBoundsExceptionTest.testAIOOBMessages(): failure > java.lang.AssertionError: expected [Index -5 out of bounds for length 0] but found [-5] > > Fix does similar thing to what `Runtime1::throw_range_check_exception` does, but using a safer `jio_snprintf`. > > Additional testing: > - [x] AIOBB tests on Linux x86_64 Zero fastdebug This pull request has now been integrated. Changeset: 87f37aa2 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/87f37aa2 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod 8256726: Zero: print proper message in ArrayIndexOutOfBoundException Reviewed-by: dholmes, sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/1341 From shade at openjdk.java.net Sun Nov 29 08:05:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 29 Nov 2020 08:05:57 GMT Subject: Integrated: 8256832: Zero: micro-optimize safepoint handling after JDK-8255384 In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 08: 20:14 GMT, Aleksey Shipilev wrote: > Now that [JDK-8255384](https://bugs.openjdk.java.net/browse/JDK-8255384) effectively made the safepoints conditional for Zero, we can do `HandleMarkCleaner` under the safepoint check. This seems to improve Linux x86_64 Zero release `make bootcycle-images`: from 33.0m to 32.5m. This pull request has now been integrated. Changeset: f4c15a98 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/f4c15a98 Stats: 9 lines in 1 file changed: 0 ins; 3 del; 6 mod 8256832: Zero: micro-optimize safepoint handling after JDK-8255384 Reviewed-by: rehn ------------- PR: https://git.openjdk.java.net/jdk/pull/1378 From dholmes at openjdk.java.net Mon Nov 30 01:17:00 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 30 Nov 2020 01:17:00 GMT Subject: RFR: 8257238: Cleanup include directives for precompiled.hpp Message-ID: The precompiled header file is: src/hotspot/share/precompiled/precompiled.hpp The normal way to include precompiled headers is to just have: #include "precompiled.hpp" as the first directive in a file. This works because the makefiles set: -I$(TOPDIR)/src/hotspot/share/precompiled Some files instead have: #include "precompiled/precompiled.hpp" ./os/bsd/semaphore_bsd.cpp ./os/linux/waitBarrier_linux.cpp ./os/posix/semaphore_posix.cpp ./os/posix/signals_posix.cpp This should be trivially cleaned up. ------------- Commit messages: - 8257238: Cleanup include directives for precompiled.hpp Changes: https://git.openjdk.java.net/jdk/pull/1510/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1510&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257238 Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1510.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1510/head:pull/1510 PR: https://git.openjdk.java.net/jdk/pull/1510 From dholmes at openjdk.java.net Mon Nov 30 02:26:55 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 30 Nov 2020 02:26:55 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes In-Reply-To: References: Message-ID: On Sat, 28 Nov 2020 13:08:38 GMT, Jie Fu wrote: > Hi all, > > Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator. > For example, this assert [1] fired on our testing boxes. > > It can be reproduced by the following two steps on Linux-64: > 1) ulimit -v 8388608 > 2) java -XX:MinHeapSize=5g -version > The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize. > > One more important fact is that this bug can be more common on Linux-32 systems. > Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M. > > Testing: > - tier1 ~ tier3 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcArguments.cpp#L96 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 This is really something the GC folk should review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From kbarrett at openjdk.java.net Mon Nov 30 03:35:55 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 30 Nov 2020 03:35:55 GMT Subject: RFR: 8257238: Cleanup include directives for precompiled.hpp In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 01:12:32 GMT, David Holmes wrote: > The precompiled header file is: > > src/hotspot/share/precompiled/precompiled.hpp > > The normal way to include precompiled headers is to just have: > > #include "precompiled.hpp" > > as the first directive in a file. This works because the makefiles set: > > -I$(TOPDIR)/src/hotspot/share/precompiled > > Some files instead have: > > #include "precompiled/precompiled.hpp" > > ./os/bsd/semaphore_bsd.cpp > ./os/linux/waitBarrier_linux.cpp > ./os/posix/semaphore_posix.cpp > ./os/posix/signals_posix.cpp > > This should be trivially cleaned up. Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1510 From dholmes at openjdk.java.net Mon Nov 30 03:40:54 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 30 Nov 2020 03:40:54 GMT Subject: RFR: 8257238: Cleanup include directives for precompiled.hpp In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 03:32:45 GMT, Kim Barrett wrote: >> The precompiled header file is: >> >> src/hotspot/share/precompiled/precompiled.hpp >> >> The normal way to include precompiled headers is to just have: >> >> #include "precompiled.hpp" >> >> as the first directive in a file. This works because the makefiles set: >> >> -I$(TOPDIR)/src/hotspot/share/precompiled >> >> Some files instead have: >> >> #include "precompiled/precompiled.hpp" >> >> ./os/bsd/semaphore_bsd.cpp >> ./os/linux/waitBarrier_linux.cpp >> ./os/posix/semaphore_posix.cpp >> ./os/posix/signals_posix.cpp >> >> This should be trivially cleaned up. > > Looks good, and trivial. Thanks Kim! ------------- PR: https://git.openjdk.java.net/jdk/pull/1510 From dholmes at openjdk.java.net Mon Nov 30 03:40:55 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 30 Nov 2020 03:40:55 GMT Subject: Integrated: 8257238: Cleanup include directives for precompiled.hpp In-Reply-To: References: Message-ID: <-2TiontJjTk_XpYw0nV3vnZkWbxxt8HaLESd-eULrUg=.a6d88c79-e5ac-4794-82db-53611a6083eb@github.com> On Mon, 30 Nov 2020 01:12:32 GMT, David Holmes wrote: > The precompiled header file is: > > src/hotspot/share/precompiled/precompiled.hpp > > The normal way to include precompiled headers is to just have: > > #include "precompiled.hpp" > > as the first directive in a file. This works because the makefiles set: > > -I$(TOPDIR)/src/hotspot/share/precompiled > > Some files instead have: > > #include "precompiled/precompiled.hpp" > > ./os/bsd/semaphore_bsd.cpp > ./os/linux/waitBarrier_linux.cpp > ./os/posix/semaphore_posix.cpp > ./os/posix/signals_posix.cpp > > This should be trivially cleaned up. This pull request has now been integrated. Changeset: 222e9430 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/222e9430 Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod 8257238: Cleanup include directives for precompiled.hpp Reviewed-by: kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/1510 From stuefe at openjdk.java.net Mon Nov 30 07:21:13 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 30 Nov 2020 07:21:13 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v3] In-Reply-To: References: Message-ID: > To analyze JDK-8256729 further, we need more tracing: > > 1) We should print all mappings inside the split area if os::split_reserved_memory() fails > > 2) The print-mapping code on windows has some shortcomings: > - should not probe for mappings outside of what we know are valid address ranges for Windows > - should handle wrap-arounds - it should be possible to print the whole address space > - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) > - should be printed in a more compact manner - base address should be on the same line as the first region > - maybe adorned with some basic range info, e.g. library mappings Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Fix gtest for MacOS and AIX ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1390/files - new: https://git.openjdk.java.net/jdk/pull/1390/files/71d8ef99..be7acf6c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=01-02 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1390/head:pull/1390 PR: https://git.openjdk.java.net/jdk/pull/1390 From rrich at openjdk.java.net Mon Nov 30 09:23:05 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 30 Nov 2020 09:23:05 GMT Subject: RFR: 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails Message-ID: This is an XS sized patch to get a zerobased compressed class space on Linux/PPC64 if a heap up to 2g size is configured and CDS is disabled. On Linux 4.1.42 and higher we fail to get a zerobased CCS because just one attempt is made to place the CCS right after the heap which will be at 4g (ELF_ET_DYN_BASE) but there the java launcher is already mapped. This change reuses the search already implemented for AARCH64. Master without Fix Master with Fix -Xmx Narrow klass base Compressed Class Space Narrow klass base Compressed Class Space ---------------------------------------------------------------------------------------------------- 512m 0x00007fff00000000 ! 0x00007fff00000000 0x0000000000000000 0x0000000200000000 1g 0x00007fff14000000 ! 0x00007fff14000000 0x0000000000000000 0x0000000200000000 2g 0x00007fff30000000 ! 0x00007fff30000000 0x0000000000000000 0x0000000200000000 3g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 4g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 8g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 12g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 16g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 20g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 24g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 28g 0x0000001702000000 0x0000001702000000 0x0000001702000000 0x0000001702000000 32g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 40g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 48g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 ------------- Commit messages: - 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails Changes: https://git.openjdk.java.net/jdk/pull/1512/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1512&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244847 Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1512.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1512/head:pull/1512 PR: https://git.openjdk.java.net/jdk/pull/1512 From stuefe at openjdk.java.net Mon Nov 30 09:40:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 30 Nov 2020 09:40:55 GMT Subject: RFR: 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 09:01:20 GMT, Richard Reingruber wrote: > This is an XS sized patch to get a zerobased compressed class space on > Linux/PPC64 if a heap up to 2g size is configured and CDS is disabled. > > On Linux 4.1.42 and higher we fail to get a zerobased CCS because just one > attempt is made to place the CCS right after the heap which will be at 4g > (ELF_ET_DYN_BASE) but there the java launcher is already mapped. > > This change reuses the search already implemented for AARCH64. > > Master without Fix Master with Fix > > -Xmx Narrow klass base Compressed Class Space Narrow klass base Compressed Class Space > ---------------------------------------------------------------------------------------------------- > 512m 0x00007fff00000000 ! 0x00007fff00000000 0x0000000000000000 0x0000000200000000 > 1g 0x00007fff14000000 ! 0x00007fff14000000 0x0000000000000000 0x0000000200000000 > 2g 0x00007fff30000000 ! 0x00007fff30000000 0x0000000000000000 0x0000000200000000 > 3g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 4g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 8g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 12g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 16g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 20g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 24g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 28g 0x0000001702000000 0x0000001702000000 0x0000001702000000 0x0000001702000000 > 32g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 > 40g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 > 48g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 LGTM. Thanks for fixing this. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1512 From rrich at openjdk.java.net Mon Nov 30 09:44:55 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 30 Nov 2020 09:44:55 GMT Subject: RFR: 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 09:38:25 GMT, Thomas Stuefe wrote: > > > LGTM. Thanks for fixing this. Thank you, Thomas. ------------- PR: https://git.openjdk.java.net/jdk/pull/1512 From mdoerr at openjdk.java.net Mon Nov 30 11:02:53 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 30 Nov 2020 11:02:53 GMT Subject: RFR: 8244847: Linux/PPC: runtime/CompressedOops/CompressedClassPointers: smallHeapTest fails In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 09:01:20 GMT, Richard Reingruber wrote: > This is an XS sized patch to get a zerobased compressed class space on > Linux/PPC64 if a heap up to 2g size is configured and CDS is disabled. > > On Linux 4.1.42 and higher we fail to get a zerobased CCS because just one > attempt is made to place the CCS right after the heap which will be at 4g > (ELF_ET_DYN_BASE) but there the java launcher is already mapped. > > This change reuses the search already implemented for AARCH64. > > Master without Fix Master with Fix > > -Xmx Narrow klass base Compressed Class Space Narrow klass base Compressed Class Space > ---------------------------------------------------------------------------------------------------- > 512m 0x00007fff00000000 ! 0x00007fff00000000 0x0000000000000000 0x0000000200000000 > 1g 0x00007fff14000000 ! 0x00007fff14000000 0x0000000000000000 0x0000000200000000 > 2g 0x00007fff30000000 ! 0x00007fff30000000 0x0000000000000000 0x0000000200000000 > 3g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 4g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 8g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 12g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 16g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 20g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 24g 0x0000000000000000 0x00000007c0000000 0x0000000000000000 0x00000007c0000000 > 28g 0x0000001702000000 0x0000001702000000 0x0000001702000000 0x0000001702000000 > 32g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 > 40g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 > 48g 0x0000000000000000 0x0000000080000000 0x0000000000000000 0x0000000080000000 Thanks for fixing it! Looks good to me, too. Was it tested on AIX? ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1512 From thomas.stuefe at gmail.com Mon Nov 30 13:26:38 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 30 Nov 2020 14:26:38 +0100 Subject: [11u] RFR: JDK-8251255: [linux] Add process-memory information to hs-err and VM.info Message-ID: Hi, may I have reviews for this small backport please. Its goal is to add some beneficial information to the hs-err file (process virtual size and resident set size). The original patch applies unmodified, but only with --fuzz=3, since the surroundings changed too much. Original issue: https://bugs.openjdk.java.net/browse/JDK-8251255 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a6bd3cd0c3a2 Modified patch: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8251255-linux-add-process-memory-info-to-hserr-modified-for-11.patch Thanks, Thomas From tschatzl at openjdk.java.net Mon Nov 30 13:45:58 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 30 Nov 2020 13:45:58 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes In-Reply-To: References: Message-ID: <42WTAHqNoLjc1ycTfLeDZr9pSjwx17sNYcYW_6y4gNQ=.900a2927-ee29-4583-9761-4c69080793a8@github.com> On Sat, 28 Nov 2020 13:08:38 GMT, Jie Fu wrote: > Hi all, > > Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator. > For example, this assert [1] fired on our testing boxes. > > It can be reproduced by the following two steps on Linux-64: > 1) ulimit -v 8388608 > 2) java -XX:MinHeapSize=5g -version > The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize. > > One more important fact is that this bug can be more common on Linux-32 systems. > Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M. > > Testing: > - tier1 ~ tier3 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcArguments.cpp#L96 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 I think the change is good, but please add a test for this. E.g. vmTestbase/nsk/jvmti/Allocate/alloc001/alloc001.java shows how to run a command with an ulimit prepended. ------------- Changes requested by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1492 From coleenp at openjdk.java.net Mon Nov 30 13:45:59 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 30 Nov 2020 13:45:59 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor In-Reply-To: References: Message-ID: <7en56aB_uqgEGsRpvX-V26aDS28pbMEJhgoRxHRd__g=.4472ecb2-5579-438c-bec6-9a1a3ad4c566@github.com> On Fri, 27 Nov 2020 08:05:09 GMT, Vladimir Ivanov wrote: > `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. > But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. > The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. > > Proposed fix is to run Mutex destructor right away. > > Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. > > In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. > > Testing: > - [x] verified that no memory leak observed with the reported test > - [x] tier1-4 > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html Changes requested by coleenp (Reviewer). src/hotspot/share/oops/methodData.cpp line 1208: > 1206: MethodData::MethodData(ciMethodData& data) > 1207: : _extra_data_lock(Mutex::leaf, "unused") { > 1208: _extra_data_lock.~Mutex(); // release allocated resources before zeroing So if _extra_data_lock was a pointer to Mutex, then this statement would be simply "delete _extra_data_lock;" instead, but we'd still have this copy constructor, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From coleenp at openjdk.java.net Mon Nov 30 13:46:02 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 30 Nov 2020 13:46:02 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor In-Reply-To: <7en56aB_uqgEGsRpvX-V26aDS28pbMEJhgoRxHRd__g=.4472ecb2-5579-438c-bec6-9a1a3ad4c566@github.com> References: <7en56aB_uqgEGsRpvX-V26aDS28pbMEJhgoRxHRd__g=.4472ecb2-5579-438c-bec6-9a1a3ad4c566@github.com> Message-ID: <6Do6NGKfK_bDrZPMvfrBscLfj2J9OtFjQNEBrXL-Fbo=.8fd00cf4-4247-4c44-af36-723746d6b26c@github.com> On Mon, 30 Nov 2020 13:39:53 GMT, Coleen Phillimore wrote: >> `ciMethodData` embeds `MethodData` to snapshot a state from the original `MethodData` instance. >> But `MethodData` embeds a `Mutex` which allocates a platform-specific implementation on C-heap. >> The `Mutex` is overwritten with `0`s, but the resources aren't deallocated, so the leak occurs. >> >> Proposed fix is to run Mutex destructor right away. >> >> Initially, I thought about switching to `Mutex*`, but then I found that Coleen already tried that and observed a performance regression [1]. So, for now I chose the conservative approach. >> >> In the longer term, I would consider replacing `MethodData::_extra_data_lock` with a lock-free scheme. Having a lock-per-MDO looks kind of excessive. >> >> Testing: >> - [x] verified that no memory leak observed with the reported test >> - [x] tier1-4 >> >> [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-October/039783.html > > src/hotspot/share/oops/methodData.cpp line 1208: > >> 1206: MethodData::MethodData(ciMethodData& data) >> 1207: : _extra_data_lock(Mutex::leaf, "unused") { >> 1208: _extra_data_lock.~Mutex(); // release allocated resources before zeroing > > So if _extra_data_lock was a pointer to Mutex, then this statement would be simply "delete _extra_data_lock;" instead, but we'd still have this copy constructor, right? Why isn't this a regular copy constructor taking MethodData, and pass this._orig instead and leave the zeroing in the caller? I don't like that oops/methodData knows about ciMethodData. ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From sjohanss at openjdk.java.net Mon Nov 30 13:55:57 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 30 Nov 2020 13:55:57 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes In-Reply-To: References: Message-ID: On Sat, 28 Nov 2020 13:08:38 GMT, Jie Fu wrote: > Hi all, > > Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator. > For example, this assert [1] fired on our testing boxes. > > It can be reproduced by the following two steps on Linux-64: > 1) ulimit -v 8388608 > 2) java -XX:MinHeapSize=5g -version > The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize. > > One more important fact is that this bug can be more common on Linux-32 systems. > Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M. > > Testing: > - tier1 ~ tier3 on Linux/x64 > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcArguments.cpp#L96 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 > [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 src/hotspot/share/runtime/arguments.cpp line 1909: > 1907: reasonable_initial = limit_by_allocatable_memory(reasonable_initial); > 1908: > 1909: FLAG_SET_ERGO(InitialHeapSize, MAX2((size_t)reasonable_initial, MinHeapSize)); I'm not sure this is a good fix, this would violate the limit set by: `limit_by_allocatable_memory(reasonable_initial);` Wouldn't the proper fix be to make sure that MinHeapSize is also limited by what's allowed to allocate? ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From vlivanov at openjdk.java.net Mon Nov 30 13:59:03 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 30 Nov 2020 13:59:03 GMT Subject: RFR: 8252049: Native memory leak in ciMethodData ctor In-Reply-To: <6Do6NGKfK_bDrZPMvfrBscLfj2J9OtFjQNEBrXL-Fbo=.8fd00cf4-4247-4c44-af36-723746d6b26c@github.com> References: <7en56aB_uqgEGsRpvX-V26aDS28pbMEJhgoRxHRd__g=.4472ecb2-5579-438c-bec6-9a1a3ad4c566@github.com> <6Do6NGKfK_bDrZPMvfrBscLfj2J9OtFjQNEBrXL-Fbo=.8fd00cf4-4247-4c44-af36-723746d6b26c@github.com> Message-ID: On Mon, 30 Nov 2020 13:41:23 GMT, Coleen Phillimore wrote: >> src/hotspot/share/oops/methodData.cpp line 1208: >> >>> 1206: MethodData::MethodData(ciMethodData& data) >>> 1207: : _extra_data_lock(Mutex::leaf, "unused") { >>> 1208: _extra_data_lock.~Mutex(); // release allocated resources before zeroing >> >> So if _extra_data_lock was a pointer to Mutex, then this statement would be simply "delete _extra_data_lock;" instead, but we'd still have this copy constructor, right? > > Why isn't this a regular copy constructor taking MethodData, and pass this._orig instead and leave the zeroing in the caller? I don't like that oops/methodData knows about ciMethodData. If `_extra_data_lock` were a pointer, then `MethodData::MethodData` would just `_extra_data_lock(NULL)`. Regarding where to put zeroing, I'm fine doing it either way. Just want to give a try the idea David and Kim proposed with separating the lock from MDO (w/ superclass trick). ------------- PR: https://git.openjdk.java.net/jdk/pull/1478 From martin.doerr at sap.com Mon Nov 30 14:23:48 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 30 Nov 2020 14:23:48 +0000 Subject: [11u] RFR: JDK-8251255: [linux] Add process-memory information to hs-err and VM.info In-Reply-To: References: Message-ID: Hi Thomas, looks good. Thanks, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Thomas St?fe > Sent: Montag, 30. November 2020 14:27 > To: jdk-updates-dev ; Hotspot dev > runtime > Subject: [11u] RFR: JDK-8251255: [linux] Add process-memory information to > hs-err and VM.info > > Hi, > > may I have reviews for this small backport please. Its goal is to add some > beneficial information to the hs-err file (process virtual size and > resident set size). > > The original patch applies unmodified, but only with --fuzz=3, since the > surroundings changed too much. > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8251255 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a6bd3cd0c3a2 > Modified patch: > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8251255-linux-add- > process-memory-info-to-hserr-modified-for-11.patch > > Thanks, Thomas From jiefu at openjdk.java.net Mon Nov 30 14:29:05 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 30 Nov 2020 14:29:05 GMT Subject: RFR: 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr Message-ID: Hi all, The newly added STATIC_ASSERT [1] breaks the build of Zero VM with clang. It complains that 'non-type template argument is not a constant expression' since strlen() [2] is not a constexpr. Any comments? Thanks. Best regards, Jie [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L1374 [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/flags/jvmFlagLookup.hpp#L42 ------------- Commit messages: - 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr Changes: https://git.openjdk.java.net/jdk/pull/1518/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1518&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257420 Stats: 22 lines in 3 files changed: 11 ins; 10 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1518.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1518/head:pull/1518 PR: https://git.openjdk.java.net/jdk/pull/1518 From jiefu at openjdk.java.net Mon Nov 30 14:41:56 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 30 Nov 2020 14:41:56 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 13:52:43 GMT, Stefan Johansson wrote: >> Hi all, >> >> Ergonomics for InitialHeapSize can be broken if the memory resource is limited by the administrator. >> For example, this assert [1] fired on our testing boxes. >> >> It can be reproduced by the following two steps on Linux-64: >> 1) ulimit -v 8388608 >> 2) java -XX:MinHeapSize=5g -version >> The reason was that limit_by_allocatable_memory() [2] returns a value less than MinHeapSize. >> >> One more important fact is that this bug can be more common on Linux-32 systems. >> Since the virtual memory is limited to 3800M [3] on Linux-32, it can be always reproduced when MinHeapSize > 1900M. >> >> Testing: >> - tier1 ~ tier3 on Linux/x64 >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/gcArguments.cpp#L96 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 >> [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 > > src/hotspot/share/runtime/arguments.cpp line 1909: > >> 1907: reasonable_initial = limit_by_allocatable_memory(reasonable_initial); >> 1908: >> 1909: FLAG_SET_ERGO(InitialHeapSize, MAX2((size_t)reasonable_initial, MinHeapSize)); > > I'm not sure this is a good fix, this would violate the limit set by: > `limit_by_allocatable_memory(reasonable_initial);` > > Wouldn't the proper fix be to make sure that MinHeapSize is also limited by what's allowed to allocate? The change just follows what is done for MaxHeapSize. MaxHeapSize is limited by reasonable_max = limit_by_allocatable_memory(reasonable_max) [1]. But it will be set to MAX2(reasonable_max, (julong)MinHeapSize) [2] if MinHeapSize is set. What do you think? [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1876 [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1885 ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From shade at openjdk.java.net Mon Nov 30 14:48:54 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 30 Nov 2020 14:48:54 GMT Subject: RFR: 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 14:24:12 GMT, Jie Fu wrote: > Hi all, > > The newly added STATIC_ASSERT [1] breaks the build of Zero VM with clang. > It complains that 'non-type template argument is not a constant expression' since strlen() [2] is not a constexpr. > > Any comments? > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L1374 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/flags/jvmFlagLookup.hpp#L42 Argh. Since I meant to backport the JDK-8257420 to 11u and 8u, and David was questioning the usefulness of `STATIC_ASSERT` in the original review, probably the simplest solution is to drop the `STATIC_ASSERT` from there entirely. This would make it a one-liner fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/1518 From jiefu at openjdk.java.net Mon Nov 30 14:56:56 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 30 Nov 2020 14:56:56 GMT Subject: RFR: 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 14:46:26 GMT, Aleksey Shipilev wrote: > Argh. Since I meant to backport the JDK-8257420 to 11u and 8u, and David was questioning the usefulness of `STATIC_ASSERT` in the original review, probably the simplest solution is to drop the `STATIC_ASSERT` from there entirely. This would make it a one-liner fix. OK. Will do it soon. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1518 From jiefu at openjdk.java.net Mon Nov 30 15:04:10 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 30 Nov 2020 15:04:10 GMT Subject: RFR: 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr [v2] In-Reply-To: References: Message-ID: > Hi all, > > The newly added STATIC_ASSERT [1] breaks the build of Zero VM with clang. > It complains that 'non-type template argument is not a constant expression' since strlen() [2] is not a constexpr. > > Any comments? > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L1374 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/flags/jvmFlagLookup.hpp#L42 Jie Fu has updated the pull request incrementally with two additional commits since the last revision: - Remove STATIC_ASSERT - Revert changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1518/files - new: https://git.openjdk.java.net/jdk/pull/1518/files/72fa6987..0e948e54 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1518&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1518&range=00-01 Stats: 22 lines in 3 files changed: 10 ins; 12 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1518.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1518/head:pull/1518 PR: https://git.openjdk.java.net/jdk/pull/1518 From shade at openjdk.java.net Mon Nov 30 15:13:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 30 Nov 2020 15:13:57 GMT Subject: RFR: 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr [v2] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 15:04:10 GMT, Jie Fu wrote: >> Hi all, >> >> The newly added STATIC_ASSERT [1] breaks the build of Zero VM with clang. >> It complains that 'non-type template argument is not a constant expression' since strlen() [2] is not a constexpr. >> >> Any comments? >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L1374 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/flags/jvmFlagLookup.hpp#L42 > > Jie Fu has updated the pull request incrementally with two additional commits since the last revision: > > - Remove STATIC_ASSERT > - Revert changes src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 1375: > 1373: const int add_len = 32; \ > 1374: /* Two integers, the additional message, and the null-terminator */ \ > 1375: char message[2 * jintAsStringSize + add_len + 1]; \ Sorry for another nit. Since `STATIC_ASSERT` is gone, we can inline `add_len`, and make the whole thing `+ 33`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1518 From jiefu at openjdk.java.net Mon Nov 30 15:24:12 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 30 Nov 2020 15:24:12 GMT Subject: RFR: 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr [v3] In-Reply-To: References: Message-ID: > Hi all, > > The newly added STATIC_ASSERT [1] breaks the build of Zero VM with clang. > It complains that 'non-type template argument is not a constant expression' since strlen() [2] is not a constexpr. > > Any comments? > > Thanks. > Best regards, > Jie > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L1374 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/flags/jvmFlagLookup.hpp#L42 Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Inline add_len ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1518/files - new: https://git.openjdk.java.net/jdk/pull/1518/files/0e948e54..41376c8f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1518&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1518&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1518.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1518/head:pull/1518 PR: https://git.openjdk.java.net/jdk/pull/1518 From shade at openjdk.java.net Mon Nov 30 15:24:13 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 30 Nov 2020 15:24:13 GMT Subject: RFR: 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr [v3] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 15:21:34 GMT, Jie Fu wrote: >> Hi all, >> >> The newly added STATIC_ASSERT [1] breaks the build of Zero VM with clang. >> It complains that 'non-type template argument is not a constant expression' since strlen() [2] is not a constexpr. >> >> Any comments? >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L1374 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/flags/jvmFlagLookup.hpp#L42 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Inline add_len Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1518 From jiefu at openjdk.java.net Mon Nov 30 15:24:14 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 30 Nov 2020 15:24:14 GMT Subject: RFR: 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr [v2] In-Reply-To: References: Message-ID: <3oIE-ztX1x-xqMzKzqOlQyrsYtnNna1jDnP7wD7U4RQ=.b52ed798-86b0-4702-bda1-0db9dfac4ccc@github.com> On Mon, 30 Nov 2020 15:10:47 GMT, Aleksey Shipilev wrote: >> Jie Fu has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove STATIC_ASSERT >> - Revert changes > > src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp line 1375: > >> 1373: const int add_len = 32; \ >> 1374: /* Two integers, the additional message, and the null-terminator */ \ >> 1375: char message[2 * jintAsStringSize + add_len + 1]; \ > > Sorry for another nit. Since `STATIC_ASSERT` is gone, we can inline `add_len`, and make the whole thing `+ 33`. Fixed. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1518 From thomas.stuefe at gmail.com Mon Nov 30 16:29:27 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 30 Nov 2020 17:29:27 +0100 Subject: [11u] RFR: JDK-8251255: [linux] Add process-memory information to hs-err and VM.info In-Reply-To: References: Message-ID: Thanks, Martin. On Mon, Nov 30, 2020 at 3:23 PM Doerr, Martin wrote: > Hi Thomas, > > looks good. > > Thanks, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Thomas St?fe > > Sent: Montag, 30. November 2020 14:27 > > To: jdk-updates-dev ; Hotspot dev > > runtime > > Subject: [11u] RFR: JDK-8251255: [linux] Add process-memory information > to > > hs-err and VM.info > > > > Hi, > > > > may I have reviews for this small backport please. Its goal is to add > some > > beneficial information to the hs-err file (process virtual size and > > resident set size). > > > > The original patch applies unmodified, but only with --fuzz=3, since the > > surroundings changed too much. > > > > Original issue: https://bugs.openjdk.java.net/browse/JDK-8251255 > > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/a6bd3cd0c3a2 > > Modified patch: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8251255-linux-add- > > process-memory-info-to-hserr-modified-for-11.patch > > > > Thanks, Thomas > From stuefe at openjdk.java.net Mon Nov 30 17:11:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 30 Nov 2020 17:11:57 GMT Subject: RFR: 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr [v3] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 15:24:12 GMT, Jie Fu wrote: >> Hi all, >> >> The newly added STATIC_ASSERT [1] breaks the build of Zero VM with clang. >> It complains that 'non-type template argument is not a constant expression' since strlen() [2] is not a constexpr. >> >> Any comments? >> >> Thanks. >> Best regards, >> Jie >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp#L1374 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/flags/jvmFlagLookup.hpp#L42 > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Inline add_len Looks fine. I guess another solution would have been #define MSGFMT "Index %d out of bounds for length %d" #define add_len sizeof(MSGFMT) .. char message[2 * jintAsStringSize + add_len]; .. jio_snprintf(message, sizeof(message), MSGFMT, \ ... to spare you the character counting ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1518 From sjohanss at openjdk.java.net Mon Nov 30 17:26:59 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 30 Nov 2020 17:26:59 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 14:38:55 GMT, Jie Fu wrote: >> src/hotspot/share/runtime/arguments.cpp line 1909: >> >>> 1907: reasonable_initial = limit_by_allocatable_memory(reasonable_initial); >>> 1908: >>> 1909: FLAG_SET_ERGO(InitialHeapSize, MAX2((size_t)reasonable_initial, MinHeapSize)); >> >> I'm not sure this is a good fix, this would violate the limit set by: >> `limit_by_allocatable_memory(reasonable_initial);` >> >> Wouldn't the proper fix be to make sure that MinHeapSize is also limited by what's allowed to allocate? > > The change just follows what is done for MaxHeapSize. > > MaxHeapSize is limited by reasonable_max = limit_by_allocatable_memory(reasonable_max) [1]. > But it will be set to MAX2(reasonable_max, (julong)MinHeapSize) [2] if MinHeapSize is set. > > What do you think? > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1876 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1885 I agree that the fix is in line with the current code and I guess setting `MinHeapSize` should override `MaxVirtMemFraction` and allow us to use more than half the address space specified. In this case I think I would prefer moving the the call `limit_by_allocatable_memory(reasonable_initial);` [1] to right after the calculation on line 1902 [2]. This way we would only have one line doing lower limiting and one line doing upper limiting. Makes sense? Or will that lead to some other problem? [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1907 [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/arguments.cpp#L1902 ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From minqi at openjdk.java.net Mon Nov 30 19:09:00 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 30 Nov 2020 19:09:00 GMT Subject: RFR: 8256256: UL should not use heap allocation for output string [v2] In-Reply-To: References: <4f1nLSVHM-WDtFOsyghjrv1WqMbiqKPf4TTfDVClzvs=.4ca23d6c-d3cc-4f19-a2b9-572398846b9e@github.com> Message-ID: <1yj-em9VRVgpqiB6l4P-UCO6oeQUVuqnIlhjXLdonIs=.3e1f02f7-bb8b-4064-af00-ca6e70955d77@github.com> On Wed, 18 Nov 2020 05:47:49 GMT, Thomas Stuefe wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Use malloc/free for large log message buffer > > Hi Yumin, > > thanks. Sorry if this seems bikesheddy - I have a proposal about how to print in case of OOM, see below. Feel free to ignore it as you see fit, the patch is already good in its current form. > > Cheers, Thomas Ping @tstuefe @dholmes-ora: Any suggestion for the last webrev? I checked for LogMessageBuffer, where it is used: 1) https://github.com/openjdk/jdk/blob/master/src/hotspot/share/classfile/compactHashtable.cpp#L171 2) https://github.com/openjdk/jdk/blob/master/src/hotspot/share/memory/dumpAllocStats.cpp#L71 3) https://github.com/openjdk/jdk/blob/master/src/hotspot/share/memory/filemap.cpp#L1199 4) https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/instanceKlass.cpp#L3626 I may miss other places --- the log with files. LogMessageBuffer's initial cap is 1024, which will grow if it is not enough (used for multiple lines for a complex output). I think we can leave this part as it is now. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1246 From hseigel at openjdk.java.net Mon Nov 30 21:20:06 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 30 Nov 2020 21:20:06 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags Message-ID: Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. Thanks, Harold ------------- Commit messages: - 8256718: Obsolete the long term deprecated and aliased Trace flags Changes: https://git.openjdk.java.net/jdk/pull/1525/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1525&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256718 Stats: 190 lines in 22 files changed: 51 ins; 112 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/1525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1525/head:pull/1525 PR: https://git.openjdk.java.net/jdk/pull/1525 From jiefu at openjdk.java.net Mon Nov 30 23:34:01 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 30 Nov 2020 23:34:01 GMT Subject: RFR: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 17:24:39 GMT, Stefan Johansson wrote: > > In this case I think I would prefer moving the the call `limit_by_allocatable_memory(reasonable_initial);` [1] to right after the calculation on line 1902 [2]. This way we would only have one line doing lower limiting and one line doing upper limiting. > Good suggestion! Will test it soon. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1492 From jiefu at openjdk.java.net Mon Nov 30 23:37:57 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 30 Nov 2020 23:37:57 GMT Subject: RFR: 8257420: Zero VM build broken with clang after JDK-8256726 due to strlen() is not a constexpr [v3] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 17:08:58 GMT, Thomas Stuefe wrote: > Looks fine. > > I guess another solution would have been > > ``` > #define MSGFMT "Index %d out of bounds for length %d" > #define add_len sizeof(MSGFMT) > .. > char message[2 * jintAsStringSize + add_len]; > .. > jio_snprintf(message, sizeof(message), MSGFMT, \ > ... > ``` > > to spare you the character counting Nice skill. Got it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1518 From sspitsyn at openjdk.java.net Mon Nov 30 23:44:55 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 30 Nov 2020 23:44:55 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 21:13:05 GMT, Harold Seigel wrote: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold Hi Harold, The fix looks okay to me. I was more focusing on the serviceability flags. I'm not sure the flag `TraceJVMTIObjectTagging` should be mentioned in the `src/java.base/share/man/java.1` the same way as the `TraceRedefineClasses`. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525