From dlong at openjdk.org Thu Sep 1 02:20:08 2022 From: dlong at openjdk.org (Dean Long) Date: Thu, 1 Sep 2022 02:20:08 GMT Subject: RFR: 8292584: assert(cb != __null) failed: must be with -XX:-Inline [v5] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 07:01:57 GMT, Dean Long wrote: >> generate_Continuation_doYield_entry() creates an interpreter entry point, but jumps to a compiled stub, which needs to be walkable. The interpreter entry does not create an interpreter frame, so frame walking expects a compiled frame. Normally everything is OK, but if C1 does not inline the intrinsic and we get to the interpreter entry through the c2i adapter, then things can break if the c2i adapter padded the stack because of alignment. The easiest fix is to undo what the c2i adapter might have done. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > fix build failures Thanks Ron. Loom testing looks good so far. ------------- PR: https://git.openjdk.org/jdk/pull/9974 From dlong at openjdk.org Thu Sep 1 03:02:50 2022 From: dlong at openjdk.org (Dean Long) Date: Thu, 1 Sep 2022 03:02:50 GMT Subject: RFR: 8292584: assert(cb != __null) failed: must be with -XX:-Inline [v6] In-Reply-To: References: Message-ID: > generate_Continuation_doYield_entry() creates an interpreter entry point, but jumps to a compiled stub, which needs to be walkable. The interpreter entry does not create an interpreter frame, so frame walking expects a compiled frame. Normally everything is OK, but if C1 does not inline the intrinsic and we get to the interpreter entry through the c2i adapter, then things can break if the c2i adapter padded the stack because of alignment. The easiest fix is to undo what the c2i adapter might have done. Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - merge fix - Merge master - fix build failures - fix zero build - cleanup - fix failed assert - version 2, make doYield a native intrinsic like enterSpecial - fix generate_Continuation_doYield_entry ------------- Changes: https://git.openjdk.org/jdk/pull/9974/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9974&range=05 Stats: 586 lines in 48 files changed: 194 ins; 340 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/9974.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9974/head:pull/9974 PR: https://git.openjdk.org/jdk/pull/9974 From dholmes at openjdk.org Thu Sep 1 04:15:28 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Sep 2022 04:15:28 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, add assert. src/hotspot/share/classfile/protectionDomainCache.hpp line 33: > 31: > 32: // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are > 33: // registered by DictionaryEntry::add_protection_domain() to a unique WeakHandle. Now that I understand what this table does, this comment is confusing to me. The table maps each PD to itself (using the WeakHandle as the actual key and value) as a means to track which PDs have been seen/registered. I would describe it thus: // The ProtectionDomainCacheTable records all of the java.security.ProtectionDomain instances that have // been registered by DictionaryEntry::add_protection_domain(). We use a hashtable to map each PD // instance to itself (using WeakHandles) to allow for fast lookup. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Thu Sep 1 04:15:28 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Sep 2022 04:15:28 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v4] In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 12:30:24 GMT, Coleen Phillimore wrote: >> I still can't decipher what this "map" actually holds. What does the unique WeakHandle actually refer to? > > WeakHandles are wrappers around a pointer to an oop that has been allocated in OopStorage. We cannot hold oops directly in hashtables because then we'd have to tell GC how and when to walk the hashtable. We want to save the oops though because they tell us whether this protection domain has been checked for the class that we're currently loading. The Old Hashtable held WeakHandles. So does this one, except with the wart in that we need the WeakHandle for both lookup and to return a unique WeakHandle for the protection domain oop. I've suggested a different comment above. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From xlinzheng at openjdk.org Thu Sep 1 04:17:57 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 1 Sep 2022 04:17:57 GMT Subject: RFR: 8293100: RISC-V: Need to save and restore callee-saved FloatRegisters in StubGenerator::generate_call_stub Message-ID: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> Hi team, 1. Tests described in JDK-8293100 are failed, for callee-saved float registers used in C++ code are observed being killed after entering the Java world since callee-saved float registers are unfortunately missed to be saved in `StubGenerator::generate_call_stub()`. So the phenomenon presented in the failed tests seems to be weird. 2. This patch also fixes some typos in `vmreg_riscv.cpp` when debugging the same issue: (before) ![140D1DC7-39AD-4D5E-ABDE-38AACB658E3F](https://user-images.githubusercontent.com/38156692/187642108-9b3c5b81-f753-4e02-8a71-1baa984f1c74.png) This one seems not right, either; and it also gets fixed in this patch: (after) ![6374B608-F574-4883-9DB5-D0525BE2536A](https://user-images.githubusercontent.com/38156692/187642140-43d0647a-0ae6-4e11-951e-d90b239bd75a.png) 3. Also, branch nodes for float registers in OptoAssembly didn't show their destination blocks. This patch adds a little enhancement for those. Hotspot tier1 has passed both on my board and qemu, and `vmTestbase/nsk/stress` tests failed before have passed as well. The test process on the board is slow and I am testing the remaining but I consider this as ready for review. Best, Xiaolin ------------- Commit messages: - riscv: Forgot to save callee-saved FloatRegisters in StubGenerator::generate_call_stub - riscv: Print dest blocks of branch instructions for OptoAssembly - riscv: Fix VMReg names for Float/Vector Registers Changes: https://git.openjdk.org/jdk/pull/10095/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10095&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293100 Stats: 79 lines in 4 files changed: 64 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/10095.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10095/head:pull/10095 PR: https://git.openjdk.org/jdk/pull/10095 From dholmes at openjdk.org Thu Sep 1 04:29:07 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Sep 2022 04:29:07 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, add assert. src/hotspot/share/classfile/protectionDomainCache.cpp line 186: > 184: > 185: // The object_no_keepalive() call peeks at the phantomly reachable oop without > 186: // keeping it alive. This is used for traversing DictionaryEntry pd_set. My confusion here was that the comment belonged to the `ProtectionDomainCacheEntry::object_no_keepalive` method, but you have deleted that and are now applying the comment to the `ProtectionDomainEntry::object_no_keepalive()` method. The end result is okay. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Thu Sep 1 05:03:10 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Sep 2022 05:03:10 GMT Subject: RFR: 8293188: x86_64: Introduce stubGenerator_x86_64.hpp In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 23:07:24 GMT, Vladimir Ivanov wrote: > Introduce stubGenerator_x86_64.hpp and extract StubGenerator class declaration there. > > Testing: hs-tier1 - hs-tier4 Rather tricky to review but as long as things build okay this should be fine. I'm assuming the motivation here was just to get smaller files to work with? A couple of minor nits. Thanks. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 51: > 49: #include "jfr/support/jfrIntrinsics.hpp" > 50: #endif > 51: #include "stubGenerator_x86_64.hpp" This should be in alphabetical order prior to the conditional includes. src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 2: > 1: /* > 2: * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. As the content of this file has been moved from another, the original file's copyright years should be preserved. Thanks. src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 24: > 22: * > 23: */ > 24: Do we need the usual header file include guard? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10111 From stuefe at openjdk.org Thu Sep 1 05:29:11 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 1 Sep 2022 05:29:11 GMT Subject: RFR: JDK-8293114: GC should trim the native heap In-Reply-To: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> References: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> Message-ID: <8wtMlnuvDglrdLmP6HAW46J5BdGUacGKYO85j9gKlAE=.664b6079-efdb-4c5b-af93-8e0404dc0a63@github.com> On Tue, 30 Aug 2022 14:35:26 GMT, Thomas Stuefe wrote: > This RFE adds the option to auto-trim the Glibc heap as part of the GC cycle. If the VM process suffered high temporary malloc spikes (regardless whether from JVM- or user code), this could recover significant amounts of memory. > > We discussed this a year ago [1], but the item got pushed to the bottom of my work pile, therefore it took longer than I thought. > > ### Motivation > > The Glibc allocator is reluctant to return memory to the OS, much more so than other allocators. Temporary malloc spikes often carry over as permanent RSS increase. > > Note that C-heap retention is difficult to observe. Since it is freed memory, it won't show up in NMT, it is just a part of private RSS. > > Theoretically, retained memory is not lost since it will be reused by future mallocs. Retaining memory is therefore a bet on the future behavior of the app. The allocator bets on the application needing memory in the near future, and to satisfy that need via malloc. > > But an app's malloc load can fluctuate wildly, with temporary spikes and long idle periods. And if the app rolls its own custom allocators atop of mmap, as hotspot does, a lot of that memory cannot be reused even though it counts toward its memory footprint. > > To help, Glibc exports an API to trim the C-heap: `malloc_trim(3)`. With JDK 18 [2], SAP contributed a new jcmd command to *manually* trim the C-heap on Linux. This RFE adds a complementary way to trim automatically. > > #### Is this even a problem? > > Do we have high malloc spikes in the JVM process? We assume that malloc load from hotspot is usually low since hotspot typically clusters allocations into custom areas - metaspace, code heap, arenas. > > But arenas are subject to Glibc mem retention too. I was surprised by that since I assumed 32k arena chunks were too big to be subject of Glibc retention. But I saw in experiments that high arena peaks often cause lasting RSS increase. > > And of course, both hotspot and JDK do a lot of finer-granular mallocs outside of custom allocators. > > But many cases of high memory retention in Glibc I have seen in third-party JNI code. Libraries allocate large buffers via malloc as temporary buffers. In fact, since we introduced the jcmd "System.trim_native_heap", some of our customers started to call this command periodically in scripts to counter these issues. > > Therefore I think while high malloc spikes are atypical for a JVM process, they can happen. Having a way to auto-trim the native heap makes sense. > > ### When should we trim? > > We want to trim when we know there is a lull in malloc activity coming. But we have no knowledge of the future. > > We could build a heuristic based on malloc frequency. But on closer inspection that is difficult. We cannot use NMT, since NMT has no complete picture (only knows hotspot) and is usually disabled in production anyway. The only way to get *all* mallocs would be to use Glibc malloc hooks. We have done so in desperate cases at SAP, but Glibc removed malloc hooks in 2.35. It would be a messy solution anyway; best to avoid it. > > The next best thing is synchronizing with the larger C-heap users in the VM: compiler and GC. But compiler turns out not to be such a problem, since the compiler uses arenas, and arena chunks are buffered in a free pool with a five-second delay. That means compiler activity that happens in bursts, like at VM startup, will just shuffle arena chunks around from/to the arena free pool, never bothering to call malloc or free. > > That leaves the GC, which was also the experts' recommendation in last year's discussion [1]. Most GCs do uncommit, and trimming the native heap fits well into this. And we want to time the trim to not get into the way of a GC. Plus, integrating trims into the GC cycle lets us reuse GC logging and timing, thereby making RSS changes caused by trim-native visible to the analyst. > > > ### How it works: > > Patch adds new options (experimental for now, and shared among all GCs): > > > -XX:+GCTrimNativeHeap > -XX:GCTrimNativeHeapInterval= (defaults to 60) > > > `GCTrimNativeHeap` is off by default. If enabled, it will cause the VM to trim the native heap on full GCs as well as periodically. The period is defined by `GCTrimNativeHeapInterval`. Periodic trimming can be completely switched off with `GCTrimNativeHeapInterval=0`; in that case, we will only trim on full GCs. > > ### Examples: > > This is an artificial test that causes two high malloc spikes with long idle periods. Observe how RSS recovers with trim but stays up without trim. The trim interval was set to 15 seconds for the test, and no GC was invoked here; this is periodic trimming. > > ![alloc-test](http://cr.openjdk.java.net/~stuefe/other/autotrim/rss-all-collectors.png) > > (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-all.sh) ) > > Spring pet clinic boots up, then idles. Once with, once without trim, with the trim interval at 60 seconds default. Of course, if it were actually doing something instead of idling, trim effects would be smaller. But the point of trimming is to recover memory in idle periods. > > ![petclinic bootup](http://cr.openjdk.java.net/~stuefe/other/autotrim/spring-petclinic-rss-with-and-without-trim.png)) > > (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-petclinic-boot.sh) ) > > > > ### Implementation > > One problem I faced when implementing this was that trimming was non-interruptable. GCs usually split the uncommit work into smaller portions, which is impossible for `malloc_trim()`. > > So very slow trims could introduce longer GC pauses. I did not want this, therefore I implemented two ways to trim: > 1) GCs can opt to trim asynchronously. In that case, a `NativeTrimmer` thread runs on behalf of the GC and takes care of all trimming. The GC just nudges the `NativeTrimmer` at the end of its GC cycle, but the trim itself runs concurrently. > 2) GCs can do the trim inside their own thread, synchronously. It will have to wait until the trim is done. > > (1) has the advantage of giving us periodic trims even without GC activity (Shenandoah does this out of the box). > > #### Serial > > Serial does the trimming synchronously as part of a full GC, and only then. I did not want to spawn a separate thread for the SerialGC. Therefore Serial is the only GC that does not offer periodic trimming, it just trims on full GC. > > #### Parallel, G1, Z > > All of them do the trimming asynchronously via `NativeTrimmer`. They schedule the native trim at the end of a full collection. They also pause the trimming at the beginning of a cycle to not trim during GCs. > > #### Shenandoah > > Shenandoah does the trimming synchronously in its service thread, similar to how it handles uncommits. Since the service thread already runs concurrently and continuously, it can do periodic trimming; no need to spin a new thread. And this way we can reuse the Shenandoah timing classes. > > ### Patch details > > - adds three new functions to the `os` namespace: > - `os::trim_native_heap()` implementing trim > - `os::can_trim_native_heap()` and `os::should_trim_native_heap()` to return whether platform supports trimming resp. whether the platform considers trimming to be useful. > - replaces implementation of the cmd "System.trim_native_heap" with the new `os::trim_native_heap` > - provides a new wrapper function wrapping the tedious `mallinfo()` vs `mallinfo2()` business: `os::Linux::get_mallinfo()` > - adds a GC-shared utility class, `GCTrimNative`, that takes care of trimming and GC-logging and houses the `NativeTrimmer` thread class. > - adds a regression test > > > ### Tests > > Tested older Glibc (2.31), and newer Glibc (2.35) (`mallinfo()` vs` mallinfo2()`), on Linux x64. > > The rest of the tests will be done by GHA and in our SAP nightlies. > > > ### Remarks > > #### How about other allocators? > > I have seen this retention problem mainly with the Glibc and the AIX libc. Muslc returns memory more eagerly to the OS. I also tested with jemalloc and found it also reclaims more aggressively, therefore I don't think MacOS or BSD are affected that much by retention either. > > #### Trim costs? > > Trim-native is a tradeoff between memory and performance. We pay > - The cost to do the trim depends on how much is trimmed. Time ranges on my machine between < 1ms for no-op trims, to ~800ms for 32GB trims. > - The cost for re-acquiring the memory, should the memory be needed again, is the second cost factor. > > #### Predicting malloc_trim effects? > > `ShenandoahUncommit` avoids uncommits if they are not necessary, thus avoiding work and gc log spamming. I liked that and tried to follow that example. Tried to devise a way to predict the effect trim could have based on allocator info from mallinfo(3). That was quite frustrating since the documentation was confusing and I had to do a lot of experimenting. In the end, I came up with a heuristic to prevent obviously pointless trim attempts; see `os::should_trim_native_heap()`. I am not completely happy with it. > > #### glibc.malloc.trim_threshold? > > glibc has a tunable that looks like it could influence the willingness of Glibc to return memory to the OS, the "trim_threshold". In practice, I could not get it to do anything useful. Regardless of the setting, it never seemed to influence the trimming behavior. Even if it would work, I'm not sure we'd want to use that, since by doing malloc_trim manually we can space out the trims as we see fit, instead of paying the trim price for free(3). > > > - [1] https://mail.openjdk.org/pipermail/hotspot-dev/2021-August/054323.html > - [2] https://bugs.openjdk.org/browse/JDK-8269345 Hi Zhengyu, > @tstuefe Nice work! > Thanks :) > I also looked into memory usage recently, I found that `os::print_os_info()` is very usefully. I would like to purpose to add a diagnostics flag, e.g. `PrintProcessInfoAtExit` to capture some insights of the process, such as `RSS`, `Peak RSS`, `C-Heap` and `C-Heap Retained`. > A small problem with "C-Heap Retained" is that it also contains blocks that are either trimmed or have never been (fully) paged in, meaning, that number may not relate 1:1 to RSS. Glibc observability is really annoying. About the "AtExit", in our SAP JVM I added a simple "DumpInfoAtExit", which prints out what "jcmd VM.info" would give you. Basically, a hs-err file without the err part. That contains a whole lot of information, including NMT and process memory information. That may be a better way than adding individual XXAtExit flags, what do you think? Another thing I would like to do is to enable Peak usage numbers in NMT for release builds too. That way one can see at VM exit how much memory each subsystem used. > Here are some numbers I captured > > C-Heap Outstanding (K) C-Heap Retained (K) > Compiler 106387 271692 > Sunflow 103882 173929 > Compress 37794 11605 > CrytioAes 37579 30580 > CryptoRsa 38318 73001 > CryptoSignVerify 37790 38769 > Derby 55389 186954 > MpegAudio 40280 71743 > ScimarkFFT.large 36698 8945 > ScimarkFFT.small 37071 10824 > ScimarkLU.large 38018 8529 > ScimarkLU.small 39198 8585 > ScimarkMonteCarlo 36946 6529 > ScimarkSOR.large 36648 8787 > ScimarkSOR.small 36569 9078 > ScimarkSparse.large 36745 9182 > ScimarkSparse.small 37253 8574 > Serial. 38652 127231 > Sunflow.test. 45450 56657 > XmlTransform. 83116 289431 > XmlValidation 59883 59883 > ? > I captured the number at JVM exit, so it might not reflect runtime characters. > But some number is quite interesting, e.g. `Derby` retained set is about x3 of outstanding set. Interesting, since it means malloc peaks are more common then we think. All the more reason to have a feature like this, to trim the C-heap. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/10085 From stefank at openjdk.org Thu Sep 1 06:19:46 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 1 Sep 2022 06:19:46 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v8] In-Reply-To: References: Message-ID: <7Asu6pqSzkB4XcWSCc-Cajiwxz4a8BWGKhgMAgh0V1I=.1aa688dc-5e5b-424c-8950-f22796172629@github.com> > Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. > > This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. > > We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. > > I'd like to suggest that we use a convention to specify what we want. This is the current proposal: > > // Guide to the suffixes used in the format specifiers for integers: > // - print the decimal value: 745565 > // _X - print as hexadecimal, without leading 0s: 0x12345 > // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 > // _H - print as hexadecimal, without 0x prefix > // _W(w) - prints w sized string with the given value right > // adjusted. Use -w to print left adjusted. > // > // Note that the PTR format specifiers print using 0x with leading zeros, > // just like the _X_0 version for integers. > > > The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8292981_unify_integer_format_specifiers - Merge branch 'master' into 8292981_unify_integer_format_specifiers - Remove _H variants - Removed extraneous 0x - Move INTPTR_FORMAT_H_W to Shenandoah - Use PTR_FORMAT in AIX code - Fix Shenandoah - 8292981: Unify and restructure integer printing format specifiers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10042/files - new: https://git.openjdk.org/jdk/pull/10042/files/52220b7d..6c1cdc84 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=06-07 Stats: 4552 lines in 177 files changed: 2348 ins; 817 del; 1387 mod Patch: https://git.openjdk.org/jdk/pull/10042.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10042/head:pull/10042 PR: https://git.openjdk.org/jdk/pull/10042 From iklam at openjdk.org Thu Sep 1 06:44:17 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 1 Sep 2022 06:44:17 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Thu, 1 Sep 2022 04:12:32 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comments, add assert. > > src/hotspot/share/classfile/protectionDomainCache.hpp line 33: > >> 31: >> 32: // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are >> 33: // registered by DictionaryEntry::add_protection_domain() to a unique WeakHandle. > > Now that I understand what this table does, this comment is confusing to me. The table maps each PD to itself (using the WeakHandle as the actual key and value) as a means to track which PDs have been seen/registered. I would describe it thus: > > // The ProtectionDomainCacheTable records all of the java.security.ProtectionDomain instances that have > // been registered by DictionaryEntry::add_protection_domain(). We use a hashtable to > map each PD > // instance to itself (using WeakHandles) to allow for fast lookup. ?Mapping to itself? is how this table works internally. I am not sure if this information is useful here. But the purpose of this table is really to keep track of all PDs that have been registered and not yet garbage collected. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From stuefe at openjdk.org Thu Sep 1 06:47:27 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 1 Sep 2022 06:47:27 GMT Subject: RFR: JDK-8293114: GC should trim the native heap [v2] In-Reply-To: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> References: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> Message-ID: > This RFE adds the option to auto-trim the Glibc heap as part of the GC cycle. If the VM process suffered high temporary malloc spikes (regardless whether from JVM- or user code), this could recover significant amounts of memory. > > We discussed this a year ago [1], but the item got pushed to the bottom of my work pile, therefore it took longer than I thought. > > ### Motivation > > The Glibc allocator is reluctant to return memory to the OS, much more so than other allocators. Temporary malloc spikes often carry over as permanent RSS increase. > > Note that C-heap retention is difficult to observe. Since it is freed memory, it won't show up in NMT, it is just a part of private RSS. > > Theoretically, retained memory is not lost since it will be reused by future mallocs. Retaining memory is therefore a bet on the future behavior of the app. The allocator bets on the application needing memory in the near future, and to satisfy that need via malloc. > > But an app's malloc load can fluctuate wildly, with temporary spikes and long idle periods. And if the app rolls its own custom allocators atop of mmap, as hotspot does, a lot of that memory cannot be reused even though it counts toward its memory footprint. > > To help, Glibc exports an API to trim the C-heap: `malloc_trim(3)`. With JDK 18 [2], SAP contributed a new jcmd command to *manually* trim the C-heap on Linux. This RFE adds a complementary way to trim automatically. > > #### Is this even a problem? > > Do we have high malloc spikes in the JVM process? We assume that malloc load from hotspot is usually low since hotspot typically clusters allocations into custom areas - metaspace, code heap, arenas. > > But arenas are subject to Glibc mem retention too. I was surprised by that since I assumed 32k arena chunks were too big to be subject of Glibc retention. But I saw in experiments that high arena peaks often cause lasting RSS increase. > > And of course, both hotspot and JDK do a lot of finer-granular mallocs outside of custom allocators. > > But many cases of high memory retention in Glibc I have seen in third-party JNI code. Libraries allocate large buffers via malloc as temporary buffers. In fact, since we introduced the jcmd "System.trim_native_heap", some of our customers started to call this command periodically in scripts to counter these issues. > > Therefore I think while high malloc spikes are atypical for a JVM process, they can happen. Having a way to auto-trim the native heap makes sense. > > ### When should we trim? > > We want to trim when we know there is a lull in malloc activity coming. But we have no knowledge of the future. > > We could build a heuristic based on malloc frequency. But on closer inspection that is difficult. We cannot use NMT, since NMT has no complete picture (only knows hotspot) and is usually disabled in production anyway. The only way to get *all* mallocs would be to use Glibc malloc hooks. We have done so in desperate cases at SAP, but Glibc removed malloc hooks in 2.35. It would be a messy solution anyway; best to avoid it. > > The next best thing is synchronizing with the larger C-heap users in the VM: compiler and GC. But compiler turns out not to be such a problem, since the compiler uses arenas, and arena chunks are buffered in a free pool with a five-second delay. That means compiler activity that happens in bursts, like at VM startup, will just shuffle arena chunks around from/to the arena free pool, never bothering to call malloc or free. > > That leaves the GC, which was also the experts' recommendation in last year's discussion [1]. Most GCs do uncommit, and trimming the native heap fits well into this. And we want to time the trim to not get into the way of a GC. Plus, integrating trims into the GC cycle lets us reuse GC logging and timing, thereby making RSS changes caused by trim-native visible to the analyst. > > > ### How it works: > > Patch adds new options (experimental for now, and shared among all GCs): > > > -XX:+GCTrimNativeHeap > -XX:GCTrimNativeHeapInterval= (defaults to 60) > > > `GCTrimNativeHeap` is off by default. If enabled, it will cause the VM to trim the native heap on full GCs as well as periodically. The period is defined by `GCTrimNativeHeapInterval`. Periodic trimming can be completely switched off with `GCTrimNativeHeapInterval=0`; in that case, we will only trim on full GCs. > > ### Examples: > > This is an artificial test that causes two high malloc spikes with long idle periods. Observe how RSS recovers with trim but stays up without trim. The trim interval was set to 15 seconds for the test, and no GC was invoked here; this is periodic trimming. > > ![alloc-test](http://cr.openjdk.java.net/~stuefe/other/autotrim/rss-all-collectors.png) > > (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-all.sh) ) > > Spring pet clinic boots up, then idles. Once with, once without trim, with the trim interval at 60 seconds default. Of course, if it were actually doing something instead of idling, trim effects would be smaller. But the point of trimming is to recover memory in idle periods. > > ![petclinic bootup](http://cr.openjdk.java.net/~stuefe/other/autotrim/spring-petclinic-rss-with-and-without-trim.png)) > > (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-petclinic-boot.sh) ) > > > > ### Implementation > > One problem I faced when implementing this was that trimming was non-interruptable. GCs usually split the uncommit work into smaller portions, which is impossible for `malloc_trim()`. > > So very slow trims could introduce longer GC pauses. I did not want this, therefore I implemented two ways to trim: > 1) GCs can opt to trim asynchronously. In that case, a `NativeTrimmer` thread runs on behalf of the GC and takes care of all trimming. The GC just nudges the `NativeTrimmer` at the end of its GC cycle, but the trim itself runs concurrently. > 2) GCs can do the trim inside their own thread, synchronously. It will have to wait until the trim is done. > > (1) has the advantage of giving us periodic trims even without GC activity (Shenandoah does this out of the box). > > #### Serial > > Serial does the trimming synchronously as part of a full GC, and only then. I did not want to spawn a separate thread for the SerialGC. Therefore Serial is the only GC that does not offer periodic trimming, it just trims on full GC. > > #### Parallel, G1, Z > > All of them do the trimming asynchronously via `NativeTrimmer`. They schedule the native trim at the end of a full collection. They also pause the trimming at the beginning of a cycle to not trim during GCs. > > #### Shenandoah > > Shenandoah does the trimming synchronously in its service thread, similar to how it handles uncommits. Since the service thread already runs concurrently and continuously, it can do periodic trimming; no need to spin a new thread. And this way we can reuse the Shenandoah timing classes. > > ### Patch details > > - adds three new functions to the `os` namespace: > - `os::trim_native_heap()` implementing trim > - `os::can_trim_native_heap()` and `os::should_trim_native_heap()` to return whether platform supports trimming resp. whether the platform considers trimming to be useful. > - replaces implementation of the cmd "System.trim_native_heap" with the new `os::trim_native_heap` > - provides a new wrapper function wrapping the tedious `mallinfo()` vs `mallinfo2()` business: `os::Linux::get_mallinfo()` > - adds a GC-shared utility class, `GCTrimNative`, that takes care of trimming and GC-logging and houses the `NativeTrimmer` thread class. > - adds a regression test > > > ### Tests > > Tested older Glibc (2.31), and newer Glibc (2.35) (`mallinfo()` vs` mallinfo2()`), on Linux x64. > > The rest of the tests will be done by GHA and in our SAP nightlies. > > > ### Remarks > > #### How about other allocators? > > I have seen this retention problem mainly with the Glibc and the AIX libc. Muslc returns memory more eagerly to the OS. I also tested with jemalloc and found it also reclaims more aggressively, therefore I don't think MacOS or BSD are affected that much by retention either. > > #### Trim costs? > > Trim-native is a tradeoff between memory and performance. We pay > - The cost to do the trim depends on how much is trimmed. Time ranges on my machine between < 1ms for no-op trims, to ~800ms for 32GB trims. > - The cost for re-acquiring the memory, should the memory be needed again, is the second cost factor. > > #### Predicting malloc_trim effects? > > `ShenandoahUncommit` avoids uncommits if they are not necessary, thus avoiding work and gc log spamming. I liked that and tried to follow that example. Tried to devise a way to predict the effect trim could have based on allocator info from mallinfo(3). That was quite frustrating since the documentation was confusing and I had to do a lot of experimenting. In the end, I came up with a heuristic to prevent obviously pointless trim attempts; see `os::should_trim_native_heap()`. I am not completely happy with it. > > #### glibc.malloc.trim_threshold? > > glibc has a tunable that looks like it could influence the willingness of Glibc to return memory to the OS, the "trim_threshold". In practice, I could not get it to do anything useful. Regardless of the setting, it never seemed to influence the trimming behavior. Even if it would work, I'm not sure we'd want to use that, since by doing malloc_trim manually we can space out the trims as we see fit, instead of paying the trim price for free(3). > > > - [1] https://mail.openjdk.org/pipermail/hotspot-dev/2021-August/054323.html > - [2] https://bugs.openjdk.org/browse/JDK-8269345 Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: - reduce test runtime on slow hardware - make tests more stable on slow hardware ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10085/files - new: https://git.openjdk.org/jdk/pull/10085/files/864b3fb5..35938c69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10085&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10085&range=00-01 Stats: 16 lines in 1 file changed: 10 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10085.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10085/head:pull/10085 PR: https://git.openjdk.org/jdk/pull/10085 From dholmes at openjdk.org Thu Sep 1 06:55:03 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Sep 2022 06:55:03 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Thu, 1 Sep 2022 06:42:06 GMT, Ioi Lam wrote: >> src/hotspot/share/classfile/protectionDomainCache.hpp line 33: >> >>> 31: >>> 32: // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are >>> 33: // registered by DictionaryEntry::add_protection_domain() to a unique WeakHandle. >> >> Now that I understand what this table does, this comment is confusing to me. The table maps each PD to itself (using the WeakHandle as the actual key and value) as a means to track which PDs have been seen/registered. I would describe it thus: >> >> // The ProtectionDomainCacheTable records all of the java.security.ProtectionDomain instances that have >> // been registered by DictionaryEntry::add_protection_domain(). We use a hashtable to >> map each PD >> // instance to itself (using WeakHandles) to allow for fast lookup. > > ?Mapping to itself? is how this table works internally. I am not sure if this information is useful here. But the purpose of this table is really to keep track of all PDs that have been registered and not yet garbage collected. "mapping to itself" is more useful than "mapping ... to a unique Weakhandle" - which is even more of an internal implementation detail. I found the use of this table very hard to discern based on the internal use of the hashtable, as there is no real mapping operation - we simply track if a PD has been seen or not. The use of the hashtable is purely for lookup convenience - we could instead have a linked-list of PD's that we traverse for lookup. So perhaps we drop my second sentence above, and move it to where the hashtable itself is declared? ------------- PR: https://git.openjdk.org/jdk/pull/10043 From vkempik at openjdk.org Thu Sep 1 07:04:08 2022 From: vkempik at openjdk.org (Vladimir Kempik) Date: Thu, 1 Sep 2022 07:04:08 GMT Subject: RFR: 8293100: RISC-V: Need to save and restore callee-saved FloatRegisters in StubGenerator::generate_call_stub In-Reply-To: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> References: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> Message-ID: <9S2DiKOSWEDrD58cX6SRNAWb5gqNIqwAVlhmzVHl3-s=.54ebc300-10b5-4810-b7a4-c89d02f1db46@github.com> On Wed, 31 Aug 2022 08:47:50 GMT, Xiaolin Zheng wrote: > Hi team, > > 1. Tests described in JDK-8293100 are failed, for callee-saved float registers used in C++ code are observed being killed after entering the Java world since callee-saved float registers are unfortunately missed to be saved in `StubGenerator::generate_call_stub()`. So the phenomenon presented in the failed tests seems to be weird. > > 2. This patch also fixes some typos in `vmreg_riscv.cpp` when debugging the same issue: > (before) > ![140D1DC7-39AD-4D5E-ABDE-38AACB658E3F](https://user-images.githubusercontent.com/38156692/187642108-9b3c5b81-f753-4e02-8a71-1baa984f1c74.png) > This one seems not right, either; and it also gets fixed in this patch: > (after) > ![6374B608-F574-4883-9DB5-D0525BE2536A](https://user-images.githubusercontent.com/38156692/187642140-43d0647a-0ae6-4e11-951e-d90b239bd75a.png) > > 3. Also, branch nodes for float registers in OptoAssembly didn't show their destination blocks. This patch adds a little enhancement for those. > > Hotspot tier1 has passed both on my board and qemu, and `vmTestbase/nsk/stress` tests failed before have passed as well. > The test process on the board is slow and I am testing the remaining but I consider this as ready for review. > > Best, > Xiaolin vmTestbase/nsk/stress/jni/jnistress002.java now passes with this patch Running now full tier4:hotspot ( which includes vmTestbase), will report on results later ------------- PR: https://git.openjdk.org/jdk/pull/10095 From yadongwang at openjdk.org Thu Sep 1 07:12:10 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Thu, 1 Sep 2022 07:12:10 GMT Subject: RFR: 8293100: RISC-V: Need to save and restore callee-saved FloatRegisters in StubGenerator::generate_call_stub In-Reply-To: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> References: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> Message-ID: <8xwUe1CstsdcgZ4n-VOcrWNKosrMDBh-lg99iuQVBG8=.9105c830-152d-4c67-bf90-a091b3bd6826@github.com> On Wed, 31 Aug 2022 08:47:50 GMT, Xiaolin Zheng wrote: > Hi team, > > 1. Tests described in JDK-8293100 are failed, for callee-saved float registers used in C++ code are observed being killed after entering the Java world since callee-saved float registers are unfortunately missed to be saved in `StubGenerator::generate_call_stub()`. So the phenomenon presented in the failed tests seems to be weird. > > 2. This patch also fixes some typos in `vmreg_riscv.cpp` when debugging the same issue: > (before) > ![140D1DC7-39AD-4D5E-ABDE-38AACB658E3F](https://user-images.githubusercontent.com/38156692/187642108-9b3c5b81-f753-4e02-8a71-1baa984f1c74.png) > This one seems not right, either; and it also gets fixed in this patch: > (after) > ![6374B608-F574-4883-9DB5-D0525BE2536A](https://user-images.githubusercontent.com/38156692/187642140-43d0647a-0ae6-4e11-951e-d90b239bd75a.png) > > 3. Also, branch nodes for float registers in OptoAssembly didn't show their destination blocks. This patch adds a little enhancement for those. > > Hotspot tier1 has passed both on my board and qemu, and `vmTestbase/nsk/stress` tests failed before have passed as well. > The test process on the board is slow and I am testing the remaining but I consider this as ready for review. > > Best, > Xiaolin lgtm(not a reviewer) ------------- Marked as reviewed by yadongwang (Author). PR: https://git.openjdk.org/jdk/pull/10095 From iklam at openjdk.org Thu Sep 1 07:16:09 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 1 Sep 2022 07:16:09 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, add assert. I am utterly confused about why we need ProtectionDomainCacheTable at all. The only interface between this class and the rest of the world is: DictionaryEntry::add_protection_domain() { WeakHandle obj = ProtectionDomainCacheTable::add_if_absent(protection_domain); // Additions and deletions hold the SystemDictionary_lock, readers are lock-free ProtectionDomainEntry* new_head = new ProtectionDomainEntry(obj, _pd_set); } (and there's code elsewhere for cleaning up this table, but that wouldn't be necessary if no one calls `add_if_absent`!). Why doesn't DictionaryEntry::add_protection_domain allocate the WeakHandle itself? I am looking at the JDK 8 code. It seems like ProtectionDomainCacheTable was needed before we had WeakHandle, so we had to do all the reference management by hand: https://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/classfile/dictionary.hpp#l137 But for today, is ProtectionDomainCacheTable a relic that can be thrown away? ------------- PR: https://git.openjdk.org/jdk/pull/10043 From iklam at openjdk.org Thu Sep 1 07:25:11 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 1 Sep 2022 07:25:11 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Thu, 1 Sep 2022 06:51:21 GMT, David Holmes wrote: >> ?Mapping to itself? is how this table works internally. I am not sure if this information is useful here. But the purpose of this table is really to keep track of all PDs that have been registered and not yet garbage collected. > > "mapping to itself" is more useful than "mapping ... to a unique Weakhandle" - which is even more of an internal implementation detail. I found the use of this table very hard to discern based on the internal use of the hashtable, as there is no real mapping operation - we simply track if a PD has been seen or not. The use of the hashtable is purely for lookup convenience - we could instead have a linked-list of PD's that we traverse for lookup. > So perhaps we drop my second sentence above, and move it to where the hashtable itself is declared? "mapping a PD to a unique Weakhandle" is not an implementation detail. It's the only useful API provided by this class: WeakHandle obj = ProtectionDomainCacheTable::add_if_absent(protection_domain); and that's the reason I question why this table is needed at all. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Thu Sep 1 07:57:14 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Sep 2022 07:57:14 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Thu, 1 Sep 2022 07:12:25 GMT, Ioi Lam wrote: > I am utterly confused about why we need ProtectionDomainCacheTable at all. It tracks whether we have seen this PD before so that `validate_protection_domain` can skip the Java upcall to `checkPackageAccess`. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Thu Sep 1 07:57:15 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Sep 2022 07:57:15 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: <6WXzI0rm-YVn2NO-wJpFokTRrihFQtSpIIoWHb7-BWA=.7ec7ea33-c104-4686-b6db-071d4c31d5ae@github.com> On Thu, 1 Sep 2022 07:23:03 GMT, Ioi Lam wrote: >> "mapping to itself" is more useful than "mapping ... to a unique Weakhandle" - which is even more of an internal implementation detail. I found the use of this table very hard to discern based on the internal use of the hashtable, as there is no real mapping operation - we simply track if a PD has been seen or not. The use of the hashtable is purely for lookup convenience - we could instead have a linked-list of PD's that we traverse for lookup. >> So perhaps we drop my second sentence above, and move it to where the hashtable itself is declared? > > "mapping a PD to a unique Weakhandle" is not an implementation detail. It's the only useful API provided by this class: > > > WeakHandle obj = ProtectionDomainCacheTable::add_if_absent(protection_domain); > > > and that's the reason I question why this table is needed at all. The fact it is a weakhandle is an implementation detail. The table simply records whether a PD (wrapped in a WeakHandle) has been seen. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From fjiang at openjdk.org Thu Sep 1 08:59:11 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 1 Sep 2022 08:59:11 GMT Subject: RFR: 8293100: RISC-V: Need to save and restore callee-saved FloatRegisters in StubGenerator::generate_call_stub In-Reply-To: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> References: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> Message-ID: On Wed, 31 Aug 2022 08:47:50 GMT, Xiaolin Zheng wrote: > Hi team, > > 1. Tests described in JDK-8293100 are failed, for callee-saved float registers used in C++ code are observed being killed after entering the Java world since callee-saved float registers are unfortunately missed to be saved in `StubGenerator::generate_call_stub()`. So the phenomenon presented in the failed tests seems to be weird. > > 2. This patch also fixes some typos in `vmreg_riscv.cpp` when debugging the same issue: > (before) > ![140D1DC7-39AD-4D5E-ABDE-38AACB658E3F](https://user-images.githubusercontent.com/38156692/187642108-9b3c5b81-f753-4e02-8a71-1baa984f1c74.png) > This one seems not right, either; and it also gets fixed in this patch: > (after) > ![6374B608-F574-4883-9DB5-D0525BE2536A](https://user-images.githubusercontent.com/38156692/187642140-43d0647a-0ae6-4e11-951e-d90b239bd75a.png) > > 3. Also, branch nodes for float registers in OptoAssembly didn't show their destination blocks. This patch adds a little enhancement for those. > > Hotspot tier1 has passed both on my board and qemu, and `vmTestbase/nsk/stress` tests failed before have passed as well. > The test process on the board is slow and I am testing the remaining but I consider this as ready for review. > > Best, > Xiaolin Looks good, with one comment. src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 131: > 129: // ... > 130: // -34 [ argument word 1 ] > 131: // -33 [ saved f27 ] <--- sp_after_call I think it's better to add some comments about saving FloatRegisters at line 124. ------------- Changes requested by fjiang (Author). PR: https://git.openjdk.org/jdk/pull/10095 From xlinzheng at openjdk.org Thu Sep 1 09:15:17 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 1 Sep 2022 09:15:17 GMT Subject: RFR: 8293100: RISC-V: Need to save and restore callee-saved FloatRegisters in StubGenerator::generate_call_stub [v2] In-Reply-To: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> References: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> Message-ID: > Hi team, > > 1. Tests described in JDK-8293100 are failed, for callee-saved float registers used in C++ code are observed being killed after entering the Java world since callee-saved float registers are unfortunately missed to be saved in `StubGenerator::generate_call_stub()`. So the phenomenon presented in the failed tests seems to be weird. > > 2. This patch also fixes some typos in `vmreg_riscv.cpp` when debugging the same issue: > (before) > ![140D1DC7-39AD-4D5E-ABDE-38AACB658E3F](https://user-images.githubusercontent.com/38156692/187642108-9b3c5b81-f753-4e02-8a71-1baa984f1c74.png) > This one seems not right, either; and it also gets fixed in this patch: > (after) > ![6374B608-F574-4883-9DB5-D0525BE2536A](https://user-images.githubusercontent.com/38156692/187642140-43d0647a-0ae6-4e11-951e-d90b239bd75a.png) > > 3. Also, branch nodes for float registers in OptoAssembly didn't show their destination blocks. This patch adds a little enhancement for those. > > Hotspot tier1 has passed both on my board and qemu, and `vmTestbase/nsk/stress` tests failed before have passed as well. > The test process on the board is slow and I am testing the remaining but I consider this as ready for review. > > Best, > Xiaolin Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: Revise comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10095/files - new: https://git.openjdk.org/jdk/pull/10095/files/bd3adac7..5e044111 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10095&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10095&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10095.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10095/head:pull/10095 PR: https://git.openjdk.org/jdk/pull/10095 From xlinzheng at openjdk.org Thu Sep 1 09:15:19 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 1 Sep 2022 09:15:19 GMT Subject: RFR: 8293100: RISC-V: Need to save and restore callee-saved FloatRegisters in StubGenerator::generate_call_stub [v2] In-Reply-To: References: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> Message-ID: On Thu, 1 Sep 2022 08:54:36 GMT, Feilong Jiang wrote: >> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: >> >> Revise comments > > src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 131: > >> 129: // ... >> 130: // -34 [ argument word 1 ] >> 131: // -33 [ saved f27 ] <--- sp_after_call > > I think it's better to add some comments about saving FloatRegisters at line 124. Thank you, always forget the comment things. Seems x9 is also missed in the comments; it is added along with f8-f9 and f18-f27 now. ------------- PR: https://git.openjdk.org/jdk/pull/10095 From mdoerr at openjdk.org Thu Sep 1 09:44:30 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 1 Sep 2022 09:44:30 GMT Subject: RFR: 8290025: Remove the Sweeper [v13] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 09:10:20 GMT, Erik ?sterlund wrote: >> When the world was still young, the sweeper was built to unload bad smelling nmethods. While it has been going through various revisions, the GCs got support for class unloading, and the need for the GCs to get rid of nmethods with a different unpleasant scent. >> >> The two systems would now compete for unloading nmethods, and the responsibility of throwing away nmethods would blur. The sweeper was still good at throwing away nmethods faster as it only needs to scan stacks, and not do a full GC. >> >> With the advent of Loom, the situation has gotten even worse. The stacks are now also in the Java heap. The sweeper is unable to throw away nmethods without the liveness analysis of a full GC, which also performs code cache unloading, but isn't allowed to actually delete nmethods due to races with the sweeper. In a way we have the worst of both worlds, where both the sweeper and GC are crippled, unable to unload nmethods without the help of the other. And there are a very large number of complicated races that the JVM needs to deal with, especially with concurrent code cache unloading not interfering with concurrent sweeping. And concurrent sweeping not interfering with the application. >> >> The sweeper cycle exposes 2 flavours of nmethods that are "dead" to the system. So whenever nmethods are used, we have to know they are not dead. But we typically don't have the tools to really know they are not dead. For example, one might think grabbing the CodeCache_lock and using an iterator that only walks is_alive() nmethods would help make sure you don't get dead nmethods in your iterator. However, that is not the case, because the CodeCache_lock can't be held across the entire zombie transition due to "reasons" that are not trivial to actually change. Because of this, code has to deal with nmethods flipping around randomly to a dead state. >> >> I propose to get out of this sad situation, by removing the sweeper. If we need a full GC anyway to remove nmethods, we might as well let the GC do everything. This removes the notion of is_zombie(), is_unloaded() and hence is_alive() from the JVM. It also removes the notion of the orthogonal but related nmethodLocker to keep nmethods around, without preventing them from dying. We instead throw away nmethods the way we throw away pretty much anything else in the unloading GC code: >> 1. Unlink >> 2. Global sync >> 3. Throw away >> 4. Profit! >> This way, if you get a reference to an nmethod, it won't go away until the next safepoint poll, and will not flip around liveness due to concurrent transitions. >> >> In the new model, we use nmethod entry barriers to keep track of the last time an nmethod was on-stack. This is then used to 1) prove that not_entrant nmethods that haven't been on-stack for an entire GC can be removed, and 2) heuristically remove nmethods that have never been called for N full GCs, where N is calculated based on code cache allocation rate, GC frequency, remaining free memory until "trouble", etc. Similar to metaspace, there is also some threshold GC trigger to start GC when the code cache is filling up, and nothing else is triggering full GCs. The threshold gets smaller as we approach a point of being uncomfortably close to code cache exhaustion. Past said point, we GC very aggressively, and you probably want a larger code cache. >> >> I have tested this in mach5 tier1-7, I have run through perf aurora with no regressions, and also run an "internal large application" to see how it scales, also with no regressions. Since testing tier1-7 a few small tweaks have been made so I am running some extra testing. >> >> I have tried to be as compatible as possible to previous sweeping related JVM flags, arguing that nothing in the flags implies whether the implementation is using a GC or a separate sweeper thread. However, the UseCodeAging flag I have obsoleted, as UseCodeCacheFlushing is the flag for deciding cold nmethods should be removed, and with the new mechanism for doing that, there is no need for UseCodeAging flag as well. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Missing PPC code I guess <240MB ReservedCodeCacheSize is relevant for people who run tiny Java apps in small containers and try to minimize all memory sizes. Some of them might observe this regression. We could reserve more space for adapters or we could try to enable SegmentedCodeCache for smaller code cache sizes as well. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From fjiang at openjdk.org Thu Sep 1 10:35:08 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 1 Sep 2022 10:35:08 GMT Subject: RFR: 8293100: RISC-V: Need to save and restore callee-saved FloatRegisters in StubGenerator::generate_call_stub [v2] In-Reply-To: References: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> Message-ID: On Thu, 1 Sep 2022 09:15:17 GMT, Xiaolin Zheng wrote: >> Hi team, >> >> 1. Tests described in JDK-8293100 are failed, for callee-saved float registers used in C++ code are observed being killed after entering the Java world since callee-saved float registers are unfortunately missed to be saved in `StubGenerator::generate_call_stub()`. So the phenomenon presented in the failed tests seems to be weird. >> >> 2. This patch also fixes some typos in `vmreg_riscv.cpp` when debugging the same issue: >> (before) >> ![140D1DC7-39AD-4D5E-ABDE-38AACB658E3F](https://user-images.githubusercontent.com/38156692/187642108-9b3c5b81-f753-4e02-8a71-1baa984f1c74.png) >> This one seems not right, either; and it also gets fixed in this patch: >> (after) >> ![6374B608-F574-4883-9DB5-D0525BE2536A](https://user-images.githubusercontent.com/38156692/187642140-43d0647a-0ae6-4e11-951e-d90b239bd75a.png) >> >> 3. Also, branch nodes for float registers in OptoAssembly didn't show their destination blocks. This patch adds a little enhancement for those. >> >> Hotspot tier1 has passed both on my board and qemu, and `vmTestbase/nsk/stress` tests failed before have passed as well. >> The test process on the board is slow and I am testing the remaining but I consider this as ready for review. >> >> Best, >> Xiaolin > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Revise comments Marked as reviewed by fjiang (Author). ------------- PR: https://git.openjdk.org/jdk/pull/10095 From aboldtch at openjdk.org Thu Sep 1 10:57:06 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 1 Sep 2022 10:57:06 GMT Subject: RFR: 8293207: Add assert to JVM_ReferenceRefersTo to clarify its API Message-ID: JVM_ReferenceRefersTo should only be used for soft/weak references and not phantom references, which has its own implementation. This is not clear from the name. `java_lang_ref_Reference::weak_referent_no_keepalive(ref_oop)` is only a valid call if `!java_lang_ref_Reference::is_phantom(ref_oop)`. Adds an assert and comment to make this clear. ------------- Commit messages: - 8293207: Add assert to JVM_ReferenceRefersTo to clarify its API Changes: https://git.openjdk.org/jdk/pull/10117/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10117&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293207 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10117.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10117/head:pull/10117 PR: https://git.openjdk.org/jdk/pull/10117 From shade at openjdk.org Thu Sep 1 11:41:30 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 1 Sep 2022 11:41:30 GMT Subject: RFR: 8293100: RISC-V: Need to save and restore callee-saved FloatRegisters in StubGenerator::generate_call_stub [v2] In-Reply-To: References: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> Message-ID: <4f6xZ_pxI00KPGS5BVGct_IWfeiwllQ-qxnA-ZQ8BhM=.23789e89-6a33-4fb5-b1e5-032b06577e59@github.com> On Thu, 1 Sep 2022 09:15:17 GMT, Xiaolin Zheng wrote: >> Hi team, >> >> 1. Tests described in JDK-8293100 are failed, for callee-saved float registers used in C++ code are observed being killed after entering the Java world since callee-saved float registers are unfortunately missed to be saved in `StubGenerator::generate_call_stub()`. So the phenomenon presented in the failed tests seems to be weird. >> >> 2. This patch also fixes some typos in `vmreg_riscv.cpp` when debugging the same issue: >> (before) >> ![140D1DC7-39AD-4D5E-ABDE-38AACB658E3F](https://user-images.githubusercontent.com/38156692/187642108-9b3c5b81-f753-4e02-8a71-1baa984f1c74.png) >> This one seems not right, either; and it also gets fixed in this patch: >> (after) >> ![6374B608-F574-4883-9DB5-D0525BE2536A](https://user-images.githubusercontent.com/38156692/187642140-43d0647a-0ae6-4e11-951e-d90b239bd75a.png) >> >> 3. Also, branch nodes for float registers in OptoAssembly didn't show their destination blocks. This patch adds a little enhancement for those. >> >> Hotspot tier1 has passed both on my board and qemu, and `vmTestbase/nsk/stress` tests failed before have passed as well. >> The test process on the board is slow and I am testing the remaining but I consider this as ready for review. >> >> Best, >> Xiaolin > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Revise comments Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10095 From coleenp at openjdk.org Thu Sep 1 12:21:24 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 1 Sep 2022 12:21:24 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, add assert. The reason we have the table is that you can have the same instance of java.security.ProtectionDomain used on multiple DictionaryEntry._pd_set lists. That is, multiple classes in the class loader data have had their loading initiated with the same protection domain, which is common. Creating WeakHandles for each is redundant and wasteful, so we want to have one WeakHandle for multiple entries to point to. The table is a place to store it. I had another version that stored the WeakHandle entries in the ClassLoaderData of the Dictionary of loaded classes that had them in their pd_set, but they had a linear lookup to determine if they were unique. We even performance tested that. In the end, I just translated the table to ResourceHashtable to make it easier to review and understand what this does. As an example, if you run hello world with the security manager allowed, you see this: java -Xlog:protectiondomain=trace -Djava.security.manager=allow -cp ~/work Hello [0.188s][trace][protectiondomain] adding protection domain for class java/lang/Object class loader: a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90} protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd set count = #1 [0.189s][trace][protectiondomain] adding protection domain for class java/lang/String class loader: a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90} protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd set count = #1 [0.189s][trace][protectiondomain] adding protection domain for class java/lang/Exception class loader: a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90} protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd set count = #1 [0.189s][trace][protectiondomain] adding protection domain for class java/lang/System class loader: a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90} protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd set count = #1 [0.189s][trace][protectiondomain] adding protection domain for class java/io/PrintStream class loader: a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90} protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd set count = #1 Hello5 Whenever we initiate loading (for example) java.lang.Object in a non bootstrap class loader with the SecureClassLoader, we pass this protection domain. Notice how the same protection domain is added to each class. In JDK8 we pointed to the oop itself which required the GC to walk the global SystemDictionary. We definitely never want that, so moved it to a table, and made several other changes to enable concurrent class unloading after that - moved the Dictionaries of loaded classes to each class loader data. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Thu Sep 1 12:25:22 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 1 Sep 2022 12:25:22 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6WXzI0rm-YVn2NO-wJpFokTRrihFQtSpIIoWHb7-BWA=.7ec7ea33-c104-4686-b6db-071d4c31d5ae@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> <6WXzI0rm-YVn2NO-wJpFokTRrihFQtSpIIoWHb7-BWA=.7ec7ea33-c104-4686-b6db-071d4c31d5ae@github.com> Message-ID: <1SP_BMq5WR8aEaDrOltFkrf3ArzSTd0yZrjt9DfIkmg=.da033eb4-8b71-4fce-a3e2-d2ec1021b6e4@github.com> On Thu, 1 Sep 2022 07:53:07 GMT, David Holmes wrote: >> "mapping a PD to a unique Weakhandle" is not an implementation detail. It's the only useful API provided by this class: >> >> >> WeakHandle obj = ProtectionDomainCacheTable::add_if_absent(protection_domain); >> >> >> and that's the reason I question why this table is needed at all. > > The fact it is a weakhandle is an implementation detail. The table simply records whether a PD (wrapped in a WeakHandle) has been seen. Since I know what this table does, either comment is fine if it helps someone understand it. The "map each PD to itself" is pretty odd to me too. How about collect each PD for fast lookup in a hashtable? The code says how it's mapped. There isn't that much code and it's easy to see how the Key is mapped. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Thu Sep 1 12:33:16 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 1 Sep 2022 12:33:16 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <1SP_BMq5WR8aEaDrOltFkrf3ArzSTd0yZrjt9DfIkmg=.da033eb4-8b71-4fce-a3e2-d2ec1021b6e4@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> <6WXzI0rm-YVn2NO-wJpFokTRrihFQtSpIIoWHb7-BWA=.7ec7ea33-c104-4686-b6db-071d4c31d5ae@github.com> <1SP_BMq5WR8aEaDrOltFkrf3ArzSTd0yZrjt9DfIkmg=.da033eb4-8b71-4fce-a3e2-d2ec1021b6e4@github.com> Message-ID: On Thu, 1 Sep 2022 12:21:30 GMT, Coleen Phillimore wrote: >> The fact it is a weakhandle is an implementation detail. The table simply records whether a PD (wrapped in a WeakHandle) has been seen. > > Since I know what this table does, either comment is fine if it helps someone understand it. > The "map each PD to itself" is pretty odd to me too. How about collect each PD for fast lookup in a hashtable? The code says how it's mapped. There isn't that much code and it's easy to see how the Key is mapped. // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are // registered by DictionaryEntry::add_protection_domain() to a unique entry. The entry // is a WeakHandle that holds the protection domain oop. or points to.... either is accurate. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From eosterlund at openjdk.org Thu Sep 1 12:39:36 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 1 Sep 2022 12:39:36 GMT Subject: RFR: 8290025: Remove the Sweeper [v13] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 09:41:34 GMT, Martin Doerr wrote: > I guess <240MB ReservedCodeCacheSize is relevant for people who run tiny Java apps in small containers and try to minimize all memory sizes. Some of them might observe this regression. We could reserve more space for adapters or we could try to enable SegmentedCodeCache for smaller code cache sizes as well. Enabling SegmentedCodeCache for smaller code cache sizes sounds like a good idea. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From stefank at openjdk.org Thu Sep 1 13:37:23 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 1 Sep 2022 13:37:23 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v9] In-Reply-To: References: Message-ID: <3PMhAJHNkpbuu4lpwMNSIZYSt9k2TeyQ2Rza3drN_xY=.76c36c51-72b9-4c13-bf30-86a51128a6a6@github.com> > Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. > > This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. > > We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. > > I'd like to suggest that we use a convention to specify what we want. This is the current proposal: > > // Guide to the suffixes used in the format specifiers for integers: > // - print the decimal value: 745565 > // _X - print as hexadecimal, without leading 0s: 0x12345 > // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 > // _H - print as hexadecimal, without 0x prefix > // _W(w) - prints w sized string with the given value right > // adjusted. Use -w to print left adjusted. > // > // Note that the PTR format specifiers print using 0x with leading zeros, > // just like the _X_0 version for integers. > > > The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. Stefan Karlsson has updated the pull request incrementally with three additional commits since the last revision: - Add gtest - Fix INTX_FORMAT_X and UINTX_FORMAT_X - Remove unintuitive _X_W versions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10042/files - new: https://git.openjdk.org/jdk/pull/10042/files/6c1cdc84..7679fdd0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=07-08 Stats: 71 lines in 3 files changed: 66 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10042.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10042/head:pull/10042 PR: https://git.openjdk.org/jdk/pull/10042 From stefank at openjdk.org Thu Sep 1 13:41:16 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 1 Sep 2022 13:41:16 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v9] In-Reply-To: <3PMhAJHNkpbuu4lpwMNSIZYSt9k2TeyQ2Rza3drN_xY=.76c36c51-72b9-4c13-bf30-86a51128a6a6@github.com> References: <3PMhAJHNkpbuu4lpwMNSIZYSt9k2TeyQ2Rza3drN_xY=.76c36c51-72b9-4c13-bf30-86a51128a6a6@github.com> Message-ID: On Thu, 1 Sep 2022 13:37:23 GMT, Stefan Karlsson wrote: >> Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. >> >> This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. >> >> We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. >> >> I'd like to suggest that we use a convention to specify what we want. This is the current proposal: >> >> // Guide to the suffixes used in the format specifiers for integers: >> // - print the decimal value: 745565 >> // _X - print as hexadecimal, without leading 0s: 0x12345 >> // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 >> // _H - print as hexadecimal, without 0x prefix >> // _W(w) - prints w sized string with the given value right >> // adjusted. Use -w to print left adjusted. >> // >> // Note that the PTR format specifiers print using 0x with leading zeros, >> // just like the _X_0 version for integers. >> >> >> The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. > > Stefan Karlsson has updated the pull request incrementally with three additional commits since the last revision: > > - Add gtest > - Fix INTX_FORMAT_X and UINTX_FORMAT_X > - Remove unintuitive _X_W versions Thanks all for the discussion. Now that we have sort-of agreed on a first version of the naming convention for these macros, I ran this through testing and created a gtest. * I found that it was very easy to abuse the _X_W versions, because: 1) The padding didn't count the 0x characters 2) Right justified specifiers caused strings like this: 0x 123 so I inlined the usage of it. * Also found that INTX_FORMAT_X/UINTX_FORMAT_X didn't convert to hex ------------- PR: https://git.openjdk.org/jdk/pull/10042 From stefank at openjdk.org Thu Sep 1 13:52:17 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 1 Sep 2022 13:52:17 GMT Subject: RFR: 8293207: Add assert to JVM_ReferenceRefersTo to clarify its API In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 10:47:50 GMT, Axel Boldt-Christmas wrote: > JVM_ReferenceRefersTo should only be used for soft/weak references and not phantom references, which has its own implementation. This is not clear from the name. `java_lang_ref_Reference::weak_referent_no_keepalive(ref_oop)` is only a valid call if `!java_lang_ref_Reference::is_phantom(ref_oop)`. > > Adds an assert and comment to make this clear. > > Testing: Oracle platforms tier 1-3 Marked as reviewed by stefank (Reviewer). src/hotspot/share/prims/jvm.cpp line 3286: > 3284: oop ref_oop = JNIHandles::resolve_non_null(ref); > 3285: // PhantomReference has it's own implementation of refersTo(). > 3286: assert(!java_lang_ref_Reference::is_phantom(ref_oop), "precondition"); Maybe this would be even clearer if it said: // PhantomReference has it's own implementation of refersTo(). See: JVM_PhantomReferenceRefersTo ------------- PR: https://git.openjdk.org/jdk/pull/10117 From bulasevich at openjdk.org Thu Sep 1 15:24:29 2022 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Thu, 1 Sep 2022 15:24:29 GMT Subject: RFR: 8290025: Remove the Sweeper [v13] In-Reply-To: References: Message-ID: <0sk_7cWnpHMOenIQMAM1oIO_56wrUF_nFmrIuabrXAU=.a30488d3-e5e8-4ac4-bc2a-5af4247f347f@github.com> On Thu, 1 Sep 2022 12:37:20 GMT, Erik ?sterlund wrote: > Enabling SegmentedCodeCache for smaller code cache sizes sounds like a good idea Moving to SegmentedCodeCache for all platforms results in a performance regression for small platforms, but I remember there were plans (@eastig?) to halve the (ReservedCodeCacheSize >= 240*M) limit. ------------- PR: https://git.openjdk.org/jdk/pull/9741 From stefank at openjdk.org Thu Sep 1 16:33:13 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 1 Sep 2022 16:33:13 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v10] In-Reply-To: References: Message-ID: > Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. > > This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. > > We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. > > I'd like to suggest that we use a convention to specify what we want. This is the current proposal: > > // Guide to the suffixes used in the format specifiers for integers: > // - print the decimal value: 745565 > // _X - print as hexadecimal, without leading 0s: 0x12345 > // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 > // _H - print as hexadecimal, without 0x prefix > // _W(w) - prints w sized string with the given value right > // adjusted. Use -w to print left adjusted. > // > // Note that the PTR format specifiers print using 0x with leading zeros, > // just like the _X_0 version for integers. > > > The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Fix gtest compilation warning ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10042/files - new: https://git.openjdk.org/jdk/pull/10042/files/7679fdd0..736b9c2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10042&range=08-09 Stats: 47 lines in 1 file changed: 0 ins; 0 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/10042.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10042/head:pull/10042 PR: https://git.openjdk.org/jdk/pull/10042 From vlivanov at openjdk.org Thu Sep 1 16:43:23 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 Sep 2022 16:43:23 GMT Subject: RFR: 8293188: x86_64: Introduce stubGenerator_x86_64.hpp [v2] In-Reply-To: References: Message-ID: <_LvEucO-0alNLU8BYjyUKtcnvC89LwCoCZSzjqjIMeU=.850eeb3b-1d86-42c4-bc50-86a4c14eac7e@github.com> > Introduce stubGenerator_x86_64.hpp and extract StubGenerator class declaration there. > > Testing: hs-tier1 - hs-tier4 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10111/files - new: https://git.openjdk.org/jdk/pull/10111/files/8e33a642..b229fce2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10111&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10111&range=00-01 Stats: 8 lines in 2 files changed: 6 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10111.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10111/head:pull/10111 PR: https://git.openjdk.org/jdk/pull/10111 From vlivanov at openjdk.org Thu Sep 1 16:43:27 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 Sep 2022 16:43:27 GMT Subject: RFR: 8293188: x86_64: Introduce stubGenerator_x86_64.hpp [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 04:52:19 GMT, David Holmes wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> update > > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 51: > >> 49: #include "jfr/support/jfrIntrinsics.hpp" >> 50: #endif >> 51: #include "stubGenerator_x86_64.hpp" > > This should be in alphabetical order prior to the conditional includes. Fixed. > src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 2: > >> 1: /* >> 2: * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. > > As the content of this file has been moved from another, the original file's copyright years should be preserved. Thanks. Fixed. > src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 24: > >> 22: * >> 23: */ >> 24: > > Do we need the usual header file include guard? Good point. Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/10111 From vlivanov at openjdk.org Thu Sep 1 16:43:28 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 Sep 2022 16:43:28 GMT Subject: RFR: 8293188: x86_64: Introduce stubGenerator_x86_64.hpp [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 16:38:06 GMT, Vladimir Ivanov wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 24: >> >>> 22: * >>> 23: */ >>> 24: >> >> Do we need the usual header file include guard? > > Good point. Fixed. Good point. Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/10111 From rehn at openjdk.org Thu Sep 1 17:07:08 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 1 Sep 2022 17:07:08 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions Message-ID: Please consider, only implemented on x64/aarch64 linux/windows. On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. Passes t1-7 with option forced on, also passes t1-4 as is in this PR. ------------- Commit messages: - 8292591 - initial Changes: https://git.openjdk.org/jdk/pull/10123/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10123&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292591 Stats: 381 lines in 19 files changed: 355 ins; 0 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/10123.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10123/head:pull/10123 PR: https://git.openjdk.org/jdk/pull/10123 From erikj at openjdk.org Thu Sep 1 17:52:02 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 1 Sep 2022 17:52:02 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 16:47:58 GMT, Robbin Ehn wrote: > Please consider, only implemented on x64/aarch64 linux/windows. > > On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. > > Passes t1-7 with option forced on, also passes t1-4 as is in this PR. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/10123 From vlivanov at openjdk.org Thu Sep 1 18:01:17 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 Sep 2022 18:01:17 GMT Subject: RFR: 8293188: x86_64: Introduce stubGenerator_x86_64.hpp [v3] In-Reply-To: References: Message-ID: > Introduce stubGenerator_x86_64.hpp and extract StubGenerator class declaration there. > > Testing: hs-tier1 - hs-tier4 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: fix hs-minimal build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10111/files - new: https://git.openjdk.org/jdk/pull/10111/files/b229fce2..93b6ddee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10111&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10111&range=01-02 Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10111.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10111/head:pull/10111 PR: https://git.openjdk.org/jdk/pull/10111 From vlivanov at openjdk.org Thu Sep 1 18:02:34 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 Sep 2022 18:02:34 GMT Subject: RFR: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files Message-ID: Move code related to AES and GHASH stubs from stubGenerator_x86_64.cpp into stubGenerator_x86_64_aes.cpp and stubGenerator_x86_64_ghash.cpp respectively. Testing: hs-tier1 - hs-tier4 ------------- Depends on: https://git.openjdk.org/jdk/pull/10111 Commit messages: - update - Refactor AES and GHASH stubs. Changes: https://git.openjdk.org/jdk/pull/10124/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10124&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293230 Stats: 7523 lines in 6 files changed: 3782 ins; 3721 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/10124.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10124/head:pull/10124 PR: https://git.openjdk.org/jdk/pull/10124 From svkamath at openjdk.org Thu Sep 1 18:31:07 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Thu, 1 Sep 2022 18:31:07 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v6] In-Reply-To: References: Message-ID: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com> > 8289552: Make intrinsic conversions between bit representations of half precision values and floats Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments, updated microbenchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9781/files - new: https://git.openjdk.org/jdk/pull/9781/files/1570e244..a4bfb34a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=04-05 Stats: 47 lines in 5 files changed: 45 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9781.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781 PR: https://git.openjdk.org/jdk/pull/9781 From svkamath at openjdk.org Thu Sep 1 18:31:10 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Thu, 1 Sep 2022 18:31:10 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v5] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 03:15:52 GMT, Sandhya Viswanathan wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated copyright comment > > src/hotspot/cpu/x86/x86_64.ad line 11330: > >> 11328: ins_pipe( pipe_slow ); >> 11329: %} >> 11330: > > For HF2F, good to also add optimized rule with LoadS to benefit from vcvtph2ps memory src form of instruction. > match(Set dst (ConvHF2F ( LoadS mem))); Hi @sviswa7 , with this rule, I dont see additional performance gain. So I have not added it in the latest update. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From vlivanov at openjdk.org Thu Sep 1 18:37:05 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 Sep 2022 18:37:05 GMT Subject: RFR: 8293245: x86_64: Extract Adler32 stub implementation into stubGenerator_x86_64_adler.cpp Message-ID: Extract Adler32 stub implementation into a dedicated file (`stubGenerator_x86_64_adler.cpp`). Minor cleanups: * got rid of `updateBytesAdler32()` by manually inlining it into `generate_updateBytesAdler32()` * unified usage of `r14` as a scratch register * added 32-byte alignment for the constants Testing: hs-tier1 - hs-tier4 ------------- Depends on: https://git.openjdk.org/jdk/pull/10111 Commit messages: - Move Adler stub definitions into stubGenerator_x86_64_adler.cpp Changes: https://git.openjdk.org/jdk/pull/10126/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10126&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293245 Stats: 542 lines in 6 files changed: 268 ins; 274 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10126/head:pull/10126 PR: https://git.openjdk.org/jdk/pull/10126 From kvn at openjdk.org Thu Sep 1 19:14:07 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 Sep 2022 19:14:07 GMT Subject: RFR: 8293188: x86_64: Introduce stubGenerator_x86_64.hpp [v3] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 18:01:17 GMT, Vladimir Ivanov wrote: >> Introduce stubGenerator_x86_64.hpp and extract StubGenerator class declaration there. >> >> Testing: hs-tier1 - hs-tier4 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > fix hs-minimal build Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10111 From kvn at openjdk.org Thu Sep 1 19:22:41 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 Sep 2022 19:22:41 GMT Subject: RFR: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 17:11:20 GMT, Vladimir Ivanov wrote: > Move code related to AES and GHASH stubs from stubGenerator_x86_64.cpp into stubGenerator_x86_64_aes.cpp and stubGenerator_x86_64_ghash.cpp respectively. > > Testing: hs-tier1 - hs-tier4 What about stubGenerator_x86_32.cpp? It also has AES intrinsic code. src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 279: > 277: enum { > 278: AESBlockSize = 16 > 279: }; Why it is not in new `aes` file? ------------- PR: https://git.openjdk.org/jdk/pull/10124 From kvn at openjdk.org Thu Sep 1 19:25:08 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 Sep 2022 19:25:08 GMT Subject: RFR: 8293245: x86_64: Extract Adler32 stub implementation into stubGenerator_x86_64_adler.cpp In-Reply-To: References: Message-ID: <3SQSSJiRIZsbpT452LEH64KOwtDyiXfalJYmGq7FenM=.b2931fd4-8b87-4a54-8a16-6ce7b60f2150@github.com> On Thu, 1 Sep 2022 18:19:06 GMT, Vladimir Ivanov wrote: > Extract Adler32 stub implementation into a dedicated file (`stubGenerator_x86_64_adler.cpp`). > > Minor cleanups: > * got rid of `updateBytesAdler32()` by manually inlining it into `generate_updateBytesAdler32()` > * unified usage of `r14` as a scratch register > * added 32-byte alignment for the constants > > Testing: hs-tier1 - hs-tier4 Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10126 From kvn at openjdk.org Thu Sep 1 19:34:13 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 Sep 2022 19:34:13 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v6] In-Reply-To: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com> References: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com> Message-ID: On Thu, 1 Sep 2022 18:31:07 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments, updated microbenchmark Thank you for adding JMH benchmarks and data. I submitted testing. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From cjplummer at openjdk.org Thu Sep 1 19:48:25 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 19:48:25 GMT Subject: RFR: 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:47:05 GMT, Serguei Spitsyn wrote: > The problem is that the following assert in the JvmtiExport::post_object_free is wrong: > ` assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE), "checking");` > > Even though the condition was checked before, it can be changed later as it is racy by JVM TI design. > It has to be replaced with the check: > > if (!env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { > return; // the event type has been already disabled > } > > > In progress: mach5 nsk.jvmti and nsk.jdi test runs. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10109 From heidinga at openjdk.org Thu Sep 1 19:52:02 2022 From: heidinga at openjdk.org (Dan Heidinga) Date: Thu, 1 Sep 2022 19:52:02 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> Message-ID: On Tue, 30 Aug 2022 23:48:07 GMT, Ashutosh Mehra wrote: >> Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode. >> >> Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier. >> >> Testing with fastdebug build: >> >> - [x] hotspot_loom >> - [x] jdk_loom >> - [x] hotspot_loom in Shenandoah IU mode >> - [x] jdk_loom in Shenandoah IU mode >> - [x] hotspot_loom in Shenandoah IU + aggressive >> - [x] jdk_loom in Shenandoah IU + aggressive >> >> Signed-off-by: Ashutosh Mehra > > @fisk @rkennke if these changes look good, I will close the previous [PR](https://github.com/openjdk/jdk/pull/9982). @ashu-mehra I opened https://bugs.openjdk.org/browse/JDK-8293252 for the ThreadMXBean crashes mentioned in https://github.com/openjdk/jdk/pull/10089#issuecomment-1232283744 ------------- PR: https://git.openjdk.org/jdk/pull/10089 From zgu at openjdk.org Thu Sep 1 20:14:10 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 1 Sep 2022 20:14:10 GMT Subject: RFR: 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:47:05 GMT, Serguei Spitsyn wrote: > The problem is that the following assert in the JvmtiExport::post_object_free is wrong: > ` assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE), "checking");` > > Even though the condition was checked before, it can be changed later as it is racy by JVM TI design. > It has to be replaced with the check: > > if (!env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { > return; // the event type has been already disabled > } > > > In progress: mach5 nsk.jvmti and nsk.jdi test runs. Looks good. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.org/jdk/pull/10109 From dlong at openjdk.org Thu Sep 1 20:21:04 2022 From: dlong at openjdk.org (Dean Long) Date: Thu, 1 Sep 2022 20:21:04 GMT Subject: RFR: 8293245: x86_64: Extract Adler32 stub implementation into stubGenerator_x86_64_adler.cpp In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 18:19:06 GMT, Vladimir Ivanov wrote: > Extract Adler32 stub implementation into a dedicated file (`stubGenerator_x86_64_adler.cpp`). > > Minor cleanups: > * got rid of `updateBytesAdler32()` by manually inlining it into `generate_updateBytesAdler32()` > * unified usage of `r14` as a scratch register > * added 32-byte alignment for the constants > > Testing: hs-tier1 - hs-tier4 Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10126 From kvn at openjdk.org Thu Sep 1 20:21:29 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 Sep 2022 20:21:29 GMT Subject: RFR: 8292584: assert(cb != __null) failed: must be with -XX:-Inline [v6] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 03:02:50 GMT, Dean Long wrote: >> generate_Continuation_doYield_entry() creates an interpreter entry point, but jumps to a compiled stub, which needs to be walkable. The interpreter entry does not create an interpreter frame, so frame walking expects a compiled frame. Normally everything is OK, but if C1 does not inline the intrinsic and we get to the interpreter entry through the c2i adapter, then things can break if the c2i adapter padded the stack because of alignment. The easiest fix is to undo what the c2i adapter might have done. > > Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - merge fix > - Merge master > - fix build failures > - fix zero build > - cleanup > - fix failed assert > - version 2, make doYield a native intrinsic like enterSpecial > - fix generate_Continuation_doYield_entry Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9974 From dlong at openjdk.org Thu Sep 1 20:21:29 2022 From: dlong at openjdk.org (Dean Long) Date: Thu, 1 Sep 2022 20:21:29 GMT Subject: RFR: 8292584: assert(cb != __null) failed: must be with -XX:-Inline [v6] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 03:02:50 GMT, Dean Long wrote: >> generate_Continuation_doYield_entry() creates an interpreter entry point, but jumps to a compiled stub, which needs to be walkable. The interpreter entry does not create an interpreter frame, so frame walking expects a compiled frame. Normally everything is OK, but if C1 does not inline the intrinsic and we get to the interpreter entry through the c2i adapter, then things can break if the c2i adapter padded the stack because of alignment. The easiest fix is to undo what the c2i adapter might have done. > > Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - merge fix > - Merge master > - fix build failures > - fix zero build > - cleanup > - fix failed assert > - version 2, make doYield a native intrinsic like enterSpecial > - fix generate_Continuation_doYield_entry Thanks Vladimir. ------------- PR: https://git.openjdk.org/jdk/pull/9974 From dlong at openjdk.org Thu Sep 1 20:22:48 2022 From: dlong at openjdk.org (Dean Long) Date: Thu, 1 Sep 2022 20:22:48 GMT Subject: Integrated: 8292584: assert(cb != __null) failed: must be with -XX:-Inline In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 06:53:36 GMT, Dean Long wrote: > generate_Continuation_doYield_entry() creates an interpreter entry point, but jumps to a compiled stub, which needs to be walkable. The interpreter entry does not create an interpreter frame, so frame walking expects a compiled frame. Normally everything is OK, but if C1 does not inline the intrinsic and we get to the interpreter entry through the c2i adapter, then things can break if the c2i adapter padded the stack because of alignment. The easiest fix is to undo what the c2i adapter might have done. This pull request has now been integrated. Changeset: fa68371b Author: Dean Long URL: https://git.openjdk.org/jdk/commit/fa68371bb816d797da02e51187955044f835d402 Stats: 586 lines in 48 files changed: 194 ins; 340 del; 52 mod 8292584: assert(cb != __null) failed: must be with -XX:-Inline Reviewed-by: kvn, rpressler ------------- PR: https://git.openjdk.org/jdk/pull/9974 From kvn at openjdk.org Thu Sep 1 20:26:11 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 Sep 2022 20:26:11 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v6] In-Reply-To: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com> References: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com> Message-ID: On Thu, 1 Sep 2022 18:31:07 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments, updated microbenchmark Looks like it is not ready. My JDK builds failed: Exception in thread "main" java.nio.file.NoSuchFileException: /workspace/closed/src/jdk.compiler/share/data/symbols/../../../../../../open/src/jdk.compiler/share/data/symbols/java.base-7.sym.txt at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) Also some compilers complain about missing parentheses in lines 482, 487, 488, 489, 522: src/hotspot/share/runtime/sharedRuntime.cpp:482:31: note: place parentheses around the '&' expression to silence this warning jint f_signif_bits = doppel & 0x007fffff | msb; ------------- PR: https://git.openjdk.org/jdk/pull/9781 From psandoz at openjdk.org Thu Sep 1 20:38:12 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 1 Sep 2022 20:38:12 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v6] In-Reply-To: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com> References: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com> Message-ID: On Thu, 1 Sep 2022 18:31:07 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments, updated microbenchmark Likely requires a merge with master. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From darcy at openjdk.org Thu Sep 1 20:44:27 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Sep 2022 20:44:27 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v6] In-Reply-To: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com> References: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com> Message-ID: On Thu, 1 Sep 2022 18:31:07 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments, updated microbenchmark Yes; I removed support for --release 7 in JDK 20 early today. On Thu, Sep 1, 2022 at 1:36 PM Paul Sandoz ***@***.***> wrote: > Likely requires a merge with master. > > ? > Reply to this email directly, view it on GitHub > , or > unsubscribe > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > ------------- PR: https://git.openjdk.org/jdk/pull/9781 From vlivanov at openjdk.org Thu Sep 1 20:52:11 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 Sep 2022 20:52:11 GMT Subject: RFR: 8293254: x86_64: Extract arraycopy stub implementations into a separate file Message-ID: <1_CR20VVro8dAulbOEksXBiQ50Jt5jbMpc2vXFyV6xw=.ab22694f-db1b-43fd-8f69-e2eff89c5f85@github.com> Move arraycopy stub implementations from `stubGenerator_x86_64.cpp` into `stubGenerator_x86_64_arraycopy.cpp`. Testing: hs-tier1 - hs-tier4 PS: FTR I left `MacroAssembler::generate_fill_avx3()` intact because it is called from `MacroAssembler::generate_fill()` which is shared between x86_64 and x86_32. Otherwise, I would either need to copy `MacroAssembler::generate_fill()` or put it into a separate file (e.g., `stubGenerator_x86.cpp` or `stubGenerator_x86_arraycopy.cpp`). IMO it doesn't add much value compared to keeping it in `macroAssembler_x86.cpp`. ------------- Depends on: https://git.openjdk.org/jdk/pull/10111 Commit messages: - arraycopy stubs Changes: https://git.openjdk.org/jdk/pull/10128/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10128&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293254 Stats: 5127 lines in 5 files changed: 2576 ins; 2550 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10128.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10128/head:pull/10128 PR: https://git.openjdk.org/jdk/pull/10128 From kbarrett at openjdk.org Thu Sep 1 21:21:21 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 1 Sep 2022 21:21:21 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v5] In-Reply-To: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com> References: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com> Message-ID: On Mon, 29 Aug 2022 08:47:31 GMT, Johan Sj?l?n wrote: >> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? >> >> This PR does 3 things: >> >> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot >> * Adds some new utilities for writing multi-threaded tests. >> * Adds some tests for MRSW Mutex using these new utilities >> >> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 >> >> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Review comments I don't expect this to be a popular opinion, but the more I think about it the less I like the direct use of PlatformMonitor here rather than using Monitor. The "extra cruft" that comes with Monitor is there for reasons, and I'm not convinced that bypassing all that is good. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From kvn at openjdk.org Thu Sep 1 21:21:28 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 Sep 2022 21:21:28 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v6] In-Reply-To: References: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com> Message-ID: On Thu, 1 Sep 2022 20:40:35 GMT, Joe Darcy wrote: > Yes; I removed support for --release 7 in JDK 20 early today. Yes, I missed that my merge of master did not apply because I modified tests, Joe fixed, to test his changes. Resubmitting testing after resolving the issue. Still missed parentheses issue should be fixed. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From lmesnik at openjdk.org Thu Sep 1 21:22:52 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 1 Sep 2022 21:22:52 GMT Subject: RFR: 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:47:05 GMT, Serguei Spitsyn wrote: > The problem is that the following assert in the JvmtiExport::post_object_free is wrong: > ` assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE), "checking");` > > Even though the condition was checked before, it can be changed later as it is racy by JVM TI design. > It has to be replaced with the check: > > if (!env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { > return; // the event type has been already disabled > } > > > In progress: mach5 nsk.jvmti and nsk.jdi test runs. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10109 From vlivanov at openjdk.org Thu Sep 1 21:27:32 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 Sep 2022 21:27:32 GMT Subject: RFR: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 19:19:56 GMT, Vladimir Kozlov wrote: > What about stubGenerator_x86_32.cpp? It also has AES intrinsic code. This PR is self-contained and deliberately focused on x86-64. I don't have ability to test x86-32 changes, but if anybody wants to contribute a patch covering `stubGenerator_x86_32.cpp`, I'll be more than happy to incorporate it. ------------- PR: https://git.openjdk.org/jdk/pull/10124 From dlong at openjdk.org Thu Sep 1 21:29:29 2022 From: dlong at openjdk.org (Dean Long) Date: Thu, 1 Sep 2022 21:29:29 GMT Subject: RFR: 8293254: x86_64: Extract arraycopy stub implementations into a separate file In-Reply-To: <1_CR20VVro8dAulbOEksXBiQ50Jt5jbMpc2vXFyV6xw=.ab22694f-db1b-43fd-8f69-e2eff89c5f85@github.com> References: <1_CR20VVro8dAulbOEksXBiQ50Jt5jbMpc2vXFyV6xw=.ab22694f-db1b-43fd-8f69-e2eff89c5f85@github.com> Message-ID: On Thu, 1 Sep 2022 20:30:37 GMT, Vladimir Ivanov wrote: > Move arraycopy stub implementations from `stubGenerator_x86_64.cpp` into `stubGenerator_x86_64_arraycopy.cpp`. > > Testing: hs-tier1 - hs-tier4 > > PS: FTR I left `MacroAssembler::generate_fill_avx3()` intact because it is called from `MacroAssembler::generate_fill()` which is shared between x86_64 and x86_32. Otherwise, I would either need to copy `MacroAssembler::generate_fill()` or put it into a separate file (e.g., `stubGenerator_x86.cpp` or `stubGenerator_x86_arraycopy.cpp`). IMO it doesn't add much value compared to keeping it in `macroAssembler_x86.cpp`. It seems OK, assuming there are no hidden changes, just cut and paste plus renames and adding "__ ". Considering the number of lines changes, it would be hard for a reviewer to check all the lines without effectively reproducing all the steps. ------------- Marked as reviewed by dlong (Reviewer). PR: https://git.openjdk.org/jdk/pull/10128 From kvn at openjdk.org Thu Sep 1 21:29:30 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 Sep 2022 21:29:30 GMT Subject: RFR: 8293254: x86_64: Extract arraycopy stub implementations into a separate file In-Reply-To: <1_CR20VVro8dAulbOEksXBiQ50Jt5jbMpc2vXFyV6xw=.ab22694f-db1b-43fd-8f69-e2eff89c5f85@github.com> References: <1_CR20VVro8dAulbOEksXBiQ50Jt5jbMpc2vXFyV6xw=.ab22694f-db1b-43fd-8f69-e2eff89c5f85@github.com> Message-ID: On Thu, 1 Sep 2022 20:30:37 GMT, Vladimir Ivanov wrote: > Move arraycopy stub implementations from `stubGenerator_x86_64.cpp` into `stubGenerator_x86_64_arraycopy.cpp`. > > Testing: hs-tier1 - hs-tier4 > > PS: FTR I left `MacroAssembler::generate_fill_avx3()` intact because it is called from `MacroAssembler::generate_fill()` which is shared between x86_64 and x86_32. Otherwise, I would either need to copy `MacroAssembler::generate_fill()` or put it into a separate file (e.g., `stubGenerator_x86.cpp` or `stubGenerator_x86_arraycopy.cpp`). IMO it doesn't add much value compared to keeping it in `macroAssembler_x86.cpp`. Good. I agree with you about not moving `generate_fill_avx3`. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10128 From vlivanov at openjdk.org Thu Sep 1 21:34:09 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 Sep 2022 21:34:09 GMT Subject: RFR: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 19:19:07 GMT, Vladimir Kozlov wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> AESBlockSize > > src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 279: > >> 277: enum { >> 278: AESBlockSize = 16 >> 279: }; > > Why it is not in new `aes` file? Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/10124 From vlivanov at openjdk.org Thu Sep 1 21:34:06 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 Sep 2022 21:34:06 GMT Subject: RFR: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files [v2] In-Reply-To: References: Message-ID: <2CCgZ9uVr3bRAMy0IhobEdsiZE_uX8v_UC-ipQ1_tqA=.e6ea7807-4b6c-4d2d-ad72-127db467dfae@github.com> > Move code related to AES and GHASH stubs from stubGenerator_x86_64.cpp into stubGenerator_x86_64_aes.cpp and stubGenerator_x86_64_ghash.cpp respectively. > > Testing: hs-tier1 - hs-tier4 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: AESBlockSize ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10124/files - new: https://git.openjdk.org/jdk/pull/10124/files/89cddeb6..7c0cb35c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10124&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10124&range=00-01 Stats: 6 lines in 2 files changed: 2 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10124.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10124/head:pull/10124 PR: https://git.openjdk.org/jdk/pull/10124 From kvn at openjdk.org Thu Sep 1 21:38:43 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 Sep 2022 21:38:43 GMT Subject: RFR: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files [v2] In-Reply-To: <2CCgZ9uVr3bRAMy0IhobEdsiZE_uX8v_UC-ipQ1_tqA=.e6ea7807-4b6c-4d2d-ad72-127db467dfae@github.com> References: <2CCgZ9uVr3bRAMy0IhobEdsiZE_uX8v_UC-ipQ1_tqA=.e6ea7807-4b6c-4d2d-ad72-127db467dfae@github.com> Message-ID: <4OqV-3gAmLIRzYXBNj4LcxyvwnzhFmzW_6DNsQds30M=.92283b2d-d0f7-4647-a1bc-bc94849d6a4c@github.com> On Thu, 1 Sep 2022 21:34:06 GMT, Vladimir Ivanov wrote: >> Move code related to AES and GHASH stubs from stubGenerator_x86_64.cpp into stubGenerator_x86_64_aes.cpp and stubGenerator_x86_64_ghash.cpp respectively. >> >> Testing: hs-tier1 - hs-tier4 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > AESBlockSize Good. @iwanowww I noticed that your repo do not have GitHub actions testing. Please, switch it on. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10124 From kvn at openjdk.org Thu Sep 1 21:38:47 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 Sep 2022 21:38:47 GMT Subject: RFR: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 21:25:10 GMT, Vladimir Ivanov wrote: > > What about stubGenerator_x86_32.cpp? It also has AES intrinsic code. > > This PR is self-contained and deliberately focused on x86-64. I don't have ability to test x86-32 changes, but if anybody wants to contribute a patch covering `stubGenerator_x86_32.cpp`, I'll be more than happy to incorporate it. I thought `macroAssembler_x86_aes.cpp` had both implementations. I was wrong. ------------- PR: https://git.openjdk.org/jdk/pull/10124 From vlivanov at openjdk.org Thu Sep 1 21:40:28 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 Sep 2022 21:40:28 GMT Subject: RFR: 8293254: x86_64: Extract arraycopy stub implementations into a separate file In-Reply-To: References: <1_CR20VVro8dAulbOEksXBiQ50Jt5jbMpc2vXFyV6xw=.ab22694f-db1b-43fd-8f69-e2eff89c5f85@github.com> Message-ID: On Thu, 1 Sep 2022 21:23:58 GMT, Dean Long wrote: > It seems OK, assuming there are no hidden changes, just cut and paste plus renames and adding "__ " Yes. Except some additional formatting, it's copy-pasted code with "__" sprinkled where methods on `MacroAssembler` are invoked. ------------- PR: https://git.openjdk.org/jdk/pull/10128 From kbarrett at openjdk.org Thu Sep 1 22:13:15 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 1 Sep 2022 22:13:15 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v10] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 16:33:13 GMT, Stefan Karlsson wrote: >> Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. >> >> This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. >> >> We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. >> >> I'd like to suggest that we use a convention to specify what we want. This is the current proposal: >> >> // Guide to the suffixes used in the format specifiers for integers: >> // - print the decimal value: 745565 >> // _X - print as hexadecimal, without leading 0s: 0x12345 >> // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 >> // _H - print as hexadecimal, without 0x prefix >> // _W(w) - prints w sized string with the given value right >> // adjusted. Use -w to print left adjusted. >> // >> // Note that the PTR format specifiers print using 0x with leading zeros, >> // just like the _X_0 version for integers. >> >> >> The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Fix gtest compilation warning Thanks for adding a gtest. One new comment that you can do whatever you want with. src/hotspot/share/cds/filemap.cpp line 1556: > 1554: if (size > 0) { > 1555: log_info(cds)("Shared file region (%-3s) %d: " SIZE_FORMAT_W(8) > 1556: " bytes, addr " INTPTR_FORMAT " file offset 0x%08" PRIxPTR If not using one of our FORMAT macros for this one-off place, I think "0x%08zx" is shorter and at least as understandable as using of one of the PRI macros (whose meanings I can never remember, and whose very existence I tend to forget, but maybe that's just me). But really, I wonder what the point of the field width is here? Why isn't this just SIZE_FORMAT_X? Alternatively, maybe SIZE_FORMAT_X_W should be SIZE_FORMAT_X_0_W? ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/10042 From vlivanov at openjdk.org Thu Sep 1 23:21:02 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 Sep 2022 23:21:02 GMT Subject: RFR: 8293188: x86_64: Introduce stubGenerator_x86_64.hpp [v4] In-Reply-To: References: Message-ID: > Introduce stubGenerator_x86_64.hpp and extract StubGenerator class declaration there. > > Testing: hs-tier1 - hs-tier4 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: RuntimeStub ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10111/files - new: https://git.openjdk.org/jdk/pull/10111/files/93b6ddee..31a8683f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10111&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10111&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10111.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10111/head:pull/10111 PR: https://git.openjdk.org/jdk/pull/10111 From svkamath at openjdk.org Thu Sep 1 23:22:46 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Thu, 1 Sep 2022 23:22:46 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v7] In-Reply-To: References: Message-ID: <6VkHnbPePwUy3s-i63Wgcxuf60z7MpHtpD2BT4q1I38=.4f5e812c-1198-4be4-8b11-ccd738773fdd@github.com> > 8289552: Make intrinsic conversions between bit representations of half precision values and floats Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Added missing parantheses ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9781/files - new: https://git.openjdk.org/jdk/pull/9781/files/a4bfb34a..cc22a401 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=05-06 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9781.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781 PR: https://git.openjdk.org/jdk/pull/9781 From vlivanov at openjdk.org Thu Sep 1 23:48:08 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 Sep 2022 23:48:08 GMT Subject: RFR: 8293188: x86_64: Introduce stubGenerator_x86_64.hpp [v5] In-Reply-To: References: Message-ID: > Introduce stubGenerator_x86_64.hpp and extract StubGenerator class declaration there. > > Testing: hs-tier1 - hs-tier4 Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - update - Merge branch 'master' into stub.x86_64.hpp - RuntimeStub - fix hs-minimal build - update - fix - stubGenerator_x86_64.hpp ------------- Changes: https://git.openjdk.org/jdk/pull/10111/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10111&range=04 Stats: 11051 lines in 2 files changed: 3926 ins; 3441 del; 3684 mod Patch: https://git.openjdk.org/jdk/pull/10111.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10111/head:pull/10111 PR: https://git.openjdk.org/jdk/pull/10111 From sviswanathan at openjdk.org Thu Sep 1 23:48:51 2022 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 1 Sep 2022 23:48:51 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v7] In-Reply-To: <6VkHnbPePwUy3s-i63Wgcxuf60z7MpHtpD2BT4q1I38=.4f5e812c-1198-4be4-8b11-ccd738773fdd@github.com> References: <6VkHnbPePwUy3s-i63Wgcxuf60z7MpHtpD2BT4q1I38=.4f5e812c-1198-4be4-8b11-ccd738773fdd@github.com> Message-ID: On Thu, 1 Sep 2022 23:22:46 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Added missing parantheses Some minor naming/formatting comments. Rest of the patch looks good to me. src/hotspot/share/runtime/sharedRuntime.cpp line 487: > 485: jshort signif_bits = (jshort)(f_signif_bits >> (13 + exp_delta)); > 486: > 487: jint lsb = (f_signif_bits & (1 << 13 + exp_delta)); It will be more clear to have the parenthesis like this: jint lsb = f_signif_bits & (1 << (13 + exp_delta)); src/hotspot/share/runtime/sharedRuntime.cpp line 522: > 520: > 521: // Add the bias of float exponent and shift > 522: int float_exp_bits = ((hf_exp + 127) << 24 - 1); It will be more clear to have the parenthesis like this: int float_exp_bits = (hf_exp + 127) << (24 - 1); May be we should refer to src/java.base/share/classes/java/lang/Float.java:floatToFloat16 and Float16toFloat in comments. src/hotspot/share/runtime/sharedRuntime.cpp line 525: > 523: > 524: // Combine sign, exponent and significand bits > 525: return (jfloat) ((hf_sign_bit << 16) | float_exp_bits | (hf_significand_bits << significand_shift)); You could call SharedRuntime::i2f here as well to be consistent to line 517. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From sviswanathan at openjdk.org Thu Sep 1 23:48:54 2022 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 1 Sep 2022 23:48:54 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v6] In-Reply-To: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com> References: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com> Message-ID: On Thu, 1 Sep 2022 18:31:07 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments, updated microbenchmark src/hotspot/cpu/x86/assembler_x86.cpp line 1931: > 1929: } > 1930: > 1931: void Assembler::vcvtps2ph(Address dst, KRegister mask, XMMRegister src, int imm8, int vector_len) { This could be named as evcvtps2ph as the instruction with mask register is evex only. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From sviswanathan at openjdk.org Thu Sep 1 23:48:57 2022 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 1 Sep 2022 23:48:57 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v5] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 18:26:52 GMT, Smita Kamath wrote: >> src/hotspot/cpu/x86/x86_64.ad line 11330: >> >>> 11328: ins_pipe( pipe_slow ); >>> 11329: %} >>> 11330: >> >> For HF2F, good to also add optimized rule with LoadS to benefit from vcvtph2ps memory src form of instruction. >> match(Set dst (ConvHF2F ( LoadS mem))); > > Hi @sviswa7 , with this rule, I dont see additional performance gain. So I have not added it in the latest update. ok, sounds good. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From jrose at openjdk.org Fri Sep 2 00:00:16 2022 From: jrose at openjdk.org (John R Rose) Date: Fri, 2 Sep 2022 00:00:16 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file Message-ID: Refactor code from inside of CompressedStream into its own unit. This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). Add gtests. ------------- Commit messages: - 8292758: put support for UNSIGNED5 format into its own header file Changes: https://git.openjdk.org/jdk/pull/10067/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292758 Stats: 935 lines in 8 files changed: 797 ins; 93 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/10067.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10067/head:pull/10067 PR: https://git.openjdk.org/jdk/pull/10067 From jrose at openjdk.org Fri Sep 2 00:00:16 2022 From: jrose at openjdk.org (John R Rose) Date: Fri, 2 Sep 2022 00:00:16 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 18:20:42 GMT, John R Rose wrote: > Refactor code from inside of CompressedStream into its own unit. > > This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). > > Add gtests. This code passes tiers 1,2,3. ------------- PR: https://git.openjdk.org/jdk/pull/10067 From jrose at openjdk.org Fri Sep 2 00:04:17 2022 From: jrose at openjdk.org (John R Rose) Date: Fri, 2 Sep 2022 00:04:17 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: References: Message-ID: > Refactor code from inside of CompressedStream into its own unit. > > This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). > > Add gtests. John R Rose 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 branch 'master' of https://git.openjdk.org/jdk into compressed-stream - 8292758: put support for UNSIGNED5 format into its own header file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10067/files - new: https://git.openjdk.org/jdk/pull/10067/files/e938b018..d903f2c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=00-01 Stats: 9272 lines in 306 files changed: 2846 ins; 5909 del; 517 mod Patch: https://git.openjdk.org/jdk/pull/10067.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10067/head:pull/10067 PR: https://git.openjdk.org/jdk/pull/10067 From jrose at openjdk.org Fri Sep 2 00:08:09 2022 From: jrose at openjdk.org (John R Rose) Date: Fri, 2 Sep 2022 00:08:09 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 00:04:17 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose 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 branch 'master' of https://git.openjdk.org/jdk into compressed-stream > - 8292758: put support for UNSIGNED5 format into its own header file The new header file presents the encoding algorithm by means of templates. The template arguments in general are: - `ARY` - a logical base address for reads and writes of bytes - `OFF` - an integral type (of any size or signed-ness) providing an offset to `ARY` - `GET` and `SET` - function-like arguments (e.g., lambdas) which get or set bytes from an address logically of the form `a[i]` shaped like `ARY[OFF]` - `GFN` a lambda used when the application requires on-the fly resizing of an output buffer (of type `ARY`) Defaults are set in such a way that any C++ types that natively support `a[i]` can be fully inferred, including the get/set behaviors. In addition, there are small "gadgets" for reading a series of ints from a buffer, writing a series to a buffer, and sizing a series (which is faster than writing or reading). These are not yet used. However, prototyping of further use cases for this compression (particularly, `FieldInfo`) makes it clear that these are repeated tasks that "canned" templates will help with. ------------- PR: https://git.openjdk.org/jdk/pull/10067 From kbarrett at openjdk.org Fri Sep 2 00:16:47 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 2 Sep 2022 00:16:47 GMT Subject: RFR: 8293207: Add assert to JVM_ReferenceRefersTo to clarify its API In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 10:47:50 GMT, Axel Boldt-Christmas wrote: > JVM_ReferenceRefersTo should only be used for soft/weak references and not phantom references, which has its own implementation. This is not clear from the name. `java_lang_ref_Reference::weak_referent_no_keepalive(ref_oop)` is only a valid call if `!java_lang_ref_Reference::is_phantom(ref_oop)`. > > Adds an assert and comment to make this clear. > > Testing: Oracle platforms tier 1-3 Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/10117 From kbarrett at openjdk.org Fri Sep 2 00:24:42 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 2 Sep 2022 00:24:42 GMT Subject: RFR: 8293207: Add assert to JVM_ReferenceRefersTo to clarify its API In-Reply-To: References: Message-ID: <-eHezoFZOpUd8iPzDWCnn7hJqW1_88KVCHGZDTlpPvw=.9dfb5b24-9754-43ed-84c3-68e66a076216@github.com> On Thu, 1 Sep 2022 10:47:50 GMT, Axel Boldt-Christmas wrote: > JVM_ReferenceRefersTo should only be used for soft/weak references and not phantom references, which has its own implementation. This is not clear from the name. `java_lang_ref_Reference::weak_referent_no_keepalive(ref_oop)` is only a valid call if `!java_lang_ref_Reference::is_phantom(ref_oop)`. > > Adds an assert and comment to make this clear. > > Testing: Oracle platforms tier 1-3 src/hotspot/share/prims/jvm.cpp line 3286: > 3284: oop ref_oop = JNIHandles::resolve_non_null(ref); > 3285: // PhantomReference has it's own implementation of refersTo(). > 3286: assert(!java_lang_ref_Reference::is_phantom(ref_oop), "precondition"); Maybe instead assertions should be added to the java_lang_ref_Reference functions for accessing the referent? (weak_referent_no_keepalive, weak_referent, phantom_referent_no_keepalive) ------------- PR: https://git.openjdk.org/jdk/pull/10117 From vlivanov at openjdk.org Fri Sep 2 00:28:02 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 2 Sep 2022 00:28:02 GMT Subject: RFR: 8293285: x86_64: Move libm stub implementations to StubGenerator Message-ID: Move libm stub implementations (used for trigonometric math intrinsics) from MacroAssembler to StubGenerator. x86_32-specific code is left intact, but all `macroAssembler_x86_*.cpp` files are renamed to `macroAssembler_x86_32_*.cpp` since there's no x86_64-specific code left there anymore. Testing: hs-tier1 - hs-tier4 ------------- Depends on: https://git.openjdk.org/jdk/pull/10111 Commit messages: - Extract libm stub implementations into separate files Changes: https://git.openjdk.org/jdk/pull/10133/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10133&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293285 Stats: 23104 lines in 26 files changed: 11818 ins; 11257 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/10133.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10133/head:pull/10133 PR: https://git.openjdk.org/jdk/pull/10133 From vlivanov at openjdk.org Fri Sep 2 00:47:15 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 2 Sep 2022 00:47:15 GMT Subject: RFR: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files [v2] In-Reply-To: <4OqV-3gAmLIRzYXBNj4LcxyvwnzhFmzW_6DNsQds30M=.92283b2d-d0f7-4647-a1bc-bc94849d6a4c@github.com> References: <2CCgZ9uVr3bRAMy0IhobEdsiZE_uX8v_UC-ipQ1_tqA=.e6ea7807-4b6c-4d2d-ad72-127db467dfae@github.com> <4OqV-3gAmLIRzYXBNj4LcxyvwnzhFmzW_6DNsQds30M=.92283b2d-d0f7-4647-a1bc-bc94849d6a4c@github.com> Message-ID: On Thu, 1 Sep 2022 21:35:48 GMT, Vladimir Kozlov wrote: > I noticed that your repo do not have GitHub actions testing. Please, switch it on. @vnkozlov I don't know how it is expected to work, but right now I see there's GHA testing going on. ------------- PR: https://git.openjdk.org/jdk/pull/10124 From svkamath at openjdk.org Fri Sep 2 00:52:49 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Fri, 2 Sep 2022 00:52:49 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: References: Message-ID: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> > 8289552: Make intrinsic conversions between bit representations of half precision values and floats Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9781/files - new: https://git.openjdk.org/jdk/pull/9781/files/cc22a401..6b828e60 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=06-07 Stats: 11 lines in 4 files changed: 2 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/9781.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781 PR: https://git.openjdk.org/jdk/pull/9781 From sviswanathan at openjdk.org Fri Sep 2 00:57:33 2022 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 2 Sep 2022 00:57:33 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: <7tLBlRgmm_3A4CTKkxrx649IQdokoSPXzQAOsWBwF2A=.eeb0bb7c-276d-431a-a6cc-fdbe2c15822d@github.com> On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Marked as reviewed by sviswanathan (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9781 From sspitsyn at openjdk.org Fri Sep 2 01:15:54 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 2 Sep 2022 01:15:54 GMT Subject: RFR: 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:47:05 GMT, Serguei Spitsyn wrote: > The problem is that the following assert in the JvmtiExport::post_object_free is wrong: > ` assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE), "checking");` > > Even though the condition was checked before, it can be changed later as it is racy by JVM TI design. > It has to be replaced with the check: > > if (!env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { > return; // the event type has been already disabled > } > > > In progress: mach5 nsk.jvmti and nsk.jdi test runs. Chris, Zhengyu and Leonid, thank you for review! ------------- PR: https://git.openjdk.org/jdk/pull/10109 From dlong at openjdk.org Fri Sep 2 01:28:15 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 2 Sep 2022 01:28:15 GMT Subject: RFR: 8293287 add ReplayReduce flag Message-ID: Add an experimental flag to help developers "reduce" a replay file. As a first step, I plan to simulate reduced inlining. This will output multiple "compile" lines as if the first level of inlining never happened: A --> B --> C A --> D --> E becomes B --> C D --> E Developers can repeat iteratively until the replay crash no longer reproduces. ------------- Commit messages: - first pass at ReplayReduce Changes: https://git.openjdk.org/jdk/pull/10134/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10134&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293287 Stats: 46 lines in 8 files changed: 39 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10134.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10134/head:pull/10134 PR: https://git.openjdk.org/jdk/pull/10134 From vlivanov at openjdk.org Fri Sep 2 01:32:41 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 2 Sep 2022 01:32:41 GMT Subject: RFR: 8293188: x86_64: Introduce stubGenerator_x86_64.hpp [v5] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 23:48:08 GMT, Vladimir Ivanov wrote: >> Introduce stubGenerator_x86_64.hpp and extract StubGenerator class declaration there. >> >> Testing: hs-tier1 - hs-tier4 > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - update > - Merge branch 'master' into stub.x86_64.hpp > - RuntimeStub > - fix hs-minimal build > - update > - fix > - stubGenerator_x86_64.hpp Thanks for the reviews, David and Vladimir. > I'm assuming the motivation here was just to get smaller files to work with? Yes, I'm looking at splitting `stubGenerator_x86_64.cpp` and grouping stub implementations based on the area they belong to. ------------- PR: https://git.openjdk.org/jdk/pull/10111 From dlong at openjdk.org Fri Sep 2 01:54:45 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 2 Sep 2022 01:54:45 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: References: Message-ID: <0IH0pSQJ9vkKzJh4rYlEMTx_0X5wNbVhkXNp5p_q3cw=.a7efccaf-700c-4b53-a87c-5e9cb89abf15@github.com> On Fri, 2 Sep 2022 00:04:17 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose 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 branch 'master' of https://git.openjdk.org/jdk into compressed-stream > - 8292758: put support for UNSIGNED5 format into its own header file src/hotspot/share/code/compressedStream.cpp line 85: > 83: const int min_expansion = UNSIGNED5::MAX_LENGTH; > 84: if (nsize < min_expansion*2) > 85: nsize = min_expansion*2; It's not clear if this is needed or just an optimization. Maybe add a comment. Also, using MIN2 might be clearer. ------------- PR: https://git.openjdk.org/jdk/pull/10067 From sspitsyn at openjdk.org Fri Sep 2 02:03:48 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 2 Sep 2022 02:03:48 GMT Subject: Integrated: 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails: assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:47:05 GMT, Serguei Spitsyn wrote: > The problem is that the following assert in the JvmtiExport::post_object_free is wrong: > ` assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE), "checking");` > > Even though the condition was checked before, it can be changed later as it is racy by JVM TI design. > It has to be replaced with the check: > > if (!env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { > return; // the event type has been already disabled > } > > > In progress: mach5 nsk.jvmti and nsk.jdi test runs. This pull request has now been integrated. Changeset: 99c3ab01 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/99c3ab01773fcab885aa041345aab1a1ad4d852f Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails: assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking Reviewed-by: cjplummer, zgu, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/10109 From xlinzheng at openjdk.org Fri Sep 2 02:59:39 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Fri, 2 Sep 2022 02:59:39 GMT Subject: RFR: 8293100: RISC-V: Need to save and restore callee-saved FloatRegisters in StubGenerator::generate_call_stub In-Reply-To: <9S2DiKOSWEDrD58cX6SRNAWb5gqNIqwAVlhmzVHl3-s=.54ebc300-10b5-4810-b7a4-c89d02f1db46@github.com> References: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> <9S2DiKOSWEDrD58cX6SRNAWb5gqNIqwAVlhmzVHl3-s=.54ebc300-10b5-4810-b7a4-c89d02f1db46@github.com> Message-ID: On Thu, 1 Sep 2022 07:02:07 GMT, Vladimir Kempik wrote: > vmTestbase/nsk/stress/jni/jnistress002.java now passes with this patch Running now full tier4:hotspot ( which includes vmTestbase), will report on results later Hi Vladimir, my hotspot tier2~4 have passed. I was wondering if all's right with your hotspot tier4? ------------- PR: https://git.openjdk.org/jdk/pull/10095 From fyang at openjdk.org Fri Sep 2 03:43:04 2022 From: fyang at openjdk.org (Fei Yang) Date: Fri, 2 Sep 2022 03:43:04 GMT Subject: RFR: 8293290: RISC-V: Explicitly pass a third temp register to MacroAssembler::store_heap_oop Message-ID: Currently G1 (and Shenandoah) implicitly uses x13 in oop_store_at on riscv. This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186). This would be fixed in the same way on riscv by passing the temporary register explicitly so it is part of the GC API. Testing: Passed Tier1 test on linux-riscv64 SiFive Unmatched board. ------------- Commit messages: - 8293290: RISC-V: Explicitly pass a third temp register to MacroAssembler::store_heap_oop Changes: https://git.openjdk.org/jdk/pull/10137/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10137&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293290 Stats: 71 lines in 16 files changed: 2 ins; 0 del; 69 mod Patch: https://git.openjdk.org/jdk/pull/10137.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10137/head:pull/10137 PR: https://git.openjdk.org/jdk/pull/10137 From dholmes at openjdk.org Fri Sep 2 05:30:42 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 2 Sep 2022 05:30:42 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, add assert. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Fri Sep 2 05:30:43 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 2 Sep 2022 05:30:43 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> <6WXzI0rm-YVn2NO-wJpFokTRrihFQtSpIIoWHb7-BWA=.7ec7ea33-c104-4686-b6db-071d4c31d5ae@github.com> <1SP_BMq5WR8aEaDrOltFkrf3ArzSTd0yZrjt9DfIkmg=.da033eb4-8b71-4fce-a3e2-d2ec1021b6e4@github.com> Message-ID: On Thu, 1 Sep 2022 12:29:41 GMT, Coleen Phillimore wrote: >> Since I know what this table does, either comment is fine if it helps someone understand it. >> The "map each PD to itself" is pretty odd to me too. How about collect each PD for fast lookup in a hashtable? The code says how it's mapped. There isn't that much code and it's easy to see how the Key is mapped. > > // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are > // registered by DictionaryEntry::add_protection_domain() to a unique entry. The entry > // is a WeakHandle that holds the protection domain oop. > > or points to.... either is accurate. It is the "maps ... to a unique entry" that I find most problematic - it begs the question as to what the unique entry is, when in reality it maps a PD instance (wrapped in a WeakHandle) to itself (wrapped in a WeakHandle). For the sake of progress, approved. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From iklam at openjdk.org Fri Sep 2 05:40:20 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 2 Sep 2022 05:40:20 GMT Subject: RFR: 8293293: Move archive heap loading code out of heapShared.cpp Message-ID: I moved all code related to loading the archive heap regions into a new file, archiveHeapLoader.cpp. A diff of the new archiveHeapLoader.cpp and the old heapShared.cpp shows that the moved code is identical, except for the change of `HeapShared::` to `ArchiveHeapLoader::`. I also removed unnecessary entries in JVM_EXCLUDE_FILES that are already covered by the `cds/` pattern. ------------- Commit messages: - 8293293: Move archive heap loading code out of heapShared.cpp Changes: https://git.openjdk.org/jdk/pull/10138/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10138&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293293 Stats: 1318 lines in 19 files changed: 716 ins; 554 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/10138.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10138/head:pull/10138 PR: https://git.openjdk.org/jdk/pull/10138 From iklam at openjdk.org Fri Sep 2 05:45:42 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 2 Sep 2022 05:45:42 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, add assert. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Fri Sep 2 05:55:40 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 2 Sep 2022 05:55:40 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 16:47:58 GMT, Robbin Ehn wrote: > Please consider, only implemented on x64/aarch64 linux/windows. > > On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. > > Passes t1-7 with option forced on, also passes t1-4 as is in this PR. Can you explain the operation and placement of the system memory barriers please. It is not obvious how the elided membars are replaced with the new mechanism. "barrier-less" seems a bit of a misnomer as we're really replacing small barriers with a sledgehammer barrier in fewer places. And does this really do enough to address the JNI overhead issue versus a true transition-less mechanism? ------------- PR: https://git.openjdk.org/jdk/pull/10123 From dholmes at openjdk.org Fri Sep 2 06:23:40 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 2 Sep 2022 06:23:40 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v10] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 16:33:13 GMT, Stefan Karlsson wrote: >> Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. >> >> This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. >> >> We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. >> >> I'd like to suggest that we use a convention to specify what we want. This is the current proposal: >> >> // Guide to the suffixes used in the format specifiers for integers: >> // - print the decimal value: 745565 >> // _X - print as hexadecimal, without leading 0s: 0x12345 >> // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 >> // _H - print as hexadecimal, without 0x prefix >> // _W(w) - prints w sized string with the given value right >> // adjusted. Use -w to print left adjusted. >> // >> // Note that the PTR format specifiers print using 0x with leading zeros, >> // just like the _X_0 version for integers. >> >> >> The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Fix gtest compilation warning LGTM. Thanks. src/hotspot/share/utilities/globalDefinitions.hpp line 137: > 135: > 136: #define INTX_FORMAT "%" PRIdPTR > 137: #define INTX_FORMAT_X "0x%" PRIxPTR Oops! Good catch on the PRIx vs PRId! ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10042 From dholmes at openjdk.org Fri Sep 2 06:34:45 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 2 Sep 2022 06:34:45 GMT Subject: RFR: 8293188: x86_64: Introduce stubGenerator_x86_64.hpp [v5] In-Reply-To: References: Message-ID: <9y9YQyeFidCwdWOjI7kfnyVnPOxwSer9yeKHeHwjqmI=.b1097c88-ad3d-4933-a3b2-e03366d14ca5@github.com> On Thu, 1 Sep 2022 23:48:08 GMT, Vladimir Ivanov wrote: >> Introduce stubGenerator_x86_64.hpp and extract StubGenerator class declaration there. >> >> Testing: hs-tier1 - hs-tier4 > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - update > - Merge branch 'master' into stub.x86_64.hpp > - RuntimeStub > - fix hs-minimal build > - update > - fix > - stubGenerator_x86_64.hpp Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10111 From rehn at openjdk.org Fri Sep 2 06:40:07 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 2 Sep 2022 06:40:07 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 16:47:58 GMT, Robbin Ehn wrote: > Please consider, only implemented on x64/aarch64 linux/windows. > > On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. > > Passes t1-7 with option forced on, also passes t1-4 as is in this PR. Yes, sorry. Since we had this code before I forgot adding an explanation. This gives back around 75% of the gained performance of transitions-less JNI calls. (in one benchmark critical gives 8ns, this gave 6ns (on JDK17)) Note that is against accidentally optimized JNI critical (removal was done in steps, before the final step it was faster than the original implementation, it was never intended to make it faster). So it should be even closer the original pre-JDK 17 numbers. But note that this applies to all JNI methods, not just some special ones. For safepoints poll the Java thread do: 1: Store an unsafe thread state as indication that we are entering the VM. 2: Check if entrance into the VM can be performed safely. VM Thread (or a handshaker) do: 1: Store polling word 2: Read the thread state This must be executed in order where 1 happens before 2. store unsafe thread state store_load_barrier load poll store poll store_load_barrier load thread state This patch moves store_load_barrier to the read of the thread state by the use of system memory barrier, which make sure we get program order: "guarantee that all its running thread siblings have passed through a state where all memory accesses to user-space addresses match program order" store unsafe thread state compiler_barrier load poll store poll system_memory_barrier load thread state As you said this big hammer have downside since it always must be emitted before thread the thread state. Such as: * Using JFR sampler with short periods, or sampling many threads. * Workload with many per seconds safepoints or handshake Which means your overall performance may suffer and only a few special workloads should notice a difference at all. I have not changed all transitions to elide the store_load, since they are not performance impacting and this PR was focused on native transitions. If you think all transitions should honor this flag I can do a follow-up. ------------- PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Fri Sep 2 06:40:07 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 2 Sep 2022 06:40:07 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions In-Reply-To: References: Message-ID: <6dT5i3moVqvpNADa08OHKL2DM7uRIAhOjvPUwRVyQw0=.35ae8009-22fd-4322-8dda-80ec95cb87ea@github.com> On Thu, 1 Sep 2022 17:49:59 GMT, Erik Joelsson wrote: > Build changes look good. Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/10123 From vkempik at openjdk.org Fri Sep 2 06:41:59 2022 From: vkempik at openjdk.org (Vladimir Kempik) Date: Fri, 2 Sep 2022 06:41:59 GMT Subject: RFR: 8293100: RISC-V: Need to save and restore callee-saved FloatRegisters in StubGenerator::generate_call_stub [v2] In-Reply-To: References: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> Message-ID: <7_anjTMEtyH2gkaCMr2LA5Hxg0bg_VFd2fBBqt3zHmc=.6bb1778a-a691-4412-8d47-4248ea44c408@github.com> On Thu, 1 Sep 2022 09:15:17 GMT, Xiaolin Zheng wrote: >> Hi team, >> >> 1. Tests described in JDK-8293100 are failed, for callee-saved float registers used in C++ code are observed being killed after entering the Java world since callee-saved float registers are unfortunately missed to be saved in `StubGenerator::generate_call_stub()`. So the phenomenon presented in the failed tests seems to be weird. >> >> 2. This patch also fixes some typos in `vmreg_riscv.cpp` when debugging the same issue: >> (before) >> ![140D1DC7-39AD-4D5E-ABDE-38AACB658E3F](https://user-images.githubusercontent.com/38156692/187642108-9b3c5b81-f753-4e02-8a71-1baa984f1c74.png) >> This one seems not right, either; and it also gets fixed in this patch: >> (after) >> ![6374B608-F574-4883-9DB5-D0525BE2536A](https://user-images.githubusercontent.com/38156692/187642140-43d0647a-0ae6-4e11-951e-d90b239bd75a.png) >> >> 3. Also, branch nodes for float registers in OptoAssembly didn't show their destination blocks. This patch adds a little enhancement for those. >> >> Hotspot tier1 has passed both on my board and qemu, and `vmTestbase/nsk/stress` tests failed before have passed as well. >> The test process on the board is slow and I am testing the remaining but I consider this as ready for review. >> >> Best, >> Xiaolin > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Revise comments Marked as reviewed by vkempik (Committer). Hello Tier4:hotspot is good on thead. ------------- PR: https://git.openjdk.org/jdk/pull/10095 From xlinzheng at openjdk.org Fri Sep 2 06:47:56 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Fri, 2 Sep 2022 06:47:56 GMT Subject: RFR: 8293100: RISC-V: Need to save and restore callee-saved FloatRegisters in StubGenerator::generate_call_stub [v2] In-Reply-To: References: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> Message-ID: On Thu, 1 Sep 2022 09:15:17 GMT, Xiaolin Zheng wrote: >> Hi team, >> >> 1. Tests described in JDK-8293100 are failed, for callee-saved float registers used in C++ code are observed being killed after entering the Java world since callee-saved float registers are unfortunately missed to be saved in `StubGenerator::generate_call_stub()`. So the phenomenon presented in the failed tests seems to be weird. >> >> 2. This patch also fixes some typos in `vmreg_riscv.cpp` when debugging the same issue: >> (before) >> ![140D1DC7-39AD-4D5E-ABDE-38AACB658E3F](https://user-images.githubusercontent.com/38156692/187642108-9b3c5b81-f753-4e02-8a71-1baa984f1c74.png) >> This one seems not right, either; and it also gets fixed in this patch: >> (after) >> ![6374B608-F574-4883-9DB5-D0525BE2536A](https://user-images.githubusercontent.com/38156692/187642140-43d0647a-0ae6-4e11-951e-d90b239bd75a.png) >> >> 3. Also, branch nodes for float registers in OptoAssembly didn't show their destination blocks. This patch adds a little enhancement for those. >> >> Hotspot tier1 has passed both on my board and qemu, and `vmTestbase/nsk/stress` tests failed before have passed as well. >> The test process on the board is slow and I am testing the remaining but I consider this as ready for review. >> >> Best, >> Xiaolin > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Revise comments Thanks! And thank you all for reviewing as always. Let's move on then. ------------- PR: https://git.openjdk.org/jdk/pull/10095 From stefank at openjdk.org Fri Sep 2 06:53:59 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 2 Sep 2022 06:53:59 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v10] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 16:33:13 GMT, Stefan Karlsson wrote: >> Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. >> >> This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. >> >> We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. >> >> I'd like to suggest that we use a convention to specify what we want. This is the current proposal: >> >> // Guide to the suffixes used in the format specifiers for integers: >> // - print the decimal value: 745565 >> // _X - print as hexadecimal, without leading 0s: 0x12345 >> // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 >> // _H - print as hexadecimal, without 0x prefix >> // _W(w) - prints w sized string with the given value right >> // adjusted. Use -w to print left adjusted. >> // >> // Note that the PTR format specifiers print using 0x with leading zeros, >> // just like the _X_0 version for integers. >> >> >> The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Fix gtest compilation warning Thanks all for reviewing! This passes tier1-3. I'm pushing this now, and then we can proceed with any follow-up fixes we want to do. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From stefank at openjdk.org Fri Sep 2 06:54:00 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 2 Sep 2022 06:54:00 GMT Subject: RFR: 8292981: Unify and restructure integer printing format specifiers [v10] In-Reply-To: References: Message-ID: <--iTksgLeAOTvoCEvDLJAZICW7WNLgff0BhHPeh3jsA=.40ba892d-f6bd-4c9d-b14b-a85f1859a5be@github.com> On Thu, 1 Sep 2022 22:06:37 GMT, Kim Barrett wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix gtest compilation warning > > src/hotspot/share/cds/filemap.cpp line 1556: > >> 1554: if (size > 0) { >> 1555: log_info(cds)("Shared file region (%-3s) %d: " SIZE_FORMAT_W(8) >> 1556: " bytes, addr " INTPTR_FORMAT " file offset 0x%08" PRIxPTR > > If not using one of our FORMAT macros for this one-off place, I think > "0x%08zx" is shorter and at least as understandable as using of one of the PRI > macros (whose meanings I can never remember, and whose very existence I tend > to forget, but maybe that's just me). > > But really, I wonder what the point of the field width is here? Why isn't > this just SIZE_FORMAT_X? > > Alternatively, maybe SIZE_FORMAT_X_W should be SIZE_FORMAT_X_0_W? I'm going to take the safer route and not poke around to much in this code. I've inlined the code verbatim, and I'll leave these questions for @iklam, in case he wants to clean this up in the feature. ------------- PR: https://git.openjdk.org/jdk/pull/10042 From stefank at openjdk.org Fri Sep 2 06:55:44 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 2 Sep 2022 06:55:44 GMT Subject: Integrated: 8292981: Unify and restructure integer printing format specifiers In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 13:38:26 GMT, Stefan Karlsson wrote: > Today we have some inconsistencies in how we name our integer printing format specifiers. I'd like to change this to be consistent. > > This patch comes from a discussion in #10028, which snowballed into restructuring the format specifiers. The main issues was that my original patch used PTR_FORMAT to print integers with the format 0x000. The reviewers felt that it was wrong to use PTR format specifiers when printing integers. I agree with that. > > We do have format specifiers to print hex values out of integers, though they don't 0-pad like the PTR macros do, and only some of the prepend 0x. > > I'd like to suggest that we use a convention to specify what we want. This is the current proposal: > > // Guide to the suffixes used in the format specifiers for integers: > // - print the decimal value: 745565 > // _X - print as hexadecimal, without leading 0s: 0x12345 > // _X_0 - print as hexadecimal, with leading 0s: 0x00012345 > // _H - print as hexadecimal, without 0x prefix > // _W(w) - prints w sized string with the given value right > // adjusted. Use -w to print left adjusted. > // > // Note that the PTR format specifiers print using 0x with leading zeros, > // just like the _X_0 version for integers. > > > The patch also removes PTR32_FORMAT and PTR64_FORMAT and replace them with the corresponding integer format specifiers. This pull request has now been integrated. Changeset: 98ce45ff Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/98ce45ff7432a56d73b51046817b5fe84a412042 Stats: 215 lines in 27 files changed: 102 ins; 22 del; 91 mod 8292981: Unify and restructure integer printing format specifiers Reviewed-by: kbarrett, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/10042 From xlinzheng at openjdk.org Fri Sep 2 07:04:12 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Fri, 2 Sep 2022 07:04:12 GMT Subject: Integrated: 8293100: RISC-V: Need to save and restore callee-saved FloatRegisters in StubGenerator::generate_call_stub In-Reply-To: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> References: <5EzwiJ4Ih0c394v3WBwhPllV_dfgEzs91nM33PZpba4=.1228b2ec-e29d-4643-be07-a65c68bb3095@github.com> Message-ID: <3Iz57kgN7G94eZNHZqAtt2q-5G5weUHhLxyuMQBXuJo=.0691f39e-eea9-4bec-941d-b628989f1b4c@github.com> On Wed, 31 Aug 2022 08:47:50 GMT, Xiaolin Zheng wrote: > Hi team, > > 1. Tests described in JDK-8293100 are failed, for callee-saved float registers used in C++ code are observed being killed after entering the Java world since callee-saved float registers are unfortunately missed to be saved in `StubGenerator::generate_call_stub()`. So the phenomenon presented in the failed tests seems to be weird. > > 2. This patch also fixes some typos in `vmreg_riscv.cpp` when debugging the same issue: > (before) > ![140D1DC7-39AD-4D5E-ABDE-38AACB658E3F](https://user-images.githubusercontent.com/38156692/187642108-9b3c5b81-f753-4e02-8a71-1baa984f1c74.png) > This one seems not right, either; and it also gets fixed in this patch: > (after) > ![6374B608-F574-4883-9DB5-D0525BE2536A](https://user-images.githubusercontent.com/38156692/187642140-43d0647a-0ae6-4e11-951e-d90b239bd75a.png) > > 3. Also, branch nodes for float registers in OptoAssembly didn't show their destination blocks. This patch adds a little enhancement for those. > > Hotspot tier1 has passed both on my board and qemu, and `vmTestbase/nsk/stress` tests failed before have passed as well. > The test process on the board is slow and I am testing the remaining but I consider this as ready for review. > > Best, > Xiaolin This pull request has now been integrated. Changeset: bc5ffc8e Author: Xiaolin Zheng Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/bc5ffc8e472ba7bbafbf68d19d1f06dd1cba10e1 Stats: 81 lines in 4 files changed: 64 ins; 0 del; 17 mod 8293100: RISC-V: Need to save and restore callee-saved FloatRegisters in StubGenerator::generate_call_stub Reviewed-by: yadongwang, fjiang, shade, vkempik ------------- PR: https://git.openjdk.org/jdk/pull/10095 From aboldtch at openjdk.org Fri Sep 2 07:12:42 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 2 Sep 2022 07:12:42 GMT Subject: RFR: 8293207: Add assert to JVM_ReferenceRefersTo to clarify its API In-Reply-To: <-eHezoFZOpUd8iPzDWCnn7hJqW1_88KVCHGZDTlpPvw=.9dfb5b24-9754-43ed-84c3-68e66a076216@github.com> References: <-eHezoFZOpUd8iPzDWCnn7hJqW1_88KVCHGZDTlpPvw=.9dfb5b24-9754-43ed-84c3-68e66a076216@github.com> Message-ID: On Fri, 2 Sep 2022 00:22:27 GMT, Kim Barrett wrote: >> JVM_ReferenceRefersTo should only be used for soft/weak references and not phantom references, which has its own implementation. This is not clear from the name. `java_lang_ref_Reference::weak_referent_no_keepalive(ref_oop)` is only a valid call if `!java_lang_ref_Reference::is_phantom(ref_oop)`. >> >> Adds an assert and comment to make this clear. >> >> Testing: Oracle platforms tier 1-3 > > src/hotspot/share/prims/jvm.cpp line 3286: > >> 3284: oop ref_oop = JNIHandles::resolve_non_null(ref); >> 3285: // PhantomReference has it's own implementation of refersTo(). >> 3286: assert(!java_lang_ref_Reference::is_phantom(ref_oop), "precondition"); > > Maybe instead assertions should be added to the java_lang_ref_Reference functions for accessing the referent? (weak_referent_no_keepalive, weak_referent, phantom_referent_no_keepalive) I fell like that is some what orthogonal to what this PR is trying to address. This wants to make the precondition clear for the JVM entry API. As a PhantomReference is a Reference it was not clear from JVM_ReferenceRefersTo entry that it is not the entry for PhantomReference. This assert and comment aims to make this clear. But I do agree that all the accessors in `java_lang_ref_Reference` should assert the type. I will make another issue with the following change. oop java_lang_ref_Reference::weak_referent_no_keepalive(oop ref) { + assert(!java_lang_ref_Reference::is_phantom(ref_oop), "must be Weak or Soft Reference"); return ref->obj_field_access(_referent_offset); } oop java_lang_ref_Reference::weak_referent(oop ref) { + assert(!java_lang_ref_Reference::is_phantom(ref_oop), "must be Weak or Soft Reference"); return ref->obj_field_access(_referent_offset); } oop java_lang_ref_Reference::phantom_referent_no_keepalive(oop ref) { + assert(java_lang_ref_Reference::is_phantom(ref_oop), "must be Phantom Reference"); return ref->obj_field_access(_referent_offset); } ------------- PR: https://git.openjdk.org/jdk/pull/10117 From aboldtch at openjdk.org Fri Sep 2 07:32:10 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 2 Sep 2022 07:32:10 GMT Subject: RFR: 8293207: Add assert to JVM_ReferenceRefersTo to clarify its API [v2] In-Reply-To: References: Message-ID: > JVM_ReferenceRefersTo should only be used for soft/weak references and not phantom references, which has its own implementation. This is not clear from the name. `java_lang_ref_Reference::weak_referent_no_keepalive(ref_oop)` is only a valid call if `!java_lang_ref_Reference::is_phantom(ref_oop)`. > > Adds an assert and comment to make this clear. > > Testing: Oracle platforms tier 1-3 Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Add comment reference to JVM_PhantomReferenceRefersTo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10117/files - new: https://git.openjdk.org/jdk/pull/10117/files/ff334b45..2325742a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10117&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10117&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10117.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10117/head:pull/10117 PR: https://git.openjdk.org/jdk/pull/10117 From stefank at openjdk.org Fri Sep 2 08:28:43 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 2 Sep 2022 08:28:43 GMT Subject: RFR: 8292921: Rewrite object field printer [v8] In-Reply-To: References: Message-ID: <0D7Bl_Agg1ZUn2dFZv7fcW-oicqeN5X0QSLIHS_KOcA=.73c2b9ed-c415-4a53-bee1-4cc2db8c031f@github.com> > See this as a RFC rather than a fully ready PR: > > fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. > > This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) > > and with the suggested change we get: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) > > which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). > > I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. > > There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. > > A full example of the generated output: > > java.lang.Class > {0x00007ffc36801080} - klass: 'java/lang/Class' > - ---- fields (total size 26 words): > - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) > - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) > - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) > - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) > - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) > - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) > - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) > - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) > - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) > - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) > - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) > - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) > - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) > - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) > - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) > - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) > - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) > - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) > - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) > - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) > - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) > - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) > - signature: Ljava/lang/String; > - ---- static fields (2): > - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) > - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) > - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) > - private static final 'REPL' 'C' @200 65533 (0x0000fffd) > - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) > - static final 'LATIN1' 'B' @203 0 (0x00000000) > - static final 'UTF16' 'B' @204 1 (0x00000001) Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Work around clang's warning about using jlong - Merge remote-tracking branch 'upstream/master' into 8292921_object_field_printer - Guide to integer format specifier suffixes - Introduce and use various 0x0... prefixed integer format specifiers - Review tsteufe - Review dholmes - Fix macOS sensitivity to format specifier for jlong - Print correct number of bits for small integer types - 8292921: Rewrite object field printer ------------- Changes: https://git.openjdk.org/jdk/pull/10028/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10028&range=07 Stats: 47 lines in 1 file changed: 16 ins; 14 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/10028.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10028/head:pull/10028 PR: https://git.openjdk.org/jdk/pull/10028 From stefank at openjdk.org Fri Sep 2 08:28:44 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 2 Sep 2022 08:28:44 GMT Subject: RFR: 8292921: Rewrite object field printer [v7] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 09:56:02 GMT, Stefan Karlsson wrote: >> See this as a RFC rather than a fully ready PR: >> >> fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. >> >> This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) >> >> and with the suggested change we get: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) >> >> which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). >> >> I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. >> >> There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. >> >> A full example of the generated output: >> >> java.lang.Class >> {0x00007ffc36801080} - klass: 'java/lang/Class' >> - ---- fields (total size 26 words): >> - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) >> - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) >> - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) >> - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) >> - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) >> - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) >> - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) >> - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) >> - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) >> - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) >> - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) >> - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) >> - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) >> - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) >> - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) >> - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) >> - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) >> - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) >> - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) >> - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) >> - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) >> - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) >> - signature: Ljava/lang/String; >> - ---- static fields (2): >> - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) >> - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) >> - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) >> - private static final 'REPL' 'C' @200 65533 (0x0000fffd) >> - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) >> - static final 'LATIN1' 'B' @203 0 (0x00000000) >> - static final 'UTF16' 'B' @204 1 (0x00000001) > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Guide to integer format specifier suffixes #10042 has been integrated and this PR has been merged. Reopening this RFR. ------------- PR: https://git.openjdk.org/jdk/pull/10028 From dlong at openjdk.org Fri Sep 2 08:37:37 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 2 Sep 2022 08:37:37 GMT Subject: RFR: 8293287 add ReplayReduce flag In-Reply-To: References: Message-ID: <2onk8LrCxLP0AuzqZulPi_XeQC-QXgXhd9iVtZWKzUw=.82614ce1-5d62-42d8-9e53-42056509c7ca@github.com> On Fri, 2 Sep 2022 01:20:26 GMT, Dean Long wrote: > Add an experimental flag to help developers "reduce" a replay file. > > As a first step, I plan to simulate reduced inlining. This will output multiple "compile" lines as if the first level of inlining never happened: > A --> B --> C > A --> D --> E > becomes > B --> C > D --> E > Developers can repeat iteratively until the replay crash no longer reproduces. One test is failing -- moving back to DRAFT. ------------- PR: https://git.openjdk.org/jdk/pull/10134 From stefank at openjdk.org Fri Sep 2 09:58:18 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 2 Sep 2022 09:58:18 GMT Subject: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT Message-ID: During the discussion of [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was voiced that we should stop using INTPTR_FORMAT when printing pointers. Some background that could explain why some tend to use INTPTR_FORMAT instead of PTR_FORMAT: Both those format specifiers require an integer and the compiler barfs if you send in a pointer. We therefore have a utility function named p2i, which converts the pointer to an integer. So, everywhere we have to write print line like this: `print("my pointer: " PTR_FORMAT, p2i(my_pointer));`. Now, p2i returns an intptr_t, and it becomes natural for some to consider the type of the converted value (that we need because of the mentioned workaround), instead of the original type of the value. With this enhancement I'd like to clean up the code that I often work in, so that it uses PTR_FORMAT when printing pointers. I'm leaving the rest of the code base for others to consider cleaning up. Cleanups have been done in directories gc/, utilities/, memory/, and oops/. ------------- Commit messages: - Fix oops/ - Fix memory/ - Fix utilities/ - Fix gc/ - Add SIZE_FORMAT_X_0 Changes: https://git.openjdk.org/jdk/pull/10141/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10141&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293304 Stats: 125 lines in 39 files changed: 6 ins; 0 del; 119 mod Patch: https://git.openjdk.org/jdk/pull/10141.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10141/head:pull/10141 PR: https://git.openjdk.org/jdk/pull/10141 From duke at openjdk.org Fri Sep 2 11:30:24 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 2 Sep 2022 11:30:24 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable Message-ID: Hi! Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. This passes tier1, tier2 tests. ------------- Commit messages: - Attempt to document base() - Change out as_string to base where applicable Changes: https://git.openjdk.org/jdk/pull/10142/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293251 Stats: 69 lines in 27 files changed: 4 ins; 8 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/10142.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10142/head:pull/10142 PR: https://git.openjdk.org/jdk/pull/10142 From erikj at openjdk.org Fri Sep 2 12:44:43 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 2 Sep 2022 12:44:43 GMT Subject: RFR: 8293293: Move archive heap loading code out of heapShared.cpp In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 05:31:35 GMT, Ioi Lam wrote: > I moved all code related to loading the archive heap regions into a new file, archiveHeapLoader.cpp. > > A diff of the new archiveHeapLoader.cpp and the old heapShared.cpp shows that the moved code is identical, except for the change of `HeapShared::` to `ArchiveHeapLoader::`. > > I also removed unnecessary entries in JVM_EXCLUDE_FILES that are already covered by the `cds/` pattern. Build change looks good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/10138 From shade at openjdk.org Fri Sep 2 12:50:41 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 2 Sep 2022 12:50:41 GMT Subject: RFR: 8293290: RISC-V: Explicitly pass a third temp register to MacroAssembler::store_heap_oop In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 03:34:49 GMT, Fei Yang wrote: > Currently G1 (and Shenandoah) implicitly uses x13 in oop_store_at on riscv. > > This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186). > This would be fixed in the same way on riscv by passing the temporary register explicitly so it is part of the GC API. > > Testing: Passed Tier1 test on linux-riscv64 SiFive Unmatched board. Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10137 From aboldtch at openjdk.org Fri Sep 2 13:03:47 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 2 Sep 2022 13:03:47 GMT Subject: Integrated: 8293207: Add assert to JVM_ReferenceRefersTo to clarify its API In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 10:47:50 GMT, Axel Boldt-Christmas wrote: > JVM_ReferenceRefersTo should only be used for soft/weak references and not phantom references, which has its own implementation. This is not clear from the name. `java_lang_ref_Reference::weak_referent_no_keepalive(ref_oop)` is only a valid call if `!java_lang_ref_Reference::is_phantom(ref_oop)`. > > Adds an assert and comment to make this clear. > > Testing: Oracle platforms tier 1-3 This pull request has now been integrated. Changeset: 6fc58b83 Author: Axel Boldt-Christmas Committer: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/6fc58b8324d5b2d36e8c62839eda50a16c9da7bd Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8293207: Add assert to JVM_ReferenceRefersTo to clarify its API Reviewed-by: stefank, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/10117 From coleenp at openjdk.org Fri Sep 2 13:09:03 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 Sep 2022 13:09:03 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, add assert. Thank you David and Ioi for approving and reviewing. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Fri Sep 2 13:09:03 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 Sep 2022 13:09:03 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> <6WXzI0rm-YVn2NO-wJpFokTRrihFQtSpIIoWHb7-BWA=.7ec7ea33-c104-4686-b6db-071d4c31d5ae@github.com> <1SP_BMq5WR8aEaDrOltFkrf3ArzSTd0yZrjt9DfIkmg=.da033eb4-8b71-4fce-a3e2-d2ec1021b6e4@github.com> Message-ID: On Fri, 2 Sep 2022 05:26:45 GMT, David Holmes wrote: >> // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are >> // registered by DictionaryEntry::add_protection_domain() to a unique entry. The entry >> // is a WeakHandle that holds the protection domain oop. >> >> or points to.... either is accurate. > > It is the "maps ... to a unique entry" that I find most problematic - it begs the question as to what the unique entry is, when in reality it maps a PD instance (wrapped in a WeakHandle) to itself (wrapped in a WeakHandle). > > For the sake of progress, approved. The "unique" means there's only one value in the table for this protection domain oop. So the oop is unique. The use of word "mapping" might be what's confusing. If we ever have to visit this code again (which I hope not, except to remove it because the security manager is finally removed since not many use it), we can see if this comment still makes sense to at least some of us. Thanks for approving for progress. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Fri Sep 2 13:11:48 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 Sep 2022 13:11:48 GMT Subject: Integrated: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 13:43:00 GMT, Coleen Phillimore wrote: > Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. > Also tested with tier1-7. This pull request has now been integrated. Changeset: fcc0cf96 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/fcc0cf96772644ece6430eee93fb018c3432135b Stats: 260 lines in 9 files changed: 58 ins; 127 del; 75 mod 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable Reviewed-by: dholmes, iklam ------------- PR: https://git.openjdk.org/jdk/pull/10043 From stuefe at openjdk.org Fri Sep 2 13:40:48 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 2 Sep 2022 13:40:48 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 11:20:59 GMT, Johan Sj?l?n wrote: > Hi! > > Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. > > When I've left ResourceMarks in place I've also commented which calls requires them. > > This passes tier1, tier2 tests. Hi @jdksjolen, Generally good, see remarks inline. Cheers, Thomas src/hotspot/share/code/codeCache.cpp line 1485: > 1483: get_code_heap_flag_name(code_blob_type)); > 1484: const char *msg1 = msg1_stream.base(); > 1485: const char *msg2 = msg2_stream.base(); I would do this only in places where it's super-obvious nothing bad will happen and where it cannot bitrot. Here it's not, since you assign it to a temporary variable. Someone inattentive may modify it in the future, forgetting about why this is special. Since the error is hard to catch and the benefit tiny, I would leave this as `as_string`. This is just my gut feeling, others may disagree. src/hotspot/share/utilities/ostream.hpp line 221: > 219: // A stringStream may free the pointer returned > 220: // if any of its methods are called, therefore > 221: // take care in using this method. Comment is a bit misleading, what does "borrow" mean? Suggestion: "Returns internal buffer. Returned buffer is only guaranteed to be valid as long as stream is not modified" src/hotspot/share/utilities/vmError.cpp line 576: > 574: stringStream message; > 575: message.print("This is a message with no ResourceMark"); > 576: tty->print_cr("%s", message.base()); I think the intent was to use as_string deliberately to get an mark-missing crash. ------------- Changes requested by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/10142 From kevinw at openjdk.org Fri Sep 2 15:09:47 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 2 Sep 2022 15:09:47 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread Message-ID: This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). A JVMTI operation could call threadObj() and clear the Windows GetLastError value. Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. ------------- Commit messages: - chmod - whitespace - 8292302: GetLastError value overwritten when running in debugger Changes: https://git.openjdk.org/jdk/pull/10147/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10147&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292302 Stats: 102 lines in 3 files changed: 98 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10147.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10147/head:pull/10147 PR: https://git.openjdk.org/jdk/pull/10147 From kvn at openjdk.org Fri Sep 2 15:38:46 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 2 Sep 2022 15:38:46 GMT Subject: RFR: 8293285: x86_64: Move libm stub implementations to StubGenerator In-Reply-To: References: Message-ID: <4TYT_rzSVuIeRjZRtfulNQqWsJ_VJFaMU1bROhx1fHA=.40f091e1-609a-42f9-afef-7dc5542bba28@github.com> On Fri, 2 Sep 2022 00:10:13 GMT, Vladimir Ivanov wrote: > Move libm stub implementations (used for trigonometric math intrinsics) from MacroAssembler to StubGenerator. > > x86_32-specific code is left intact, but all `macroAssembler_x86_*.cpp` files are renamed to `macroAssembler_x86_32_*.cpp` since there's no x86_64-specific code left there anymore. > > Testing: hs-tier1 - hs-tier4 Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10133 From kvn at openjdk.org Fri Sep 2 15:39:42 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 2 Sep 2022 15:39:42 GMT Subject: RFR: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files [v2] In-Reply-To: References: <2CCgZ9uVr3bRAMy0IhobEdsiZE_uX8v_UC-ipQ1_tqA=.e6ea7807-4b6c-4d2d-ad72-127db467dfae@github.com> <4OqV-3gAmLIRzYXBNj4LcxyvwnzhFmzW_6DNsQds30M=.92283b2d-d0f7-4647-a1bc-bc94849d6a4c@github.com> Message-ID: On Fri, 2 Sep 2022 00:44:30 GMT, Vladimir Ivanov wrote: > > I noticed that your repo do not have GitHub actions testing. Please, switch it on. > > @vnkozlov I don't know how it is expected to work, but right now I see there's GHA testing going on. I see it now. Yesterday it was not present in this and an other your PR. ------------- PR: https://git.openjdk.org/jdk/pull/10124 From psandoz at openjdk.org Fri Sep 2 16:01:46 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 2 Sep 2022 16:01:46 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Can you please file a follow up issue to write a test (gtest?) for the `f2hf` and `hf2f` methods? If a bug is lurking in those it will otherwise be really hard to track down. (Perhaps an alternative to a gtest is to to somehow call those methods natively from Java using Panama, then we can reuse all the existing testing logic.) ------------- PR: https://git.openjdk.org/jdk/pull/9781 From kvn at openjdk.org Fri Sep 2 16:11:56 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 2 Sep 2022 16:11:56 GMT Subject: RFR: 8293287 add ReplayReduce flag In-Reply-To: References: Message-ID: <79t3IdX7_aa4bpwrD9kHGiijB4x77reAW-rhW7jZX_0=.a9dfccb0-8dbd-4d7b-b66f-8a727746338e@github.com> On Fri, 2 Sep 2022 01:20:26 GMT, Dean Long wrote: > Add an experimental flag to help developers "reduce" a replay file. > > As a first step, I plan to simulate reduced inlining. This will output multiple "compile" lines as if the first level of inlining never happened: > A --> B --> C > A --> D --> E > becomes > B --> C > D --> E > Developers can repeat iteratively until the replay crash no longer reproduces. src/hotspot/share/ci/ciEnv.cpp line 1651: > 1649: if (task) { > 1650: #ifdef COMPILER2 > 1651: if (ReplayReduce && compiler_data() != NULL) { Is this feature when you are replaying compilation? If yes, add `ReplayCompiles` check too. src/hotspot/share/opto/compile.cpp line 4576: > 4574: } > 4575: > 4576: void Compile::dump_inline_data_reduced(outputStream* out) { Add `assert(ReplayReduce`. ------------- PR: https://git.openjdk.org/jdk/pull/10134 From cjplummer at openjdk.org Fri Sep 2 16:23:46 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Sep 2022 16:23:46 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 14:47:35 GMT, Kevin Walls wrote: > This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). > > A JVMTI operation could call threadObj() and clear the Windows GetLastError value. > > Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. The new test looks good. I'll let someone with a better understanding of JDK-8289091 comment on the runtime changes. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/10147 From asmehra at redhat.com Fri Sep 2 16:23:53 2022 From: asmehra at redhat.com (Ashutosh Mehra) Date: Fri, 2 Sep 2022 12:23:53 -0400 Subject: Archived heap support in Shenandoah GC Message-ID: Hi, I came across this enhancement [1] to add support for loading archived heap for non-G1 gc policies. But it is missing Shenandoah GC in the list. Based on the changes done for supporting other policies (like Parallel) I added following APIs: - ShenandoahHeap::allocate_loaded_archive_space() - ShenandoahHeap::can_load_archived_objects() and tested it with "-XX:+UseShenandoahGC -Xlog:cds,cds+heap=info" options. The logs show that the jvm is able to load the archived heap and use the archived objects: [0.047s][info][cds] Mapped static region #2 at base 0x00007f7706699000 top 0x00007f77066d5000 (Bitmap) [0.047s][info][cds] Loaded heap region #5 at base 0x0000000611e00000 top 0x0000000611e78000 size 491520 delta 21776826368 [0.048s][info][cds] Loaded heap region #3 at base 0x0000000611e78000 top 0x0000000611efa000 size 532480 delta 21776269312 [0.048s][info][cds] optimized module handling: enabled [0.048s][info][cds] full module graph: enabled [0.048s][info][cds] use_full_module_graph = true; java.base = 0x00000008004f46c0 [0.049s][info][cds] Unmapping region #2 at base 0x00007f7706699000 (Bitmap) [0.077s][info][cds,heap] initialize_from_archived_subgraph java.lang.Module$ArchivedData 0x000000080019ff10 (early) [0.078s][info][cds,heap] initialize_from_archived_subgraph java.util.ImmutableCollections 0x000000080018c190 (early) [0.083s][info][cds,heap] initialize_from_archived_subgraph java.lang.Integer$IntegerCache 0x0000000800048d58 (early) [0.086s][info][cds,heap] initialize_from_archived_subgraph java.lang.module.Configuration 0x0000000800193128 (early) [0.086s][info][cds,heap] initialize_from_archived_subgraph java.lang.ModuleLayer 0x0000000800162b68 (early) [0.086s][info][cds,heap] Initializing Enum class: java.lang.module.ModuleDescriptor$Requires$Modifier [0.087s][info][cds,heap] initialize_from_archived_subgraph jdk.internal.loader.ArchivedClassLoaders 0x00000008000fe280 (early) [0.087s][info][cds,heap] initialize_from_archived_subgraph jdk.internal.module.ArchivedBootLayer 0x000000080023cd40 (early) [0.090s][info][cds,heap] initialize_from_archived_subgraph sun.util.locale.BaseLocale 0x0000000800365660 [0.102s][info][cds,heap] initialize_from_archived_subgraph java.lang.Long$LongCache 0x000000080004c180 I want to check if adding these two APIs is sufficient. Did I miss anything? [1] https://bugs.openjdk.org/browse/JDK-8234679 Thanks, Ashutosh Mehra -------------- next part -------------- An HTML attachment was scrubbed... URL: From svkamath at openjdk.org Fri Sep 2 16:58:45 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Fri, 2 Sep 2022 16:58:45 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Fri, 2 Sep 2022 15:59:23 GMT, Paul Sandoz wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed review comments > > Can you please file a follow up issue to write a test (gtest?) for the `f2hf` and `hf2f` methods? If a bug is lurking in those it will otherwise be really hard to track down. (Perhaps an alternative to a gtest is to to somehow call those methods natively from Java using Panama, then we can reuse all the existing testing logic.) @PaulSandoz - Bug link- https://bugs.openjdk.org/browse/JDK-8293323 ------------- PR: https://git.openjdk.org/jdk/pull/9781 From vlivanov at openjdk.org Fri Sep 2 17:06:41 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 2 Sep 2022 17:06:41 GMT Subject: RFR: 8293188: x86_64: Introduce stubGenerator_x86_64.hpp [v5] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 23:48:08 GMT, Vladimir Ivanov wrote: >> Introduce stubGenerator_x86_64.hpp and extract StubGenerator class declaration there. >> >> Testing: hs-tier1 - hs-tier4 > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - update > - Merge branch 'master' into stub.x86_64.hpp > - RuntimeStub > - fix hs-minimal build > - update > - fix > - stubGenerator_x86_64.hpp Thanks for the reviews, David and Vladimir. ------------- PR: https://git.openjdk.org/jdk/pull/10111 From vlivanov at openjdk.org Fri Sep 2 17:09:49 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 2 Sep 2022 17:09:49 GMT Subject: Integrated: 8293188: x86_64: Introduce stubGenerator_x86_64.hpp In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 23:07:24 GMT, Vladimir Ivanov wrote: > Introduce stubGenerator_x86_64.hpp and extract StubGenerator class declaration there. > > Testing: hs-tier1 - hs-tier4 This pull request has now been integrated. Changeset: 0c6094e7 Author: Vladimir Ivanov URL: https://git.openjdk.org/jdk/commit/0c6094e79602fe85a88e3131710bb39813364ad2 Stats: 11051 lines in 2 files changed: 3926 ins; 3441 del; 3684 mod 8293188: x86_64: Introduce stubGenerator_x86_64.hpp Reviewed-by: dholmes, kvn ------------- PR: https://git.openjdk.org/jdk/pull/10111 From vlivanov at openjdk.org Fri Sep 2 17:11:56 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 2 Sep 2022 17:11:56 GMT Subject: RFR: 8293285: x86_64: Move libm stub implementations to StubGenerator [v2] In-Reply-To: References: Message-ID: > Move libm stub implementations (used for trigonometric math intrinsics) from MacroAssembler to StubGenerator. > > x86_32-specific code is left intact, but all `macroAssembler_x86_*.cpp` files are renamed to `macroAssembler_x86_32_*.cpp` since there's no x86_64-specific code left there anymore. > > Testing: hs-tier1 - hs-tier4 Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Extract libm stub implementations into separate files - update - Merge branch 'master' into stub.x86_64.hpp - RuntimeStub - fix hs-minimal build - update - fix - stubGenerator_x86_64.hpp ------------- Changes: https://git.openjdk.org/jdk/pull/10133/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10133&range=01 Stats: 34076 lines in 26 files changed: 15803 ins; 14757 del; 3516 mod Patch: https://git.openjdk.org/jdk/pull/10133.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10133/head:pull/10133 PR: https://git.openjdk.org/jdk/pull/10133 From vlivanov at openjdk.org Fri Sep 2 17:12:16 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 2 Sep 2022 17:12:16 GMT Subject: RFR: 8293254: x86_64: Extract arraycopy stub implementations into a separate file [v2] In-Reply-To: <1_CR20VVro8dAulbOEksXBiQ50Jt5jbMpc2vXFyV6xw=.ab22694f-db1b-43fd-8f69-e2eff89c5f85@github.com> References: <1_CR20VVro8dAulbOEksXBiQ50Jt5jbMpc2vXFyV6xw=.ab22694f-db1b-43fd-8f69-e2eff89c5f85@github.com> Message-ID: > Move arraycopy stub implementations from `stubGenerator_x86_64.cpp` into `stubGenerator_x86_64_arraycopy.cpp`. > > Testing: hs-tier1 - hs-tier4 > > PS: FTR I left `MacroAssembler::generate_fill_avx3()` intact because it is called from `MacroAssembler::generate_fill()` which is shared between x86_64 and x86_32. Otherwise, I would either need to copy `MacroAssembler::generate_fill()` or put it into a separate file (e.g., `stubGenerator_x86.cpp` or `stubGenerator_x86_arraycopy.cpp`). IMO it doesn't add much value compared to keeping it in `macroAssembler_x86.cpp`. Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10128/files - new: https://git.openjdk.org/jdk/pull/10128/files/e518a78d..e518a78d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10128&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10128&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10128.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10128/head:pull/10128 PR: https://git.openjdk.org/jdk/pull/10128 From vlivanov at openjdk.org Fri Sep 2 17:12:20 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 2 Sep 2022 17:12:20 GMT Subject: RFR: 8293245: x86_64: Extract Adler32 stub implementation into stubGenerator_x86_64_adler.cpp [v2] In-Reply-To: References: Message-ID: > Extract Adler32 stub implementation into a dedicated file (`stubGenerator_x86_64_adler.cpp`). > > Minor cleanups: > * got rid of `updateBytesAdler32()` by manually inlining it into `generate_updateBytesAdler32()` > * unified usage of `r14` as a scratch register > * added 32-byte alignment for the constants > > Testing: hs-tier1 - hs-tier4 Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10126/files - new: https://git.openjdk.org/jdk/pull/10126/files/69e427b3..69e427b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10126&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10126&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10126/head:pull/10126 PR: https://git.openjdk.org/jdk/pull/10126 From duke at openjdk.org Fri Sep 2 17:15:53 2022 From: duke at openjdk.org (Ashutosh Mehra) Date: Fri, 2 Sep 2022 17:15:53 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> Message-ID: On Tue, 30 Aug 2022 23:40:32 GMT, Ashutosh Mehra wrote: > Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode. > > Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier. > > Testing with fastdebug build: > > - [x] hotspot_loom > - [x] jdk_loom > - [x] hotspot_loom in Shenandoah IU mode > - [x] jdk_loom in Shenandoah IU mode > - [x] hotspot_loom in Shenandoah IU + aggressive > - [x] jdk_loom in Shenandoah IU + aggressive > > Signed-off-by: Ashutosh Mehra @fisk can you please review the changes ------------- PR: https://git.openjdk.org/jdk/pull/10089 From coleenp at openjdk.org Fri Sep 2 17:20:53 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 Sep 2022 17:20:53 GMT Subject: RFR: 8293293: Move archive heap loading code out of heapShared.cpp In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 05:31:35 GMT, Ioi Lam wrote: > I moved all code related to loading the archive heap regions into a new file, archiveHeapLoader.cpp. > > A diff of the new archiveHeapLoader.cpp and the old heapShared.cpp shows that the moved code is identical, except for the change of `HeapShared::` to `ArchiveHeapLoader::`. > > I also removed unnecessary entries in JVM_EXCLUDE_FILES that are already covered by the `cds/` pattern. src/hotspot/share/cds/archiveHeapLoader.cpp line 58: > 56: #include "oops/oop.inline.hpp" > 57: #include "oops/typeArrayOop.inline.hpp" > 58: #include "prims/jvmtiExport.hpp" It looks like you should be able to remove a lot of these header files. ------------- PR: https://git.openjdk.org/jdk/pull/10138 From iklam at openjdk.org Fri Sep 2 18:18:10 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 2 Sep 2022 18:18:10 GMT Subject: RFR: 8293293: Move archive heap loading code out of heapShared.cpp [v2] In-Reply-To: References: Message-ID: > I moved all code related to loading the archive heap regions into a new file, archiveHeapLoader.cpp. > > A diff of the new archiveHeapLoader.cpp and the old heapShared.cpp shows that the moved code is identical, except for the change of `HeapShared::` to `ArchiveHeapLoader::`. > > I also removed unnecessary entries in JVM_EXCLUDE_FILES that are already covered by the `cds/` pattern. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Cleaned up header files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10138/files - new: https://git.openjdk.org/jdk/pull/10138/files/35c14e8d..7acf47bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10138&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10138&range=00-01 Stats: 60 lines in 8 files changed: 7 ins; 49 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10138.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10138/head:pull/10138 PR: https://git.openjdk.org/jdk/pull/10138 From coleenp at openjdk.org Fri Sep 2 18:18:10 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 Sep 2022 18:18:10 GMT Subject: RFR: 8293293: Move archive heap loading code out of heapShared.cpp [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 18:14:31 GMT, Ioi Lam wrote: >> I moved all code related to loading the archive heap regions into a new file, archiveHeapLoader.cpp. >> >> A diff of the new archiveHeapLoader.cpp and the old heapShared.cpp shows that the moved code is identical, except for the change of `HeapShared::` to `ArchiveHeapLoader::`. >> >> I also removed unnecessary entries in JVM_EXCLUDE_FILES that are already covered by the `cds/` pattern. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Cleaned up header files Great! looks good ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/10138 From iklam at openjdk.org Fri Sep 2 18:20:56 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 2 Sep 2022 18:20:56 GMT Subject: RFR: 8293293: Move archive heap loading code out of heapShared.cpp [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 17:16:42 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleaned up header files > > src/hotspot/share/cds/archiveHeapLoader.cpp line 58: > >> 56: #include "oops/oop.inline.hpp" >> 57: #include "oops/typeArrayOop.inline.hpp" >> 58: #include "prims/jvmtiExport.hpp" > > It looks like you should be able to remove a lot of these header files. Thanks for the review. I took out the unnecessary includes in the four affected files {heapShared,archiveHeapLoader}.{cpp,hpp}. As a result, I had to fix a few other files to add missing header files that were included transitively. ------------- PR: https://git.openjdk.org/jdk/pull/10138 From eosterlund at openjdk.org Fri Sep 2 19:48:44 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 2 Sep 2022 19:48:44 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> Message-ID: On Tue, 30 Aug 2022 23:40:32 GMT, Ashutosh Mehra wrote: > Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode. > > Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier. > > Testing with fastdebug build: > > - [x] hotspot_loom > - [x] jdk_loom > - [x] hotspot_loom in Shenandoah IU mode > - [x] jdk_loom in Shenandoah IU mode > - [x] hotspot_loom in Shenandoah IU + aggressive > - [x] jdk_loom in Shenandoah IU + aggressive > > Signed-off-by: Ashutosh Mehra Looks great! ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/10089 From zgu at openjdk.org Fri Sep 2 20:07:40 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Fri, 2 Sep 2022 20:07:40 GMT Subject: RFR: JDK-8293114: GC should trim the native heap In-Reply-To: <8wtMlnuvDglrdLmP6HAW46J5BdGUacGKYO85j9gKlAE=.664b6079-efdb-4c5b-af93-8e0404dc0a63@github.com> References: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> <8wtMlnuvDglrdLmP6HAW46J5BdGUacGKYO85j9gKlAE=.664b6079-efdb-4c5b-af93-8e0404dc0a63@github.com> Message-ID: On Thu, 1 Sep 2022 05:25:27 GMT, Thomas Stuefe wrote: > Hi Zhengyu, > > > @tstuefe Nice work! > > Thanks :) > > > I also looked into memory usage recently, I found that `os::print_os_info()` is very usefully. I would like to purpose to add a diagnostics flag, e.g. `PrintProcessInfoAtExit` to capture some insights of the process, such as `RSS`, `Peak RSS`, `C-Heap` and `C-Heap Retained`. > > A small problem with "C-Heap Retained" is that it also contains blocks that are either trimmed or have never been (fully) paged in, meaning, that number may not relate 1:1 to RSS. Glibc observability is really annoying. > > About the "AtExit", in our SAP JVM I added a simple "DumpInfoAtExit", which prints out what "jcmd VM.info" would give you. Basically, a hs-err file without the err part. That contains a whole lot of information, including NMT and process memory information. That may be a better way than adding individual XXAtExit flags, what do you think? I am not sure, because it overlaps many other XXAtExit options? > > Another thing I would like to do is to enable Peak usage numbers in NMT for release builds too. That way one can see at VM exit how much memory each subsystem used. > > > Here are some numbers I captured > > C-Heap Outstanding (K) C-Heap Retained (K) > > Compiler 106387 271692 > > Sunflow 103882 173929 > > Compress 37794 11605 > > CrytioAes 37579 30580 > > CryptoRsa 38318 73001 > > CryptoSignVerify 37790 38769 > > Derby 55389 186954 > > MpegAudio 40280 71743 > > ScimarkFFT.large 36698 8945 > > ScimarkFFT.small 37071 10824 > > ScimarkLU.large 38018 8529 > > ScimarkLU.small 39198 8585 > > ScimarkMonteCarlo 36946 6529 > > ScimarkSOR.large 36648 8787 > > ScimarkSOR.small 36569 9078 > > ScimarkSparse.large 36745 9182 > > ScimarkSparse.small 37253 8574 > > Serial. 38652 127231 > > Sunflow.test. 45450 56657 > > XmlTransform. 83116 289431 > > XmlValidation 59883 59883 > > ? > > I captured the number at JVM exit, so it might not reflect runtime characters. > > But some number is quite interesting, e.g. `Derby` retained set is about x3 of outstanding set. > > Interesting, since it means malloc peaks are more common then we think. All the more reason to have a feature like this, to trim the C-heap. > > Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/10085 From zgu at openjdk.org Fri Sep 2 20:07:42 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Fri, 2 Sep 2022 20:07:42 GMT Subject: RFR: JDK-8293114: GC should trim the native heap [v2] In-Reply-To: References: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> Message-ID: On Thu, 1 Sep 2022 06:47:27 GMT, Thomas Stuefe wrote: >> This RFE adds the option to auto-trim the Glibc heap as part of the GC cycle. If the VM process suffered high temporary malloc spikes (regardless whether from JVM- or user code), this could recover significant amounts of memory. >> >> We discussed this a year ago [1], but the item got pushed to the bottom of my work pile, therefore it took longer than I thought. >> >> ### Motivation >> >> The Glibc allocator is reluctant to return memory to the OS, much more so than other allocators. Temporary malloc spikes often carry over as permanent RSS increase. >> >> Note that C-heap retention is difficult to observe. Since it is freed memory, it won't show up in NMT, it is just a part of private RSS. >> >> Theoretically, retained memory is not lost since it will be reused by future mallocs. Retaining memory is therefore a bet on the future behavior of the app. The allocator bets on the application needing memory in the near future, and to satisfy that need via malloc. >> >> But an app's malloc load can fluctuate wildly, with temporary spikes and long idle periods. And if the app rolls its own custom allocators atop of mmap, as hotspot does, a lot of that memory cannot be reused even though it counts toward its memory footprint. >> >> To help, Glibc exports an API to trim the C-heap: `malloc_trim(3)`. With JDK 18 [2], SAP contributed a new jcmd command to *manually* trim the C-heap on Linux. This RFE adds a complementary way to trim automatically. >> >> #### Is this even a problem? >> >> Do we have high malloc spikes in the JVM process? We assume that malloc load from hotspot is usually low since hotspot typically clusters allocations into custom areas - metaspace, code heap, arenas. >> >> But arenas are subject to Glibc mem retention too. I was surprised by that since I assumed 32k arena chunks were too big to be subject of Glibc retention. But I saw in experiments that high arena peaks often cause lasting RSS increase. >> >> And of course, both hotspot and JDK do a lot of finer-granular mallocs outside of custom allocators. >> >> But many cases of high memory retention in Glibc I have seen in third-party JNI code. Libraries allocate large buffers via malloc as temporary buffers. In fact, since we introduced the jcmd "System.trim_native_heap", some of our customers started to call this command periodically in scripts to counter these issues. >> >> Therefore I think while high malloc spikes are atypical for a JVM process, they can happen. Having a way to auto-trim the native heap makes sense. >> >> ### When should we trim? >> >> We want to trim when we know there is a lull in malloc activity coming. But we have no knowledge of the future. >> >> We could build a heuristic based on malloc frequency. But on closer inspection that is difficult. We cannot use NMT, since NMT has no complete picture (only knows hotspot) and is usually disabled in production anyway. The only way to get *all* mallocs would be to use Glibc malloc hooks. We have done so in desperate cases at SAP, but Glibc removed malloc hooks in 2.35. It would be a messy solution anyway; best to avoid it. >> >> The next best thing is synchronizing with the larger C-heap users in the VM: compiler and GC. But compiler turns out not to be such a problem, since the compiler uses arenas, and arena chunks are buffered in a free pool with a five-second delay. That means compiler activity that happens in bursts, like at VM startup, will just shuffle arena chunks around from/to the arena free pool, never bothering to call malloc or free. >> >> That leaves the GC, which was also the experts' recommendation in last year's discussion [1]. Most GCs do uncommit, and trimming the native heap fits well into this. And we want to time the trim to not get into the way of a GC. Plus, integrating trims into the GC cycle lets us reuse GC logging and timing, thereby making RSS changes caused by trim-native visible to the analyst. >> >> >> ### How it works: >> >> Patch adds new options (experimental for now, and shared among all GCs): >> >> >> -XX:+GCTrimNativeHeap >> -XX:GCTrimNativeHeapInterval= (defaults to 60) >> >> >> `GCTrimNativeHeap` is off by default. If enabled, it will cause the VM to trim the native heap on full GCs as well as periodically. The period is defined by `GCTrimNativeHeapInterval`. Periodic trimming can be completely switched off with `GCTrimNativeHeapInterval=0`; in that case, we will only trim on full GCs. >> >> ### Examples: >> >> This is an artificial test that causes two high malloc spikes with long idle periods. Observe how RSS recovers with trim but stays up without trim. The trim interval was set to 15 seconds for the test, and no GC was invoked here; this is periodic trimming. >> >> ![alloc-test](http://cr.openjdk.java.net/~stuefe/other/autotrim/rss-all-collectors.png) >> >> (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-all.sh) ) >> >> Spring pet clinic boots up, then idles. Once with, once without trim, with the trim interval at 60 seconds default. Of course, if it were actually doing something instead of idling, trim effects would be smaller. But the point of trimming is to recover memory in idle periods. >> >> ![petclinic bootup](http://cr.openjdk.java.net/~stuefe/other/autotrim/spring-petclinic-rss-with-and-without-trim.png)) >> >> (See here for parameters: [run script](http://cr.openjdk.java.net/~stuefe/other/autotrim/run-petclinic-boot.sh) ) >> >> >> >> ### Implementation >> >> One problem I faced when implementing this was that trimming was non-interruptable. GCs usually split the uncommit work into smaller portions, which is impossible for `malloc_trim()`. >> >> So very slow trims could introduce longer GC pauses. I did not want this, therefore I implemented two ways to trim: >> 1) GCs can opt to trim asynchronously. In that case, a `NativeTrimmer` thread runs on behalf of the GC and takes care of all trimming. The GC just nudges the `NativeTrimmer` at the end of its GC cycle, but the trim itself runs concurrently. >> 2) GCs can do the trim inside their own thread, synchronously. It will have to wait until the trim is done. >> >> (1) has the advantage of giving us periodic trims even without GC activity (Shenandoah does this out of the box). >> >> #### Serial >> >> Serial does the trimming synchronously as part of a full GC, and only then. I did not want to spawn a separate thread for the SerialGC. Therefore Serial is the only GC that does not offer periodic trimming, it just trims on full GC. >> >> #### Parallel, G1, Z >> >> All of them do the trimming asynchronously via `NativeTrimmer`. They schedule the native trim at the end of a full collection. They also pause the trimming at the beginning of a cycle to not trim during GCs. >> >> #### Shenandoah >> >> Shenandoah does the trimming synchronously in its service thread, similar to how it handles uncommits. Since the service thread already runs concurrently and continuously, it can do periodic trimming; no need to spin a new thread. And this way we can reuse the Shenandoah timing classes. >> >> ### Patch details >> >> - adds three new functions to the `os` namespace: >> - `os::trim_native_heap()` implementing trim >> - `os::can_trim_native_heap()` and `os::should_trim_native_heap()` to return whether platform supports trimming resp. whether the platform considers trimming to be useful. >> - replaces implementation of the cmd "System.trim_native_heap" with the new `os::trim_native_heap` >> - provides a new wrapper function wrapping the tedious `mallinfo()` vs `mallinfo2()` business: `os::Linux::get_mallinfo()` >> - adds a GC-shared utility class, `GCTrimNative`, that takes care of trimming and GC-logging and houses the `NativeTrimmer` thread class. >> - adds a regression test >> >> >> ### Tests >> >> Tested older Glibc (2.31), and newer Glibc (2.35) (`mallinfo()` vs` mallinfo2()`), on Linux x64. >> >> The rest of the tests will be done by GHA and in our SAP nightlies. >> >> >> ### Remarks >> >> #### How about other allocators? >> >> I have seen this retention problem mainly with the Glibc and the AIX libc. Muslc returns memory more eagerly to the OS. I also tested with jemalloc and found it also reclaims more aggressively, therefore I don't think MacOS or BSD are affected that much by retention either. >> >> #### Trim costs? >> >> Trim-native is a tradeoff between memory and performance. We pay >> - The cost to do the trim depends on how much is trimmed. Time ranges on my machine between < 1ms for no-op trims, to ~800ms for 32GB trims. >> - The cost for re-acquiring the memory, should the memory be needed again, is the second cost factor. >> >> #### Predicting malloc_trim effects? >> >> `ShenandoahUncommit` avoids uncommits if they are not necessary, thus avoiding work and gc log spamming. I liked that and tried to follow that example. Tried to devise a way to predict the effect trim could have based on allocator info from mallinfo(3). That was quite frustrating since the documentation was confusing and I had to do a lot of experimenting. In the end, I came up with a heuristic to prevent obviously pointless trim attempts; see `os::should_trim_native_heap()`. I am not completely happy with it. >> >> #### glibc.malloc.trim_threshold? >> >> glibc has a tunable that looks like it could influence the willingness of Glibc to return memory to the OS, the "trim_threshold". In practice, I could not get it to do anything useful. Regardless of the setting, it never seemed to influence the trimming behavior. Even if it would work, I'm not sure we'd want to use that, since by doing malloc_trim manually we can space out the trims as we see fit, instead of paying the trim price for free(3). >> >> >> - [1] https://mail.openjdk.org/pipermail/hotspot-dev/2021-August/054323.html >> - [2] https://bugs.openjdk.org/browse/JDK-8269345 > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - reduce test runtime on slow hardware > - make tests more stable on slow hardware Another question: does it have to create another thread? can it piggyback to e.g. `ServiceThread`? ------------- PR: https://git.openjdk.org/jdk/pull/10085 From dlong at openjdk.org Fri Sep 2 20:39:46 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 2 Sep 2022 20:39:46 GMT Subject: RFR: 8293287 add ReplayReduce flag In-Reply-To: <79t3IdX7_aa4bpwrD9kHGiijB4x77reAW-rhW7jZX_0=.a9dfccb0-8dbd-4d7b-b66f-8a727746338e@github.com> References: <79t3IdX7_aa4bpwrD9kHGiijB4x77reAW-rhW7jZX_0=.a9dfccb0-8dbd-4d7b-b66f-8a727746338e@github.com> Message-ID: On Fri, 2 Sep 2022 16:07:47 GMT, Vladimir Kozlov wrote: >> Add an experimental flag to help developers "reduce" a replay file. >> >> As a first step, I plan to simulate reduced inlining. This will output multiple "compile" lines as if the first level of inlining never happened: >> A --> B --> C >> A --> D --> E >> becomes >> B --> C >> D --> E >> Developers can repeat iteratively until the replay crash no longer reproduces. > > src/hotspot/share/ci/ciEnv.cpp line 1651: > >> 1649: if (task) { >> 1650: #ifdef COMPILER2 >> 1651: if (ReplayReduce && compiler_data() != NULL) { > > Is this feature when you are replaying compilation? If yes, add `ReplayCompiles` check too. It seems most useful with ReplayCompiles, but I don't want to require it. A developer might want to turn on ReplayReduce without ReplayCompiles, to save a replay step, for example when running generated tests from creduce or javafuzzer without an existing replay file. ------------- PR: https://git.openjdk.org/jdk/pull/10134 From dholmes at openjdk.org Fri Sep 2 20:40:59 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 2 Sep 2022 20:40:59 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread In-Reply-To: References: Message-ID: <8Utk-bzbBROX3wb9XELnyeJCldtrwlWf_bBHQD7KicU=.4adb9aab-baeb-4d5e-9ebd-e2345b1b7e83@github.com> On Fri, 2 Sep 2022 14:47:35 GMT, Kevin Walls wrote: > This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). > > A JVMTI operation could call threadObj() and clear the Windows GetLastError value. > > Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. This is fine to me - modulo changing the comment as below. As I'm away on vacation I will pre-approve. Please be sure @dcubed-ojdk sees this before integrating. Thanks. src/hotspot/share/runtime/javaThread.cpp line 165: > 163: oop JavaThread::threadObj() const { > 164: // Using Thread::current_or_null_safe() here risks that calling threadObj() can > 165: // overwrite a native thread local, e.g. JVMTI operations clearing GetLastError on Windows. Suggestion: // Ideally we would verify the current thread is oop_safe when this is called, but as we can // be called from a signal handler we would have to use Thread::current_or_null_safe(). That // has overhead and also interacts poorly with GetLastError on Windows due to the use of TLS. // Instead callers must verify oop safe access. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10147 From dlong at openjdk.org Fri Sep 2 20:41:58 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 2 Sep 2022 20:41:58 GMT Subject: RFR: 8293287 add ReplayReduce flag [v2] In-Reply-To: References: Message-ID: > Add an experimental flag to help developers "reduce" a replay file. > > As a first step, I plan to simulate reduced inlining. This will output multiple "compile" lines as if the first level of inlining never happened: > A --> B --> C > A --> D --> E > becomes > B --> C > D --> E > Developers can repeat iteratively until the replay crash no longer reproduces. Dean Long has updated the pull request incrementally with two additional commits since the last revision: - add assert - fix for TestVMNoCompLevel.java test failure ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10134/files - new: https://git.openjdk.org/jdk/pull/10134/files/b5959eb6..73d6e812 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10134&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10134&range=00-01 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10134.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10134/head:pull/10134 PR: https://git.openjdk.org/jdk/pull/10134 From kvn at openjdk.org Fri Sep 2 22:23:40 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 2 Sep 2022 22:23:40 GMT Subject: RFR: 8293287 add ReplayReduce flag [v2] In-Reply-To: References: Message-ID: <0THbzp1y6RrdE9KH_8xbzLx2YNmYJidQ0u8P7NuyIzg=.0e6cf4cd-97fb-45b3-917a-40ee3c151990@github.com> On Fri, 2 Sep 2022 20:41:58 GMT, Dean Long wrote: >> Add an experimental flag to help developers "reduce" a replay file. >> >> As a first step, I plan to simulate reduced inlining. This will output multiple "compile" lines as if the first level of inlining never happened: >> A --> B --> C >> A --> D --> E >> becomes >> B --> C >> D --> E >> Developers can repeat iteratively until the replay crash no longer reproduces. > > Dean Long has updated the pull request incrementally with two additional commits since the last revision: > > - add assert > - fix for TestVMNoCompLevel.java test failure Okay. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10134 From vlivanov at openjdk.org Fri Sep 2 22:52:42 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 2 Sep 2022 22:52:42 GMT Subject: RFR: 8293245: x86_64: Extract Adler32 stub implementation into stubGenerator_x86_64_adler.cpp [v3] In-Reply-To: References: Message-ID: > Extract Adler32 stub implementation into a dedicated file (`stubGenerator_x86_64_adler.cpp`). > > Minor cleanups: > * got rid of `updateBytesAdler32()` by manually inlining it into `generate_updateBytesAdler32()` > * unified usage of `r14` as a scratch register > * added 32-byte alignment for the constants > > Testing: hs-tier1 - hs-tier4 Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - fix - Merge branch 'master' into stub.x86_64.adler - Move Adler stub definitions into stubGenerator_x86_64_adler.cpp - update - fix - stubGenerator_x86_64.hpp ------------- Changes: https://git.openjdk.org/jdk/pull/10126/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10126&range=02 Stats: 542 lines in 6 files changed: 268 ins; 274 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10126.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10126/head:pull/10126 PR: https://git.openjdk.org/jdk/pull/10126 From vlivanov at openjdk.org Fri Sep 2 23:09:21 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 2 Sep 2022 23:09:21 GMT Subject: RFR: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files [v3] In-Reply-To: References: Message-ID: > Move code related to AES and GHASH stubs from `stubGenerator_x86_64.cpp` into `stubGenerator_x86_64_aes.cpp` and `stubGenerator_x86_64_ghash.cpp` respectively. > > Testing: hs-tier1 - hs-tier4 Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into stub.x86_64.aes - AESBlockSize - update - Refactor AES and GHASH stubs. - update - fix - stubGenerator_x86_64.hpp ------------- Changes: https://git.openjdk.org/jdk/pull/10124/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10124&range=02 Stats: 7521 lines in 6 files changed: 3779 ins; 3721 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/10124.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10124/head:pull/10124 PR: https://git.openjdk.org/jdk/pull/10124 From vlivanov at openjdk.org Fri Sep 2 23:19:30 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 2 Sep 2022 23:19:30 GMT Subject: RFR: 8293254: x86_64: Extract arraycopy stub implementations into a separate file [v3] In-Reply-To: <1_CR20VVro8dAulbOEksXBiQ50Jt5jbMpc2vXFyV6xw=.ab22694f-db1b-43fd-8f69-e2eff89c5f85@github.com> References: <1_CR20VVro8dAulbOEksXBiQ50Jt5jbMpc2vXFyV6xw=.ab22694f-db1b-43fd-8f69-e2eff89c5f85@github.com> Message-ID: > Move arraycopy stub implementations from `stubGenerator_x86_64.cpp` into `stubGenerator_x86_64_arraycopy.cpp`. > > Testing: hs-tier1 - hs-tier4 > > PS: FTR I left `MacroAssembler::generate_fill_avx3()` intact because it is called from `MacroAssembler::generate_fill()` which is shared between x86_64 and x86_32. Otherwise, I would either need to copy `MacroAssembler::generate_fill()` or put it into a separate file (e.g., `stubGenerator_x86.cpp` or `stubGenerator_x86_arraycopy.cpp`). IMO it doesn't add much value compared to keeping it in `macroAssembler_x86.cpp`. Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into stub.x86_64.arraycopy - arraycopy stubs - fix hs-minimal build - update - fix - stubGenerator_x86_64.hpp ------------- Changes: https://git.openjdk.org/jdk/pull/10128/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10128&range=02 Stats: 5127 lines in 5 files changed: 2576 ins; 2550 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10128.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10128/head:pull/10128 PR: https://git.openjdk.org/jdk/pull/10128 From vlivanov at openjdk.org Fri Sep 2 23:22:54 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 2 Sep 2022 23:22:54 GMT Subject: RFR: 8293285: x86_64: Move libm stub implementations to StubGenerator [v3] In-Reply-To: References: Message-ID: > Move libm stub implementations (used for trigonometric math intrinsics) from MacroAssembler to StubGenerator. > > x86_32-specific code is left intact, but all `macroAssembler_x86_*.cpp` files are renamed to `macroAssembler_x86_32_*.cpp` since there's no x86_64-specific code left there anymore. > > Testing: hs-tier1 - hs-tier4 Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' into stub.x86_64.libm - Extract libm stub implementations into separate files - update - Merge branch 'master' into stub.x86_64.hpp - RuntimeStub - fix hs-minimal build - update - fix - stubGenerator_x86_64.hpp ------------- Changes: https://git.openjdk.org/jdk/pull/10133/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10133&range=02 Stats: 23104 lines in 26 files changed: 11818 ins; 11257 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/10133.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10133/head:pull/10133 PR: https://git.openjdk.org/jdk/pull/10133 From dlong at openjdk.org Fri Sep 2 23:30:44 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 2 Sep 2022 23:30:44 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: References: Message-ID: <61NHaDLfEQn-CYuywwXtsaW5yjla8A-T7GM_Qd6Htyc=.f7fab619-df0c-455f-bcce-b26ce2abfa6b@github.com> On Fri, 2 Sep 2022 00:04:17 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose 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 branch 'master' of https://git.openjdk.org/jdk into compressed-stream > - 8292758: put support for UNSIGNED5 format into its own header file I'm concerned about the "excluded bytes" change. It appears to change the encoding, which would mean that SA would not be able to read streams from earlier JVMs, which may or may not be a concern. I suggest splitting this up into the straight-forward refactor (without the excluded bytes change), then adding excluded bytes as a follow-up. ------------- Changes requested by dlong (Reviewer). PR: https://git.openjdk.org/jdk/pull/10067 From dlong at openjdk.org Fri Sep 2 23:38:39 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 2 Sep 2022 23:38:39 GMT Subject: RFR: 8293287 add ReplayReduce flag [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 20:41:58 GMT, Dean Long wrote: >> Add an experimental flag to help developers "reduce" a replay file. >> >> As a first step, I plan to simulate reduced inlining. This will output multiple "compile" lines as if the first level of inlining never happened: >> A --> B --> C >> A --> D --> E >> becomes >> B --> C >> D --> E >> Developers can repeat iteratively until the replay crash no longer reproduces. > > Dean Long has updated the pull request incrementally with two additional commits since the last revision: > > - add assert > - fix for TestVMNoCompLevel.java test failure Unfortunately, the TestVMNoCompLevel.java test is still failing on some platforms. I'm tempted to remove that test, as it doesn't not seem to add value anymore. ------------- PR: https://git.openjdk.org/jdk/pull/10134 From vlivanov at openjdk.org Fri Sep 2 23:40:32 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 2 Sep 2022 23:40:32 GMT Subject: RFR: 8293329: x86: Improve handling of constants in AES/GHASH stubs Message-ID: Pre-generating constants saves on startup and static/dynamic footprint a bit, plus simplifies bootstrapping logic. As a downside, constants aren't guaranteed to be always reachable anymore, but since they are used from stubs, finding a scratch register when needed is not a problem. Testing: - [x] hs-tier1 - hs-tier4 w/ `-XX:+ForceUnreachable` - [x] x86_32 build ------------- Depends on: https://git.openjdk.org/jdk/pull/10124 Commit messages: - constants Changes: https://git.openjdk.org/jdk/pull/10152/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10152&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293329 Stats: 502 lines in 6 files changed: 152 ins; 227 del; 123 mod Patch: https://git.openjdk.org/jdk/pull/10152.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10152/head:pull/10152 PR: https://git.openjdk.org/jdk/pull/10152 From iklam at openjdk.org Fri Sep 2 23:51:03 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 2 Sep 2022 23:51:03 GMT Subject: RFR: 8293293: Move archive heap loading code out of heapShared.cpp [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 12:42:36 GMT, Erik Joelsson wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleaned up header files > > Build change looks good. Thanks for the review @erikj79 @coleenp ------------- PR: https://git.openjdk.org/jdk/pull/10138 From iklam at openjdk.org Fri Sep 2 23:51:04 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 2 Sep 2022 23:51:04 GMT Subject: Integrated: 8293293: Move archive heap loading code out of heapShared.cpp In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 05:31:35 GMT, Ioi Lam wrote: > I moved all code related to loading the archive heap regions into a new file, archiveHeapLoader.cpp. > > A diff of the new archiveHeapLoader.cpp and the old heapShared.cpp shows that the moved code is identical, except for the change of `HeapShared::` to `ArchiveHeapLoader::`. > > I also removed unnecessary entries in JVM_EXCLUDE_FILES that are already covered by the `cds/` pattern. This pull request has now been integrated. Changeset: ac05bc86 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/ac05bc8605bcf343f0c230868af3056f03461e01 Stats: 1294 lines in 19 files changed: 683 ins; 563 del; 48 mod 8293293: Move archive heap loading code out of heapShared.cpp Reviewed-by: erikj, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/10138 From kvn at openjdk.org Sat Sep 3 00:55:38 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 3 Sep 2022 00:55:38 GMT Subject: RFR: 8293329: x86: Improve handling of constants in AES/GHASH stubs In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 23:24:32 GMT, Vladimir Ivanov wrote: > Pre-generating constants saves on startup and static/dynamic footprint a bit, plus simplifies bootstrapping logic. > > As a downside, constants aren't guaranteed to be always reachable anymore, but since they are used from stubs, finding a scratch register when needed is not a problem. > > Testing: > - [x] hs-tier1 - hs-tier4 w/ `-XX:+ForceUnreachable` > - [x] x86_32 build I would like to see the effect on performance. In worst case constants will not be reachable always. Changes are fine if the effect is negligible. ------------- PR: https://git.openjdk.org/jdk/pull/10152 From kvn at openjdk.org Sat Sep 3 00:55:40 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 3 Sep 2022 00:55:40 GMT Subject: RFR: 8293287 add ReplayReduce flag [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 23:36:38 GMT, Dean Long wrote: > Unfortunately, the TestVMNoCompLevel.java test is still failing on some platforms. I'm tempted to remove that test, as it doesn't not seem to add value anymore. Can you explain the issue with this test and your changes? New code should be off by default. ------------- PR: https://git.openjdk.org/jdk/pull/10134 From sspitsyn at openjdk.org Sat Sep 3 01:01:11 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 3 Sep 2022 01:01:11 GMT Subject: RFR: 8291586: Broken links in JVMTI specification Message-ID: The Loom related spec of the extension VirtualThreadMount and VirtualThreadUnmount events in the jvmti.xml is surrounded by the elements ` ... `, so these specs have to be ignored when the `jvmti.html `is generated. However the `jvmti.xsl` which does the XSL transformation misses to do that when the description of the JVM TI capabilities is collected. The fix is a one-liner: diff --git a/src/hotspot/share/prims/jvmti.xsl b/src/hotspot/share/prims/jvmti.xsl index 5ef89f91daf..d54d2a371e6 100644 --- a/src/hotspot/share/prims/jvmti.xsl +++ b/src/hotspot/share/prims/jvmti.xsl @@ -1172,7 +1172,7 @@ typedef struct { - + The correctness verification both the generated `jvmti.html` and `jvmti.h` was checked. TBD: mach5 sanity builds and `nsk.jvmti` tests runs. ------------- Commit messages: - 8291586: Broken links in JVMTI specification Changes: https://git.openjdk.org/jdk/pull/10153/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10153&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291586 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10153.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10153/head:pull/10153 PR: https://git.openjdk.org/jdk/pull/10153 From dlong at openjdk.org Sat Sep 3 02:58:38 2022 From: dlong at openjdk.org (Dean Long) Date: Sat, 3 Sep 2022 02:58:38 GMT Subject: RFR: 8293287 add ReplayReduce flag [v2] In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 00:51:45 GMT, Vladimir Kozlov wrote: > Can you explain the issue with this test and your changes? New code should be off by default. I had to move the call to reset() (which clears parsing errors) to allow multiple compile commands. This revealed an existing problem with compiler/ciReplay/TestVMNoCompLevel.java. This test removes the last token from the "compile" line, trying to simulate a pre-2013 replay file. Removing the last token is wrong if there are inlining tokens. I could fix the test, but I don't see the value. I don't think a 2022 JVM needs to read pre-2013 replay files. If necessary, an old replay file can be edited to allow it to be parsed by a recent JVM. I proposed to deleted the test and related workarounds in the code. ------------- PR: https://git.openjdk.org/jdk/pull/10134 From jrose at openjdk.org Sat Sep 3 03:38:35 2022 From: jrose at openjdk.org (John R Rose) Date: Sat, 3 Sep 2022 03:38:35 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: <61NHaDLfEQn-CYuywwXtsaW5yjla8A-T7GM_Qd6Htyc=.f7fab619-df0c-455f-bcce-b26ce2abfa6b@github.com> References: <61NHaDLfEQn-CYuywwXtsaW5yjla8A-T7GM_Qd6Htyc=.f7fab619-df0c-455f-bcce-b26ce2abfa6b@github.com> Message-ID: On Fri, 2 Sep 2022 23:28:38 GMT, Dean Long wrote: > I suggest splitting this up into the straight-forward refactor (without the excluded bytes change), then adding excluded bytes as a follow-up. Yes, that is a slight change. Splitting is not necessary for the reason you mention because this PR includes SA changes. This SA change is tested by several jtreg tests: That is, injecting bugs causes SA tests to fail, and fixing them fixes the tests. This is the case because the compressed stream data structure is used for all stack walking. So if there's a bug, we find it immediately. And the same is true for SA unit tests which peform stack walking. Net result: It's safe, there is no bug, because testing coverage is robust. The math of the encoding is the same whether there are 255 or 256 byte values available, so the adjustment is very low risk. (The math works for any underlying byte type or size; we choose 8-bit bytes excluding nulls to provide 255 distinct tokens.) The benefit is that the encoding can be accompanied by null termination, which enhances debuggability and resilience against bad counts and bad pointers. ------------- PR: https://git.openjdk.org/jdk/pull/10067 From stuefe at openjdk.org Sat Sep 3 04:20:37 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 3 Sep 2022 04:20:37 GMT Subject: RFR: JDK-8293114: GC should trim the native heap [v2] In-Reply-To: References: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> Message-ID: On Fri, 2 Sep 2022 20:04:11 GMT, Zhengyu Gu wrote: > Another question: does it have to create another thread? can it piggyback to e.g. `ServiceThread`? It does so on Shenandoah, but the problem is the time trimming takes. As I wrote, it can take <1ms to up to almost a second. You then block the service thread for that time. So, even on Shenandoah I am not sure I shouldn't use a different thread. ------------- PR: https://git.openjdk.org/jdk/pull/10085 From kvn at openjdk.org Sat Sep 3 04:54:28 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 3 Sep 2022 04:54:28 GMT Subject: RFR: 8293287 add ReplayReduce flag [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 20:41:58 GMT, Dean Long wrote: >> Add an experimental flag to help developers "reduce" a replay file. >> >> As a first step, I plan to simulate reduced inlining. This will output multiple "compile" lines as if the first level of inlining never happened: >> A --> B --> C >> A --> D --> E >> becomes >> B --> C >> D --> E >> Developers can repeat iteratively until the replay crash no longer reproduces. > > Dean Long has updated the pull request incrementally with two additional commits since the last revision: > > - add assert > - fix for TestVMNoCompLevel.java test failure Okay ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10134 From alanb at openjdk.org Sat Sep 3 06:05:38 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 3 Sep 2022 06:05:38 GMT Subject: RFR: 8291586: Broken links in JVMTI specification In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 00:52:56 GMT, Serguei Spitsyn wrote: > The Loom related spec of the extension VirtualThreadMount and VirtualThreadUnmount events in the jvmti.xml is surrounded by the elements ` ... `, so these specs have to be ignored when the `jvmti.html `is generated. However the `jvmti.xsl` which does the XSL transformation misses to do that when the description of the JVM TI capabilities is collected. > > The fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmti.xsl b/src/hotspot/share/prims/jvmti.xsl > index 5ef89f91daf..d54d2a371e6 100644 > --- a/src/hotspot/share/prims/jvmti.xsl > +++ b/src/hotspot/share/prims/jvmti.xsl > @@ -1172,7 +1172,7 @@ typedef struct { > > > > - > + > > > > > > The correctness verification both the generated `jvmti.html` and `jvmti.h` was checked. > TBD: mach5 sanity builds and `nsk.jvmti` tests runs. `not(ancestor::elide)` looks right. Looks good. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/10153 From dlong at openjdk.org Sat Sep 3 07:52:31 2022 From: dlong at openjdk.org (Dean Long) Date: Sat, 3 Sep 2022 07:52:31 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: References: Message-ID: <-RXfpRzuGeXmyRSEg2u0XNJETE5VHaI9wrailPSF3IA=.26c9b859-fa04-442b-9fdb-9ead1b07ab0c@github.com> On Fri, 2 Sep 2022 00:04:17 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose 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 branch 'master' of https://git.openjdk.org/jdk into compressed-stream > - 8292758: put support for UNSIGNED5 format into its own header file Wouldn't the SA stack walk fail when attaching to a core dump from an earlier JVM that does not exclude nulls? ------------- PR: https://git.openjdk.org/jdk/pull/10067 From sspitsyn at openjdk.org Sat Sep 3 09:26:38 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 3 Sep 2022 09:26:38 GMT Subject: RFR: 8291586: Broken links in JVMTI specification In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 00:52:56 GMT, Serguei Spitsyn wrote: > The Loom related spec of the extension VirtualThreadMount and VirtualThreadUnmount events in the jvmti.xml is surrounded by the elements ` ... `, so these specs have to be ignored when the `jvmti.html `is generated. However the `jvmti.xsl` which does the XSL transformation misses to do that when the description of the JVM TI capabilities is collected. > > The fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmti.xsl b/src/hotspot/share/prims/jvmti.xsl > index 5ef89f91daf..d54d2a371e6 100644 > --- a/src/hotspot/share/prims/jvmti.xsl > +++ b/src/hotspot/share/prims/jvmti.xsl > @@ -1172,7 +1172,7 @@ typedef struct { > > > > - > + > > > > > > The correctness verification both the generated `jvmti.html` and `jvmti.h` was checked. > TBD: mach5 sanity builds and `nsk.jvmti` tests runs. Thank you for review, Alan! ------------- PR: https://git.openjdk.org/jdk/pull/10153 From sspitsyn at openjdk.org Sat Sep 3 09:32:51 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 3 Sep 2022 09:32:51 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v2] In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:28:24 GMT, Alex Menkov wrote: >> The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) >> >> cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. >> After successful RedefineClasses it should be reset. >> The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated comments test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 76: > 74: private static byte[] initialClassBytes; > 75: > 76: private static class VersionScanner extends ClassVisitor { This class needs some explanation. It is unclear how does it work. Could you, please, add relevant comments where needed? For instance, how are the class file bytes constructed and what role does the version play. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 236: > 234: redefine(2, 5); // updates cached class bytes > 235: retransform(3, 2); > 236: retransform(4, 2); The comments for all test cases need to be aligned. Also, it is better to comment all redefine/retransform cases. ------------- PR: https://git.openjdk.org/jdk/pull/10032 From sspitsyn at openjdk.org Sat Sep 3 09:42:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 3 Sep 2022 09:42:22 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v2] In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:28:24 GMT, Alex Menkov wrote: >> The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) >> >> cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. >> After successful RedefineClasses it should be reset. >> The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated comments test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 179: > 177: if (err != JVMTI_ERROR_NONE) { > 178: _log("nRedefine: SetEventNotificationMode(JVMTI_DISABLE) error %d\n", err); > 179: } It makes sense to introduce an utility function which does SetEventNotificationMode. It can be two separate functions to enable and disable or one single function can support both cases. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 195: > 193: _log("nRedefine: classLoadHookSavedClassBytes is NULL\n"); > 194: return nullptr; > 195: } The checks 181-195 seems to be the same in functions nRedefine and nRetransform, so one utility function can be used in both cases. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 274: > 272: classLoadHookSavedClassBytes = nullptr; > 273: > 274: return result; The fragments 197-214 and 256-274 do the same. I'd suggest to define and use a function that does this post-processing. ------------- PR: https://git.openjdk.org/jdk/pull/10032 From sspitsyn at openjdk.org Sat Sep 3 09:50:01 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 3 Sep 2022 09:50:01 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v2] In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:28:24 GMT, Alex Menkov wrote: >> The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) >> >> cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. >> After successful RedefineClasses it should be reset. >> The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated comments Alex, My apology for latency with review. The fix itself looks good to me. Thank you for your good analysis and fix! I've posted several comments on new test. It feels like more comments are needed. Could you, please, add them where you consider it relevant? Also, I'm curious how did you verify that no regressions have been introduced? Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10032 From kevinw at openjdk.org Sat Sep 3 11:08:41 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Sat, 3 Sep 2022 11:08:41 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread In-Reply-To: <8Utk-bzbBROX3wb9XELnyeJCldtrwlWf_bBHQD7KicU=.4adb9aab-baeb-4d5e-9ebd-e2345b1b7e83@github.com> References: <8Utk-bzbBROX3wb9XELnyeJCldtrwlWf_bBHQD7KicU=.4adb9aab-baeb-4d5e-9ebd-e2345b1b7e83@github.com> Message-ID: On Fri, 2 Sep 2022 20:33:37 GMT, David Holmes wrote: >> This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). >> >> A JVMTI operation could call threadObj() and clear the Windows GetLastError value. >> >> Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. > > src/hotspot/share/runtime/javaThread.cpp line 165: > >> 163: oop JavaThread::threadObj() const { >> 164: // Using Thread::current_or_null_safe() here risks that calling threadObj() can >> 165: // overwrite a native thread local, e.g. JVMTI operations clearing GetLastError on Windows. > > Suggestion: > > // Ideally we would verify the current thread is oop_safe when this is called, but as we can > // be called from a signal handler we would have to use Thread::current_or_null_safe(). That > // has overhead and also interacts poorly with GetLastError on Windows due to the use of TLS. > // Instead callers must verify oop safe access. Thanks David, will update comment and check Dan is OK with this. ------------- PR: https://git.openjdk.org/jdk/pull/10147 From dlong at openjdk.org Sat Sep 3 21:56:50 2022 From: dlong at openjdk.org (Dean Long) Date: Sat, 3 Sep 2022 21:56:50 GMT Subject: RFR: 8293287 add ReplayReduce flag [v3] In-Reply-To: References: Message-ID: > Add an experimental flag to help developers "reduce" a replay file. > > As a first step, I plan to simulate reduced inlining. This will output multiple "compile" lines as if the first level of inlining never happened: > A --> B --> C > A --> D --> E > becomes > B --> C > D --> E > Developers can repeat iteratively until the replay crash no longer reproduces. Dean Long has updated the pull request incrementally with one additional commit since the last revision: remove support for pre-2013 replay files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10134/files - new: https://git.openjdk.org/jdk/pull/10134/files/73d6e812..4ba53b45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10134&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10134&range=01-02 Stats: 88 lines in 2 files changed: 0 ins; 87 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10134.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10134/head:pull/10134 PR: https://git.openjdk.org/jdk/pull/10134 From zgu at openjdk.org Sat Sep 3 23:25:39 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Sat, 3 Sep 2022 23:25:39 GMT Subject: RFR: JDK-8293114: GC should trim the native heap [v2] In-Reply-To: References: <23KpPM4oPV6F1nz3g5CvIqvuX-ANcsMH4GuVNXjR-Lw=.b8d0fa2d-bb85-4899-8e21-f68ea64b988d@github.com> Message-ID: <3d7NQ4gxKbY6jXhFZkMbBIr-yu43GdbJVLHob8Fk4qQ=.09c59f61-0b78-4486-92a1-6e4ca6995bac@github.com> On Sat, 3 Sep 2022 04:18:23 GMT, Thomas Stuefe wrote: > > Another question: does it have to create another thread? can it piggyback to e.g. `ServiceThread`? > > It does so on Shenandoah, but the problem is the time trimming takes. As I wrote, it can take <1ms to up to almost a second. You then block the service thread for that time. So, even on Shenandoah I am not sure I shouldn't use a different thread. Yea, you probably should not use `ShenandoahControlThread`, it may delay GC from happening. ------------- PR: https://git.openjdk.org/jdk/pull/10085 From jrose at openjdk.org Sat Sep 3 23:46:41 2022 From: jrose at openjdk.org (John R Rose) Date: Sat, 3 Sep 2022 23:46:41 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v3] In-Reply-To: References: Message-ID: > Refactor code from inside of CompressedStream into its own unit. > > This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). > > Add gtests. John R Rose has updated the pull request incrementally with one additional commit since the last revision: add more support for SA including vmStructs; tweak some debug code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10067/files - new: https://git.openjdk.org/jdk/pull/10067/files/d903f2c7..dc30f7ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=01-02 Stats: 346 lines in 6 files changed: 284 ins; 43 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/10067.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10067/head:pull/10067 PR: https://git.openjdk.org/jdk/pull/10067 From cjplummer at openjdk.org Sun Sep 4 00:26:44 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Sun, 4 Sep 2022 00:26:44 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: <-RXfpRzuGeXmyRSEg2u0XNJETE5VHaI9wrailPSF3IA=.26c9b859-fa04-442b-9fdb-9ead1b07ab0c@github.com> References: <-RXfpRzuGeXmyRSEg2u0XNJETE5VHaI9wrailPSF3IA=.26c9b859-fa04-442b-9fdb-9ead1b07ab0c@github.com> Message-ID: On Sat, 3 Sep 2022 07:48:50 GMT, Dean Long wrote: > Wouldn't the SA stack walk fail when attaching to a core dump from an earlier JVM that does not exclude nulls? I'm not sure how important compatibility is with older JVMs. SA is capable of (if properly maintained) connecting to any JVM. You'll see signs of that in the code: // The threadStatus is only present starting in 1.5 if (threadStatusField != null) { Oop holderOop = threadHolderField.getValue(threadOop); return (int) threadStatusField.getValue(holderOop); } else { // All we can easily figure out is if it is alive, but that is // enough info for a valid unknown status. ... } However, attempts like this one are ancient, and certainly this one should be removed. There's probably a 100 other reasons why attaching to a 1.5 JVM won't work. We don't do any compatibility testing with older JVMs. For the most part I'd say SA users should always match SA with the version of the JVM they are targeting. I'd be interested in hearing if anyone feels otherwise. ------------- PR: https://git.openjdk.org/jdk/pull/10067 From cstein at openjdk.org Mon Sep 5 06:12:18 2022 From: cstein at openjdk.org (Christian Stein) Date: Mon, 5 Sep 2022 06:12:18 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6] In-Reply-To: References: Message-ID: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com> > Please review the change to update to using jtreg 7. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Update configure to check for jtreg 7 or later - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Revert junit.java Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Update to new JUnit JAR file With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2"). This change updates the hard-coded library tag value to the new JUnit JAR file. Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316, in order to unblock the "Update to use jtreg 7" PR 9393: https://github.com/openjdk/jdk/pull/9393 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 - ... and 4 more: https://git.openjdk.org/jdk/compare/3464019d...16b140ab ------------- Changes: https://git.openjdk.org/jdk/pull/9393/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9393&range=05 Stats: 11 lines in 8 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/9393.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9393/head:pull/9393 PR: https://git.openjdk.org/jdk/pull/9393 From stuefe at openjdk.org Mon Sep 5 06:39:21 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 5 Sep 2022 06:39:21 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6] In-Reply-To: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com> References: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com> Message-ID: On Mon, 5 Sep 2022 06:12:18 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 7. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Update configure to check for jtreg 7 or later > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Revert junit.java > > Commit https://github.com/openjdk/jdk/commit/45c3e898ed538545921395372fe507e9111401e1 deleted this file > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Update to new JUnit JAR file > > With version 7 of `jtreg` comes JUnit Platform 1.8.2 (also known as "JUnit 5.8.2"). > This change updates the hard-coded library tag value to the new JUnit JAR file. > Therefore, it partly addresses https://bugs.openjdk.org/browse/JDK-8292316, > in order to unblock the "Update to use jtreg 7" PR 9393: > https://github.com/openjdk/jdk/pull/9393 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - Merge branch 'openjdk:master' into JDK-8289798-jtreg-7 > - ... and 4 more: https://git.openjdk.org/jdk/compare/3464019d...16b140ab Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9393 From cstein at openjdk.org Mon Sep 5 07:21:41 2022 From: cstein at openjdk.org (Christian Stein) Date: Mon, 5 Sep 2022 07:21:41 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6] In-Reply-To: References: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com> Message-ID: <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com> On Mon, 5 Sep 2022 06:36:04 GMT, Thomas Stuefe wrote: > Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version? Yes, down to JDK 11. Quote from [Coming soon: jtreg 7](https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html) > Also starting with version 7, jtreg is compiled with JDK 11 and so requires a recent release of JDK 11 to run it. And it should have said more correctly: _...requires a recent release of JDK 11 **or later** to run it._ ------------- PR: https://git.openjdk.org/jdk/pull/9393 From stuefe at openjdk.org Mon Sep 5 07:42:41 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 5 Sep 2022 07:42:41 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6] In-Reply-To: <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com> References: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com> <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com> Message-ID: On Mon, 5 Sep 2022 07:18:09 GMT, Christian Stein wrote: > > Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down to which version? > > Yes, down to JDK 11. > > Quote from [Coming soon: jtreg 7](https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html) > > > Also starting with version 7, jtreg is compiled with JDK 11 and so requires a recent release of JDK 11 to run it. I read this to mean JT_JAVA, so the JVM running jtreg, not the testee VM. But you are saying that the testee VM (`-jdk` option) can be JDK11 or later? I wonder whether I can use jtreg7 to test downport JDKs, especially since you wrote "This did affect some existing JDK tests, but those tests that relied on specific jar file names have already been updated." So I guess at the minimum we would have to downport those test changes to be able to test older JDKs with the new jtreg, right? ------------- PR: https://git.openjdk.org/jdk/pull/9393 From duke at openjdk.org Mon Sep 5 07:49:32 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 5 Sep 2022 07:49:32 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 13:31:46 GMT, Thomas Stuefe wrote: >> Hi! >> >> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. >> >> When I've left ResourceMarks in place I've also commented which calls requires them. >> >> This passes tier1, tier2 tests. > > src/hotspot/share/code/codeCache.cpp line 1485: > >> 1483: get_code_heap_flag_name(code_blob_type)); >> 1484: const char *msg1 = msg1_stream.base(); >> 1485: const char *msg2 = msg2_stream.base(); > > I would do this only in places where it's super-obvious nothing bad will happen and where it cannot bitrot. Here it's not, since you assign it to a temporary variable. Someone inattentive may modify it in the future, forgetting about why this is special. > > Since the error is hard to catch and the benefit tiny, I would leave this as `as_string`. This is just my gut feeling, others may disagree. I think it's a very good idea. > src/hotspot/share/utilities/ostream.hpp line 221: > >> 219: // A stringStream may free the pointer returned >> 220: // if any of its methods are called, therefore >> 221: // take care in using this method. > > Comment is a bit misleading, what does "borrow" mean? > > Suggestion: "Returns internal buffer. Returned buffer is only guaranteed to be valid as long as stream is not modified" That's much clearer, thank you for the suggestion. > src/hotspot/share/utilities/vmError.cpp line 576: > >> 574: stringStream message; >> 575: message.print("This is a message with no ResourceMark"); >> 576: tty->print_cr("%s", message.base()); > > I think the intent was to use as_string deliberately to get an mark-missing crash. Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/10142 From cstein at openjdk.org Mon Sep 5 07:50:33 2022 From: cstein at openjdk.org (Christian Stein) Date: Mon, 5 Sep 2022 07:50:33 GMT Subject: RFR: JDK-8289798: Update to use jtreg 7 [v6] In-Reply-To: References: <4lMzpkkcl7esFeW4hbYTCoAsGPZfAcoRvdSahdVtte4=.e1de0004-3f48-455d-8828-da495c6fe123@github.com> <6OOJkTK0YdlUyt8mUZytcutfeolSChmgx_EX9_Ll4jg=.41414343-4750-45c9-a0d8-d043611401cc@github.com> Message-ID: On Mon, 5 Sep 2022 07:38:33 GMT, Thomas Stuefe wrote: > So I guess at the minimum we would have to downport those test changes to be able to test older JDKs with the new jtreg, right? Yes. Otherwise those tests will fail as they still do depend on hard-coded names of 3rd-party JAR files. Find backport candidates listed as Sub-Tasks number 3 to 5 at https://bugs.openjdk.org/browse/JDK-8289798 (Sub-Tasks number 1 and 2 were closed without changes.) ------------- PR: https://git.openjdk.org/jdk/pull/9393 From duke at openjdk.org Mon Sep 5 08:22:23 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 5 Sep 2022 08:22:23 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable [v2] In-Reply-To: References: Message-ID: > Hi! > > Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. > > When I've left ResourceMarks in place I've also commented which calls requires them. > > This passes tier1, tier2 tests. Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Fix review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10142/files - new: https://git.openjdk.org/jdk/pull/10142/files/2fe12418..24dd048c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=00-01 Stats: 8 lines in 3 files changed: 1 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10142.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10142/head:pull/10142 PR: https://git.openjdk.org/jdk/pull/10142 From duke at openjdk.org Mon Sep 5 08:22:25 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 5 Sep 2022 08:22:25 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable [v2] In-Reply-To: References: Message-ID: <0ijpBLniU8SAOKHxosyjaT2aR3pDdiQYg1r6rEEwrnc=.94072329-396b-442c-b16a-e5cc91e3e607@github.com> On Fri, 2 Sep 2022 13:37:17 GMT, Thomas Stuefe wrote: >> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix review comments > > Hi @jdksjolen, > > Generally good, see remarks inline. > > Cheers, Thomas Thank you for going through all of the changes @tstuefe , I am well aware that it's not very exciting stuff :-). ------------- PR: https://git.openjdk.org/jdk/pull/10142 From stuefe at openjdk.org Mon Sep 5 08:35:47 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 5 Sep 2022 08:35:47 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable [v2] In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 08:22:23 GMT, Johan Sj?l?n wrote: >> Hi! >> >> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. >> >> When I've left ResourceMarks in place I've also commented which calls requires them. >> >> This passes tier1, tier2 tests. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Fix review comments All good! ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/10142 From sspitsyn at openjdk.org Mon Sep 5 08:54:28 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 5 Sep 2022 08:54:28 GMT Subject: RFR: 8291586: Broken links in JVMTI specification In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 00:52:56 GMT, Serguei Spitsyn wrote: > The Loom related spec of the extension VirtualThreadMount and VirtualThreadUnmount events in the jvmti.xml is surrounded by the elements ` ... `, so these specs have to be ignored when the `jvmti.html `is generated. However the `jvmti.xsl` which does the XSL transformation misses to do that when the description of the JVM TI capabilities is collected. > > The fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmti.xsl b/src/hotspot/share/prims/jvmti.xsl > index 5ef89f91daf..d54d2a371e6 100644 > --- a/src/hotspot/share/prims/jvmti.xsl > +++ b/src/hotspot/share/prims/jvmti.xsl > @@ -1172,7 +1172,7 @@ typedef struct { > > > > - > + > > > > > > The correctness verification both the generated `jvmti.html` and `jvmti.h` was checked. > TBD: mach5 sanity builds and `nsk.jvmti` tests runs. I'm going to integrate this fix with one review as trivial. In fact, the fix does not change anything in the implementation and behavior. It only results in removal of a couple of unneeded links in the JVM TI spec (jvmti.html). ------------- PR: https://git.openjdk.org/jdk/pull/10153 From sspitsyn at openjdk.org Mon Sep 5 08:54:29 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 5 Sep 2022 08:54:29 GMT Subject: Integrated: 8291586: Broken links in JVMTI specification In-Reply-To: References: Message-ID: <1eQcjWn5FABJIfskCv5ula6MgrlLjQEVroIZ9Rg1hjA=.4e674b2b-14eb-495b-a8c9-3d9cb4f969a1@github.com> On Sat, 3 Sep 2022 00:52:56 GMT, Serguei Spitsyn wrote: > The Loom related spec of the extension VirtualThreadMount and VirtualThreadUnmount events in the jvmti.xml is surrounded by the elements ` ... `, so these specs have to be ignored when the `jvmti.html `is generated. However the `jvmti.xsl` which does the XSL transformation misses to do that when the description of the JVM TI capabilities is collected. > > The fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmti.xsl b/src/hotspot/share/prims/jvmti.xsl > index 5ef89f91daf..d54d2a371e6 100644 > --- a/src/hotspot/share/prims/jvmti.xsl > +++ b/src/hotspot/share/prims/jvmti.xsl > @@ -1172,7 +1172,7 @@ typedef struct { > > > > - > + > > > > > > The correctness verification both the generated `jvmti.html` and `jvmti.h` was checked. > TBD: mach5 sanity builds and `nsk.jvmti` tests runs. This pull request has now been integrated. Changeset: 4067321e Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/4067321ef413cc6c934aa5e7ec652c56dfdf81eb Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8291586: Broken links in JVMTI specification Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/10153 From ayang at openjdk.org Mon Sep 5 09:10:19 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 5 Sep 2022 09:10:19 GMT Subject: RFR: 8293353: [BACKOUT] G1: Remove redundant is-marking-active checks in C1 barrier Message-ID: Clean revert of [JDK-8289138](https://bugs.openjdk.org/browse/JDK-8289138) to keep CI clean. Test: ~2/200 failing rate before the PR and pass after the PR. ------------- Commit messages: - Revert "8289138: G1: Remove redundant is-marking-active checks in C1 barrier" Changes: https://git.openjdk.org/jdk/pull/10159/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10159&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293353 Stats: 51 lines in 6 files changed: 51 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10159/head:pull/10159 PR: https://git.openjdk.org/jdk/pull/10159 From kbarrett at openjdk.org Mon Sep 5 09:10:20 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 5 Sep 2022 09:10:20 GMT Subject: RFR: 8293353: [BACKOUT] G1: Remove redundant is-marking-active checks in C1 barrier In-Reply-To: References: Message-ID: <46IyZujJfsjK3FYSchgiRPo3T8o9HJxxRqWP6Zj6Dss=.259d881f-6825-4784-b6f3-be8b1b4ac91c@github.com> On Mon, 5 Sep 2022 08:58:33 GMT, Albert Mingkun Yang wrote: > Clean revert of [JDK-8289138](https://bugs.openjdk.org/browse/JDK-8289138) to keep CI clean. > > Test: ~2/200 failing rate before the PR and pass after the PR. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/10159 From mdoerr at openjdk.org Mon Sep 5 09:32:39 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 5 Sep 2022 09:32:39 GMT Subject: RFR: 8293353: [BACKOUT] G1: Remove redundant is-marking-active checks in C1 barrier In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 08:58:33 GMT, Albert Mingkun Yang wrote: > Clean revert of [JDK-8289138](https://bugs.openjdk.org/browse/JDK-8289138) to keep CI clean. > > Test: ~2/200 failing rate before the PR and pass after the PR. `mem2reg` with patching in `G1BarrierSetAssembler::gen_pre_barrier_stub` contains a safepoint. Rechecking is needed in this case. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.org/jdk/pull/10159 From tschatzl at openjdk.org Mon Sep 5 09:48:32 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 5 Sep 2022 09:48:32 GMT Subject: RFR: 8293353: [BACKOUT] G1: Remove redundant is-marking-active checks in C1 barrier In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 08:58:33 GMT, Albert Mingkun Yang wrote: > Clean revert of [JDK-8289138](https://bugs.openjdk.org/browse/JDK-8289138) to keep CI clean. > > Test: ~2/200 failing rate before the PR and pass after the PR. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10159 From fyang at openjdk.org Mon Sep 5 10:04:48 2022 From: fyang at openjdk.org (Fei Yang) Date: Mon, 5 Sep 2022 10:04:48 GMT Subject: RFR: 8293290: RISC-V: Explicitly pass a third temp register to MacroAssembler::store_heap_oop In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 12:47:20 GMT, Aleksey Shipilev wrote: >> Currently G1 (and Shenandoah) implicitly uses x13 in oop_store_at on riscv. >> >> This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186). >> This would be fixed in the same way on riscv by passing the temporary register explicitly so it is part of the GC API. >> >> Testing: Passed Tier1 test on linux-riscv64 SiFive Unmatched board. > > Looks fine. @shipilev : Thanks for the review. Also passed Tier2 test. Integrate then. ------------- PR: https://git.openjdk.org/jdk/pull/10137 From fyang at openjdk.org Mon Sep 5 10:04:49 2022 From: fyang at openjdk.org (Fei Yang) Date: Mon, 5 Sep 2022 10:04:49 GMT Subject: Integrated: 8293290: RISC-V: Explicitly pass a third temp register to MacroAssembler::store_heap_oop In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 03:34:49 GMT, Fei Yang wrote: > Currently G1 (and Shenandoah) implicitly uses x13 in oop_store_at on riscv. > > This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186). > This would be fixed in the same way on riscv by passing the temporary register explicitly so it is part of the GC API. > > Testing: Passed Tier1 test on linux-riscv64 SiFive Unmatched board. This pull request has now been integrated. Changeset: 5bed9f76 Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/5bed9f767507bb0f123247d149ead84d2d635f52 Stats: 71 lines in 16 files changed: 2 ins; 0 del; 69 mod 8293290: RISC-V: Explicitly pass a third temp register to MacroAssembler::store_heap_oop Reviewed-by: shade ------------- PR: https://git.openjdk.org/jdk/pull/10137 From aboldtch at openjdk.org Mon Sep 5 10:16:26 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 5 Sep 2022 10:16:26 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at Message-ID: Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. Testing: Oracle platforms tier 1-3 ------------- Commit messages: - 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at Changes: https://git.openjdk.org/jdk/pull/10161/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293351 Stats: 88 lines in 14 files changed: 7 ins; 2 del; 79 mod Patch: https://git.openjdk.org/jdk/pull/10161.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10161/head:pull/10161 PR: https://git.openjdk.org/jdk/pull/10161 From aph at openjdk.org Mon Sep 5 10:40:44 2022 From: aph at openjdk.org (Andrew Haley) Date: Mon, 5 Sep 2022 10:40:44 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 10:09:09 GMT, Axel Boldt-Christmas wrote: > Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. > > Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. > > Testing: Oracle platforms tier 1-3 This is s welcome improvement. Thanks. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.org/jdk/pull/10161 From fyang at openjdk.org Mon Sep 5 12:30:40 2022 From: fyang at openjdk.org (Fei Yang) Date: Mon, 5 Sep 2022 12:30:40 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 10:09:09 GMT, Axel Boldt-Christmas wrote: > Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. > > Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. > > Testing: Oracle platforms tier 1-3 src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2466: > 2464: #endif > 2465: > 2466: void MacroAssembler::resolve_jobject(Register value, Register tmp1, Register tmp2) { You might want to rename the second parameter for its declaration in file macroAssembler_aarch64.hpp ------------- PR: https://git.openjdk.org/jdk/pull/10161 From aboldtch at openjdk.org Mon Sep 5 12:49:14 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 5 Sep 2022 12:49:14 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v2] In-Reply-To: References: Message-ID: > Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. > > Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. > > Testing: Oracle platforms tier 1-3 Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Fix argument names ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10161/files - new: https://git.openjdk.org/jdk/pull/10161/files/ebcd8ebe..bfc33939 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10161.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10161/head:pull/10161 PR: https://git.openjdk.org/jdk/pull/10161 From aboldtch at openjdk.org Mon Sep 5 12:49:15 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 5 Sep 2022 12:49:15 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v2] In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 12:26:53 GMT, Fei Yang wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix argument names > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 2466: > >> 2464: #endif >> 2465: >> 2466: void MacroAssembler::resolve_jobject(Register value, Register tmp1, Register tmp2) { > > You might want to rename the second parameter for its declaration in file macroAssembler_aarch64.hpp Good catch ? . Fixed ------------- PR: https://git.openjdk.org/jdk/pull/10161 From tschatzl at openjdk.org Mon Sep 5 13:05:44 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 5 Sep 2022 13:05:44 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v2] In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 12:49:14 GMT, Axel Boldt-Christmas wrote: >> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. >> >> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. >> >> Testing: Oracle platforms tier 1-3 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Fix argument names Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10161 From mdoerr at openjdk.org Mon Sep 5 13:43:48 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 5 Sep 2022 13:43:48 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 16:47:58 GMT, Robbin Ehn wrote: > Please consider, only implemented on x64/aarch64 linux/windows. > > On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. > > Passes t1-7 with option forced on, also passes t1-4 as is in this PR. Nice to see usage of this OS feature. I like it more than the serialization page we have in 11u (with `-XX:-UseMembar`) and Critical JNI Natives (which still have some advantage). I have observed the same speedup for a trivial JNI call on my x86_64 machine. src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 36: > 34: // Syscall defined in kernel 4.3 > 35: #if !defined(SYS_membarrier) > 36: #define SYS_membarrier 324 I'd like to get rid of the platform checks in this generic linux file. This number seems to be the only platform specific part: ------------- PR: https://git.openjdk.org/jdk/pull/10123 From fyang at openjdk.org Mon Sep 5 13:53:43 2022 From: fyang at openjdk.org (Fei Yang) Date: Mon, 5 Sep 2022 13:53:43 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v2] In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 12:49:14 GMT, Axel Boldt-Christmas wrote: >> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. >> >> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. >> >> Testing: Oracle platforms tier 1-3 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Fix argument names Would you mind a few more tweaks? Thanks. src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.hpp line 73: > 71: > 72: void load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type, > 73: Register dst, Address src, Register tmp1, Register tmp2); Need similar modification for function definition in file barrierSetAssembler_aarch64.cpp src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp line 288: > 286: > 287: // Is it a weak but alive CLD? > 288: __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize))); No need to save r11 then? ------------- Changes requested by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10161 From rehn at openjdk.org Mon Sep 5 14:09:19 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 5 Sep 2022 14:09:19 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 13:41:31 GMT, Martin Doerr wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > Nice to see usage of this OS feature. I like it more than the serialization page we have in 11u (with `-XX:-UseMembar`) and Critical JNI Natives (which still have some advantage). I have observed the same speedup for a trivial JNI call on my x86_64 machine. Thanks for having a look Martin(@TheRealMDoerr), I'll see what I can do regarding the define! ------------- PR: https://git.openjdk.org/jdk/pull/10123 From aboldtch at openjdk.org Mon Sep 5 14:57:32 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 5 Sep 2022 14:57:32 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v3] In-Reply-To: References: Message-ID: > Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. > > Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. > > Testing: Oracle platforms tier 1-3 Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Fix argument name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10161/files - new: https://git.openjdk.org/jdk/pull/10161/files/bfc33939..7f604f84 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10161.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10161/head:pull/10161 PR: https://git.openjdk.org/jdk/pull/10161 From aboldtch at openjdk.org Mon Sep 5 14:57:34 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 5 Sep 2022 14:57:34 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v2] In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 13:45:57 GMT, Fei Yang wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix argument names > > src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.hpp line 73: > >> 71: >> 72: void load_at(MacroAssembler* masm, DecoratorSet decorators, BasicType type, >> 73: Register dst, Address src, Register tmp1, Register tmp2); > > Need similar modification for function definition in file barrierSetAssembler_aarch64.cpp ? . Fixed ------------- PR: https://git.openjdk.org/jdk/pull/10161 From aboldtch at openjdk.org Mon Sep 5 15:00:06 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 5 Sep 2022 15:00:06 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v2] In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 13:46:24 GMT, Fei Yang wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix argument names > > src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp line 288: > >> 286: >> 287: // Is it a weak but alive CLD? >> 288: __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize))); > > No need to save r11 then? As `resolve_weak_handle` may call into the VM `r11` may still be clobbered. The reason that `rscratch[1/2]` was not used previously was because some GC in the `resolve_weak_handle` call graph used them implicitly. This is all explicit now so `rscratch` is used instead as it seems like it is the way the GC API has gone, with all registers being explicit. There is still some room for improvement here with regards to being more consistent with what registers are used. ------------- PR: https://git.openjdk.org/jdk/pull/10161 From coleenp at openjdk.org Mon Sep 5 18:25:24 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 5 Sep 2022 18:25:24 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v3] In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 23:46:41 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose has updated the pull request incrementally with one additional commit since the last revision: > > add more support for SA including vmStructs; tweak some debug code Thank you for adding the SA and debug.cpp for debugging this. src/hotspot/share/code/compressedStream.cpp line 85: > 83: const int min_expansion = UNSIGNED5::MAX_LENGTH; > 84: if (nsize < min_expansion*2) > 85: nsize = min_expansion*2; I think our coding style guide recommends having {} around even one line code inside if and else statements. I usually ignore this if it's on the same line, but on a separate line, it seems worth pointing out. src/hotspot/share/utilities/unsigned5.cpp line 35: > 33: template u4 UNSIGNED5::read_uint(u_char* array, int& offset_rw, int limit, AGS); > 34: template void UNSIGNED5::write_uint(uint32_t value, u_char* array, int& offset_rw, int limit, AGS); > 35: template int UNSIGNED5::check_length(u_char* array, int offset, int limit, AGS); I don't know why you'd need these explicit instantiations. The entire templates are in the hpp files so the caller will instantiate them. src/hotspot/share/utilities/unsigned5.hpp line 174: > 172: > 173: // returns the encoded byte length of an unsigned 32-bit int > 174: static constexpr int encoded_length(uint32_t value) { Should all of these functions be private? src/hotspot/share/utilities/unsigned5.hpp line 312: > 310: : _array(const_cast(array)), _limit_ptr(NULL) > 311: // note: if _limit_ptr is NULL, the ARR& is never reassigned > 312: { limit_init(); _position = 0; } indent needed. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/Unsigned5.java line 59: > 57: hval = db.lookupIntConstant("UNSIGNED5::H").intValue(); > 58: lval = db.lookupIntConstant("UNSIGNED5::L").intValue(); > 59: xval = db.lookupIntConstant("UNSIGNED5::X").intValue(); These constants aren't likely to change ever, are they? I don't see why we'd need the SA to get these constants from the VM. It could just hard-code them like you have here. Then UNSIGNED5 doesn't have to make VMStructs a friend class. Also, there isn't a compatibility issue with older SA - it might work sometimes but the SA version should match the JVM that is being debugged. test/hotspot/gtest/utilities/test_unsigned5.cpp line 31: > 29: // T.I.L. > 30: // $ sh ./configure ... --with-gtest=<...>/googletest ... > 31: // $ make exploded-test TEST=gtest:unsigned5 What does T.I.L mean? This isn't the only way to run this test, so don't include this. ------------- PR: https://git.openjdk.org/jdk/pull/10067 From haosun at openjdk.org Tue Sep 6 00:24:45 2022 From: haosun at openjdk.org (Hao Sun) Date: Tue, 6 Sep 2022 00:24:45 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v3] In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 14:57:32 GMT, Axel Boldt-Christmas wrote: >> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. >> >> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. >> >> Testing: Oracle platforms tier 1-3 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Fix argument name src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.hpp line 48: > 46: Register pre_val, > 47: Register thread, > 48: Register tmp, It would be better to use `tmp1` as the definition site does. ------------- PR: https://git.openjdk.org/jdk/pull/10161 From fyang at openjdk.org Tue Sep 6 03:40:42 2022 From: fyang at openjdk.org (Fei Yang) Date: Tue, 6 Sep 2022 03:40:42 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v2] In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 14:58:00 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp line 288: >> >>> 286: >>> 287: // Is it a weak but alive CLD? >>> 288: __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize))); >> >> No need to save r11 then? > > As `resolve_weak_handle` may call into the VM `r11` may still be clobbered. The reason that `rscratch[1/2]` was not used previously was because some GC in the `resolve_weak_handle` call graph used them implicitly. This is all explicit now so `rscratch` is used instead as it seems like it is the way the GC API has gone, with all registers being explicit. > > There is still some room for improvement here with regards to being more consistent with what registers are used. "As resolve_weak_handle may call into the VM r11 may still be clobbered. " -- I don't quite understand this. If this is the case, shouldn't r11 be saved & restored immediate before and after the VM call together with other live caller-save registers? ------------- PR: https://git.openjdk.org/jdk/pull/10161 From aboldtch at openjdk.org Tue Sep 6 06:24:38 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 6 Sep 2022 06:24:38 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v4] In-Reply-To: References: Message-ID: > Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. > > Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. > > Testing: Oracle platforms tier 1-3 Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Make tmp register names consistent g1BarrierSetAssembler_aarch64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10161/files - new: https://git.openjdk.org/jdk/pull/10161/files/7f604f84..ad5a7694 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=02-03 Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/10161.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10161/head:pull/10161 PR: https://git.openjdk.org/jdk/pull/10161 From aboldtch at openjdk.org Tue Sep 6 06:24:40 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 6 Sep 2022 06:24:40 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v3] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 00:15:08 GMT, Hao Sun wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix argument name > > src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.hpp line 48: > >> 46: Register pre_val, >> 47: Register thread, >> 48: Register tmp, > > It would be better to use `tmp1` as the definition site does. ? Fixed. Made all two temporary register names consistent across g1BarrierSetAssembler ------------- PR: https://git.openjdk.org/jdk/pull/10161 From aboldtch at openjdk.org Tue Sep 6 06:38:46 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 6 Sep 2022 06:38:46 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v2] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 03:38:33 GMT, Fei Yang wrote: >> As `resolve_weak_handle` may call into the VM `r11` may still be clobbered. The reason that `rscratch[1/2]` was not used previously was because some GC in the `resolve_weak_handle` call graph used them implicitly. This is all explicit now so `rscratch` is used instead as it seems like it is the way the GC API has gone, with all registers being explicit. >> >> There is still some room for improvement here with regards to being more consistent with what registers are used. > > "As resolve_weak_handle may call into the VM r11 may still be clobbered. " > -- I don't quite understand this. If this is the case, shouldn't r11 be saved & restored immediate before and after the VM call together with other live caller-save registers? Maybe? Actually looking at it a second time it seems like r0-r7 and r9-r17 are pushed to the stack at the vm call I was looking at. I am probably missing something. I do not fully understand the reason for pushing the registers at this point, not earlier or later. Would have to investigate further. I do however think that such a change belongs to a separate issue/PR. This PR should not change the instruction emission, only which registers are used. ------------- PR: https://git.openjdk.org/jdk/pull/10161 From fyang at openjdk.org Tue Sep 6 06:57:44 2022 From: fyang at openjdk.org (Fei Yang) Date: Tue, 6 Sep 2022 06:57:44 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v4] In-Reply-To: References: Message-ID: <3_Z3Lkc5c0detzCU9-j4ps0Eyr_qMf4mOB3fNy0QPyM=.3e3579ad-ce26-4b6f-97e6-90fafd20be09@github.com> On Tue, 6 Sep 2022 06:24:38 GMT, Axel Boldt-Christmas wrote: >> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. >> >> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. >> >> Testing: Oracle platforms tier 1-3 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Make tmp register names consistent g1BarrierSetAssembler_aarch64 Marked as reviewed by fyang (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10161 From fyang at openjdk.org Tue Sep 6 06:57:45 2022 From: fyang at openjdk.org (Fei Yang) Date: Tue, 6 Sep 2022 06:57:45 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v2] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 06:35:13 GMT, Axel Boldt-Christmas wrote: >> "As resolve_weak_handle may call into the VM r11 may still be clobbered. " >> -- I don't quite understand this. If this is the case, shouldn't r11 be saved & restored immediate before and after the VM call together with other live caller-save registers? > > Maybe? Actually looking at it a second time it seems like r0-r7 and r9-r17 are pushed to the stack at the vm call I was looking at. > I am probably missing something. I do not fully understand the reason for pushing the registers at this point, not earlier or later. Would have to investigate further. I do however think that such a change belongs to a separate issue/PR. This PR should not change the instruction emission, only which registers are used. I think the reason is that register r11 was used as temp register (and thus gets clobbered) by resolve_weak_handle previously. That's why this register was saved/restored here. But this has changed since it not used here anymore with your change. I am OK if you want to handle that in another PR. Just reminds. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10161 From aboldtch at openjdk.org Tue Sep 6 07:28:43 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 6 Sep 2022 07:28:43 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v2] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 06:52:53 GMT, Fei Yang wrote: >> Maybe? Actually looking at it a second time it seems like r0-r7 and r9-r17 are pushed to the stack at the vm call I was looking at. >> I am probably missing something. I do not fully understand the reason for pushing the registers at this point, not earlier or later. Would have to investigate further. I do however think that such a change belongs to a separate issue/PR. This PR should not change the instruction emission, only which registers are used. > > I think the reason is that register r11 was used as temp register (and thus gets clobbered) by resolve_weak_handle previously. That's why this register was saved/restored here. But this has changed since it not used here anymore with your change. I am OK if you want to handle that in another PR. Just reminds. Thanks. I looked into it some further. You are correct. The reason I thought it was important was because this change hard crashed. + __ str(r10, Address(__ pre(sp, -wordSize))); - __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize))); But I guess it is because I am misaligning the stack or there is some other reason `sp` cannot be bumped by `8`, only `16`. As this change is fine. + __ str(r10, Address(__ pre(sp, -2 * wordSize))); - __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize))); Maybe using the RegSets and `push` would do this correctly, or it is some special invariant for these adapters. ------------- PR: https://git.openjdk.org/jdk/pull/10161 From kevinw at openjdk.org Tue Sep 6 08:42:13 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 6 Sep 2022 08:42:13 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread [v2] In-Reply-To: References: Message-ID: > This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). > > A JVMTI operation could call threadObj() and clear the Windows GetLastError value. > > Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Comment update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10147/files - new: https://git.openjdk.org/jdk/pull/10147/files/2cbaa186..8de54561 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10147&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10147&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10147.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10147/head:pull/10147 PR: https://git.openjdk.org/jdk/pull/10147 From kevinw at openjdk.org Tue Sep 6 08:42:14 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 6 Sep 2022 08:42:14 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread [v2] In-Reply-To: References: <8Utk-bzbBROX3wb9XELnyeJCldtrwlWf_bBHQD7KicU=.4adb9aab-baeb-4d5e-9ebd-e2345b1b7e83@github.com> Message-ID: On Sat, 3 Sep 2022 11:05:18 GMT, Kevin Walls wrote: >> src/hotspot/share/runtime/javaThread.cpp line 165: >> >>> 163: oop JavaThread::threadObj() const { >>> 164: // Using Thread::current_or_null_safe() here risks that calling threadObj() can >>> 165: // overwrite a native thread local, e.g. JVMTI operations clearing GetLastError on Windows. >> >> Suggestion: >> >> // Ideally we would verify the current thread is oop_safe when this is called, but as we can >> // be called from a signal handler we would have to use Thread::current_or_null_safe(). That >> // has overhead and also interacts poorly with GetLastError on Windows due to the use of TLS. >> // Instead callers must verify oop safe access. > > Thanks David, will update comment and check Dan is OK with this. Updated comment. ------------- PR: https://git.openjdk.org/jdk/pull/10147 From ayang at openjdk.org Tue Sep 6 08:43:40 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 6 Sep 2022 08:43:40 GMT Subject: RFR: 8293353: [BACKOUT] G1: Remove redundant is-marking-active checks in C1 barrier In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 08:58:33 GMT, Albert Mingkun Yang wrote: > Clean revert of [JDK-8289138](https://bugs.openjdk.org/browse/JDK-8289138) to keep CI clean. > > Test: ~2/200 failing rate before the PR and pass after the PR. Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/10159 From ayang at openjdk.org Tue Sep 6 08:47:50 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 6 Sep 2022 08:47:50 GMT Subject: Integrated: 8293353: [BACKOUT] G1: Remove redundant is-marking-active checks in C1 barrier In-Reply-To: References: Message-ID: <4eV5_IGVqsRPNbAuO5SQb1oxsLzIqXWANbr-A3Ywnkc=.4991787f-1f39-404f-8e26-c68e39e35be4@github.com> On Mon, 5 Sep 2022 08:58:33 GMT, Albert Mingkun Yang wrote: > Clean revert of [JDK-8289138](https://bugs.openjdk.org/browse/JDK-8289138) to keep CI clean. > > Test: ~2/200 failing rate before the PR and pass after the PR. This pull request has now been integrated. Changeset: 1bed23a1 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/1bed23a1af8f992003bff053ff982f4938b7221f Stats: 51 lines in 6 files changed: 51 ins; 0 del; 0 mod 8293353: [BACKOUT] G1: Remove redundant is-marking-active checks in C1 barrier Reviewed-by: kbarrett, mdoerr, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/10159 From aph-open at littlepinkcloud.com Tue Sep 6 09:44:04 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 6 Sep 2022 10:44:04 +0100 Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v2] In-Reply-To: References: Message-ID: <820c6c25-cd1a-e9c0-4393-3794ef90d799@littlepinkcloud.com> On 9/6/22 08:28, Axel Boldt-Christmas wrote: > Maybe using the RegSets and `push` would do this correctly It would. Using a RegSet for push and pop also reduces the risk of error. From magnus.ihse.bursie at oracle.com Tue Sep 6 10:31:58 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Sep 2022 12:31:58 +0200 Subject: Hall of shame: Header compilation times Message-ID: <8f64fe8a-ea39-75db-91db-9a2f23a701e8@oracle.com> I recently discovered the clang -ftime-trace flag, combined with the nifty tool ClangBuildAnalyzer[1] which analyses the output files from -ftime-trace, and presents the "top offenders" for a whole project. Naturally, I ran this on hotspot. :-) I think the most important information gathered was how costly different header files are. It is hard to understand which files are included many times, and if that is a problem or if they are trivial. But now we can get this in black and white. So, without further ado, here is the top list of costly header files in Hotspot: src/hotspot/share/asm/assembler.hpp (total 30284 ms, included 541 times, avg 55 ms) src/hotspot/share/runtime/frame.inline.hpp (total 29234 ms, included 344 times, avg 84 ms) src/hotspot/share/runtime/javaThread.inline.hpp (total 22297 ms, included 226 times, avg 98 ms) src/hotspot/share/oops/access.inline.hpp (total 19675 ms, included 514 times, avg 38 ms) src/hotspot/share/ci/ciEnv.hpp (total 18703 ms, included 231 times, avg 80 ms) src/hotspot/share/runtime/continuationEntry.inline.hpp (total 17318 ms, included 230 times, avg 75 ms) src/hotspot/share/oops/access.hpp (total 17123 ms, included 594 times, avg 28 ms) src/hotspot/share/code/nativeInst.hpp (total 14769 ms, included 389 times, avg 37 ms) src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp (total 14757 ms, included 393 times, avg 37 ms) src/hotspot/share/code/debugInfoRec.hpp (total 13809 ms, included 257 times, avg 53 ms) src/hotspot/share/oops/stackChunkOop.inline.hpp (total 13549 ms, included 347 times, avg 39 ms) src/hotspot/share/code/debugInfo.hpp (total 13411 ms, included 503 times, avg 26 ms) src/hotspot/share/gc/g1/g1BarrierSet.inline.hpp (total 13393 ms, included 512 times, avg 26 ms) src/hotspot/share/code/compiledMethod.inline.hpp (total 13337 ms, included 330 times, avg 40 ms) src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp (total 13295 ms, included 60 times, avg 221 ms) src/hotspot/share/code/location.hpp (total 12095 ms, included 316 times, avg 38 ms) gensrc/adfiles/ad_aarch64.hpp (total 11987 ms, included 44 times, avg 272 ms) src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp (total 11588 ms, included 60 times, avg 193 ms) src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp (total 11406 ms, included 97 times, avg 117 ms) gensrc/jfrfiles/jfrEventClasses.hpp (total 11147 ms, included 72 times, avg 154 ms) src/hotspot/share/oops/oop.inline.hpp (total 11128 ms, included 510 times, avg 21 ms) src/hotspot/share/jfr/jfrEvents.hpp (total 10968 ms, included 71 times, avg 154 ms) src/hotspot/share/memory/iterator.inline.hpp (total 10512 ms, included 83 times, avg 126 ms) src/hotspot/share/opto/compile.hpp (total 10107 ms, included 117 times, avg 86 ms) src/hotspot/share/gc/g1/g1OopClosures.inline.hpp (total 10018 ms, included 60 times, avg 166 ms) src/hotspot/share/opto/node.hpp (total 8731 ms, included 93 times, avg 93 ms) src/hotspot/share/code/codeCache.hpp (total 8574 ms, included 587 times, avg 14 ms) src/hotspot/share/gc/z/zBarrier.inline.hpp (total 8446 ms, included 509 times, avg 16 ms) src/hotspot/share/asm/macroAssembler.hpp (total 8419 ms, included 433 times, avg 19 ms) src/hotspot/share/jfr/recorder/service/jfrEvent.hpp (total 8390 ms, included 73 times, avg 114 ms) src/hotspot/share/classfile/vmSymbols.hpp (total 8346 ms, included 297 times, avg 28 ms) src/hotspot/share/opto/ad.hpp (total 8258 ms, included 34 times, avg 242 ms) src/hotspot/share/classfile/javaClasses.inline.hpp (total 8174 ms, included 185 times, avg 44 ms) src/hotspot/share/runtime/interfaceSupport.inline.hpp (total 8053 ms, included 135 times, avg 59 ms) src/hotspot/share/asm/codeBuffer.hpp (total 7117 ms, included 692 times, avg 10 ms) src/hotspot/share/interpreter/interpreter.hpp (total 6891 ms, included 380 times, avg 18 ms) src/hotspot/share/ci/ciUtilities.hpp (total 6759 ms, included 196 times, avg 34 ms) src/hotspot/share/memory/allocation.inline.hpp (total 6557 ms, included 266 times, avg 24 ms) src/hotspot/share/oops/instanceKlass.inline.hpp (total 6395 ms, included 193 times, avg 33 ms) src/hotspot/share/code/codeBlob.hpp (total 6108 ms, included 685 times, avg 8 ms) So, given this list, it seems like it would have a huge potential payoff to start looking more closely on assembler.hpp. Is it strictly needed everywhere it is included? Can it be split into multiple parts, so most users only need to include some smaller subsets? Etc. And then continuing doing the same with ciEnv.hpp and the top inline.hpp files... Caveats: This is from compiling with clang on a mac. There is probably variations due to OS/compiler, etc. But I think this is a very good approximation on what is problematic even for gcc and msvc. /Magnus [1] https://github.com/aras-p/ClangBuildAnalyzer From magnus.ihse.bursie at oracle.com Tue Sep 6 10:36:54 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Sep 2022 12:36:54 +0200 Subject: Additional clang -ftime-trace data Message-ID: <5a53f5e1-35c5-5390-457b-418e16ca88ef@oracle.com> Here are more output from ClangBuildAnalyzer. Seems that AccessInternal might be worth having a second look at, to see if it can be made easier on the compiler..? **** Time summary: Compilation (2033 times): ? Parsing (frontend):????????? 271.6 s ? Codegen & opts (backend):??? 274.1 s **** Files that took longest to parse (compiler frontend): ? 1339 ms: ad_aarch64.o ? 1311 ms: dfa_aarch64.o ? 1108 ms: compileBroker.o ? 1088 ms: compile.o ? 1005 ms: ad_aarch64_misc.o ?? 990 ms: library_call.o ?? 971 ms: whitebox.o ?? 953 ms: runtime.o ?? 938 ms: sharedRuntime_aarch64.o ?? 889 ms: instanceKlass.o **** Files that took longest to codegen (compiler backend): ? 7267 ms: ad_aarch64_gen.o ? 6830 ms: ad_aarch64.o ? 5402 ms: dfa_aarch64.o ? 3482 ms: whitebox.o ? 3106 ms: ad_aarch64_misc.o ? 2960 ms: jvmtiEnterTrace.o ? 2844 ms: macroAssembler_aarch64.o ? 2568 ms: jvmciCompilerToVMInit.o ? 2520 ms: jni.o ? 2512 ms: stubGenerator_aarch64.o **** Templates that took longest to instantiate: ? 2884 ms: AccessInternal::OopLoadAtProxy<262144>::operator oopDesc * (512 times, avg 5 ms) ? 2870 ms: AccessInternal::load_at<262148, oopDesc *> (512 times, avg 5 ms) ? 2797 ms: AccessInternal::OopLoadAtProxy<1310720>::operator oopDesc * (512 times, avg 5 ms) ? 2783 ms: AccessInternal::load_at<1310724, oopDesc *> (512 times, avg 5 ms) ? 2656 ms: AccessInternal::PreRuntimeDispatch::load_at<286790, oopDesc *> (512 times, avg 5 ms) ? 2569 ms: AccessInternal::PreRuntimeDispatch::load_at<1335366, oopDesc *> (512 times, avg 5 ms) ? 2446 ms: Access<525312>::oop_atomic_xchg (383 times, avg 6 ms) ? 2380 ms: AccessInternal::atomic_xchg<525316, oopDesc *, oopDesc *> (383 times, avg 6 ms) ? 2311 ms: AccessInternal::atomic_xchg_reduce_types<549892, oopDesc *> (383 times, avg 6 ms) ? 2252 ms: AccessInternal::PreRuntimeDispatch::atomic_xchg<549892, oopDesc *> (383 times, avg 5 ms) ? 2234 ms: Access<262144>::oop_store_at (512 times, avg 4 ms) ? 2168 ms: Access<1310720>::oop_store_at (512 times, avg 4 ms) ? 2162 ms: AccessInternal::store_at<262148, oopDesc *> (512 times, avg 4 ms) ? 2119 ms: AccessInternal::PreRuntimeDispatch::store_at<286790, oopDesc *> (512 times, avg 4 ms) ? 2098 ms: AccessInternal::store_at<1310724, oopDesc *> (512 times, avg 4 ms) ? 2059 ms: AccessInternal::PreRuntimeDispatch::store_at<1335366, oopDesc *> (512 times, avg 4 ms) ? 2018 ms: AccessInternal::RuntimeDispatch<286790, oopDesc *, AccessInternal::B... (512 times, avg 3 ms) ? 1999 ms: AccessInternal::RuntimeDispatch<286790, oopDesc *, AccessInternal::B... (512 times, avg 3 ms) ? 1954 ms: AccessInternal::BarrierResolver<286790, oopDesc *(*)(oopDesc *, long... (512 times, avg 3 ms) ? 1949 ms: AccessInternal::BarrierResolver<286790, oopDesc *(*)(oopDesc *, long... (512 times, avg 3 ms) ? 1941 ms: AccessInternal::RuntimeDispatch<1335366, oopDesc *, AccessInternal::... (512 times, avg 3 ms) ? 1931 ms: AccessInternal::OopLoadProxy::operator oopDesc * (414 times, avg 4 ms) ? 1921 ms: AccessInternal::load<524292, oopDesc *, oopDesc *> (414 times, avg 4 ms) ? 1919 ms: AccessInternal::RuntimeDispatch<1335366, oopDesc *, AccessInternal::... (512 times, avg 3 ms) ? 1877 ms: AccessInternal::BarrierResolver<1335366, oopDesc *(*)(oopDesc *, lon... (512 times, avg 3 ms) ? 1872 ms: AccessInternal::BarrierResolver<1335366, oopDesc *(*)(oopDesc *, lon... (512 times, avg 3 ms) ? 1844 ms: AccessInternal::OopLoadProxy::operator oopDesc * (391 times, avg 4 ms) ? 1840 ms: AccessInternal::load_reduce_types<548932, oopDesc *> (414 times, avg 4 ms) ? 1834 ms: AccessInternal::load<528388, oopDesc *, oopDesc *> (391 times, avg 4 ms) ? 1789 ms: AccessInternal::PreRuntimeDispatch::load<548932, oopDesc *> (414 times, avg 4 ms) **** Template sets that took longest to instantiate: ?19441 ms: AccessInternal::BarrierResolver<$>::resolve_barrier (5560 times, avg 3 ms) ?19373 ms: AccessInternal::BarrierResolver<$>::resolve_barrier_rt (5560 times, avg 3 ms) ?18680 ms: AccessInternal::BarrierResolver<$>::resolve_barrier_gc<$> (10787 times, avg 1 ms) ?10406 ms: AccessInternal::PostRuntimeDispatch<$>::oop_access_barrier (10218 times, avg 1 ms) ?10357 ms: AccessInternal::load_at<$> (1953 times, avg 5 ms) ? 9745 ms: AccessInternal::PreRuntimeDispatch::load_at<$> (1953 times, avg 4 ms) ? 8775 ms: AccessInternal::load<$> (3284 times, avg 2 ms) ? 7888 ms: AccessInternal::RuntimeDispatch<$>::load_at (1953 times, avg 4 ms) ? 7876 ms: AccessInternal::PreRuntimeDispatch::load<$> (3068 times, avg 2 ms) ? 7811 ms: AccessInternal::RuntimeDispatch<$>::load_at_init (1953 times, avg 3 ms) ? 7470 ms: AccessInternal::load_reduce_types<$> (2771 times, avg 2 ms) ? 5702 ms: AccessInternal::RuntimeDispatch<$>::load (1529 times, avg 3 ms) ? 5644 ms: AccessInternal::RuntimeDispatch<$>::load_init (1529 times, avg 3 ms) ? 5055 ms: oopDesc::obj_field_access<$> (925 times, avg 5 ms) ? 4418 ms: Access<$>::oop_store_at<$> (1029 times, avg 4 ms) ? 4275 ms: AccessInternal::store_at<$> (1029 times, avg 4 ms) ? 4194 ms: AccessInternal::PreRuntimeDispatch::store_at<$> (1029 times, avg 4 ms) ? 3515 ms: AccessInternal::RuntimeDispatch<$>::store_at (1029 times, avg 3 ms) ? 3477 ms: AccessInternal::RuntimeDispatch<$>::store_at_init (1029 times, avg 3 ms) ? 2884 ms: AccessInternal::OopLoadAtProxy<262144>::operator oopDesc * (512 times, avg 5 ms) ? 2797 ms: AccessInternal::OopLoadAtProxy<1310720>::operator oopDesc * (512 times, avg 5 ms) ? 2446 ms: Access<$>::oop_atomic_xchg<$> (383 times, avg 6 ms) ? 2380 ms: AccessInternal::atomic_xchg<$> (383 times, avg 6 ms) ? 2311 ms: AccessInternal::atomic_xchg_reduce_types<$> (383 times, avg 6 ms) ? 2269 ms: IsIntegral<$> (2546 times, avg 0 ms) ? 2252 ms: AccessInternal::PreRuntimeDispatch::atomic_xchg<$> (383 times, avg 5 ms) ? 2035 ms: ModRefBarrierSet::AccessBarrier<$>::oop_store_in_heap<$> (1416 times, avg 1 ms) ? 1996 ms: ModRefBarrierSet::AccessBarrier<$>::oop_store_in_heap_at (1306 times, avg 1 ms) ? 1931 ms: AccessInternal::OopLoadProxy::operator oopDesc * (414 times, avg 4 ms) ? 1844 ms: AccessInternal::OopLoadProxy::operator oopDesc * (391 times, avg 4 ms) **** Functions that took longest to compile: ? 3963 ms: State::MachNodeGenerator(int) (gensrc/adfiles/ad_aarch64_gen.cpp) ? 1137 ms: CompilerToVM::initialize_intrinsics(JVMCIEnv*) (src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp) ? 1099 ms: ClassVerifier::verify_method(methodHandle const&, JavaThread*) (src/hotspot/share/classfile/verifier.cpp) ? 1050 ms: readConfiguration0(JNIEnv_*, JVMCIEnv*) (src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp) ?? 595 ms: Parse::do_one_bytecode() (src/hotspot/share/opto/parse2.cpp) ?? 511 ms: schema_extend_event_subklass_bytes(InstanceKlass const*, ClassFilePa... (src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp) ?? 464 ms: State::_sub_Op_AddL(Node const*) (gensrc/adfiles/dfa_aarch64.cpp) ?? 394 ms: State::DFA(int, Node const*) (gensrc/adfiles/dfa_aarch64.cpp) ?? 383 ms: State::MachOperGenerator(int) (gensrc/adfiles/ad_aarch64_gen.cpp) ?? 378 ms: JNIJVMCI::initialize_ids(JNIEnv_*) (src/hotspot/share/jvmci/jvmciJavaClasses.cpp) ?? 319 ms: State::_sub_Op_XorI(Node const*) (gensrc/adfiles/dfa_aarch64.cpp) ?? 315 ms: PhaseChaitin::Split(unsigned int, ResourceArea*) (src/hotspot/share/opto/reg_split.cpp) ?? 277 ms: GenerateOopMap::interp1(BytecodeStream*) (src/hotspot/share/oops/generateOopMap.cpp) ?? 260 ms: PhiNode::Ideal(PhaseGVN*, bool) (src/hotspot/share/opto/cfgnode.cpp) ?? 255 ms: State::_sub_Op_AndI(Node const*) (gensrc/adfiles/dfa_aarch64.cpp) ?? 229 ms: LIR_OpVisitState::visit(LIR_Op*) (src/hotspot/share/c1/c1_LIR.cpp) ?? 226 ms: Bytecodes::initialize() (src/hotspot/share/interpreter/bytecodes.cpp) ?? 222 ms: State::_sub_Op_AddI(Node const*) (gensrc/adfiles/dfa_aarch64.cpp) ?? 219 ms: State::_sub_Op_XorL(Node const*) (gensrc/adfiles/dfa_aarch64.cpp) ?? 216 ms: State::_sub_Op_AddP(Node const*) (gensrc/adfiles/dfa_aarch64.cpp) ?? 214 ms: TemplateTable::initialize() (src/hotspot/share/interpreter/templateTable.cpp) ?? 208 ms: Arguments::parse_each_vm_init_arg(JavaVMInitArgs const*, bool*, JVMF... (src/hotspot/share/runtime/arguments.cpp) ?? 208 ms: BCEscapeAnalyzer::iterate_one_block(ciBlock*, BCEscapeAnalyzer::Stat... (src/hotspot/share/ci/bcEscapeAnalyzer.cpp) ?? 189 ms: LibraryCallKit::inline_native_getEventWriter() (src/hotspot/share/opto/library_call.cpp) ?? 181 ms: PhaseStringOpts::replace_string_concat(StringConcat*) (src/hotspot/share/opto/stringopts.cpp) ?? 179 ms: PhaseChaitin::post_allocate_copy_removal() (src/hotspot/share/opto/postaloc.cpp) ?? 170 ms: Type::Initialize_shared(Compile*) (src/hotspot/share/opto/type.cpp) ?? 167 ms: _GLOBAL__sub_I_vmStructs.cpp (src/hotspot/share/runtime/vmStructs.cpp) ?? 166 ms: ConnectionGraph::split_unique_types(GrowableArray&, GrowableA... (src/hotspot/share/opto/escape.cpp) ?? 153 ms: State::_sub_Op_AndL(Node const*) (gensrc/adfiles/dfa_aarch64.cpp) **** Function sets that took longest to compile / optimize: ? 1725 ms: GrowableArrayWithAllocator<$>::grow(int) (436 times, avg 3 ms) ? 1698 ms: void OopOopIterateBoundedDispatch<$>::Table::oop_oop_iterate_bounded... (515 times, avg 3 ms) ? 1682 ms: void OopOopIterateDispatch<$>::Table::oop_oop_iterate<$>(G1CMOopClos... (613 times, avg 2 ms) ? 1545 ms: AccessInternal::PostRuntimeDispatch<$>::oop_access_barrier(void*) (766 times, avg 2 ms) ? 1037 ms: JfrEvent<$>::write_sized_event(JfrBuffer*, Thread*, unsigned long lo... (145 times, avg 7 ms) ?? 831 ms: void InstanceMirrorKlass::oop_oop_iterate_bounded<$>(oopDesc*, G1CMO... (120 times, avg 6 ms) ?? 719 ms: void InstanceStackChunkKlass::oop_oop_iterate_stack<$>(stackChunkOop... (121 times, avg 5 ms) ?? 641 ms: void InstanceMirrorKlass::oop_oop_iterate<$>(oopDesc*, G1CMOopClosur... (121 times, avg 5 ms) ?? 615 ms: void InstanceRefKlass::oop_oop_iterate_ref_processing<$>(oopDesc*, G... (120 times, avg 5 ms) ?? 538 ms: void InstanceRefKlass::oop_oop_iterate_discovery<$>(oopDesc*, Refere... (120 times, avg 4 ms) ?? 484 ms: EventWriterHost<$>::end_event_write(bool) (51 times, avg 9 ms) ?? 481 ms: void InstanceStackChunkKlass::oop_oop_iterate_stack_with_bitmap<$>(s... (121 times, avg 3 ms) ?? 468 ms: AccessInternal::PostRuntimeDispatch<$>::oop_access_barrier(oopDesc*,... (324 times, avg 1 ms) ?? 468 ms: void InstanceStackChunkKlass::oop_oop_iterate_stack_bounded<$>(stack... (77 times, avg 6 ms) ?? 443 ms: void InstanceRefKlass::oop_oop_iterate_ref_processing<$>(oopDesc*, G... (121 times, avg 3 ms) ?? 417 ms: void InstanceRefKlass::oop_oop_iterate_discovery<$>(oopDesc*, Refere... (120 times, avg 3 ms) ?? 385 ms: bool BitMap::iterate<$>(StackChunkOopIterateBitmapClosure<$>*, unsig... (238 times, avg 1 ms) ?? 383 ms: AccessInternal::RuntimeDispatch<$>::load_init(void*) (346 times, avg 1 ms) ?? 351 ms: void InstanceClassLoaderKlass::oop_oop_iterate_bounded<$>(oopDesc*, ... (120 times, avg 2 ms) ?? 328 ms: void OopOopIterateDispatch<$>::Table::oop_oop_iterate<$>(AdjustPoint... (86 times, avg 3 ms) ?? 310 ms: WriterHost<$>::write_utf8(char const*) (27 times, avg 11 ms) ?? 293 ms: oopDesc* ZBarrierSet::AccessBarrier<$>::load_barrier_on_oop_field_pr... (284 times, avg 1 ms) ?? 268 ms: void WriterHost<$>::write<$>(unsigned long long) (62 times, avg 4 ms) ?? 257 ms: EventWriterHost<$>::begin_event_write(bool) (52 times, avg 4 ms) ?? 255 ms: void InstanceStackChunkKlass::oop_oop_iterate_bounded<$>(oopDesc*, G... (84 times, avg 3 ms) ?? 228 ms: void OopOopIterateDispatch<$>::Table::oop_oop_iterate<$>(G1MarkAndPu... (40 times, avg 5 ms) ?? 210 ms: BCEscapeAnalyzer::iterate_one_block(ciBlock*, BCEscapeAnalyzer::Stat... (2 times, avg 105 ms) ?? 197 ms: void WriterHost<$>::write<$>(long) (47 times, avg 4 ms) ?? 183 ms: void OopOopIterateBackwardsDispatch<$>::Table::oop_oop_iterate_backw... (33 times, avg 5 ms) ?? 171 ms: ZBarrierSet::AccessBarrier<$>::oop_load_in_heap_at(oopDesc*, long) (65 times, avg 2 ms) /Magnus From smonteith at openjdk.org Tue Sep 6 10:51:59 2022 From: smonteith at openjdk.org (Stuart Monteith) Date: Tue, 6 Sep 2022 10:51:59 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v4] In-Reply-To: References: Message-ID: <2UVNEbi5HyCGK7dTdnd9fhCvoE8_xSfmTjgZ7SrtNnI=.e758be5a-ea7d-45f8-bb3f-0877c10ad2f3@github.com> On Tue, 6 Sep 2022 06:24:38 GMT, Axel Boldt-Christmas wrote: >> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. >> >> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. >> >> Testing: Oracle platforms tier 1-3 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Make tmp register names consistent g1BarrierSetAssembler_aarch64 src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 277: > 275: dst /* pre_val */, > 276: rthread /* thread */, > 277: tmp1 /* tmp */, For tmp1 and tmp2 the comments, to match the paramter names, would also be "/* tmp1 */" and "/* tmp2 */". ------------- PR: https://git.openjdk.org/jdk/pull/10161 From duke at openjdk.org Tue Sep 6 10:57:15 2022 From: duke at openjdk.org (hev) Date: Tue, 6 Sep 2022 10:57:15 GMT Subject: RFR: 8293416: ZGC: Set mark bit with unconditional atomic ops Message-ID: **Summary** Support to set ZGC mark bit with unconditional atomic ops. **Motivation** ZGC currently modify mark-bitmap by a conditional atomic operation (cmpxchg). This way is not optimal, which will retry the loop when cmpxchg fails. **Description** First, This patch-set add an new unconditional atomic operation: Atomic::fetch_and_or, which is implemented in different ways for different CPU architectures: * Exclusive access: Non-nested loop retry: ll old_val, addr or new_val, old_val, set_val sc new_val, addr beq retry * Atomic access: One instruction ldset old_val, set_val, addr * Generic: Fallback to cmpxchg or use c++ __atomic_fetch_or **Testing** * jtreg tests * benchmark tests ------------- Commit messages: - 8293416: ZGC: Set mark bit with unconditional atomic ops Changes: https://git.openjdk.org/jdk/pull/10182/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10182&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293416 Stats: 467 lines in 18 files changed: 449 ins; 8 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/10182.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10182/head:pull/10182 PR: https://git.openjdk.org/jdk/pull/10182 From duke at openjdk.org Tue Sep 6 11:01:08 2022 From: duke at openjdk.org (hev) Date: Tue, 6 Sep 2022 11:01:08 GMT Subject: RFR: 8293416: ZGC: Set mark bit with unconditional atomic ops [v2] In-Reply-To: References: Message-ID: > **Summary** > Support to set ZGC mark bit with unconditional atomic ops. > > **Motivation** > ZGC currently modify mark-bitmap by a conditional atomic operation (cmpxchg). This way is not optimal, which will retry the loop when cmpxchg fails. > > **Description** > First, This patch-set add an new unconditional atomic operation: Atomic::fetch_and_or, which is implemented in different ways for different CPU architectures: > > * Exclusive access: Non-nested loop > > > retry: > ll old_val, addr > or new_val, old_val, set_val > sc new_val, addr > beq retry > > > * Atomic access: One instruction > > > ldset old_val, set_val, addr > > > * Generic: Fallback to cmpxchg or use c++ __atomic_fetch_or > > **Testing** > * jtreg tests > * benchmark tests hev 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: 8293416: ZGC: Set mark bit with unconditional atomic ops ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10182/files - new: https://git.openjdk.org/jdk/pull/10182/files/5e580f44..016ee1f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10182&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10182&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10182.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10182/head:pull/10182 PR: https://git.openjdk.org/jdk/pull/10182 From shade at redhat.com Tue Sep 6 11:01:40 2022 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 6 Sep 2022 13:01:40 +0200 Subject: Hall of shame: Header compilation times In-Reply-To: <8f64fe8a-ea39-75db-91db-9a2f23a701e8@oracle.com> References: <8f64fe8a-ea39-75db-91db-9a2f23a701e8@oracle.com> Message-ID: <154d1bb3-6d8d-01d9-cb9f-20da74480646@redhat.com> On 9/6/22 12:31, Magnus Ihse Bursie wrote: > So, given this list, it seems like it would have a huge potential payoff > to start looking more closely on assembler.hpp. Is it strictly needed > everywhere it is included? Can it be split into multiple parts, so most > users only need to include some smaller subsets? Etc. And then > continuing doing the same with ciEnv.hpp and the top inline.hpp files... I agree it would be nice to comb through the includes and see what could be trimmed down. But it would be weird to do major file splits for minor build time improvements. This unfortunately has implications on long-term releases maintainability, where backports would not be cleanly applicable, the code archaeology would need to account for these splits, etc. I think once we combed through the obvious over-includes, we could just rely on precompiled headers to handle the rest? I just went and added these to precompiled.hpp: +#include "asm/assembler.hpp" +#include "asm/codeBuffer.hpp" +#include "asm/macroAssembler.hpp" +#include "code/debugInfo.hpp" +#include "code/codeCache.hpp" +#include "oops/access.hpp" ...and got fairly reproducible improvements with PCH with GCC 9.4.0: Before: real 1m7.208s user 43m38.448s sys 3m15.264s After: real 1m6.801s user 42m6.183s ; <-- about 3.7% improvement sys 3m19.828s -- Thanks, -Aleksey From aph-open at littlepinkcloud.com Tue Sep 6 11:02:45 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 6 Sep 2022 12:02:45 +0100 Subject: Hall of shame: Header compilation times In-Reply-To: <8f64fe8a-ea39-75db-91db-9a2f23a701e8@oracle.com> References: <8f64fe8a-ea39-75db-91db-9a2f23a701e8@oracle.com> Message-ID: On 9/6/22 11:31, Magnus Ihse Bursie wrote: > So, given this list, it seems like it would have a huge potential payoff > to start looking more closely on assembler.hpp. Is it strictly needed > everywhere it is included? Can it be split into multiple parts, so most > users only need to include some smaller subsets? Etc. And then > continuing doing the same with ciEnv.hpp and the top inline.hpp files... Do we really want to go there? Splitting files to "help" the compiler sounds like a time sink for the maintainers. We should be trying to minimize that, surely. Was this with precompiled headers? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From smonteith at openjdk.org Tue Sep 6 11:04:54 2022 From: smonteith at openjdk.org (Stuart Monteith) Date: Tue, 6 Sep 2022 11:04:54 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v2] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 07:26:39 GMT, Axel Boldt-Christmas wrote: >> I think the reason is that register r11 was used as temp register (and thus gets clobbered) by resolve_weak_handle previously. That's why this register was saved/restored here. But this has changed since it not used here anymore with your change. I am OK if you want to handle that in another PR. Just reminds. Thanks. > > I looked into it some further. You are correct. The reason I thought it was important was because this change hard crashed. > > + __ str(r10, Address(__ pre(sp, -wordSize))); > - __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize))); > > But I guess it is because I am misaligning the stack or there is some other reason `sp` cannot be bumped by `8`, only `16`. As this change is fine. > > + __ str(r10, Address(__ pre(sp, -2 * wordSize))); > - __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize))); > > Maybe using the RegSets and `push` would do this correctly, or it is some special invariant for these adapters. The stackpointer needs 128 bit/64 byte alignment. use RegSets and` MacroAssembler::push(RegSet, sp);`, which will only push pairs of register. In this case: ` stp(r10, zr, Address(__ pre(sp, -2 * wordSize)));` ------------- PR: https://git.openjdk.org/jdk/pull/10161 From smonteith at openjdk.org Tue Sep 6 11:04:53 2022 From: smonteith at openjdk.org (Stuart Monteith) Date: Tue, 6 Sep 2022 11:04:53 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v4] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 06:24:38 GMT, Axel Boldt-Christmas wrote: >> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. >> >> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. >> >> Testing: Oracle platforms tier 1-3 > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Make tmp register names consistent g1BarrierSetAssembler_aarch64 src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 301: > 299: rthread /* thread */, > 300: tmp1 /* tmp */, > 301: rscratch2 /* tmp */, "tmp1 /* tmp1 */," and "rscratch2 /* tmp2 */," to match the signature argument names. ------------- PR: https://git.openjdk.org/jdk/pull/10161 From magnus.ihse.bursie at oracle.com Tue Sep 6 11:14:27 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Sep 2022 13:14:27 +0200 Subject: Hall of shame: Header compilation times In-Reply-To: <154d1bb3-6d8d-01d9-cb9f-20da74480646@redhat.com> References: <8f64fe8a-ea39-75db-91db-9a2f23a701e8@oracle.com> <154d1bb3-6d8d-01d9-cb9f-20da74480646@redhat.com> Message-ID: On 2022-09-06 13:01, Aleksey Shipilev wrote: > On 9/6/22 12:31, Magnus Ihse Bursie wrote: >> So, given this list, it seems like it would have a huge potential payoff >> to start looking more closely on assembler.hpp. Is it strictly needed >> everywhere it is included? Can it be split into multiple parts, so most >> users only need to include some smaller subsets? Etc. And then >> continuing doing the same with ciEnv.hpp and the top inline.hpp files... > > I agree it would be nice to comb through the includes and see what > could be trimmed down. > > But it would be weird to do major file splits for minor build time > improvements. This unfortunately has implications on long-term > releases maintainability, where backports would not be cleanly > applicable, the code archaeology would need to account for these > splits, etc. Certainly! I do not claim to dictate how the hotspot folks wants to address it (or even if addressing it at all). Any changes must of course be reasonable. I only gave a few suggestions on the top off my head. However, I know from my prior experience that sometimes a header file can grow very large since it really covers too much. If that is the case, refactoring and breaking apart huge monolithic parts can be beneficial in many ways. But I do not know if that applies here. > > I think once we combed through the obvious over-includes, we could > just rely on precompiled headers to handle the rest? I just went and > added these to precompiled.hpp: > > +#include "asm/assembler.hpp" > +#include "asm/codeBuffer.hpp" > +#include "asm/macroAssembler.hpp" > +#include "code/debugInfo.hpp" > +#include "code/codeCache.hpp" > +#include "oops/access.hpp" > > ...and got fairly reproducible improvements with PCH with GCC 9.4.0: > > Before: > > real??? 1m7.208s > user??? 43m38.448s > sys??? 3m15.264s > > After: > > real??? 1m6.801s > user??? 42m6.183s? ; <-- about 3.7% improvement > sys??? 3m19.828s > Interesting. That is certainly one way to use this information, so the expensive header files are at least only compiled once. The result list has not only total time, but also average time and number of times included. Using the latter two, we can calculate a theoretical time saving for compiling a header file only once. This ordering might be slightly different from the total time spent, since a file that rather quick to compile but is included in many places can give a greater benefit to compile only once, than a "heavy" file that is included in just a few places, and the include count seems to go from ~40 to ~700 in the data, so there is definitely some variance there. /Magnus From aboldtch at openjdk.org Tue Sep 6 12:06:38 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 6 Sep 2022 12:06:38 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v5] In-Reply-To: References: Message-ID: > Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. > > Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. > > Testing: Oracle platforms tier 1-3 Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: - Push r10 using push and pop - Fix Argument Comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10161/files - new: https://git.openjdk.org/jdk/pull/10161/files/ad5a7694..1572b08a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10161&range=03-04 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10161.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10161/head:pull/10161 PR: https://git.openjdk.org/jdk/pull/10161 From aboldtch at openjdk.org Tue Sep 6 12:06:42 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 6 Sep 2022 12:06:42 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v4] In-Reply-To: <2UVNEbi5HyCGK7dTdnd9fhCvoE8_xSfmTjgZ7SrtNnI=.e758be5a-ea7d-45f8-bb3f-0877c10ad2f3@github.com> References: <2UVNEbi5HyCGK7dTdnd9fhCvoE8_xSfmTjgZ7SrtNnI=.e758be5a-ea7d-45f8-bb3f-0877c10ad2f3@github.com> Message-ID: On Tue, 6 Sep 2022 10:49:06 GMT, Stuart Monteith wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: >> >> Make tmp register names consistent g1BarrierSetAssembler_aarch64 > > src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 277: > >> 275: dst /* pre_val */, >> 276: rthread /* thread */, >> 277: tmp1 /* tmp */, > > For tmp1 and tmp2 the comments, to match the paramter names, would also be "/* tmp1 */" and "/* tmp2 */". Fixed ? > src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 301: > >> 299: rthread /* thread */, >> 300: tmp1 /* tmp */, >> 301: rscratch2 /* tmp */, > > "tmp1 /* tmp1 */," and "rscratch2 /* tmp2 */," to match the signature argument names. Fixed ? ------------- PR: https://git.openjdk.org/jdk/pull/10161 From aboldtch at openjdk.org Tue Sep 6 12:06:43 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 6 Sep 2022 12:06:43 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v2] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 10:57:47 GMT, Stuart Monteith wrote: >> I looked into it some further. You are correct. The reason I thought it was important was because this change hard crashed. >> >> + __ str(r10, Address(__ pre(sp, -wordSize))); >> - __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize))); >> >> But I guess it is because I am misaligning the stack or there is some other reason `sp` cannot be bumped by `8`, only `16`. As this change is fine. >> >> + __ str(r10, Address(__ pre(sp, -2 * wordSize))); >> - __ stp(r10, r11, Address(__ pre(sp, -2 * wordSize))); >> >> Maybe using the RegSets and `push` would do this correctly, or it is some special invariant for these adapters. > > The stackpointer needs 128 bit/64 byte alignment. use RegSets and` MacroAssembler::push(RegSet, sp);`, which will only push pairs of register. In this case: ` stp(r10, zr, Address(__ pre(sp, -2 * wordSize)));` Fix using `MacroAssembler::push(RegSet, sp);` ------------- PR: https://git.openjdk.org/jdk/pull/10161 From stuefe at openjdk.org Tue Sep 6 12:21:36 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 6 Sep 2022 12:21:36 GMT Subject: RFR: JDK-8293402: hs-err file printer should reattempt stack trace printing if it fails Message-ID: Hi, may I have reviews for this small improvement. The call stack may be the most important part of an hs-err file. We recently introduced printing of source information (https://bugs.openjdk.org/browse/JDK-8242181) which is nice but makes stack printing more vulnerable for two reasons: - we may crash due to a programmer error (e.g. https://bugs.openjdk.org/browse/JDK-8293344) - we may timeout on very slow machines/file systems when the source information are parsed from the debug info (we have seen those problems in the past) Therefore, VMError should retry stack printing without source information if the first attempt to print failed. Examples: Step timeouts while retrieving source info: 24 --------------- T H R E A D --------------- 25 26 Current thread (0x00007f70ac028bd0): JavaThread "main" [_thread_in_vm, id=565259, stack(0x00007f70b0587000,0x00007f70b0688000)] 27 28 Stack: [0x00007f70b0587000,0x00007f70b0688000], sp=0x00007f70b0686cf0, free space=1023k 29 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) 30 V [libjvm.so+0x1cd41c1] VMError::controlled_crash(int)+0x241 31 [timeout occurred during error reporting in step "printing native stack (with source info)"] after 30 s. 32 33 Retrying call stack printing without source information... 34 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) 35 V [libjvm.so+0x1cd41c1] VMError::controlled_crash(int)+0x241 36 V [libjvm.so+0x11cbe45] JNI_CreateJavaVM+0x5b5 37 C [libjli.so+0x4013] JavaMain+0x93 38 C [libjli.so+0x800d] ThreadJavaMain+0xd 39 Step crashes while retrieving source info: 24 --------------- T H R E A D --------------- 25 26 Current thread (0x00007fc000028bd0): JavaThread "main" [_thread_in_vm, id=569254, stack(0x00007fc00573c000,0x00007fc00583d000)] 27 28 Stack: [0x00007fc00573c000,0x00007fc00583d000], sp=0x00007fc00583bcf0, free space=1023k 29 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) 30 V [libjvm.so+0x1cd41e1] VMError::controlled_crash(int)+0x241 31 [error occurred during error reporting (printing native stack (with source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fc006694d78] 32 33 34 Retrying call stack printing without source information... 35 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) 36 V [libjvm.so+0x1cd41e1] VMError::controlled_crash(int)+0x241 37 V [libjvm.so+0x11cbe65] JNI_CreateJavaVM+0x5b5 38 C [libjli.so+0x4013] JavaMain+0x93 39 C [libjli.so+0x800d] ThreadJavaMain+0xd Thanks, Thomas ------------- Commit messages: - JDK-8293402-hs-err-file-printer-should-reattempt-stack-trace-printing-if-it-fails Changes: https://git.openjdk.org/jdk/pull/10179/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10179&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293402 Stats: 21 lines in 3 files changed: 14 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10179.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10179/head:pull/10179 PR: https://git.openjdk.org/jdk/pull/10179 From stefan.karlsson at oracle.com Tue Sep 6 12:28:53 2022 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 6 Sep 2022 14:28:53 +0200 Subject: Additional clang -ftime-trace data In-Reply-To: <5a53f5e1-35c5-5390-457b-418e16ca88ef@oracle.com> References: <5a53f5e1-35c5-5390-457b-418e16ca88ef@oracle.com> Message-ID: <6b07085f-bb59-2726-0e0a-d0b7b2d29426@oracle.com> If you want to see something ugly take a look at this patch, which cuts the inlining of AccessInternal code, and explicitly instantiate needed definitions in the a new access.cpp file: https://github.com/openjdk/jdk/compare/master...stefank:jdk:access_backend_no_inline_for_compile_times This PoC showed a 20% HotSpot compile time improvement, but I got feedback that this was so ugly that they would rather live with the extra compile time, than to ever have to look at the access.cpp file again. :) StefanK On 2022-09-06 12:36, Magnus Ihse Bursie wrote: > Here are more output from ClangBuildAnalyzer. Seems that > AccessInternal might be worth having a second look at, to see if it > can be made easier on the compiler..? > > **** Time summary: > Compilation (2033 times): > ? Parsing (frontend):????????? 271.6 s > ? Codegen & opts (backend):??? 274.1 s > > **** Files that took longest to parse (compiler frontend): > ? 1339 ms: ad_aarch64.o > ? 1311 ms: dfa_aarch64.o > ? 1108 ms: compileBroker.o > ? 1088 ms: compile.o > ? 1005 ms: ad_aarch64_misc.o > ?? 990 ms: library_call.o > ?? 971 ms: whitebox.o > ?? 953 ms: runtime.o > ?? 938 ms: sharedRuntime_aarch64.o > ?? 889 ms: instanceKlass.o > > **** Files that took longest to codegen (compiler backend): > ? 7267 ms: ad_aarch64_gen.o > ? 6830 ms: ad_aarch64.o > ? 5402 ms: dfa_aarch64.o > ? 3482 ms: whitebox.o > ? 3106 ms: ad_aarch64_misc.o > ? 2960 ms: jvmtiEnterTrace.o > ? 2844 ms: macroAssembler_aarch64.o > ? 2568 ms: jvmciCompilerToVMInit.o > ? 2520 ms: jni.o > ? 2512 ms: stubGenerator_aarch64.o > > **** Templates that took longest to instantiate: > ? 2884 ms: AccessInternal::OopLoadAtProxy<262144>::operator oopDesc * > (512 times, avg 5 ms) > ? 2870 ms: AccessInternal::load_at<262148, oopDesc *> (512 times, avg > 5 ms) > ? 2797 ms: AccessInternal::OopLoadAtProxy<1310720>::operator oopDesc * > (512 times, avg 5 ms) > ? 2783 ms: AccessInternal::load_at<1310724, oopDesc *> (512 times, avg > 5 ms) > ? 2656 ms: AccessInternal::PreRuntimeDispatch::load_at<286790, oopDesc > *> (512 times, avg 5 ms) > ? 2569 ms: AccessInternal::PreRuntimeDispatch::load_at<1335366, > oopDesc *> (512 times, avg 5 ms) > ? 2446 ms: Access<525312>::oop_atomic_xchg (383 > times, avg 6 ms) > ? 2380 ms: AccessInternal::atomic_xchg<525316, oopDesc *, oopDesc *> > (383 times, avg 6 ms) > ? 2311 ms: AccessInternal::atomic_xchg_reduce_types<549892, oopDesc *> > (383 times, avg 6 ms) > ? 2252 ms: AccessInternal::PreRuntimeDispatch::atomic_xchg<549892, > oopDesc *> (383 times, avg 5 ms) > ? 2234 ms: Access<262144>::oop_store_at (512 times, avg 4 ms) > ? 2168 ms: Access<1310720>::oop_store_at (512 times, avg 4 ms) > ? 2162 ms: AccessInternal::store_at<262148, oopDesc *> (512 times, avg > 4 ms) > ? 2119 ms: AccessInternal::PreRuntimeDispatch::store_at<286790, > oopDesc *> (512 times, avg 4 ms) > ? 2098 ms: AccessInternal::store_at<1310724, oopDesc *> (512 times, > avg 4 ms) > ? 2059 ms: AccessInternal::PreRuntimeDispatch::store_at<1335366, > oopDesc *> (512 times, avg 4 ms) > ? 2018 ms: AccessInternal::RuntimeDispatch<286790, oopDesc *, > AccessInternal::B... (512 times, avg 3 ms) > ? 1999 ms: AccessInternal::RuntimeDispatch<286790, oopDesc *, > AccessInternal::B... (512 times, avg 3 ms) > ? 1954 ms: AccessInternal::BarrierResolver<286790, oopDesc > *(*)(oopDesc *, long... (512 times, avg 3 ms) > ? 1949 ms: AccessInternal::BarrierResolver<286790, oopDesc > *(*)(oopDesc *, long... (512 times, avg 3 ms) > ? 1941 ms: AccessInternal::RuntimeDispatch<1335366, oopDesc *, > AccessInternal::... (512 times, avg 3 ms) > ? 1931 ms: AccessInternal::OopLoadProxy::operator > oopDesc * (414 times, avg 4 ms) > ? 1921 ms: AccessInternal::load<524292, oopDesc *, oopDesc *> (414 > times, avg 4 ms) > ? 1919 ms: AccessInternal::RuntimeDispatch<1335366, oopDesc *, > AccessInternal::... (512 times, avg 3 ms) > ? 1877 ms: AccessInternal::BarrierResolver<1335366, oopDesc > *(*)(oopDesc *, lon... (512 times, avg 3 ms) > ? 1872 ms: AccessInternal::BarrierResolver<1335366, oopDesc > *(*)(oopDesc *, lon... (512 times, avg 3 ms) > ? 1844 ms: AccessInternal::OopLoadProxy::operator > oopDesc * (391 times, avg 4 ms) > ? 1840 ms: AccessInternal::load_reduce_types<548932, oopDesc *> (414 > times, avg 4 ms) > ? 1834 ms: AccessInternal::load<528388, oopDesc *, oopDesc *> (391 > times, avg 4 ms) > ? 1789 ms: AccessInternal::PreRuntimeDispatch::load<548932, oopDesc *> > (414 times, avg 4 ms) > > **** Template sets that took longest to instantiate: > ?19441 ms: AccessInternal::BarrierResolver<$>::resolve_barrier (5560 > times, avg 3 ms) > ?19373 ms: AccessInternal::BarrierResolver<$>::resolve_barrier_rt > (5560 times, avg 3 ms) > ?18680 ms: AccessInternal::BarrierResolver<$>::resolve_barrier_gc<$> > (10787 times, avg 1 ms) > ?10406 ms: AccessInternal::PostRuntimeDispatch<$>::oop_access_barrier > (10218 times, avg 1 ms) > ?10357 ms: AccessInternal::load_at<$> (1953 times, avg 5 ms) > ? 9745 ms: AccessInternal::PreRuntimeDispatch::load_at<$> (1953 times, > avg 4 ms) > ? 8775 ms: AccessInternal::load<$> (3284 times, avg 2 ms) > ? 7888 ms: AccessInternal::RuntimeDispatch<$>::load_at (1953 times, > avg 4 ms) > ? 7876 ms: AccessInternal::PreRuntimeDispatch::load<$> (3068 times, > avg 2 ms) > ? 7811 ms: AccessInternal::RuntimeDispatch<$>::load_at_init (1953 > times, avg 3 ms) > ? 7470 ms: AccessInternal::load_reduce_types<$> (2771 times, avg 2 ms) > ? 5702 ms: AccessInternal::RuntimeDispatch<$>::load (1529 times, avg 3 > ms) > ? 5644 ms: AccessInternal::RuntimeDispatch<$>::load_init (1529 times, > avg 3 ms) > ? 5055 ms: oopDesc::obj_field_access<$> (925 times, avg 5 ms) > ? 4418 ms: Access<$>::oop_store_at<$> (1029 times, avg 4 ms) > ? 4275 ms: AccessInternal::store_at<$> (1029 times, avg 4 ms) > ? 4194 ms: AccessInternal::PreRuntimeDispatch::store_at<$> (1029 > times, avg 4 ms) > ? 3515 ms: AccessInternal::RuntimeDispatch<$>::store_at (1029 times, > avg 3 ms) > ? 3477 ms: AccessInternal::RuntimeDispatch<$>::store_at_init (1029 > times, avg 3 ms) > ? 2884 ms: AccessInternal::OopLoadAtProxy<262144>::operator oopDesc * > (512 times, avg 5 ms) > ? 2797 ms: AccessInternal::OopLoadAtProxy<1310720>::operator oopDesc * > (512 times, avg 5 ms) > ? 2446 ms: Access<$>::oop_atomic_xchg<$> (383 times, avg 6 ms) > ? 2380 ms: AccessInternal::atomic_xchg<$> (383 times, avg 6 ms) > ? 2311 ms: AccessInternal::atomic_xchg_reduce_types<$> (383 times, avg > 6 ms) > ? 2269 ms: IsIntegral<$> (2546 times, avg 0 ms) > ? 2252 ms: AccessInternal::PreRuntimeDispatch::atomic_xchg<$> (383 > times, avg 5 ms) > ? 2035 ms: ModRefBarrierSet::AccessBarrier<$>::oop_store_in_heap<$> > (1416 times, avg 1 ms) > ? 1996 ms: ModRefBarrierSet::AccessBarrier<$>::oop_store_in_heap_at > (1306 times, avg 1 ms) > ? 1931 ms: AccessInternal::OopLoadProxy::operator > oopDesc * (414 times, avg 4 ms) > ? 1844 ms: AccessInternal::OopLoadProxy::operator > oopDesc * (391 times, avg 4 ms) > > **** Functions that took longest to compile: > ? 3963 ms: State::MachNodeGenerator(int) > (gensrc/adfiles/ad_aarch64_gen.cpp) > ? 1137 ms: CompilerToVM::initialize_intrinsics(JVMCIEnv*) > (src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp) > ? 1099 ms: ClassVerifier::verify_method(methodHandle const&, > JavaThread*) (src/hotspot/share/classfile/verifier.cpp) > ? 1050 ms: readConfiguration0(JNIEnv_*, JVMCIEnv*) > (src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp) > ?? 595 ms: Parse::do_one_bytecode() (src/hotspot/share/opto/parse2.cpp) > ?? 511 ms: schema_extend_event_subklass_bytes(InstanceKlass const*, > ClassFilePa... > (src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp) > ?? 464 ms: State::_sub_Op_AddL(Node const*) > (gensrc/adfiles/dfa_aarch64.cpp) > ?? 394 ms: State::DFA(int, Node const*) (gensrc/adfiles/dfa_aarch64.cpp) > ?? 383 ms: State::MachOperGenerator(int) > (gensrc/adfiles/ad_aarch64_gen.cpp) > ?? 378 ms: JNIJVMCI::initialize_ids(JNIEnv_*) > (src/hotspot/share/jvmci/jvmciJavaClasses.cpp) > ?? 319 ms: State::_sub_Op_XorI(Node const*) > (gensrc/adfiles/dfa_aarch64.cpp) > ?? 315 ms: PhaseChaitin::Split(unsigned int, ResourceArea*) > (src/hotspot/share/opto/reg_split.cpp) > ?? 277 ms: GenerateOopMap::interp1(BytecodeStream*) > (src/hotspot/share/oops/generateOopMap.cpp) > ?? 260 ms: PhiNode::Ideal(PhaseGVN*, bool) > (src/hotspot/share/opto/cfgnode.cpp) > ?? 255 ms: State::_sub_Op_AndI(Node const*) > (gensrc/adfiles/dfa_aarch64.cpp) > ?? 229 ms: LIR_OpVisitState::visit(LIR_Op*) > (src/hotspot/share/c1/c1_LIR.cpp) > ?? 226 ms: Bytecodes::initialize() > (src/hotspot/share/interpreter/bytecodes.cpp) > ?? 222 ms: State::_sub_Op_AddI(Node const*) > (gensrc/adfiles/dfa_aarch64.cpp) > ?? 219 ms: State::_sub_Op_XorL(Node const*) > (gensrc/adfiles/dfa_aarch64.cpp) > ?? 216 ms: State::_sub_Op_AddP(Node const*) > (gensrc/adfiles/dfa_aarch64.cpp) > ?? 214 ms: TemplateTable::initialize() > (src/hotspot/share/interpreter/templateTable.cpp) > ?? 208 ms: Arguments::parse_each_vm_init_arg(JavaVMInitArgs const*, > bool*, JVMF... (src/hotspot/share/runtime/arguments.cpp) > ?? 208 ms: BCEscapeAnalyzer::iterate_one_block(ciBlock*, > BCEscapeAnalyzer::Stat... (src/hotspot/share/ci/bcEscapeAnalyzer.cpp) > ?? 189 ms: LibraryCallKit::inline_native_getEventWriter() > (src/hotspot/share/opto/library_call.cpp) > ?? 181 ms: PhaseStringOpts::replace_string_concat(StringConcat*) > (src/hotspot/share/opto/stringopts.cpp) > ?? 179 ms: PhaseChaitin::post_allocate_copy_removal() > (src/hotspot/share/opto/postaloc.cpp) > ?? 170 ms: Type::Initialize_shared(Compile*) > (src/hotspot/share/opto/type.cpp) > ?? 167 ms: _GLOBAL__sub_I_vmStructs.cpp > (src/hotspot/share/runtime/vmStructs.cpp) > ?? 166 ms: ConnectionGraph::split_unique_types(GrowableArray&, > GrowableA... (src/hotspot/share/opto/escape.cpp) > ?? 153 ms: State::_sub_Op_AndL(Node const*) > (gensrc/adfiles/dfa_aarch64.cpp) > > **** Function sets that took longest to compile / optimize: > ? 1725 ms: GrowableArrayWithAllocator<$>::grow(int) (436 times, avg 3 ms) > ? 1698 ms: void > OopOopIterateBoundedDispatch<$>::Table::oop_oop_iterate_bounded... > (515 times, avg 3 ms) > ? 1682 ms: void > OopOopIterateDispatch<$>::Table::oop_oop_iterate<$>(G1CMOopClos... > (613 times, avg 2 ms) > ? 1545 ms: > AccessInternal::PostRuntimeDispatch<$>::oop_access_barrier(void*) (766 > times, avg 2 ms) > ? 1037 ms: JfrEvent<$>::write_sized_event(JfrBuffer*, Thread*, > unsigned long lo... (145 times, avg 7 ms) > ?? 831 ms: void > InstanceMirrorKlass::oop_oop_iterate_bounded<$>(oopDesc*, G1CMO... > (120 times, avg 6 ms) > ?? 719 ms: void > InstanceStackChunkKlass::oop_oop_iterate_stack<$>(stackChunkOop... > (121 times, avg 5 ms) > ?? 641 ms: void InstanceMirrorKlass::oop_oop_iterate<$>(oopDesc*, > G1CMOopClosur... (121 times, avg 5 ms) > ?? 615 ms: void > InstanceRefKlass::oop_oop_iterate_ref_processing<$>(oopDesc*, G... > (120 times, avg 5 ms) > ?? 538 ms: void > InstanceRefKlass::oop_oop_iterate_discovery<$>(oopDesc*, Refere... > (120 times, avg 4 ms) > ?? 484 ms: EventWriterHost<$>::end_event_write(bool) (51 times, avg 9 ms) > ?? 481 ms: void > InstanceStackChunkKlass::oop_oop_iterate_stack_with_bitmap<$>(s... > (121 times, avg 3 ms) > ?? 468 ms: > AccessInternal::PostRuntimeDispatch<$>::oop_access_barrier(oopDesc*,... > (324 times, avg 1 ms) > ?? 468 ms: void > InstanceStackChunkKlass::oop_oop_iterate_stack_bounded<$>(stack... (77 > times, avg 6 ms) > ?? 443 ms: void > InstanceRefKlass::oop_oop_iterate_ref_processing<$>(oopDesc*, G... > (121 times, avg 3 ms) > ?? 417 ms: void > InstanceRefKlass::oop_oop_iterate_discovery<$>(oopDesc*, Refere... > (120 times, avg 3 ms) > ?? 385 ms: bool > BitMap::iterate<$>(StackChunkOopIterateBitmapClosure<$>*, unsig... > (238 times, avg 1 ms) > ?? 383 ms: AccessInternal::RuntimeDispatch<$>::load_init(void*) (346 > times, avg 1 ms) > ?? 351 ms: void > InstanceClassLoaderKlass::oop_oop_iterate_bounded<$>(oopDesc*, ... > (120 times, avg 2 ms) > ?? 328 ms: void > OopOopIterateDispatch<$>::Table::oop_oop_iterate<$>(AdjustPoint... (86 > times, avg 3 ms) > ?? 310 ms: WriterHost<$>::write_utf8(char const*) (27 times, avg 11 ms) > ?? 293 ms: oopDesc* > ZBarrierSet::AccessBarrier<$>::load_barrier_on_oop_field_pr... (284 > times, avg 1 ms) > ?? 268 ms: void WriterHost<$>::write<$>(unsigned long long) (62 times, > avg 4 ms) > ?? 257 ms: EventWriterHost<$>::begin_event_write(bool) (52 times, avg > 4 ms) > ?? 255 ms: void > InstanceStackChunkKlass::oop_oop_iterate_bounded<$>(oopDesc*, G... (84 > times, avg 3 ms) > ?? 228 ms: void > OopOopIterateDispatch<$>::Table::oop_oop_iterate<$>(G1MarkAndPu... (40 > times, avg 5 ms) > ?? 210 ms: BCEscapeAnalyzer::iterate_one_block(ciBlock*, > BCEscapeAnalyzer::Stat... (2 times, avg 105 ms) > ?? 197 ms: void WriterHost<$>::write<$>(long) (47 times, avg 4 ms) > ?? 183 ms: void > OopOopIterateBackwardsDispatch<$>::Table::oop_oop_iterate_backw... (33 > times, avg 5 ms) > ?? 171 ms: > ZBarrierSet::AccessBarrier<$>::oop_load_in_heap_at(oopDesc*, long) (65 > times, avg 2 ms) > > /Magnus > From rehn at openjdk.org Tue Sep 6 13:06:40 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 6 Sep 2022 13:06:40 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 13:36:31 GMT, Martin Doerr wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 36: > >> 34: // Syscall defined in kernel 4.3 >> 35: #if !defined(SYS_membarrier) >> 36: #define SYS_membarrier 324 > > I'd like to get rid of the platform checks in this generic linux file. > This number seems to be the only platform specific part: SYS_gettid just have large ifdef else and then an error. I guess e.g. ppc always compile on platforms with it defined since it doesn't need to define it. The solution with a per plattform file as zSyscall does seems to be the nicest way. But IMHO a bit out of scope for this PR. ------------- PR: https://git.openjdk.org/jdk/pull/10123 From duke at openjdk.org Tue Sep 6 14:30:40 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Tue, 6 Sep 2022 14:30:40 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v6] In-Reply-To: References: Message-ID: > This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: > > vptest xmm0, xmm1 > jb if_true > if_false: > > instead of: > > vptest xmm0, xmm1 > setb r10 > movzbl r10 > testl r10 > jne if_true > if_false: > > The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: > > Before After > Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change > ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% > > I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Merge branch 'master' into improveVTest - refactor x86 - revert renaming temp - style + use rscratch instead of tmp - fix - redo aarch - Merge branch 'master' into improveVTest - delete aarch64 vector files - copyright - fix condition - ... and 12 more: https://git.openjdk.org/jdk/compare/6a1e98cb...c188a518 ------------- Changes: https://git.openjdk.org/jdk/pull/9855/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=05 Stats: 482 lines in 23 files changed: 214 ins; 144 del; 124 mod Patch: https://git.openjdk.org/jdk/pull/9855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9855/head:pull/9855 PR: https://git.openjdk.org/jdk/pull/9855 From magnus.ihse.bursie at oracle.com Tue Sep 6 14:44:35 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 6 Sep 2022 16:44:35 +0200 Subject: Additional clang -ftime-trace data In-Reply-To: <6b07085f-bb59-2726-0e0a-d0b7b2d29426@oracle.com> References: <5a53f5e1-35c5-5390-457b-418e16ca88ef@oracle.com> <6b07085f-bb59-2726-0e0a-d0b7b2d29426@oracle.com> Message-ID: <6302700d-ed1f-e877-d7ab-63d0817c1408@oracle.com> On 2022-09-06 14:28, Stefan Karlsson wrote: > If you want to see something ugly take a look at this patch, which > cuts the inlining of AccessInternal code, and explicitly instantiate > needed definitions in the a new access.cpp file: > https://github.com/openjdk/jdk/compare/master...stefank:jdk:access_backend_no_inline_for_compile_times > > > This PoC showed a 20% HotSpot compile time improvement, but I got > feedback that this was so ugly that they would rather live with the > extra compile time, than to ever have to look at the access.cpp file > again. :) Ok, so the AccessInternal cost of compile time was already well-known. I had hoped I would at least provide some new insights. :) I can understand that this was perceived as ugly. Is this the only possible solution, though? I realize I'm far outside my (admittedly very small) comfort zone of C++, but usually, There Is More Than One Way To Do It. Maybe it's possible to find a more palatable solution, that still cuts down compilation time? /Magnus > > StefanK > > On 2022-09-06 12:36, Magnus Ihse Bursie wrote: >> Here are more output from ClangBuildAnalyzer. Seems that >> AccessInternal might be worth having a second look at, to see if it >> can be made easier on the compiler..? >> >> **** Time summary: >> Compilation (2033 times): >> ? Parsing (frontend):????????? 271.6 s >> ? Codegen & opts (backend):??? 274.1 s >> >> **** Files that took longest to parse (compiler frontend): >> ? 1339 ms: ad_aarch64.o >> ? 1311 ms: dfa_aarch64.o >> ? 1108 ms: compileBroker.o >> ? 1088 ms: compile.o >> ? 1005 ms: ad_aarch64_misc.o >> ?? 990 ms: library_call.o >> ?? 971 ms: whitebox.o >> ?? 953 ms: runtime.o >> ?? 938 ms: sharedRuntime_aarch64.o >> ?? 889 ms: instanceKlass.o >> >> **** Files that took longest to codegen (compiler backend): >> ? 7267 ms: ad_aarch64_gen.o >> ? 6830 ms: ad_aarch64.o >> ? 5402 ms: dfa_aarch64.o >> ? 3482 ms: whitebox.o >> ? 3106 ms: ad_aarch64_misc.o >> ? 2960 ms: jvmtiEnterTrace.o >> ? 2844 ms: macroAssembler_aarch64.o >> ? 2568 ms: jvmciCompilerToVMInit.o >> ? 2520 ms: jni.o >> ? 2512 ms: stubGenerator_aarch64.o >> >> **** Templates that took longest to instantiate: >> ? 2884 ms: AccessInternal::OopLoadAtProxy<262144>::operator oopDesc * >> (512 times, avg 5 ms) >> ? 2870 ms: AccessInternal::load_at<262148, oopDesc *> (512 times, avg >> 5 ms) >> ? 2797 ms: AccessInternal::OopLoadAtProxy<1310720>::operator oopDesc >> * (512 times, avg 5 ms) >> ? 2783 ms: AccessInternal::load_at<1310724, oopDesc *> (512 times, >> avg 5 ms) >> ? 2656 ms: AccessInternal::PreRuntimeDispatch::load_at<286790, >> oopDesc *> (512 times, avg 5 ms) >> ? 2569 ms: AccessInternal::PreRuntimeDispatch::load_at<1335366, >> oopDesc *> (512 times, avg 5 ms) >> ? 2446 ms: Access<525312>::oop_atomic_xchg (383 >> times, avg 6 ms) >> ? 2380 ms: AccessInternal::atomic_xchg<525316, oopDesc *, oopDesc *> >> (383 times, avg 6 ms) >> ? 2311 ms: AccessInternal::atomic_xchg_reduce_types<549892, oopDesc >> *> (383 times, avg 6 ms) >> ? 2252 ms: AccessInternal::PreRuntimeDispatch::atomic_xchg<549892, >> oopDesc *> (383 times, avg 5 ms) >> ? 2234 ms: Access<262144>::oop_store_at (512 times, avg 4 ms) >> ? 2168 ms: Access<1310720>::oop_store_at (512 times, avg 4 >> ms) >> ? 2162 ms: AccessInternal::store_at<262148, oopDesc *> (512 times, >> avg 4 ms) >> ? 2119 ms: AccessInternal::PreRuntimeDispatch::store_at<286790, >> oopDesc *> (512 times, avg 4 ms) >> ? 2098 ms: AccessInternal::store_at<1310724, oopDesc *> (512 times, >> avg 4 ms) >> ? 2059 ms: AccessInternal::PreRuntimeDispatch::store_at<1335366, >> oopDesc *> (512 times, avg 4 ms) >> ? 2018 ms: AccessInternal::RuntimeDispatch<286790, oopDesc *, >> AccessInternal::B... (512 times, avg 3 ms) >> ? 1999 ms: AccessInternal::RuntimeDispatch<286790, oopDesc *, >> AccessInternal::B... (512 times, avg 3 ms) >> ? 1954 ms: AccessInternal::BarrierResolver<286790, oopDesc >> *(*)(oopDesc *, long... (512 times, avg 3 ms) >> ? 1949 ms: AccessInternal::BarrierResolver<286790, oopDesc >> *(*)(oopDesc *, long... (512 times, avg 3 ms) >> ? 1941 ms: AccessInternal::RuntimeDispatch<1335366, oopDesc *, >> AccessInternal::... (512 times, avg 3 ms) >> ? 1931 ms: AccessInternal::OopLoadProxy::operator >> oopDesc * (414 times, avg 4 ms) >> ? 1921 ms: AccessInternal::load<524292, oopDesc *, oopDesc *> (414 >> times, avg 4 ms) >> ? 1919 ms: AccessInternal::RuntimeDispatch<1335366, oopDesc *, >> AccessInternal::... (512 times, avg 3 ms) >> ? 1877 ms: AccessInternal::BarrierResolver<1335366, oopDesc >> *(*)(oopDesc *, lon... (512 times, avg 3 ms) >> ? 1872 ms: AccessInternal::BarrierResolver<1335366, oopDesc >> *(*)(oopDesc *, lon... (512 times, avg 3 ms) >> ? 1844 ms: AccessInternal::OopLoadProxy::operator >> oopDesc * (391 times, avg 4 ms) >> ? 1840 ms: AccessInternal::load_reduce_types<548932, oopDesc *> (414 >> times, avg 4 ms) >> ? 1834 ms: AccessInternal::load<528388, oopDesc *, oopDesc *> (391 >> times, avg 4 ms) >> ? 1789 ms: AccessInternal::PreRuntimeDispatch::load<548932, oopDesc >> *> (414 times, avg 4 ms) >> >> **** Template sets that took longest to instantiate: >> ?19441 ms: AccessInternal::BarrierResolver<$>::resolve_barrier (5560 >> times, avg 3 ms) >> ?19373 ms: AccessInternal::BarrierResolver<$>::resolve_barrier_rt >> (5560 times, avg 3 ms) >> ?18680 ms: AccessInternal::BarrierResolver<$>::resolve_barrier_gc<$> >> (10787 times, avg 1 ms) >> ?10406 ms: AccessInternal::PostRuntimeDispatch<$>::oop_access_barrier >> (10218 times, avg 1 ms) >> ?10357 ms: AccessInternal::load_at<$> (1953 times, avg 5 ms) >> ? 9745 ms: AccessInternal::PreRuntimeDispatch::load_at<$> (1953 >> times, avg 4 ms) >> ? 8775 ms: AccessInternal::load<$> (3284 times, avg 2 ms) >> ? 7888 ms: AccessInternal::RuntimeDispatch<$>::load_at (1953 times, >> avg 4 ms) >> ? 7876 ms: AccessInternal::PreRuntimeDispatch::load<$> (3068 times, >> avg 2 ms) >> ? 7811 ms: AccessInternal::RuntimeDispatch<$>::load_at_init (1953 >> times, avg 3 ms) >> ? 7470 ms: AccessInternal::load_reduce_types<$> (2771 times, avg 2 ms) >> ? 5702 ms: AccessInternal::RuntimeDispatch<$>::load (1529 times, avg >> 3 ms) >> ? 5644 ms: AccessInternal::RuntimeDispatch<$>::load_init (1529 times, >> avg 3 ms) >> ? 5055 ms: oopDesc::obj_field_access<$> (925 times, avg 5 ms) >> ? 4418 ms: Access<$>::oop_store_at<$> (1029 times, avg 4 ms) >> ? 4275 ms: AccessInternal::store_at<$> (1029 times, avg 4 ms) >> ? 4194 ms: AccessInternal::PreRuntimeDispatch::store_at<$> (1029 >> times, avg 4 ms) >> ? 3515 ms: AccessInternal::RuntimeDispatch<$>::store_at (1029 times, >> avg 3 ms) >> ? 3477 ms: AccessInternal::RuntimeDispatch<$>::store_at_init (1029 >> times, avg 3 ms) >> ? 2884 ms: AccessInternal::OopLoadAtProxy<262144>::operator oopDesc * >> (512 times, avg 5 ms) >> ? 2797 ms: AccessInternal::OopLoadAtProxy<1310720>::operator oopDesc >> * (512 times, avg 5 ms) >> ? 2446 ms: Access<$>::oop_atomic_xchg<$> (383 times, avg 6 ms) >> ? 2380 ms: AccessInternal::atomic_xchg<$> (383 times, avg 6 ms) >> ? 2311 ms: AccessInternal::atomic_xchg_reduce_types<$> (383 times, >> avg 6 ms) >> ? 2269 ms: IsIntegral<$> (2546 times, avg 0 ms) >> ? 2252 ms: AccessInternal::PreRuntimeDispatch::atomic_xchg<$> (383 >> times, avg 5 ms) >> ? 2035 ms: ModRefBarrierSet::AccessBarrier<$>::oop_store_in_heap<$> >> (1416 times, avg 1 ms) >> ? 1996 ms: ModRefBarrierSet::AccessBarrier<$>::oop_store_in_heap_at >> (1306 times, avg 1 ms) >> ? 1931 ms: AccessInternal::OopLoadProxy::operator >> oopDesc * (414 times, avg 4 ms) >> ? 1844 ms: AccessInternal::OopLoadProxy::operator >> oopDesc * (391 times, avg 4 ms) >> >> **** Functions that took longest to compile: >> ? 3963 ms: State::MachNodeGenerator(int) >> (gensrc/adfiles/ad_aarch64_gen.cpp) >> ? 1137 ms: CompilerToVM::initialize_intrinsics(JVMCIEnv*) >> (src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp) >> ? 1099 ms: ClassVerifier::verify_method(methodHandle const&, >> JavaThread*) (src/hotspot/share/classfile/verifier.cpp) >> ? 1050 ms: readConfiguration0(JNIEnv_*, JVMCIEnv*) >> (src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp) >> ?? 595 ms: Parse::do_one_bytecode() (src/hotspot/share/opto/parse2.cpp) >> ?? 511 ms: schema_extend_event_subklass_bytes(InstanceKlass const*, >> ClassFilePa... >> (src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp) >> ?? 464 ms: State::_sub_Op_AddL(Node const*) >> (gensrc/adfiles/dfa_aarch64.cpp) >> ?? 394 ms: State::DFA(int, Node const*) (gensrc/adfiles/dfa_aarch64.cpp) >> ?? 383 ms: State::MachOperGenerator(int) >> (gensrc/adfiles/ad_aarch64_gen.cpp) >> ?? 378 ms: JNIJVMCI::initialize_ids(JNIEnv_*) >> (src/hotspot/share/jvmci/jvmciJavaClasses.cpp) >> ?? 319 ms: State::_sub_Op_XorI(Node const*) >> (gensrc/adfiles/dfa_aarch64.cpp) >> ?? 315 ms: PhaseChaitin::Split(unsigned int, ResourceArea*) >> (src/hotspot/share/opto/reg_split.cpp) >> ?? 277 ms: GenerateOopMap::interp1(BytecodeStream*) >> (src/hotspot/share/oops/generateOopMap.cpp) >> ?? 260 ms: PhiNode::Ideal(PhaseGVN*, bool) >> (src/hotspot/share/opto/cfgnode.cpp) >> ?? 255 ms: State::_sub_Op_AndI(Node const*) >> (gensrc/adfiles/dfa_aarch64.cpp) >> ?? 229 ms: LIR_OpVisitState::visit(LIR_Op*) >> (src/hotspot/share/c1/c1_LIR.cpp) >> ?? 226 ms: Bytecodes::initialize() >> (src/hotspot/share/interpreter/bytecodes.cpp) >> ?? 222 ms: State::_sub_Op_AddI(Node const*) >> (gensrc/adfiles/dfa_aarch64.cpp) >> ?? 219 ms: State::_sub_Op_XorL(Node const*) >> (gensrc/adfiles/dfa_aarch64.cpp) >> ?? 216 ms: State::_sub_Op_AddP(Node const*) >> (gensrc/adfiles/dfa_aarch64.cpp) >> ?? 214 ms: TemplateTable::initialize() >> (src/hotspot/share/interpreter/templateTable.cpp) >> ?? 208 ms: Arguments::parse_each_vm_init_arg(JavaVMInitArgs const*, >> bool*, JVMF... (src/hotspot/share/runtime/arguments.cpp) >> ?? 208 ms: BCEscapeAnalyzer::iterate_one_block(ciBlock*, >> BCEscapeAnalyzer::Stat... (src/hotspot/share/ci/bcEscapeAnalyzer.cpp) >> ?? 189 ms: LibraryCallKit::inline_native_getEventWriter() >> (src/hotspot/share/opto/library_call.cpp) >> ?? 181 ms: PhaseStringOpts::replace_string_concat(StringConcat*) >> (src/hotspot/share/opto/stringopts.cpp) >> ?? 179 ms: PhaseChaitin::post_allocate_copy_removal() >> (src/hotspot/share/opto/postaloc.cpp) >> ?? 170 ms: Type::Initialize_shared(Compile*) >> (src/hotspot/share/opto/type.cpp) >> ?? 167 ms: _GLOBAL__sub_I_vmStructs.cpp >> (src/hotspot/share/runtime/vmStructs.cpp) >> ?? 166 ms: ConnectionGraph::split_unique_types(GrowableArray&, >> GrowableA... (src/hotspot/share/opto/escape.cpp) >> ?? 153 ms: State::_sub_Op_AndL(Node const*) >> (gensrc/adfiles/dfa_aarch64.cpp) >> >> **** Function sets that took longest to compile / optimize: >> ? 1725 ms: GrowableArrayWithAllocator<$>::grow(int) (436 times, avg 3 >> ms) >> ? 1698 ms: void >> OopOopIterateBoundedDispatch<$>::Table::oop_oop_iterate_bounded... >> (515 times, avg 3 ms) >> ? 1682 ms: void >> OopOopIterateDispatch<$>::Table::oop_oop_iterate<$>(G1CMOopClos... >> (613 times, avg 2 ms) >> ? 1545 ms: >> AccessInternal::PostRuntimeDispatch<$>::oop_access_barrier(void*) >> (766 times, avg 2 ms) >> ? 1037 ms: JfrEvent<$>::write_sized_event(JfrBuffer*, Thread*, >> unsigned long lo... (145 times, avg 7 ms) >> ?? 831 ms: void >> InstanceMirrorKlass::oop_oop_iterate_bounded<$>(oopDesc*, G1CMO... >> (120 times, avg 6 ms) >> ?? 719 ms: void >> InstanceStackChunkKlass::oop_oop_iterate_stack<$>(stackChunkOop... >> (121 times, avg 5 ms) >> ?? 641 ms: void InstanceMirrorKlass::oop_oop_iterate<$>(oopDesc*, >> G1CMOopClosur... (121 times, avg 5 ms) >> ?? 615 ms: void >> InstanceRefKlass::oop_oop_iterate_ref_processing<$>(oopDesc*, G... >> (120 times, avg 5 ms) >> ?? 538 ms: void >> InstanceRefKlass::oop_oop_iterate_discovery<$>(oopDesc*, Refere... >> (120 times, avg 4 ms) >> ?? 484 ms: EventWriterHost<$>::end_event_write(bool) (51 times, avg 9 >> ms) >> ?? 481 ms: void >> InstanceStackChunkKlass::oop_oop_iterate_stack_with_bitmap<$>(s... >> (121 times, avg 3 ms) >> ?? 468 ms: >> AccessInternal::PostRuntimeDispatch<$>::oop_access_barrier(oopDesc*,... >> (324 times, avg 1 ms) >> ?? 468 ms: void >> InstanceStackChunkKlass::oop_oop_iterate_stack_bounded<$>(stack... >> (77 times, avg 6 ms) >> ?? 443 ms: void >> InstanceRefKlass::oop_oop_iterate_ref_processing<$>(oopDesc*, G... >> (121 times, avg 3 ms) >> ?? 417 ms: void >> InstanceRefKlass::oop_oop_iterate_discovery<$>(oopDesc*, Refere... >> (120 times, avg 3 ms) >> ?? 385 ms: bool >> BitMap::iterate<$>(StackChunkOopIterateBitmapClosure<$>*, unsig... >> (238 times, avg 1 ms) >> ?? 383 ms: AccessInternal::RuntimeDispatch<$>::load_init(void*) (346 >> times, avg 1 ms) >> ?? 351 ms: void >> InstanceClassLoaderKlass::oop_oop_iterate_bounded<$>(oopDesc*, ... >> (120 times, avg 2 ms) >> ?? 328 ms: void >> OopOopIterateDispatch<$>::Table::oop_oop_iterate<$>(AdjustPoint... >> (86 times, avg 3 ms) >> ?? 310 ms: WriterHost<$>::write_utf8(char const*) (27 times, avg 11 ms) >> ?? 293 ms: oopDesc* >> ZBarrierSet::AccessBarrier<$>::load_barrier_on_oop_field_pr... (284 >> times, avg 1 ms) >> ?? 268 ms: void WriterHost<$>::write<$>(unsigned long long) (62 >> times, avg 4 ms) >> ?? 257 ms: EventWriterHost<$>::begin_event_write(bool) (52 times, avg >> 4 ms) >> ?? 255 ms: void >> InstanceStackChunkKlass::oop_oop_iterate_bounded<$>(oopDesc*, G... >> (84 times, avg 3 ms) >> ?? 228 ms: void >> OopOopIterateDispatch<$>::Table::oop_oop_iterate<$>(G1MarkAndPu... >> (40 times, avg 5 ms) >> ?? 210 ms: BCEscapeAnalyzer::iterate_one_block(ciBlock*, >> BCEscapeAnalyzer::Stat... (2 times, avg 105 ms) >> ?? 197 ms: void WriterHost<$>::write<$>(long) (47 times, avg 4 ms) >> ?? 183 ms: void >> OopOopIterateBackwardsDispatch<$>::Table::oop_oop_iterate_backw... >> (33 times, avg 5 ms) >> ?? 171 ms: >> ZBarrierSet::AccessBarrier<$>::oop_load_in_heap_at(oopDesc*, long) >> (65 times, avg 2 ms) >> >> /Magnus >> > From stuefe at openjdk.org Tue Sep 6 15:37:40 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 6 Sep 2022 15:37:40 GMT Subject: RFR: JDK-8293402: hs-err file printer should reattempt stack trace printing if it fails In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 08:05:23 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews for this small improvement. > > The call stack may be the most important part of an hs-err file. We recently introduced printing of source information (https://bugs.openjdk.org/browse/JDK-8242181) which is nice but makes stack printing more vulnerable for two reasons: > - we may crash due to a programmer error (e.g. https://bugs.openjdk.org/browse/JDK-8293344) > - we may timeout on very slow machines/file systems when the source information are parsed from the debug info (we have seen those problems in the past) > > Therefore, VMError should retry stack printing without source information if the first attempt to print failed. > > Examples: > > Step timeouts while retrieving source info: > > > 24 --------------- T H R E A D --------------- > 25 > 26 Current thread (0x00007f70ac028bd0): JavaThread "main" [_thread_in_vm, id=565259, stack(0x00007f70b0587000,0x00007f70b0688000)] > 27 > 28 Stack: [0x00007f70b0587000,0x00007f70b0688000], sp=0x00007f70b0686cf0, free space=1023k > 29 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 30 V [libjvm.so+0x1cd41c1] VMError::controlled_crash(int)+0x241 > 31 [timeout occurred during error reporting in step "printing native stack (with source info)"] after 30 s. > 32 > 33 Retrying call stack printing without source information... > 34 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 35 V [libjvm.so+0x1cd41c1] VMError::controlled_crash(int)+0x241 > 36 V [libjvm.so+0x11cbe45] JNI_CreateJavaVM+0x5b5 > 37 C [libjli.so+0x4013] JavaMain+0x93 > 38 C [libjli.so+0x800d] ThreadJavaMain+0xd > 39 > > > > Step crashes while retrieving source info: > > > 24 --------------- T H R E A D --------------- > 25 > 26 Current thread (0x00007fc000028bd0): JavaThread "main" [_thread_in_vm, id=569254, stack(0x00007fc00573c000,0x00007fc00583d000)] > 27 > 28 Stack: [0x00007fc00573c000,0x00007fc00583d000], sp=0x00007fc00583bcf0, free space=1023k > 29 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 30 V [libjvm.so+0x1cd41e1] VMError::controlled_crash(int)+0x241 > 31 [error occurred during error reporting (printing native stack (with source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fc006694d78] > 32 > 33 > 34 Retrying call stack printing without source information... > 35 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 36 V [libjvm.so+0x1cd41e1] VMError::controlled_crash(int)+0x241 > 37 V [libjvm.so+0x11cbe65] JNI_CreateJavaVM+0x5b5 > 38 C [libjli.so+0x4013] JavaMain+0x93 > 39 C [libjli.so+0x800d] ThreadJavaMain+0xd > > > > Thanks, Thomas Pinging @chhagedorn :) ------------- PR: https://git.openjdk.org/jdk/pull/10179 From coleenp at openjdk.org Tue Sep 6 16:40:18 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 6 Sep 2022 16:40:18 GMT Subject: RFR: 8292383: Create a SymbolHandle type to use for ResourceHashtable Message-ID: This change creates a SymbolHandle which shares code with TempNewSymbol and moves them to their own header file. We could expand this use if needed for GrowableArrays and other things where we have some various Symbol increment/decrement refcounts now. Changed a few ResourceHashtables that take Symbol* keys to use SymbolHandle and verified the refcounts. Also fixed the gtest. Tested with tier1-7. ------------- Commit messages: - 8292383: Create a SymbolKey type to use for ResourceHashtable Changes: https://git.openjdk.org/jdk/pull/10052/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10052&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292383 Stats: 237 lines in 16 files changed: 108 ins; 82 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/10052.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10052/head:pull/10052 PR: https://git.openjdk.org/jdk/pull/10052 From chagedorn at openjdk.org Tue Sep 6 17:24:02 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 6 Sep 2022 17:24:02 GMT Subject: RFR: JDK-8293402: hs-err file printer should reattempt stack trace printing if it fails In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 08:05:23 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews for this small improvement. > > The call stack may be the most important part of an hs-err file. We recently introduced printing of source information (https://bugs.openjdk.org/browse/JDK-8242181) which is nice but makes stack printing more vulnerable for two reasons: > - we may crash due to a programmer error (e.g. https://bugs.openjdk.org/browse/JDK-8293344) > - we may timeout on very slow machines/file systems when the source information are parsed from the debug info (we have seen those problems in the past) > > Therefore, VMError should retry stack printing without source information if the first attempt to print failed. > > Examples: > > Step timeouts while retrieving source info: > > > 24 --------------- T H R E A D --------------- > 25 > 26 Current thread (0x00007f70ac028bd0): JavaThread "main" [_thread_in_vm, id=565259, stack(0x00007f70b0587000,0x00007f70b0688000)] > 27 > 28 Stack: [0x00007f70b0587000,0x00007f70b0688000], sp=0x00007f70b0686cf0, free space=1023k > 29 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 30 V [libjvm.so+0x1cd41c1] VMError::controlled_crash(int)+0x241 > 31 [timeout occurred during error reporting in step "printing native stack (with source info)"] after 30 s. > 32 > 33 Retrying call stack printing without source information... > 34 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 35 V [libjvm.so+0x1cd41c1] VMError::controlled_crash(int)+0x241 > 36 V [libjvm.so+0x11cbe45] JNI_CreateJavaVM+0x5b5 > 37 C [libjli.so+0x4013] JavaMain+0x93 > 38 C [libjli.so+0x800d] ThreadJavaMain+0xd > 39 > > > > Step crashes while retrieving source info: > > > 24 --------------- T H R E A D --------------- > 25 > 26 Current thread (0x00007fc000028bd0): JavaThread "main" [_thread_in_vm, id=569254, stack(0x00007fc00573c000,0x00007fc00583d000)] > 27 > 28 Stack: [0x00007fc00573c000,0x00007fc00583d000], sp=0x00007fc00583bcf0, free space=1023k > 29 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 30 V [libjvm.so+0x1cd41e1] VMError::controlled_crash(int)+0x241 > 31 [error occurred during error reporting (printing native stack (with source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fc006694d78] > 32 > 33 > 34 Retrying call stack printing without source information... > 35 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 36 V [libjvm.so+0x1cd41e1] VMError::controlled_crash(int)+0x241 > 37 V [libjvm.so+0x11cbe65] JNI_CreateJavaVM+0x5b5 > 38 C [libjli.so+0x4013] JavaMain+0x93 > 39 C [libjli.so+0x800d] ThreadJavaMain+0xd > > > > Thanks, Thomas That looks good to me! Thanks for following up with this RFE after proposing it in the PR of JDK-8242181. I think it is very beneficial to have this safety net for the reasons you've stated - also in regard to extending the parser to support DWARF 5 (or older versions) at some point in the future. I fully agree that a missing stack trace due to a crash/timeout is one of the worst things that could happen when reporting an error. ------------- Marked as reviewed by chagedorn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10179 From kbarrett at openjdk.org Tue Sep 6 17:30:48 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 6 Sep 2022 17:30:48 GMT Subject: RFR: 8293416: ZGC: Set mark bit with unconditional atomic ops [v2] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 11:01:08 GMT, hev wrote: >> **Summary** >> Support to set ZGC mark bit with unconditional atomic ops. >> >> **Motivation** >> ZGC currently modify mark-bitmap by a conditional atomic operation (cmpxchg). This way is not optimal, which will retry the loop when cmpxchg fails. >> >> **Description** >> First, This patch-set add an new unconditional atomic operation: Atomic::fetch_and_or, which is implemented in different ways for different CPU architectures: >> >> * Exclusive access: Non-nested loop >> >> >> retry: >> ll old_val, addr >> or new_val, old_val, set_val >> sc new_val, addr >> beq retry >> >> >> * Atomic access: One instruction >> >> >> ldset old_val, set_val, addr >> >> >> * Generic: Fallback to cmpxchg or use c++ __atomic_fetch_or >> >> **Testing** >> * jtreg tests >> * benchmark tests > > hev 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: > > 8293416: ZGC: Set mark bit with unconditional atomic ops The Atomic changes being proposed here are a subset of https://bugs.openjdk.org/browse/JDK-8293117 Add atomic bitset functions which is in-progress. ------------- PR: https://git.openjdk.org/jdk/pull/10182 From duke at openjdk.org Tue Sep 6 17:31:46 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Tue, 6 Sep 2022 17:31:46 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v7] In-Reply-To: References: Message-ID: > This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: > > vptest xmm0, xmm1 > jb if_true > if_false: > > instead of: > > vptest xmm0, xmm1 > setb r10 > movzbl r10 > testl r10 > jne if_true > if_false: > > The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: > > Before After > Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change > ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% > > I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: fix merge problems ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9855/files - new: https://git.openjdk.org/jdk/pull/9855/files/c188a518..e5a81c41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9855/head:pull/9855 PR: https://git.openjdk.org/jdk/pull/9855 From iklam at openjdk.org Tue Sep 6 18:14:43 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 6 Sep 2022 18:14:43 GMT Subject: RFR: 8292383: Create a SymbolHandle type to use for ResourceHashtable In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 21:00:57 GMT, Coleen Phillimore wrote: > This change creates a SymbolHandle which shares code with TempNewSymbol and moves them to their own header file. We could expand this use if needed for GrowableArrays and other things where we have some various Symbol increment/decrement refcounts now. Changed a few ResourceHashtables that take Symbol* keys to use SymbolHandle and verified the refcounts. Also fixed the gtest. > Tested with tier1-7. LGTM! This is a nice clean up. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/10052 From jrose at openjdk.org Tue Sep 6 18:41:45 2022 From: jrose at openjdk.org (John R Rose) Date: Tue, 6 Sep 2022 18:41:45 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v4] In-Reply-To: References: Message-ID: > Refactor code from inside of CompressedStream into its own unit. > > This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). > > Add gtests. John R Rose has updated the pull request incrementally with one additional commit since the last revision: respond to reviewer comments; move printing code to a better place; remove vmStructs coupling from SA ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10067/files - new: https://git.openjdk.org/jdk/pull/10067/files/dc30f7ce..439b108b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=02-03 Stats: 228 lines in 8 files changed: 112 ins; 85 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/10067.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10067/head:pull/10067 PR: https://git.openjdk.org/jdk/pull/10067 From coleenp at openjdk.org Tue Sep 6 18:44:46 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 6 Sep 2022 18:44:46 GMT Subject: RFR: 8292383: Create a SymbolHandle type to use for ResourceHashtable In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 21:00:57 GMT, Coleen Phillimore wrote: > This change creates a SymbolHandle which shares code with TempNewSymbol and moves them to their own header file. We could expand this use if needed for GrowableArrays and other things where we have some various Symbol increment/decrement refcounts now. Changed a few ResourceHashtables that take Symbol* keys to use SymbolHandle and verified the refcounts. Also fixed the gtest. > Tested with tier1-7. Thanks Ioi! ------------- PR: https://git.openjdk.org/jdk/pull/10052 From ayang at openjdk.org Tue Sep 6 18:45:40 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 6 Sep 2022 18:45:40 GMT Subject: RFR: 8293416: ZGC: Set mark bit with unconditional atomic ops [v2] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 11:01:08 GMT, hev wrote: >> **Summary** >> Support to set ZGC mark bit with unconditional atomic ops. >> >> **Motivation** >> ZGC currently modify mark-bitmap by a conditional atomic operation (cmpxchg). This way is not optimal, which will retry the loop when cmpxchg fails. >> >> **Description** >> First, This patch-set add an new unconditional atomic operation: Atomic::fetch_and_or, which is implemented in different ways for different CPU architectures: >> >> * Exclusive access: Non-nested loop >> >> >> retry: >> ll old_val, addr >> or new_val, old_val, set_val >> sc new_val, addr >> beq retry >> >> >> * Atomic access: One instruction >> >> >> ldset old_val, set_val, addr >> >> >> * Generic: Fallback to cmpxchg or use c++ __atomic_fetch_or >> >> **Testing** >> * jtreg tests >> * benchmark tests > > hev 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: > > 8293416: ZGC: Set mark bit with unconditional atomic ops src/hotspot/share/gc/z/zBitMap.inline.hpp line 62: > 60: const bm_word_t marked_mask = bit_mask(bit); > 61: inc_live = !(cur_val & marked_mask); > 62: return inc_live; I don't think this is correct -- previously, the return value and `inc_live` can take different values. For example, when the current thread successfully upgrades an obj from finalize-marked to strongly-marked, the return value is `true` while `inc_live == false`. ------------- PR: https://git.openjdk.org/jdk/pull/10182 From duke at openjdk.org Tue Sep 6 19:24:40 2022 From: duke at openjdk.org (Ashutosh Mehra) Date: Tue, 6 Sep 2022 19:24:40 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> Message-ID: On Tue, 30 Aug 2022 23:40:32 GMT, Ashutosh Mehra wrote: > Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode. > > Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier. > > Testing with fastdebug build: > > - [x] hotspot_loom > - [x] jdk_loom > - [x] hotspot_loom in Shenandoah IU mode > - [x] jdk_loom in Shenandoah IU mode > - [x] hotspot_loom in Shenandoah IU + aggressive > - [x] jdk_loom in Shenandoah IU + aggressive > > Signed-off-by: Ashutosh Mehra @rkennke ping to get your review :-) ------------- PR: https://git.openjdk.org/jdk/pull/10089 From svkamath at openjdk.org Tue Sep 6 21:09:50 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Tue, 6 Sep 2022 21:09:50 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v6] In-Reply-To: References: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com> Message-ID: On Thu, 1 Sep 2022 21:17:30 GMT, Vladimir Kozlov wrote: >> Yes; I removed support for --release 7 in JDK 20 early today. >> >> >> On Thu, Sep 1, 2022 at 1:36 PM Paul Sandoz ***@***.***> wrote: >> >>> Likely requires a merge with master. >>> >>> ? >>> Reply to this email directly, view it on GitHub >>> , or >>> unsubscribe >>> >>> . >>> You are receiving this because you were mentioned.Message ID: >>> ***@***.***> >>> > >> Yes; I removed support for --release 7 in JDK 20 early today. > > Yes, I missed that my merge of master did not apply because I modified tests, Joe fixed, to test his changes. > > Resubmitting testing after resolving the issue. Still missed parentheses issue should be fixed. @vnkozlov Hi Vladimir, thanks for testing the changes. Could you let me know if the tests completed and passed? Thanks once again. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From vlivanov at openjdk.org Tue Sep 6 22:17:45 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 6 Sep 2022 22:17:45 GMT Subject: RFR: 8293254: x86_64: Extract arraycopy stub implementations into a separate file [v3] In-Reply-To: References: <1_CR20VVro8dAulbOEksXBiQ50Jt5jbMpc2vXFyV6xw=.ab22694f-db1b-43fd-8f69-e2eff89c5f85@github.com> Message-ID: On Fri, 2 Sep 2022 23:19:30 GMT, Vladimir Ivanov wrote: >> Move arraycopy stub implementations from `stubGenerator_x86_64.cpp` into `stubGenerator_x86_64_arraycopy.cpp`. >> >> Testing: hs-tier1 - hs-tier4 >> >> PS: FTR I left `MacroAssembler::generate_fill_avx3()` intact because it is called from `MacroAssembler::generate_fill()` which is shared between x86_64 and x86_32. Otherwise, I would either need to copy `MacroAssembler::generate_fill()` or put it into a separate file (e.g., `stubGenerator_x86.cpp` or `stubGenerator_x86_arraycopy.cpp`). IMO it doesn't add much value compared to keeping it in `macroAssembler_x86.cpp`. > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' into stub.x86_64.arraycopy > - arraycopy stubs > - fix hs-minimal build > - update > - fix > - stubGenerator_x86_64.hpp Thanks for the reviews, Dean and Vladimir. ------------- PR: https://git.openjdk.org/jdk/pull/10128 From vlivanov at openjdk.org Tue Sep 6 22:19:50 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 6 Sep 2022 22:19:50 GMT Subject: Integrated: 8293254: x86_64: Extract arraycopy stub implementations into a separate file In-Reply-To: <1_CR20VVro8dAulbOEksXBiQ50Jt5jbMpc2vXFyV6xw=.ab22694f-db1b-43fd-8f69-e2eff89c5f85@github.com> References: <1_CR20VVro8dAulbOEksXBiQ50Jt5jbMpc2vXFyV6xw=.ab22694f-db1b-43fd-8f69-e2eff89c5f85@github.com> Message-ID: On Thu, 1 Sep 2022 20:30:37 GMT, Vladimir Ivanov wrote: > Move arraycopy stub implementations from `stubGenerator_x86_64.cpp` into `stubGenerator_x86_64_arraycopy.cpp`. > > Testing: hs-tier1 - hs-tier4 > > PS: FTR I left `MacroAssembler::generate_fill_avx3()` intact because it is called from `MacroAssembler::generate_fill()` which is shared between x86_64 and x86_32. Otherwise, I would either need to copy `MacroAssembler::generate_fill()` or put it into a separate file (e.g., `stubGenerator_x86.cpp` or `stubGenerator_x86_arraycopy.cpp`). IMO it doesn't add much value compared to keeping it in `macroAssembler_x86.cpp`. This pull request has now been integrated. Changeset: 5b4c4155 Author: Vladimir Ivanov URL: https://git.openjdk.org/jdk/commit/5b4c415510cbd1b34217c976006ea900d5917f46 Stats: 5127 lines in 5 files changed: 2576 ins; 2550 del; 1 mod 8293254: x86_64: Extract arraycopy stub implementations into a separate file Reviewed-by: dlong, kvn ------------- PR: https://git.openjdk.org/jdk/pull/10128 From vlivanov at openjdk.org Tue Sep 6 22:19:56 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 6 Sep 2022 22:19:56 GMT Subject: RFR: 8293245: x86_64: Extract Adler32 stub implementation into stubGenerator_x86_64_adler.cpp [v3] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 22:52:42 GMT, Vladimir Ivanov wrote: >> Extract Adler32 stub implementation into a dedicated file (`stubGenerator_x86_64_adler.cpp`). >> >> Minor cleanups: >> * got rid of `updateBytesAdler32()` by manually inlining it into `generate_updateBytesAdler32()` >> * unified usage of `r14` as a scratch register >> * added 32-byte alignment for the constants >> >> Testing: hs-tier1 - hs-tier4 > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - fix > - Merge branch 'master' into stub.x86_64.adler > - Move Adler stub definitions into stubGenerator_x86_64_adler.cpp > - update > - fix > - stubGenerator_x86_64.hpp Thanks for the review, Vladimir and Dean. ------------- PR: https://git.openjdk.org/jdk/pull/10126 From vlivanov at openjdk.org Tue Sep 6 22:19:58 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 6 Sep 2022 22:19:58 GMT Subject: Integrated: 8293245: x86_64: Extract Adler32 stub implementation into stubGenerator_x86_64_adler.cpp In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 18:19:06 GMT, Vladimir Ivanov wrote: > Extract Adler32 stub implementation into a dedicated file (`stubGenerator_x86_64_adler.cpp`). > > Minor cleanups: > * got rid of `updateBytesAdler32()` by manually inlining it into `generate_updateBytesAdler32()` > * unified usage of `r14` as a scratch register > * added 32-byte alignment for the constants > > Testing: hs-tier1 - hs-tier4 This pull request has now been integrated. Changeset: fb6eb6f2 Author: Vladimir Ivanov URL: https://git.openjdk.org/jdk/commit/fb6eb6f26728d379fe666ac87630236f58065bbe Stats: 542 lines in 6 files changed: 268 ins; 274 del; 0 mod 8293245: x86_64: Extract Adler32 stub implementation into stubGenerator_x86_64_adler.cpp Reviewed-by: kvn, dlong ------------- PR: https://git.openjdk.org/jdk/pull/10126 From vlivanov at openjdk.org Tue Sep 6 22:21:11 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 6 Sep 2022 22:21:11 GMT Subject: RFR: 8293285: x86_64: Move libm stub implementations to StubGenerator [v3] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 23:22:54 GMT, Vladimir Ivanov wrote: >> Move libm stub implementations (used for trigonometric math intrinsics) from MacroAssembler to StubGenerator. >> >> x86_32-specific code is left intact, but all `macroAssembler_x86_*.cpp` files are renamed to `macroAssembler_x86_32_*.cpp` since there's no x86_64-specific code left there anymore. >> >> Testing: hs-tier1 - hs-tier4 > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge branch 'master' into stub.x86_64.libm > - Extract libm stub implementations into separate files > - update > - Merge branch 'master' into stub.x86_64.hpp > - RuntimeStub > - fix hs-minimal build > - update > - fix > - stubGenerator_x86_64.hpp Thanks for the review, Vladimir. ------------- PR: https://git.openjdk.org/jdk/pull/10133 From vlivanov at openjdk.org Tue Sep 6 22:21:11 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 6 Sep 2022 22:21:11 GMT Subject: Integrated: 8293285: x86_64: Move libm stub implementations to StubGenerator In-Reply-To: References: Message-ID: <_lcec4J02G3gumRBysZVa07N83F6cN2A6DFCzDOzNcs=.8389203c-6262-4bab-9428-10e9b84f20e6@github.com> On Fri, 2 Sep 2022 00:10:13 GMT, Vladimir Ivanov wrote: > Move libm stub implementations (used for trigonometric math intrinsics) from MacroAssembler to StubGenerator. > > x86_32-specific code is left intact, but all `macroAssembler_x86_*.cpp` files are renamed to `macroAssembler_x86_32_*.cpp` since there's no x86_64-specific code left there anymore. > > Testing: hs-tier1 - hs-tier4 This pull request has now been integrated. Changeset: 57930f8e Author: Vladimir Ivanov URL: https://git.openjdk.org/jdk/commit/57930f8e53e85bd923127bd638286898cfe3b117 Stats: 23104 lines in 26 files changed: 11818 ins; 11257 del; 29 mod 8293285: x86_64: Move libm stub implementations to StubGenerator Reviewed-by: kvn ------------- PR: https://git.openjdk.org/jdk/pull/10133 From vlivanov at openjdk.org Tue Sep 6 22:29:10 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 6 Sep 2022 22:29:10 GMT Subject: RFR: 8293329: x86: Improve handling of constants in AES/GHASH stubs [v2] In-Reply-To: References: Message-ID: > Pre-generating constants saves on startup and static/dynamic footprint a bit, plus simplifies bootstrapping logic. > > As a downside, constants aren't guaranteed to be always reachable anymore, but since they are used from stubs, finding a scratch register when needed is not a problem. > > Testing: > - [x] hs-tier1 - hs-tier4 w/ `-XX:+ForceUnreachable` > - [x] x86_32 build Vladimir Ivanov has updated the pull request incrementally with 41 additional commits since the last revision: - Merge branch 'stub.x86_64.aes' into stub.x86_64.aes.consts - Merge branch 'master' into stub.x86_64.aes - 8293285: x86_64: Move libm stub implementations to StubGenerator Reviewed-by: kvn - 8293254: x86_64: Extract arraycopy stub implementations into a separate file Reviewed-by: dlong, kvn - 8293245: x86_64: Extract Adler32 stub implementation into stubGenerator_x86_64_adler.cpp Reviewed-by: kvn, dlong - 8264744: (fs) Use file cloning in Linux version of Files::copy method Reviewed-by: alanb - 8283929: GHA: Add RISC-V build config Reviewed-by: ihse, shade - 8292579: (tz) Update Timezone Data to 2022c Reviewed-by: naoto, alanb - 8293403: JfrResolution::on_jvmci_resolution crashes when caller is null Reviewed-by: never - 8291736: find_method_handle_intrinsic leaks Method* Reviewed-by: hseigel, iklam, dholmes - ... and 31 more: https://git.openjdk.org/jdk/compare/20d589e3...7c35132b ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10152/files - new: https://git.openjdk.org/jdk/pull/10152/files/20d589e3..7c35132b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10152&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10152&range=00-01 Stats: 33649 lines in 190 files changed: 16839 ins; 16134 del; 676 mod Patch: https://git.openjdk.org/jdk/pull/10152.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10152/head:pull/10152 PR: https://git.openjdk.org/jdk/pull/10152 From vlivanov at openjdk.org Tue Sep 6 22:29:31 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 6 Sep 2022 22:29:31 GMT Subject: RFR: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files [v4] In-Reply-To: References: Message-ID: > Move code related to AES and GHASH stubs from `stubGenerator_x86_64.cpp` into `stubGenerator_x86_64_aes.cpp` and `stubGenerator_x86_64_ghash.cpp` respectively. > > Testing: hs-tier1 - hs-tier4 Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into stub.x86_64.aes - Merge branch 'master' into stub.x86_64.aes - AESBlockSize - update - Refactor AES and GHASH stubs. - update - fix - stubGenerator_x86_64.hpp ------------- Changes: https://git.openjdk.org/jdk/pull/10124/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10124&range=03 Stats: 7522 lines in 6 files changed: 3779 ins; 3722 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/10124.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10124/head:pull/10124 PR: https://git.openjdk.org/jdk/pull/10124 From vlivanov at openjdk.org Tue Sep 6 22:39:28 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 6 Sep 2022 22:39:28 GMT Subject: RFR: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files [v5] In-Reply-To: References: Message-ID: > Move code related to AES and GHASH stubs from `stubGenerator_x86_64.cpp` into `stubGenerator_x86_64_aes.cpp` and `stubGenerator_x86_64_ghash.cpp` respectively. > > Testing: hs-tier1 - hs-tier4 Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: include ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10124/files - new: https://git.openjdk.org/jdk/pull/10124/files/9d749483..a5246337 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10124&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10124&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10124.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10124/head:pull/10124 PR: https://git.openjdk.org/jdk/pull/10124 From jrose at openjdk.org Wed Sep 7 01:05:38 2022 From: jrose at openjdk.org (John R Rose) Date: Wed, 7 Sep 2022 01:05:38 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v5] In-Reply-To: References: Message-ID: > Refactor code from inside of CompressedStream into its own unit. > > This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). > > Add gtests. John R Rose has updated the pull request incrementally with one additional commit since the last revision: add missing "this->" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10067/files - new: https://git.openjdk.org/jdk/pull/10067/files/439b108b..172420ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10067.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10067/head:pull/10067 PR: https://git.openjdk.org/jdk/pull/10067 From duke at openjdk.org Wed Sep 7 02:25:41 2022 From: duke at openjdk.org (hev) Date: Wed, 7 Sep 2022 02:25:41 GMT Subject: RFR: 8293416: ZGC: Set mark bit with unconditional atomic ops [v2] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 17:27:20 GMT, Kim Barrett wrote: > The Atomic changes being proposed here are a subset of https://bugs.openjdk.org/browse/JDK-8293117 Add atomic bitset functions which is in-progress. I'll depends on it. Thank you. ------------- PR: https://git.openjdk.org/jdk/pull/10182 From duke at openjdk.org Wed Sep 7 02:25:44 2022 From: duke at openjdk.org (hev) Date: Wed, 7 Sep 2022 02:25:44 GMT Subject: RFR: 8293416: ZGC: Set mark bit with unconditional atomic ops [v2] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 18:42:19 GMT, Albert Mingkun Yang wrote: >> hev 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: >> >> 8293416: ZGC: Set mark bit with unconditional atomic ops > > src/hotspot/share/gc/z/zBitMap.inline.hpp line 62: > >> 60: const bm_word_t marked_mask = bit_mask(bit); >> 61: inc_live = !(cur_val & marked_mask); >> 62: return inc_live; > > I don't think this is correct -- previously, the return value and `inc_live` can take different values. For example, when the current thread successfully upgrades an obj from finalize-marked to strongly-marked, the return value is `true` while `inc_live == false`. You're right. I misunderstood the paired mark. BitMap also seems to work with this approach as well. I'll do these in next version. Thank you. ------------- PR: https://git.openjdk.org/jdk/pull/10182 From kim.barrett at oracle.com Wed Sep 7 04:41:37 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 7 Sep 2022 04:41:37 +0000 Subject: RFC: linux-aarch64 and LSE support Message-ID: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> I?m puzzled by this change: https://bugs.openjdk.org/browse/JDK-8282322 8282322: AArch64: Provide a means to eliminate all STREX family of instructions (2022-07-08, jdk20, no backports) It?s a followup to these changes: https://bugs.openjdk.org/browse/JDK-8261027 8261027: AArch64: Support for LSE atomics C++ HotSpot code (2021-02-12, jdk17, backported to jdk11, but not jdk8) 8261649: AArch64: Optimize LSE atomics in C++ code (2021-02-19, jdk17, backported to jdk11, but not jdk8) [Also related is this https://bugs.openjdk.org/browse/JDK-8261660 AArch64: Race condition in stub code generation for LSE Atomics (2021-02-12, jdk17, superseded by 8261649)] which are essentially reimplementing gcc?s -moutline-atomics option. The point of doing this is to allow those changes to be used while building jdk with gcc versions that don't support -moutline-atomics, esp. for purposes of backports. (That option arrived with gcc8.5/gcc9.4/gcc10, enabled by default in gcc10. I guess some non-Oracle folks might still be using something earlier, esp. in the jdk17 timeframe when LSE support was being added.) 8282322 builds on the earlier two, adding more complexity. It's purpose is to support a development activity (the use of rr for debugging), and requires building the jdk with additional configure options (specifying an `-march=` or `-mcpu` option that supports LSE, so the result of the build will *only* run on such hardware). As noted in its review, it doesn't fit the normal criteria for backporting. For jdk20+ (where 8282322 landed), I question whether the approach being taken here really makes sense. If one is willing to assume a relatively recent version of gcc is being used, then I think there is no reason to reimplement the effect of -moutline-atomics. We could undo all three of those changes, reverting back to using gcc __atomic intrinsics, and rely on -moutline-atomics (explicitly requested for gcc8/9). In that case, nothing like 8282322 is needed; just specify armv8.1-a or later when configuring the build (which is already needed to activate the current 8282322 behavior) and LSE will be used, regardless of -moutline-atomics (or if it is even supported, if you want to use rr with an old gcc version). That would be a lot simpler. It also makes it easier to make further changes. (Reading through the PR comments for 8282322, it looks like Andrew Haley almost suggested doing this. But instead of really buying into it, he seemed to be suggesting having a parallel implementation and some mechanism for selecting which one to use. That's definitely not what I'm suggesting.) In particular, I noticed all this because I'm working on 8293117: ?Add atomic bitset functions?, and I?m trying to figure out how I should implement them for linux-aarch64. I?d rather not jump through the existing hoops when it would be really easy to just use the appropriate gcc __atomic intrinsics, as we used to do for other operations. The downside of going back to using the __atomic intrinsics rather than continuing to roll our own is that using an old gcc to build a recent jdk might get less than optimal performance on spiffy new hardware. I think that's worth the benefit of a much simpler implementation. From stefank at openjdk.org Wed Sep 7 07:02:44 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 7 Sep 2022 07:02:44 GMT Subject: RFR: 8292921: Rewrite object field printer [v6] In-Reply-To: References: Message-ID: <6aKPW5Xi2OdZTV3emFn_NPkBAVQfkUu3WSqcPY9CH7g=.9070cae6-7d0f-47e3-b6ae-3d4418a2e7b8@github.com> On Fri, 26 Aug 2022 09:31:00 GMT, Thomas Stuefe wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Introduce and use various 0x0... prefixed integer format specifiers > > Looks good. I like the new format macros. > > Somehow I was assuming xxx_FORMAT_X was already 0-padding. But this is better. @tstuefe @dholmes-ora Are you OK with the latest version of this patch? ------------- PR: https://git.openjdk.org/jdk/pull/10028 From stefank at openjdk.org Wed Sep 7 07:06:47 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 7 Sep 2022 07:06:47 GMT Subject: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 09:51:06 GMT, Stefan Karlsson wrote: > During the discussion of [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was voiced that we should stop using INTPTR_FORMAT when printing pointers. > > Some background that could explain why some tend to use INTPTR_FORMAT instead of PTR_FORMAT: > > Both those format specifiers require an integer and the compiler barfs if you send in a pointer. We therefore have a utility function named p2i, which converts the pointer to an integer. So, everywhere we have to write print line like this: `print("my pointer: " PTR_FORMAT, p2i(my_pointer));`. Now, p2i returns an intptr_t, and it becomes natural for some to consider the type of the converted value (that we need because of the mentioned workaround), instead of the original type of the value. > > With this enhancement I'd like to clean up the code that I often work in, so that it uses PTR_FORMAT when printing pointers. I'm leaving the rest of the code base for others to consider cleaning up. > > Cleanups have been done in directories gc/, utilities/, memory/, and oops/. @kimbarrett You commented on the "incorrect" usages of INTPTR_FORMAT in JDK-8292981. Do you think this PR moves the code in the right direction? ------------- PR: https://git.openjdk.org/jdk/pull/10141 From fyang at openjdk.org Wed Sep 7 08:44:37 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 7 Sep 2022 08:44:37 GMT Subject: RFR: 8293474: RISC-V: Unify the way of moving function pointer Message-ID: Currently, there are two different ways of moving function pointer on riscv with either 'li' or 'mv' assembler functions. For example, in file shenandoahBarrierSetAssembler_riscv.cpp, we use 'li' function: li(ra, (int64_t)(uintptr_t)ShenandoahRuntime::load_reference_barrier_strong_narrow) But in file templateInterpreterGenerator_riscv.cpp, we use 'mv' function: mv(t1, CAST_FROM_FN_PTR(address, JavaThread::check_special_condition_for_native_trans)) Use of 'mv' here calls 'movptr' and will emits fixed length instruction sequence, which is neither necessary nor optimal compared with use of 'li'. This changes to use 'li' instead of 'movptr' to implement 'mv' thus unifying the way of moving function pointer. Testing: Passed Tier1 test on Linux-riscv64 SiFive Unmatched board. ------------- Commit messages: - 8293474: RISC-V: Unify the way of moving function pointer Changes: https://git.openjdk.org/jdk/pull/10194/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10194&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293474 Stats: 31 lines in 3 files changed: 2 ins; 10 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/10194.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10194/head:pull/10194 PR: https://git.openjdk.org/jdk/pull/10194 From duke at openjdk.org Wed Sep 7 09:15:02 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 7 Sep 2022 09:15:02 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v5] In-Reply-To: References: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com> Message-ID: On Tue, 30 Aug 2022 00:13:35 GMT, David Holmes wrote: >To be clear, you will only ever get a null if someone passes it in explicitly as Thread::current_or_null() should never be able to return null in the contexts you would use this RWL. Context: UL uses static initialization for LogTagSets, these use the RWLock and as such our thread system isn't initialized yet. It's not strictly necessary, as we can re-write things to not require this. Edit: Perhaps the right decision is to simply delay the initialization of LogTagSets. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From dmitry.chuyko at bell-sw.com Wed Sep 7 09:30:00 2022 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Wed, 7 Sep 2022 12:30:00 +0300 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> Message-ID: Hi Kim, The implementation of the main JDK-8261027 change doesn't just try to provide the functionality when built with older GCC (or not GCC). What it does is dynamically switch to a more advanced implementation if the appropriate hardware capabilities were detected during the VM start. The selected code is picked by the compiler. So there are 2 implementations and non-LSE one is the default. This allows us to provide a single binary for all supported ARM devices and get better performance where possible. >From another hand, a less advanced implementation is always used initially in the default configuration. As you noticed, JDK-8282322 just makes it possible to create a build that uses the LSE variant from the start. -Dmitry On Wed, Sep 7, 2022 at 7:41 AM Kim Barrett wrote: > I?m puzzled by this change: > > https://bugs.openjdk.org/browse/JDK-8282322 > 8282322: AArch64: Provide a means to eliminate all STREX family of > instructions > (2022-07-08, jdk20, no backports) > > It?s a followup to these changes: > > https://bugs.openjdk.org/browse/JDK-8261027 > 8261027: AArch64: Support for LSE atomics C++ HotSpot code > (2021-02-12, jdk17, backported to jdk11, but not jdk8) > > 8261649: AArch64: Optimize LSE atomics in C++ code > (2021-02-19, jdk17, backported to jdk11, but not jdk8) > > [Also related is this > https://bugs.openjdk.org/browse/JDK-8261660 > AArch64: Race condition in stub code generation for LSE Atomics > (2021-02-12, jdk17, superseded by 8261649)] > > which are essentially reimplementing gcc?s -moutline-atomics option. The > point > of doing this is to allow those changes to be used while building jdk with > gcc > versions that don't support -moutline-atomics, esp. for purposes of > backports. > (That option arrived with gcc8.5/gcc9.4/gcc10, enabled by default in > gcc10. I > guess some non-Oracle folks might still be using something earlier, esp. in > the jdk17 timeframe when LSE support was being added.) > > 8282322 builds on the earlier two, adding more complexity. It's purpose is > to > support a development activity (the use of rr for debugging), and requires > building the jdk with additional configure options (specifying an > `-march=` or > `-mcpu` option that supports LSE, so the result of the build will *only* > run > on such hardware). As noted in its review, it doesn't fit the normal > criteria > for backporting. > > For jdk20+ (where 8282322 landed), I question whether the approach being > taken > here really makes sense. If one is willing to assume a relatively recent > version of gcc is being used, then I think there is no reason to > reimplement > the effect of -moutline-atomics. We could undo all three of those changes, > reverting back to using gcc __atomic intrinsics, and rely on > -moutline-atomics > (explicitly requested for gcc8/9). In that case, nothing like 8282322 is > needed; just specify armv8.1-a or later when configuring the build (which > is > already needed to activate the current 8282322 behavior) and LSE will be > used, > regardless of -moutline-atomics (or if it is even supported, if you want to > use rr with an old gcc version). > > That would be a lot simpler. It also makes it easier to make further > changes. > > (Reading through the PR comments for 8282322, it looks like Andrew Haley > almost suggested doing this. But instead of really buying into it, he > seemed > to be suggesting having a parallel implementation and some mechanism for > selecting which one to use. That's definitely not what I'm suggesting.) > > In particular, I noticed all this because I'm working on 8293117: ?Add > atomic > bitset functions?, and I?m trying to figure out how I should implement them > for linux-aarch64. I?d rather not jump through the existing hoops when it > would be really easy to just use the appropriate gcc __atomic intrinsics, > as > we used to do for other operations. > > The downside of going back to using the __atomic intrinsics rather than > continuing to roll our own is that using an old gcc to build a recent jdk > might get less than optimal performance on spiffy new hardware. I think > that's > worth the benefit of a much simpler implementation. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph-open at littlepinkcloud.com Wed Sep 7 09:30:12 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Wed, 7 Sep 2022 10:30:12 +0100 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> Message-ID: <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> On 9/7/22 05:41, Kim Barrett wrote: > I?m puzzled by this change: > > https://bugs.openjdk.org/browse/JDK-8282322 > 8282322: AArch64: Provide a means to eliminate all STREX family of instructions > (2022-07-08, jdk20, no backports) > > It?s a followup to these changes: > > https://bugs.openjdk.org/browse/JDK-8261027 > 8261027: AArch64: Support for LSE atomics C++ HotSpot code > (2021-02-12, jdk17, backported to jdk11, but not jdk8) > > 8261649: AArch64: Optimize LSE atomics in C++ code > (2021-02-19, jdk17, backported to jdk11, but not jdk8) > > [Also related is this > https://bugs.openjdk.org/browse/JDK-8261660 > AArch64: Race condition in stub code generation for LSE Atomics > (2021-02-12, jdk17, superseded by 8261649)] > > which are essentially reimplementing gcc?s -moutline-atomics option. The point > of doing this is to allow those changes to be used while building jdk with gcc > versions that don't support -moutline-atomics, esp. for purposes of backports. > (That option arrived with gcc8.5/gcc9.4/gcc10, enabled by default in gcc10. I > guess some non-Oracle folks might still be using something earlier, esp. in > the jdk17 timeframe when LSE support was being added.) Sure. The timing wasn't good: the outline-atomics patch went in to GCC in September 2019, but was back-ported to GCC releases by May/June 2021. Our patch was committed in Feb that year. > For jdk20+ (where 8282322 landed), I question whether the approach being taken > here really makes sense. If one is willing to assume a relatively recent > version of gcc is being used, then I think there is no reason to reimplement > the effect of -moutline-atomics. We could undo all three of those changes, > reverting back to using gcc __atomic intrinsics, and rely on -moutline-atomics > (explicitly requested for gcc8/9). In that case, nothing like 8282322 is > needed; just specify armv8.1-a or later when configuring the build (which is > already needed to activate the current 8282322 behavior) and LSE will be used, > regardless of -moutline-atomics (or if it is even supported, if you want to > use rr with an old gcc version). > > That would be a lot simpler. It also makes it easier to make further changes. True. It all feels a bit early to me, though. I don't think that OpenJDK has ever needed so recent compiler features before. We've always been very conservative about what we depend on. So it might be OK to do this, but (to me) it feels like sailing close to the wind. I'm curious, though: wouldn't atomic bitset ops be based on CAS? If so, you don't need to care how CAS is implemented. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From yadongwang at openjdk.org Wed Sep 7 09:41:56 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Wed, 7 Sep 2022 09:41:56 GMT Subject: RFR: 8293474: RISC-V: Unify the way of moving function pointer In-Reply-To: References: Message-ID: <-lTrZCCdVIsgaxcmQmEz1jwQVM88Ca_YsFi_Dy0HObA=.f4ad4367-aa1a-485c-b6b0-d548c527fc69@github.com> On Wed, 7 Sep 2022 08:36:49 GMT, Fei Yang wrote: > Currently, there are two different ways of moving function pointer on riscv with either 'li' or 'mv' assembler functions. > For example, in file shenandoahBarrierSetAssembler_riscv.cpp, we use 'li' function: > li(ra, (int64_t)(uintptr_t)ShenandoahRuntime::load_reference_barrier_strong_narrow) > > But in file templateInterpreterGenerator_riscv.cpp, we use 'mv' function: > mv(t1, CAST_FROM_FN_PTR(address, JavaThread::check_special_condition_for_native_trans)) > > Use of 'mv' here calls 'movptr' and emits fixed length instruction sequence, which is neither necessary nor optimal compared with use of 'li'. This changes to use 'li' instead of 'movptr' to implement 'mv' and unifies the way of moving function pointer. > > Testing: Passed Tier1 test on Linux-riscv64 SiFive Unmatched board. lgtm ------------- Marked as reviewed by yadongwang (Author). PR: https://git.openjdk.org/jdk/pull/10194 From fjiang at openjdk.org Wed Sep 7 11:01:40 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 7 Sep 2022 11:01:40 GMT Subject: RFR: 8293474: RISC-V: Unify the way of moving function pointer In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 08:36:49 GMT, Fei Yang wrote: > Currently, there are two different ways of moving function pointer on riscv with either 'li' or 'mv' assembler functions. > For example, in file shenandoahBarrierSetAssembler_riscv.cpp, we use 'li' function: > li(ra, (int64_t)(uintptr_t)ShenandoahRuntime::load_reference_barrier_strong_narrow) > > But in file templateInterpreterGenerator_riscv.cpp, we use 'mv' function: > mv(t1, CAST_FROM_FN_PTR(address, JavaThread::check_special_condition_for_native_trans)) > > Use of 'mv' here calls 'movptr' and emits fixed length instruction sequence, which is neither necessary nor optimal compared with use of 'li'. This changes to use 'li' instead of 'movptr' to implement 'mv' and unifies the way of moving function pointer. > > Testing: Passed Tier1 test on Linux-riscv64 SiFive Unmatched board. Looks Good. (Not a JDK reviewer) ------------- Marked as reviewed by fjiang (Author). PR: https://git.openjdk.org/jdk/pull/10194 From coleenp at openjdk.org Wed Sep 7 11:46:40 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 7 Sep 2022 11:46:40 GMT Subject: RFR: 8292921: Rewrite object field printer [v8] In-Reply-To: <0D7Bl_Agg1ZUn2dFZv7fcW-oicqeN5X0QSLIHS_KOcA=.73c2b9ed-c415-4a53-bee1-4cc2db8c031f@github.com> References: <0D7Bl_Agg1ZUn2dFZv7fcW-oicqeN5X0QSLIHS_KOcA=.73c2b9ed-c415-4a53-bee1-4cc2db8c031f@github.com> Message-ID: On Fri, 2 Sep 2022 08:28:43 GMT, Stefan Karlsson wrote: >> See this as a RFC rather than a fully ready PR: >> >> fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. >> >> This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) >> >> and with the suggested change we get: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) >> >> which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). >> >> I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. >> >> There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. >> >> A full example of the generated output: >> >> java.lang.Class >> {0x00007ffc36801080} - klass: 'java/lang/Class' >> - ---- fields (total size 26 words): >> - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) >> - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) >> - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) >> - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) >> - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) >> - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) >> - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) >> - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) >> - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) >> - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) >> - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) >> - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) >> - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) >> - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) >> - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) >> - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) >> - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) >> - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) >> - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) >> - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) >> - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) >> - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) >> - signature: Ljava/lang/String; >> - ---- static fields (2): >> - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) >> - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) >> - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) >> - private static final 'REPL' 'C' @200 65533 (0x0000fffd) >> - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) >> - static final 'LATIN1' 'B' @203 0 (0x00000000) >> - static final 'UTF16' 'B' @204 1 (0x00000001) > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Work around clang's warning about using jlong > - Merge remote-tracking branch 'upstream/master' into 8292921_object_field_printer > - Guide to integer format specifier suffixes > - Introduce and use various 0x0... prefixed integer format specifiers > - Review tsteufe > - Review dholmes > - Fix macOS sensitivity to format specifier for jlong > - Print correct number of bits for small integer types > - 8292921: Rewrite object field printer Seems like an improvement. Those non-hex numbers for field addresses were never helpful. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/10028 From stuefe at openjdk.org Wed Sep 7 11:51:40 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 7 Sep 2022 11:51:40 GMT Subject: RFR: 8292921: Rewrite object field printer [v8] In-Reply-To: <0D7Bl_Agg1ZUn2dFZv7fcW-oicqeN5X0QSLIHS_KOcA=.73c2b9ed-c415-4a53-bee1-4cc2db8c031f@github.com> References: <0D7Bl_Agg1ZUn2dFZv7fcW-oicqeN5X0QSLIHS_KOcA=.73c2b9ed-c415-4a53-bee1-4cc2db8c031f@github.com> Message-ID: On Fri, 2 Sep 2022 08:28:43 GMT, Stefan Karlsson wrote: >> See this as a RFC rather than a fully ready PR: >> >> fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. >> >> This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) >> >> and with the suggested change we get: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) >> >> which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). >> >> I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. >> >> There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. >> >> A full example of the generated output: >> >> java.lang.Class >> {0x00007ffc36801080} - klass: 'java/lang/Class' >> - ---- fields (total size 26 words): >> - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) >> - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) >> - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) >> - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) >> - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) >> - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) >> - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) >> - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) >> - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) >> - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) >> - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) >> - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) >> - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) >> - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) >> - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) >> - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) >> - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) >> - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) >> - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) >> - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) >> - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) >> - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) >> - signature: Ljava/lang/String; >> - ---- static fields (2): >> - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) >> - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) >> - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) >> - private static final 'REPL' 'C' @200 65533 (0x0000fffd) >> - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) >> - static final 'LATIN1' 'B' @203 0 (0x00000000) >> - static final 'UTF16' 'B' @204 1 (0x00000001) > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Work around clang's warning about using jlong > - Merge remote-tracking branch 'upstream/master' into 8292921_object_field_printer > - Guide to integer format specifier suffixes > - Introduce and use various 0x0... prefixed integer format specifiers > - Review tsteufe > - Review dholmes > - Fix macOS sensitivity to format specifier for jlong > - Print correct number of bits for small integer types > - 8292921: Rewrite object field printer Still good. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/10028 From stefank at openjdk.org Wed Sep 7 12:10:49 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 7 Sep 2022 12:10:49 GMT Subject: RFR: 8292921: Rewrite object field printer [v8] In-Reply-To: <0D7Bl_Agg1ZUn2dFZv7fcW-oicqeN5X0QSLIHS_KOcA=.73c2b9ed-c415-4a53-bee1-4cc2db8c031f@github.com> References: <0D7Bl_Agg1ZUn2dFZv7fcW-oicqeN5X0QSLIHS_KOcA=.73c2b9ed-c415-4a53-bee1-4cc2db8c031f@github.com> Message-ID: On Fri, 2 Sep 2022 08:28:43 GMT, Stefan Karlsson wrote: >> See this as a RFC rather than a fully ready PR: >> >> fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. >> >> This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) >> >> and with the suggested change we get: >> >> - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) >> >> which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). >> >> I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. >> >> There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. >> >> A full example of the generated output: >> >> java.lang.Class >> {0x00007ffc36801080} - klass: 'java/lang/Class' >> - ---- fields (total size 26 words): >> - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) >> - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) >> - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) >> - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) >> - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) >> - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) >> - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) >> - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) >> - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) >> - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) >> - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) >> - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) >> - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) >> - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) >> - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) >> - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) >> - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) >> - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) >> - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) >> - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) >> - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) >> - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) >> - signature: Ljava/lang/String; >> - ---- static fields (2): >> - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) >> - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) >> - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) >> - private static final 'REPL' 'C' @200 65533 (0x0000fffd) >> - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) >> - static final 'LATIN1' 'B' @203 0 (0x00000000) >> - static final 'UTF16' 'B' @204 1 (0x00000001) > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Work around clang's warning about using jlong > - Merge remote-tracking branch 'upstream/master' into 8292921_object_field_printer > - Guide to integer format specifier suffixes > - Introduce and use various 0x0... prefixed integer format specifiers > - Review tsteufe > - Review dholmes > - Fix macOS sensitivity to format specifier for jlong > - Print correct number of bits for small integer types > - 8292921: Rewrite object field printer Thanks for reviewing! ------------- PR: https://git.openjdk.org/jdk/pull/10028 From stefank at openjdk.org Wed Sep 7 12:10:50 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 7 Sep 2022 12:10:50 GMT Subject: Integrated: 8292921: Rewrite object field printer In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:27:12 GMT, Stefan Karlsson wrote: > See this as a RFC rather than a fully ready PR: > > fieldDescriptor::print_on_for is a bit inconsistent in how it deals with printing the "underlying representation" of the field values. I'd like to change to make it easier to both read output that gets generated in our hs_err files, but also make it easier to understand the code. > > This started out as a small patch in Generational ZGC to change how the underlying representation was written. Before this patch, the fields in the hs_err files were written with this format: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (5e808a30, 4000f63) > > and with the suggested change we get: > > - final 'interruptLock' 'Ljava/lang/Object;' @112 a 'java/lang/Object'{0x000004000f635e80} (0x04000f635e808a30) > > which makes it much easier to read the colored pointer (0x04000f635e808a30) of the object address (0x000004000f635e80). > > I think this is good even for the upstream repository, so I'd like to propose that we print the underlying representation as a full hex value without trying to split the value into 4-bytes chunks. > > There used to be a filter that said that we shouldn't print the underlying bits if the value was a positive, single digit, 4-bytes primitive. I've removed that code, but that will add more logging (esp. of 0 values). So, I'd like to get some feedback on that. > > A full example of the generated output: > > java.lang.Class > {0x00007ffc36801080} - klass: 'java/lang/Class' > - ---- fields (total size 26 words): > - private volatile transient 'classRedefinedCount' 'I' @12 0 (0x00000000) > - abstract internal 'klass' 'J' @16 2147753408 (0x0000000080041dc0) > - abstract internal 'array_klass' 'J' @24 0 (0x0000000000000000) > - abstract internal 'oop_size' 'I' @32 26 (0x0000001a) > - abstract internal 'static_oop_field_count' 'I' @36 2 (0x00000002) > - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40 NULL (0x0000000000000000) > - private transient 'name' 'Ljava/lang/String;' @48 NULL (0x0000000000000000) > - private transient 'module' 'Ljava/lang/Module;' @56 NULL (0x0000000000000000) > - private final 'classLoader' 'Ljava/lang/ClassLoader;' @64 NULL (0x0000000000000000) > - private transient 'classData' 'Ljava/lang/Object;' @72 NULL (0x0000000000000000) > - private transient 'packageName' 'Ljava/lang/String;' @80 NULL (0x0000000000000000) > - private final 'componentType' 'Ljava/lang/Class;' @88 NULL (0x0000000000000000) > - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @96 NULL (0x0000000000000000) > - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @104 NULL (0x0000000000000000) > - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @112 NULL (0x0000000000000000) > - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @120 NULL (0x0000000000000000) > - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @128 NULL (0x0000000000000000) > - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @136 NULL (0x0000000000000000) > - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @144 NULL (0x0000000000000000) > - abstract internal 'protection_domain' 'Ljava/lang/Object;' @152 NULL (0x0000000000000000) > - abstract internal 'signers_name' 'Ljava/lang/Object;' @160 NULL (0x0000000000000000) > - abstract internal 'source_file' 'Ljava/lang/Object;' @168 NULL (0x0000000000000000) > - signature: Ljava/lang/String; > - ---- static fields (2): > - private static final 'serialVersionUID' 'J' @192 -6849794470754667710 (0xa0f0a4387a3bb342) > - static final 'COMPACT_STRINGS' 'Z' @202 false (0x00000000) > - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @176 NULL (0x0000000000000000) > - private static final 'REPL' 'C' @200 65533 (0x0000fffd) > - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @184 NULL (0x0000000000000000) > - static final 'LATIN1' 'B' @203 0 (0x00000000) > - static final 'UTF16' 'B' @204 1 (0x00000001) This pull request has now been integrated. Changeset: 14fd1b6c Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/14fd1b6cdfc2f912d350ac0da07f3fe4b1f976e0 Stats: 47 lines in 1 file changed: 16 ins; 14 del; 17 mod 8292921: Rewrite object field printer Reviewed-by: stuefe, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/10028 From shade at openjdk.org Wed Sep 7 13:11:40 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 7 Sep 2022 13:11:40 GMT Subject: RFR: 8293474: RISC-V: Unify the way of moving function pointer In-Reply-To: References: Message-ID: <9hZhFVshKxsAt5NIeyQREh5nOv2miazYEUt-EYi1UeQ=.3c445083-124a-4749-86b7-26bb55c27ccd@github.com> On Wed, 7 Sep 2022 08:36:49 GMT, Fei Yang wrote: > Currently, there are two different ways of moving function pointer on riscv with either 'li' or 'mv' assembler functions. > For example, in file shenandoahBarrierSetAssembler_riscv.cpp, we use 'li' function: > li(ra, (int64_t)(uintptr_t)ShenandoahRuntime::load_reference_barrier_strong_narrow) > > But in file templateInterpreterGenerator_riscv.cpp, we use 'mv' function: > mv(t1, CAST_FROM_FN_PTR(address, JavaThread::check_special_condition_for_native_trans)) > > Use of 'mv' here calls 'movptr' and emits fixed length instruction sequence, which is neither necessary nor optimal compared with use of 'li'. This changes to use 'li' instead of 'movptr' to implement 'mv' and unifies the way of moving function pointer. > > Testing: Passed Tier1 test on Linux-riscv64 SiFive Unmatched board. Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10194 From duke at openjdk.org Wed Sep 7 13:45:44 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Wed, 7 Sep 2022 13:45:44 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v6] In-Reply-To: References: <7-9sMaveCa-a2sxHULFPmCYf1-uudLSkm3WLzwF_UuY=.eab16718-87d4-4a2e-803a-2f60c746c0c5@github.com> Message-ID: On Tue, 16 Aug 2022 12:04:20 GMT, Andrew Haley wrote: >> This is the fix of: >> [JDK-8286314](https://bugs.openjdk.org/browse/JDK-8286314): Trampoline not created for far runtime targets outside small CodeCache >> >> At the time of writing the fix I could not find how to test the fix. We don't generate such trampoline calls. >> >> I think if such calls appear, they will always be unreachable. > > Please take it out, then. Hi Andrew (@theRealAph), Have you had a change to review the latest version? Thanks, Evgeny ------------- PR: https://git.openjdk.org/jdk/pull/8403 From aph at openjdk.org Wed Sep 7 14:13:44 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 7 Sep 2022 14:13:44 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v8] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 13:09:26 GMT, Evgeny Astigeevich wrote: >> Runtime calls are calls of non-compiled methods. Non-compiled methods stay forever in CodeCache. If they are always within the branch range, they don't need trampolines. >> >> This PR adds `is_always_within_branch_range(Address entry)`. >> >> Results from DaCapo: the total number of eliminated trampolines per a benchmark run >> >> >> +----------+--------+ >> | avrora | 15491 | >> | batik | 75837 | >> | biojava | 13927 | >> | eclipse | 414143 | >> | fop | 119267 | >> | graphchi | 7665 | >> | jme | 8279 | >> | luindex | 56061 | >> | lusearch | 50277 | >> | pmd | 132719 | >> | sunflow | 10689 | >> | tomcat | 186967 | >> | xalan | 50349 | >> | zxing | 41497 | >> +----------+--------+ >> >> >> >> Testing: >> - `tier1`...`tier2`: Passed >> - `compiler/c2/aarch64/TestTrampoline.java`: Passed >> >> Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Simplify checks in is_always_within_branch_range Looks good. Sorry for the delay, I thought I'd already approved this patch. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.org/jdk/pull/8403 From asmehra at redhat.com Wed Sep 7 14:16:40 2022 From: asmehra at redhat.com (Ashutosh Mehra) Date: Wed, 7 Sep 2022 10:16:40 -0400 Subject: Missing ShenandoahControlThread in hs_err log Message-ID: While working on another issue I noticed hs_err log file is missing "ShenandoahControlThread" in the dumped thread list. As an example, threads from a hs_err dump: Java Threads: ( => current thread ) 0x00007ff18c0986b0 JavaThread "main" [_thread_blocked, id=231505, stack(0x00007ff1938c2000,0x00007ff1939c3000)] 0x00007ff18c1fded0 JavaThread "Reference Handler" daemon [_thread_blocked, id=231513, stack(0x00007ff1723fc000,0x00007ff1724fd000)] 0x00007ff18c1ff910 JavaThread "Finalizer" daemon [_thread_blocked, id=231514, stack(0x00007ff1722fb000,0x00007ff1723fc000)] 0x00007ff18c2018a0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=231515, stack(0x00007ff1721fa000,0x00007ff1722fb000)] 0x00007ff18c2031f0 JavaThread "Service Thread" daemon [_thread_blocked, id=231517, stack(0x00007ff171ff7000,0x00007ff1720f8000)] 0x00007ff18c204b40 JavaThread "Monitor Deflation Thread" daemon [_thread_blocked, id=231518, stack(0x00007ff171ef6000,0x00007ff171ff7000)] 0x00007ff18c2069f0 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=231519, stack(0x00007ff171df5000,0x00007ff171ef6000)] 0x00007ff18c208490 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=231520, stack(0x00007ff171cf4000,0x00007ff171df5000)] 0x00007ff18c211e10 JavaThread "Sweeper thread" daemon [_thread_blocked, id=231521, stack(0x00007ff171bf3000,0x00007ff171cf4000)] 0x00007ff18c28b810 JavaThread "Common-Cleaner" daemon [_thread_blocked, id=231524, stack(0x00007ff1718ee000,0x00007ff1719ef000)] 0x00007ff18c2e6a00 JavaThread "Notification Thread" daemon [_thread_blocked, id=231525, stack(0x00007ff1717ed000,0x00007ff1718ee000)] 0x00007ff18c35de20 JavaThread "MainThread" [_thread_blocked, id=231527, stack(0x00007ff170fc1000,0x00007ff1710c2000)] _threads_hazard_ptr=0x00007ff0f402d1b0, _nested_threads_hazard_ptr_cnt=0 0x00007ff0f402c0e0 JavaThread "MyThread" daemon [_thread_blocked, id=231528, stack(0x00007ff170ab4000,0x00007ff170bb5000)] Other Threads: =>0x00007ff18c1cb090 VMThread "VM Thread" [stack: 0x00007ff1724ff000,0x00007ff1725ff000] [id=231512] 0x00007ff18c2e8bf0 WatcherThread "VM Periodic Task Thread" [stack: 0x00007ff1716ed000,0x00007ff1717ed000] [id=231526] 0x00007ff18c0b4e90 WorkerThread "Shenandoah GC Threads#0" [stack: 0x00007ff172fb3000,0x00007ff1730b3000] [id=231506] 0x00007ff168000cc0 WorkerThread "Shenandoah GC Threads#1" [stack: 0x00007ff1720fa000,0x00007ff1721fa000] [id=231516] 0x00007ff13c000d20 WorkerThread "Shenandoah GC Threads#2" [stack: 0x00007ff171af3000,0x00007ff171bf3000] [id=231522] 0x00007ff13c001db0 WorkerThread "Shenandoah GC Threads#3" [stack: 0x00007ff1719f1000,0x00007ff171af1000] [id=231523] 0x00007ff18c0b5b80 WorkerThread "Safepoint Cleanup Thread#0" [stack: 0x00007ff172eb1000,0x00007ff172fb1000] [id=231507] "ShenandoahControlThread" should appear under "Other Threads" along with other "Shenandoah GC Threads". If someone opens a bug I can open a PR to fix it. Regards, Ashutosh Mehra -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Wed Sep 7 14:41:21 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 7 Sep 2022 16:41:21 +0200 Subject: Missing ShenandoahControlThread in hs_err log In-Reply-To: References: Message-ID: Yes, also missing from Thread.print resp. SIGQUIT printing. I'll open an bug for you. On Wed, Sep 7, 2022 at 4:17 PM Ashutosh Mehra wrote: > While working on another issue I noticed hs_err log file is missing > "ShenandoahControlThread" in the dumped thread list. > As an example, threads from a hs_err dump: > > Java Threads: ( => current thread ) > 0x00007ff18c0986b0 JavaThread "main" [_thread_blocked, id=231505, > stack(0x00007ff1938c2000,0x00007ff1939c3000)] > 0x00007ff18c1fded0 JavaThread "Reference Handler" daemon > [_thread_blocked, id=231513, stack(0x00007ff1723fc000,0x00007ff1724fd000)] > 0x00007ff18c1ff910 JavaThread "Finalizer" daemon [_thread_blocked, > id=231514, stack(0x00007ff1722fb000,0x00007ff1723fc000)] > 0x00007ff18c2018a0 JavaThread "Signal Dispatcher" daemon > [_thread_blocked, id=231515, stack(0x00007ff1721fa000,0x00007ff1722fb000)] > 0x00007ff18c2031f0 JavaThread "Service Thread" daemon [_thread_blocked, > id=231517, stack(0x00007ff171ff7000,0x00007ff1720f8000)] > 0x00007ff18c204b40 JavaThread "Monitor Deflation Thread" daemon > [_thread_blocked, id=231518, stack(0x00007ff171ef6000,0x00007ff171ff7000)] > 0x00007ff18c2069f0 JavaThread "C2 CompilerThread0" daemon > [_thread_blocked, id=231519, stack(0x00007ff171df5000,0x00007ff171ef6000)] > 0x00007ff18c208490 JavaThread "C1 CompilerThread0" daemon > [_thread_blocked, id=231520, stack(0x00007ff171cf4000,0x00007ff171df5000)] > 0x00007ff18c211e10 JavaThread "Sweeper thread" daemon [_thread_blocked, > id=231521, stack(0x00007ff171bf3000,0x00007ff171cf4000)] > 0x00007ff18c28b810 JavaThread "Common-Cleaner" daemon [_thread_blocked, > id=231524, stack(0x00007ff1718ee000,0x00007ff1719ef000)] > 0x00007ff18c2e6a00 JavaThread "Notification Thread" daemon > [_thread_blocked, id=231525, stack(0x00007ff1717ed000,0x00007ff1718ee000)] > 0x00007ff18c35de20 JavaThread "MainThread" [_thread_blocked, id=231527, > stack(0x00007ff170fc1000,0x00007ff1710c2000)] > _threads_hazard_ptr=0x00007ff0f402d1b0, _nested_threads_hazard_ptr_cnt=0 > 0x00007ff0f402c0e0 JavaThread "MyThread" daemon [_thread_blocked, > id=231528, stack(0x00007ff170ab4000,0x00007ff170bb5000)] > > Other Threads: > =>0x00007ff18c1cb090 VMThread "VM Thread" [stack: > 0x00007ff1724ff000,0x00007ff1725ff000] [id=231512] > 0x00007ff18c2e8bf0 WatcherThread "VM Periodic Task Thread" [stack: > 0x00007ff1716ed000,0x00007ff1717ed000] [id=231526] > 0x00007ff18c0b4e90 WorkerThread "Shenandoah GC Threads#0" [stack: > 0x00007ff172fb3000,0x00007ff1730b3000] [id=231506] > 0x00007ff168000cc0 WorkerThread "Shenandoah GC Threads#1" [stack: > 0x00007ff1720fa000,0x00007ff1721fa000] [id=231516] > 0x00007ff13c000d20 WorkerThread "Shenandoah GC Threads#2" [stack: > 0x00007ff171af3000,0x00007ff171bf3000] [id=231522] > 0x00007ff13c001db0 WorkerThread "Shenandoah GC Threads#3" [stack: > 0x00007ff1719f1000,0x00007ff171af1000] [id=231523] > 0x00007ff18c0b5b80 WorkerThread "Safepoint Cleanup Thread#0" [stack: > 0x00007ff172eb1000,0x00007ff172fb1000] [id=231507] > > "ShenandoahControlThread" should appear under "Other Threads" along with > other "Shenandoah GC Threads". > > If someone opens a bug I can open a PR to fix it. > > Regards, > Ashutosh Mehra > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Sep 7 14:42:57 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Wed, 7 Sep 2022 14:42:57 GMT Subject: Integrated: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls In-Reply-To: References: Message-ID: On Tue, 26 Apr 2022 16:14:44 GMT, Evgeny Astigeevich wrote: > Runtime calls are calls of non-compiled methods. Non-compiled methods stay forever in CodeCache. If they are always within the branch range, they don't need trampolines. > > This PR adds `is_always_within_branch_range(Address entry)`. > > Results from DaCapo: the total number of eliminated trampolines per a benchmark run > > > +----------+--------+ > | avrora | 15491 | > | batik | 75837 | > | biojava | 13927 | > | eclipse | 414143 | > | fop | 119267 | > | graphchi | 7665 | > | jme | 8279 | > | luindex | 56061 | > | lusearch | 50277 | > | pmd | 132719 | > | sunflow | 10689 | > | tomcat | 186967 | > | xalan | 50349 | > | zxing | 41497 | > +----------+--------+ > > > > Testing: > - `tier1`...`tier2`: Passed > - `compiler/c2/aarch64/TestTrampoline.java`: Passed > > Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. This pull request has now been integrated. Changeset: 6ff4775b Author: Evgeny Astigeevich Committer: Andrew Haley URL: https://git.openjdk.org/jdk/commit/6ff4775b717d91f9acf24d014ae155dfacac06c5 Stats: 151 lines in 2 files changed: 135 ins; 15 del; 1 mod 8285487: AArch64: Do not generate unneeded trampolines for runtime calls Reviewed-by: xliu, aph ------------- PR: https://git.openjdk.org/jdk/pull/8403 From thomas.stuefe at gmail.com Wed Sep 7 14:46:39 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 7 Sep 2022 16:46:39 +0200 Subject: Missing ShenandoahControlThread in hs_err log In-Reply-To: References: Message-ID: Here you go: https://bugs.openjdk.org/browse/JDK-8293492 Cheers, Thomas On Wed, Sep 7, 2022 at 4:41 PM Thomas St?fe wrote: > Yes, also missing from Thread.print resp. SIGQUIT printing. I'll open an > bug for you. > > On Wed, Sep 7, 2022 at 4:17 PM Ashutosh Mehra wrote: > >> While working on another issue I noticed hs_err log file is missing >> "ShenandoahControlThread" in the dumped thread list. >> As an example, threads from a hs_err dump: >> >> Java Threads: ( => current thread ) >> 0x00007ff18c0986b0 JavaThread "main" [_thread_blocked, id=231505, >> stack(0x00007ff1938c2000,0x00007ff1939c3000)] >> 0x00007ff18c1fded0 JavaThread "Reference Handler" daemon >> [_thread_blocked, id=231513, stack(0x00007ff1723fc000,0x00007ff1724fd000)] >> 0x00007ff18c1ff910 JavaThread "Finalizer" daemon [_thread_blocked, >> id=231514, stack(0x00007ff1722fb000,0x00007ff1723fc000)] >> 0x00007ff18c2018a0 JavaThread "Signal Dispatcher" daemon >> [_thread_blocked, id=231515, stack(0x00007ff1721fa000,0x00007ff1722fb000)] >> 0x00007ff18c2031f0 JavaThread "Service Thread" daemon [_thread_blocked, >> id=231517, stack(0x00007ff171ff7000,0x00007ff1720f8000)] >> 0x00007ff18c204b40 JavaThread "Monitor Deflation Thread" daemon >> [_thread_blocked, id=231518, stack(0x00007ff171ef6000,0x00007ff171ff7000)] >> 0x00007ff18c2069f0 JavaThread "C2 CompilerThread0" daemon >> [_thread_blocked, id=231519, stack(0x00007ff171df5000,0x00007ff171ef6000)] >> 0x00007ff18c208490 JavaThread "C1 CompilerThread0" daemon >> [_thread_blocked, id=231520, stack(0x00007ff171cf4000,0x00007ff171df5000)] >> 0x00007ff18c211e10 JavaThread "Sweeper thread" daemon [_thread_blocked, >> id=231521, stack(0x00007ff171bf3000,0x00007ff171cf4000)] >> 0x00007ff18c28b810 JavaThread "Common-Cleaner" daemon [_thread_blocked, >> id=231524, stack(0x00007ff1718ee000,0x00007ff1719ef000)] >> 0x00007ff18c2e6a00 JavaThread "Notification Thread" daemon >> [_thread_blocked, id=231525, stack(0x00007ff1717ed000,0x00007ff1718ee000)] >> 0x00007ff18c35de20 JavaThread "MainThread" [_thread_blocked, id=231527, >> stack(0x00007ff170fc1000,0x00007ff1710c2000)] >> _threads_hazard_ptr=0x00007ff0f402d1b0, _nested_threads_hazard_ptr_cnt=0 >> 0x00007ff0f402c0e0 JavaThread "MyThread" daemon [_thread_blocked, >> id=231528, stack(0x00007ff170ab4000,0x00007ff170bb5000)] >> >> Other Threads: >> =>0x00007ff18c1cb090 VMThread "VM Thread" [stack: >> 0x00007ff1724ff000,0x00007ff1725ff000] [id=231512] >> 0x00007ff18c2e8bf0 WatcherThread "VM Periodic Task Thread" [stack: >> 0x00007ff1716ed000,0x00007ff1717ed000] [id=231526] >> 0x00007ff18c0b4e90 WorkerThread "Shenandoah GC Threads#0" [stack: >> 0x00007ff172fb3000,0x00007ff1730b3000] [id=231506] >> 0x00007ff168000cc0 WorkerThread "Shenandoah GC Threads#1" [stack: >> 0x00007ff1720fa000,0x00007ff1721fa000] [id=231516] >> 0x00007ff13c000d20 WorkerThread "Shenandoah GC Threads#2" [stack: >> 0x00007ff171af3000,0x00007ff171bf3000] [id=231522] >> 0x00007ff13c001db0 WorkerThread "Shenandoah GC Threads#3" [stack: >> 0x00007ff1719f1000,0x00007ff171af1000] [id=231523] >> 0x00007ff18c0b5b80 WorkerThread "Safepoint Cleanup Thread#0" [stack: >> 0x00007ff172eb1000,0x00007ff172fb1000] [id=231507] >> >> "ShenandoahControlThread" should appear under "Other Threads" along with >> other "Shenandoah GC Threads". >> >> If someone opens a bug I can open a PR to fix it. >> >> Regards, >> Ashutosh Mehra >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Sep 7 14:51:59 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Wed, 7 Sep 2022 14:51:59 GMT Subject: RFR: 8285487: AArch64: Do not generate unneeded trampolines for runtime calls [v8] In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 14:11:30 GMT, Andrew Haley wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Simplify checks in is_always_within_branch_range > > Looks good. Sorry for the delay, I thought I'd already approved this patch. @theRealAph Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/8403 From hseigel at openjdk.org Wed Sep 7 14:53:47 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Wed, 7 Sep 2022 14:53:47 GMT Subject: RFR: 8292383: Create a SymbolHandle type to use for ResourceHashtable In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 21:00:57 GMT, Coleen Phillimore wrote: > This change creates a SymbolHandle which shares code with TempNewSymbol and moves them to their own header file. We could expand this use if needed for GrowableArrays and other things where we have some various Symbol increment/decrement refcounts now. Changed a few ResourceHashtables that take Symbol* keys to use SymbolHandle and verified the refcounts. Also fixed the gtest. > Tested with tier1-7. LGTM ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.org/jdk/pull/10052 From coleenp at openjdk.org Wed Sep 7 14:53:48 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 7 Sep 2022 14:53:48 GMT Subject: RFR: 8292383: Create a SymbolHandle type to use for ResourceHashtable In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 21:00:57 GMT, Coleen Phillimore wrote: > This change creates a SymbolHandle which shares code with TempNewSymbol and moves them to their own header file. We could expand this use if needed for GrowableArrays and other things where we have some various Symbol increment/decrement refcounts now. Changed a few ResourceHashtables that take Symbol* keys to use SymbolHandle and verified the refcounts. Also fixed the gtest. > Tested with tier1-7. Thanks Harold! ------------- PR: https://git.openjdk.org/jdk/pull/10052 From coleenp at openjdk.org Wed Sep 7 14:53:49 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 7 Sep 2022 14:53:49 GMT Subject: Integrated: 8292383: Create a SymbolHandle type to use for ResourceHashtable In-Reply-To: References: Message-ID: <86XL3mk7Lno3xffVblenXw6CyssBsEhhyiNk2xQ24Ms=.6b851734-c100-4357-8614-b419b321c9e0@github.com> On Fri, 26 Aug 2022 21:00:57 GMT, Coleen Phillimore wrote: > This change creates a SymbolHandle which shares code with TempNewSymbol and moves them to their own header file. We could expand this use if needed for GrowableArrays and other things where we have some various Symbol increment/decrement refcounts now. Changed a few ResourceHashtables that take Symbol* keys to use SymbolHandle and verified the refcounts. Also fixed the gtest. > Tested with tier1-7. This pull request has now been integrated. Changeset: 5934669c Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/5934669ca88c919fe9419410ea75a022a676eef4 Stats: 237 lines in 16 files changed: 108 ins; 82 del; 47 mod 8292383: Create a SymbolHandle type to use for ResourceHashtable Reviewed-by: iklam, hseigel ------------- PR: https://git.openjdk.org/jdk/pull/10052 From cstein at openjdk.org Wed Sep 7 15:17:53 2022 From: cstein at openjdk.org (Christian Stein) Date: Wed, 7 Sep 2022 15:17:53 GMT Subject: Integrated: JDK-8289798: Update to use jtreg 7 In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. This pull request has now been integrated. Changeset: 1ee59adc Author: Christian Stein Committer: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/1ee59adcfead2128316556121c1711d308c7ea01 Stats: 11 lines in 8 files changed: 0 ins; 0 del; 11 mod 8289798: Update to use jtreg 7 Reviewed-by: ihse, jpai ------------- PR: https://git.openjdk.org/jdk/pull/9393 From duke at openjdk.org Wed Sep 7 15:32:46 2022 From: duke at openjdk.org (Ashutosh Mehra) Date: Wed, 7 Sep 2022 15:32:46 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive [v2] In-Reply-To: <9ah9SD1YhJdPEqRlH4n9k1NqWha3eTTuNaiQhywVP_Q=.9ab53e2a-4c10-4e2b-be4e-cf1483c2f12d@github.com> References: <9ah9SD1YhJdPEqRlH4n9k1NqWha3eTTuNaiQhywVP_Q=.9ab53e2a-4c10-4e2b-be4e-cf1483c2f12d@github.com> Message-ID: <0FNcAv6JKl-l2gzKYkB2F8Zs_r68rUK6k_FBJS_eKWk=.65ccbb69-d9a2-48d5-9b30-d4e7587e4fda@github.com> On Fri, 26 Aug 2022 20:22:57 GMT, Ashutosh Mehra wrote: >> Please review this patch to fix the crash when running Loom with Shenandoah in iu+aggressive mode. >> >> When running with `-XX:+ShenandoahVerify`, the issue manifests as assertion at: >> >> >> 1 # >> 2 # A fatal error has been detected by the Java Runtime Environment: >> 3 # >> 4 # Internal Error (/home/asmehra/data/ashu-mehra/loom/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:92), pid=920144, tid=920156 >> 5 # Error: Before Evacuation, Reachable; Must be marked in complete bitmap, except j.l.r.Reference referents >> 6 >> 7 Referenced from: >> 8 interior location: 0x00007f0a40000090 >> 9 0x00007f0a40000060 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk >> 10 allocated after mark start >> 11 not after update watermark >> 12 marked strong >> 13 marked weak >> 14 not in collection set >> 15 mark: mark(is_neutral no_hash age=0) >> 16 region: | 0|R |BTE 7f0a40000000, 7f0a401ff9b0, 7f0a40200000|TAMS 7f0a40000000|UWM 7f0a401ff9b0|U 2046K|T 2046K|G 0B|S 0B|L 2046K|CP 0 >> 17 >> 18 Object: >> 19 0x00007f0c2f848a40 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk >> 20 not allocated after mark start >> 21 not after update watermark >> 22 not marked strong >> 23 not marked weak >> 24 in collection set >> 25 mark: mark(is_neutral no_hash age=0) >> 26 region: | 3964|CS |BTE 7f0c2f800000, 7f0c2fa00000, 7f0c2fa00000|TAMS 7f0c2fa00000|UWM 7f0c2fa00000|U 2048K|T 0B|G 2048K|S 0B|L 1612K|CP 0 >> 27 >> 28 Forwardee: >> 29 (the object itself) >> >> >> The StackChunk object `0x00007f0c2f848a40` is not marked which happens to be referenced from the parent field of the newly allocated StackChunk object `0x00007f0a40000060`. >> The sequence for setting `StackChunk::parent` is as follows. At some point during the process of freezing the continuation, the jvm does: >> >> >> continuationWrapper::_tail = stackChunk1 >> stackChunk2 = allocate new StackChunk >> stackChunk2::parent = continuationWrapper::_tail >> continuationWrapper::_tail = stackChunk2 >> >> >> At the end of the sequence stackChunk1 is only reachable from stackChunk2. If stackChunk2 happens to be allocated after concurrent mark has started and if the shenandoahgc is using IU mode, then the stackChunk2 would would not be scanned. This results in gc missing the marking of stackChunk1 which triggers the the assertion during heap verification. >> >> This is similar to the sequence described by @fisk [here](https://github.com/openjdk/jdk19/pull/140#issuecomment-1185491224) >> >> There is code in `FreezeBase::finish_freeze()` to call `stackChunkOopDesc::do_barriers()` which triggers the gc barriers for the newly allocated StackChunk object. But it has two problems: >> 1. The call to `stackChunkOopDesc::do_barriers()` is guarded by a flag [1] which is false for StackChunk objects allocated after marking has started [2] >> 2. `stackChunkOopDesc::do_barriers()` currently triggers the gc barriers for the oops in the stack represented by the newly allocated StackChunk, but it ignores the oops in the StackChunk header >> >> To fix these two issues, we need the following changes: >> 1. Always enable barrier for Shenandoah IU mode (this change is same as 8288129: Shenandoah: Skynet test crashed with iu + aggressive #9494). >> 2. Add the code in `stackChunkOopDesc::do_barriers` to run the barriers on the oops present in the stack chunk header. >> >> [1] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1201 >> [2] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L2308 >> >> Signed-off-by: Ashutosh Mehra > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Enable loom for ShenandoahGC IU mode > > Signed-off-by: Ashutosh Mehra Closing it in favor of #10089 ------------- PR: https://git.openjdk.org/jdk/pull/9982 From duke at openjdk.org Wed Sep 7 15:32:48 2022 From: duke at openjdk.org (Ashutosh Mehra) Date: Wed, 7 Sep 2022 15:32:48 GMT Subject: Withdrawn: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 15:05:48 GMT, Ashutosh Mehra wrote: > Please review this patch to fix the crash when running Loom with Shenandoah in iu+aggressive mode. > > When running with `-XX:+ShenandoahVerify`, the issue manifests as assertion at: > > > 1 # > 2 # A fatal error has been detected by the Java Runtime Environment: > 3 # > 4 # Internal Error (/home/asmehra/data/ashu-mehra/loom/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:92), pid=920144, tid=920156 > 5 # Error: Before Evacuation, Reachable; Must be marked in complete bitmap, except j.l.r.Reference referents > 6 > 7 Referenced from: > 8 interior location: 0x00007f0a40000090 > 9 0x00007f0a40000060 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk > 10 allocated after mark start > 11 not after update watermark > 12 marked strong > 13 marked weak > 14 not in collection set > 15 mark: mark(is_neutral no_hash age=0) > 16 region: | 0|R |BTE 7f0a40000000, 7f0a401ff9b0, 7f0a40200000|TAMS 7f0a40000000|UWM 7f0a401ff9b0|U 2046K|T 2046K|G 0B|S 0B|L 2046K|CP 0 > 17 > 18 Object: > 19 0x00007f0c2f848a40 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk > 20 not allocated after mark start > 21 not after update watermark > 22 not marked strong > 23 not marked weak > 24 in collection set > 25 mark: mark(is_neutral no_hash age=0) > 26 region: | 3964|CS |BTE 7f0c2f800000, 7f0c2fa00000, 7f0c2fa00000|TAMS 7f0c2fa00000|UWM 7f0c2fa00000|U 2048K|T 0B|G 2048K|S 0B|L 1612K|CP 0 > 27 > 28 Forwardee: > 29 (the object itself) > > > The StackChunk object `0x00007f0c2f848a40` is not marked which happens to be referenced from the parent field of the newly allocated StackChunk object `0x00007f0a40000060`. > The sequence for setting `StackChunk::parent` is as follows. At some point during the process of freezing the continuation, the jvm does: > > > continuationWrapper::_tail = stackChunk1 > stackChunk2 = allocate new StackChunk > stackChunk2::parent = continuationWrapper::_tail > continuationWrapper::_tail = stackChunk2 > > > At the end of the sequence stackChunk1 is only reachable from stackChunk2. If stackChunk2 happens to be allocated after concurrent mark has started and if the shenandoahgc is using IU mode, then the stackChunk2 would would not be scanned. This results in gc missing the marking of stackChunk1 which triggers the the assertion during heap verification. > > This is similar to the sequence described by @fisk [here](https://github.com/openjdk/jdk19/pull/140#issuecomment-1185491224) > > There is code in `FreezeBase::finish_freeze()` to call `stackChunkOopDesc::do_barriers()` which triggers the gc barriers for the newly allocated StackChunk object. But it has two problems: > 1. The call to `stackChunkOopDesc::do_barriers()` is guarded by a flag [1] which is false for StackChunk objects allocated after marking has started [2] > 2. `stackChunkOopDesc::do_barriers()` currently triggers the gc barriers for the oops in the stack represented by the newly allocated StackChunk, but it ignores the oops in the StackChunk header > > To fix these two issues, we need the following changes: > 1. Always enable barrier for Shenandoah IU mode (this change is same as 8288129: Shenandoah: Skynet test crashed with iu + aggressive #9494). > 2. Add the code in `stackChunkOopDesc::do_barriers` to run the barriers on the oops present in the stack chunk header. > > [1] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1201 > [2] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L2308 > > Signed-off-by: Ashutosh Mehra This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9982 From stuefe at openjdk.org Wed Sep 7 17:02:21 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 7 Sep 2022 17:02:21 GMT Subject: RFR: JDK-8293346: Add NoThreadCurrentMark to simulate non-attached threads Message-ID: When working on [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344), I needed a way to verify that I had removed all offending usages of ResourceArea memory inside an extend. For that, a NoThreadCurrentMark was useful. It temporarily sets the current Thread* to NULL for the extend. Any use of Thread::current below that mark will now crash or assert. This can be used for two things: - guard code that is supposed to be safe for non-attached threads (os::malloc, stack printing, UL etc) against accidental usage of Thread::current() (e.g. resource area allocation) - in gtests, simulate a non-attached thread to cover code that behaves differently with Thread::current()==NULL. This patch: - Introduces the debug-only `NoThreadCurrentMark` - Adds a gtest for it - Adds it to guard dwarf-parsing-based stack printing, which had not been safe due to use of ResourceArea, fixed with [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344) - Adds it to `os::malloc()`, `os::realloc()` and `os::free()`, since those can certainly be called without a current thread. - Replaces the test-local mark in the SafeFetch gtests that did a similar thing - I may add and fix up other users later I also had to change Library-based TLS initialization such that it runs at C++ dynamic initialization time. That is because the `NoThreadCurrentMark` needs to set both Library-based TLS and C++ TLS slots, and having library-based TLS not available before VM initialization made the code too complex. This also means we can remove the explicit TLS initialization from create_vm. Finally, while I was here, I also fixed the error printing in library based TLS (since the pthread_key_xxx functions don't modify errno). ------------- Commit messages: - NoThreadCurrentMark Changes: https://git.openjdk.org/jdk/pull/10178/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10178&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293346 Stats: 192 lines in 11 files changed: 143 ins; 24 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/10178.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10178/head:pull/10178 PR: https://git.openjdk.org/jdk/pull/10178 From coleenp at openjdk.org Wed Sep 7 17:37:44 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 7 Sep 2022 17:37:44 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v5] In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 01:05:38 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose has updated the pull request incrementally with one additional commit since the last revision: > > add missing "this->" src/hotspot/share/utilities/unsigned5.hpp line 190: > 188: // reports the largest uint32_t value that can be encoded using len bytes > 189: // len must be in the range [1..5] > 190: static constexpr uint32_t max_encoded_in_length(uint32_t len) { A few of the classes make the gtest test a friend so that internal functions can be private. ------------- PR: https://git.openjdk.org/jdk/pull/10067 From coleenp at openjdk.org Wed Sep 7 17:46:59 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 7 Sep 2022 17:46:59 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v5] In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 01:05:38 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose has updated the pull request incrementally with one additional commit since the last revision: > > add missing "this->" This looks good to me, for the current CompressedStream and for upcoming changes. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/10067 From amenkov at openjdk.org Wed Sep 7 20:09:05 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 7 Sep 2022 20:09:05 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v3] In-Reply-To: References: Message-ID: > The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) > > cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. > After successful RedefineClasses it should be reset. > The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: updated test. comments, code reorg ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10032/files - new: https://git.openjdk.org/jdk/pull/10032/files/d86ae7fa..9bc08346 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=01-02 Stats: 303 lines in 2 files changed: 129 ins; 104 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/10032.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10032/head:pull/10032 PR: https://git.openjdk.org/jdk/pull/10032 From amenkov at openjdk.org Wed Sep 7 20:09:06 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 7 Sep 2022 20:09:06 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v2] In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 09:47:05 GMT, Serguei Spitsyn wrote: > Also, I'm curious how did you verify that no regressions have been introduced? Run all Redefine/Retransform Classes tests: test/jdk/java/lang/instrument test/hotspot/jtreg/serviceability/jvmti/RedefineClasses test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 76: > >> 74: private static byte[] initialClassBytes; >> 75: >> 76: private static class VersionScanner extends ClassVisitor { > > This class needs some explanation. > It is unclear how does it work. > Could you, please, add relevant comments where needed? > For instance, how are the class file bytes constructed and what role does the version play. Done. > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 236: > >> 234: redefine(2, 5); // updates cached class bytes >> 235: retransform(3, 2); >> 236: retransform(4, 2); > > The comments for all test cases need to be aligned. > Also, it is better to comment all redefine/retransform cases. Done. > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 179: > >> 177: if (err != JVMTI_ERROR_NONE) { >> 178: _log("nRedefine: SetEventNotificationMode(JVMTI_DISABLE) error %d\n", err); >> 179: } > > It makes sense to introduce an utility function which does SetEventNotificationMode. > It can be two separate functions to enable and disable or one single function can support both cases. Removed code duplication - now the code is in helper class > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 195: > >> 193: _log("nRedefine: classLoadHookSavedClassBytes is NULL\n"); >> 194: return nullptr; >> 195: } > > The checks 181-195 seems to be the same in functions nRedefine and nRetransform, > so one utility function can be used in both cases. Removed code duplication - now the code is in helper class > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 274: > >> 272: classLoadHookSavedClassBytes = nullptr; >> 273: >> 274: return result; > > The fragments 197-214 and 256-274 do the same. > I'd suggest to define and use a function that does this post-processing. reworked the code a bit, moved all common code to helper class ------------- PR: https://git.openjdk.org/jdk/pull/10032 From kbarrett at openjdk.org Wed Sep 7 22:09:47 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 7 Sep 2022 22:09:47 GMT Subject: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT In-Reply-To: References: Message-ID: <0Nhq3dcg-Z0G4AYgpcHDGa4xMDHSSBC97eGtKmiw_bY=.934c0f0c-7c1a-4f90-9cce-91bcf0c2ac00@github.com> On Fri, 2 Sep 2022 09:51:06 GMT, Stefan Karlsson wrote: > During the discussion of [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was voiced that we should stop using INTPTR_FORMAT when printing pointers. > > Some background that could explain why some tend to use INTPTR_FORMAT instead of PTR_FORMAT: > > Both those format specifiers require an integer and the compiler barfs if you send in a pointer. We therefore have a utility function named p2i, which converts the pointer to an integer. So, everywhere we have to write print line like this: `print("my pointer: " PTR_FORMAT, p2i(my_pointer));`. Now, p2i returns an intptr_t, and it becomes natural for some to consider the type of the converted value (that we need because of the mentioned workaround), instead of the original type of the value. > > With this enhancement I'd like to clean up the code that I often work in, so that it uses PTR_FORMAT when printing pointers. I'm leaving the rest of the code base for others to consider cleaning up. > > Cleanups have been done in directories gc/, utilities/, memory/, and oops/. Looks good. I did notice a couple INTPTR_FORMAT => (new) SIZE_FORMAT_X_0. Good change. I also noticed a place where there are sequential asserts, one (previously) using INTPTR_FORMAT and the next PTR_FORMAT, for the same value. Seems like somebody wasn't paying attention. Again good change. Also noticed some pre-existing unnecessary (void*) casts of the pointer argument to p2i. Not your problem, and not really appropriate for this change to do anything about them, but I really hate eye-catching cast junk like that. There were also a few INTPTR_FORMAT uses that were left in place. All that I recall looked like they could/should instead be SIZE_FORMAT_X_0 or maybe even SIZE_FORMAT_X if the zero padding isn't useful. Leaving those for a later pass seems fine. I wonder how many INTPTR_FORMATs are left in the areas you worked on? ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/10141 From vlivanov at openjdk.org Wed Sep 7 22:56:42 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 7 Sep 2022 22:56:42 GMT Subject: RFR: 8293329: x86: Improve handling of constants in AES/GHASH stubs [v3] In-Reply-To: References: Message-ID: > Pre-generating constants saves on startup and static/dynamic footprint a bit, plus simplifies bootstrapping logic. > > As a downside, constants aren't guaranteed to be always reachable anymore, but since they are used from stubs, finding a scratch register when needed is not a problem. > > Testing: > - [x] hs-tier1 - hs-tier4 w/ `-XX:+ForceUnreachable` > - [x] x86_32 build Vladimir Ivanov 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 'stub.x86_64.aes' into stub.x86_64.aes.consts - Merge branch 'stub.x86_64.aes' into stub.x86_64.aes.consts - constants ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10152/files - new: https://git.openjdk.org/jdk/pull/10152/files/7c35132b..332040b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10152&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10152&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10152.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10152/head:pull/10152 PR: https://git.openjdk.org/jdk/pull/10152 From sspitsyn at openjdk.org Thu Sep 8 00:10:42 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 8 Sep 2022 00:10:42 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v3] In-Reply-To: References: Message-ID: <94C15Oo65ApUHiIfsMs68E_bk1isRLk3KQXndfb6_tM=.c96142ba-e8ae-4274-af6f-f9225ebd7201@github.com> On Wed, 7 Sep 2022 20:09:05 GMT, Alex Menkov wrote: >> The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) >> >> cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. >> After successful RedefineClasses it should be reset. >> The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated test. comments, code reorg Alex, Thank you for the update! It looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10032 From fyang at openjdk.org Thu Sep 8 01:15:57 2022 From: fyang at openjdk.org (Fei Yang) Date: Thu, 8 Sep 2022 01:15:57 GMT Subject: RFR: 8293474: RISC-V: Unify the way of moving function pointer In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 08:36:49 GMT, Fei Yang wrote: > Currently, there are two different ways of moving function pointer on riscv with either 'li' or 'mv' assembler functions. > For example, in file shenandoahBarrierSetAssembler_riscv.cpp, we use 'li' function: > li(ra, (int64_t)(uintptr_t)ShenandoahRuntime::load_reference_barrier_strong_narrow) > > While in file templateInterpreterGenerator_riscv.cpp, we use 'mv' function: > mv(t1, CAST_FROM_FN_PTR(address, JavaThread::check_special_condition_for_native_trans)) > > Use of 'mv' here calls 'movptr' and emits fixed length instruction sequence, which is neither necessary nor optimal compared with use of 'li'. This changes to use 'li' instead of 'movptr' to implement 'mv' and unifies the way of moving function pointer. > > Testing: Passed Tier1 test on Linux-riscv64 SiFive Unmatched board. Thanks all for the review. Integrate then. ------------- PR: https://git.openjdk.org/jdk/pull/10194 From fyang at openjdk.org Thu Sep 8 01:17:48 2022 From: fyang at openjdk.org (Fei Yang) Date: Thu, 8 Sep 2022 01:17:48 GMT Subject: Integrated: 8293474: RISC-V: Unify the way of moving function pointer In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 08:36:49 GMT, Fei Yang wrote: > Currently, there are two different ways of moving function pointer on riscv with either 'li' or 'mv' assembler functions. > For example, in file shenandoahBarrierSetAssembler_riscv.cpp, we use 'li' function: > li(ra, (int64_t)(uintptr_t)ShenandoahRuntime::load_reference_barrier_strong_narrow) > > While in file templateInterpreterGenerator_riscv.cpp, we use 'mv' function: > mv(t1, CAST_FROM_FN_PTR(address, JavaThread::check_special_condition_for_native_trans)) > > Use of 'mv' here calls 'movptr' and emits fixed length instruction sequence, which is neither necessary nor optimal compared with use of 'li'. This changes to use 'li' instead of 'movptr' to implement 'mv' and unifies the way of moving function pointer. > > Testing: Passed Tier1 test on Linux-riscv64 SiFive Unmatched board. This pull request has now been integrated. Changeset: fc5f97fe Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/fc5f97fe379825cb927666ae26aef00082cfae56 Stats: 31 lines in 3 files changed: 2 ins; 10 del; 19 mod 8293474: RISC-V: Unify the way of moving function pointer Reviewed-by: yadongwang, fjiang, shade ------------- PR: https://git.openjdk.org/jdk/pull/10194 From dlong at openjdk.org Thu Sep 8 01:37:01 2022 From: dlong at openjdk.org (Dean Long) Date: Thu, 8 Sep 2022 01:37:01 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v5] In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 01:05:38 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose has updated the pull request incrementally with one additional commit since the last revision: > > add missing "this->" Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10067 From fyang at openjdk.org Thu Sep 8 03:30:12 2022 From: fyang at openjdk.org (Fei Yang) Date: Thu, 8 Sep 2022 03:30:12 GMT Subject: RFR: 8293524: RISC-V: Use macro-assembler functions as appropriate Message-ID: Use of assember functions on riscv can be improved. For example, we use 'fence(0xf, 0xf)' in function TemplateInterpreterGenerator::generate_safept_entry_for to emit a full memory fence instruction. Here we should use 'membar(MacroAssembler::AnyAny)' instead, which would make the code more readable. This also replace some calls to 'li' with 'mv' so that it will be more consistent when moving integer constant. Testing: Tier1 tested on Linux-riscv64 SiFive Unmatched board. ------------- Commit messages: - 8293524: RISC-V: Use macro-assembler functions as appropriate Changes: https://git.openjdk.org/jdk/pull/10210/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10210&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293524 Stats: 78 lines in 13 files changed: 0 ins; 0 del; 78 mod Patch: https://git.openjdk.org/jdk/pull/10210.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10210/head:pull/10210 PR: https://git.openjdk.org/jdk/pull/10210 From kim.barrett at oracle.com Thu Sep 8 04:35:09 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 8 Sep 2022 04:35:09 +0000 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> Message-ID: <0AAEC728-3D24-46FC-9D11-4A2F5FBD70FA@oracle.com> On Sep 7, 2022, at 5:30 AM, Dmitry Chuyko wrote: > > Hi Kim, > > The implementation of the main JDK-8261027 change doesn't just try to provide the functionality when built with older GCC (or not GCC). What it does is dynamically switch to a more advanced implementation if the appropriate hardware capabilities were detected during the VM start. The selected code is picked by the compiler. So there are 2 implementations and non-LSE one is the default. This allows us to provide a single binary for all supported ARM devices and get better performance where possible. That's close to what the __atomic intrinsics with -moutline-atomics do. Except the compiler intrinsic approach has various benefits accrued from being built into the compiler. (And the code that we need to maintain is much simpler.) > From another hand, a less advanced implementation is always used initially in the default configuration. As you noticed, JDK-8282322 just makes it possible to create a build that uses the LSE variant from the start. JDK-8282322 requires an appropriate -march or similar option. The intrinsic approach gets the same desired effect (use only LSE) when such an option is provided, but inline. That's one of the benefits. From thartmann at openjdk.org Thu Sep 8 05:09:51 2022 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 8 Sep 2022 05:09:51 GMT Subject: RFR: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files [v5] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 22:39:28 GMT, Vladimir Ivanov wrote: >> Move code related to AES and GHASH stubs from `stubGenerator_x86_64.cpp` into `stubGenerator_x86_64_aes.cpp` and `stubGenerator_x86_64_ghash.cpp` respectively. >> >> Testing: hs-tier1 - hs-tier4 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > include Looks good. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.org/jdk/pull/10124 From shade at openjdk.org Thu Sep 8 06:18:43 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 8 Sep 2022 06:18:43 GMT Subject: RFR: 8293524: RISC-V: Use macro-assembler functions as appropriate In-Reply-To: References: Message-ID: <2yxPwlehWfNYflxKSv56dY9JAUZQFUTXIUGIW4tqZNk=.d41a9b56-3862-42b2-bcc1-75c4cd077484@github.com> On Thu, 8 Sep 2022 03:20:41 GMT, Fei Yang wrote: > Use of assember functions on riscv can be improved. For example, we use 'fence(0xf, 0xf)' in function TemplateInterpreterGenerator::generate_safept_entry_for to emit a full memory fence instruction. Here we should use 'membar(MacroAssembler::AnyAny)' instead, which would make the code more readable. This also replace some calls to 'li' with 'mv' so that it will be more consistent when moving integer constant. > > Testing: Tier1 tested on Linux-riscv64 SiFive Unmatched board. Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10210 From jrose at openjdk.org Thu Sep 8 07:37:53 2022 From: jrose at openjdk.org (John R Rose) Date: Thu, 8 Sep 2022 07:37:53 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: <-RXfpRzuGeXmyRSEg2u0XNJETE5VHaI9wrailPSF3IA=.26c9b859-fa04-442b-9fdb-9ead1b07ab0c@github.com> References: <-RXfpRzuGeXmyRSEg2u0XNJETE5VHaI9wrailPSF3IA=.26c9b859-fa04-442b-9fdb-9ead1b07ab0c@github.com> Message-ID: On Sat, 3 Sep 2022 07:48:50 GMT, Dean Long wrote: >> John R Rose 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 branch 'master' of https://git.openjdk.org/jdk into compressed-stream >> - 8292758: put support for UNSIGNED5 format into its own header file > > Wouldn't the SA stack walk fail when attaching to a core dump from an earlier JVM that does not exclude nulls? @dean-long and @coleenp Thank you for the reviews. The public functions in `UNSIGNED5` are not internal but are designed to be useful by themselves. That is why the gtest tests them separately. For example, `check_length` is used inside the `Reader` but if you are building your own reader-like logic, you might want to use it to avoid buffer overflows. Likewise `fits_in_limit` is used by the sizing logic of `write_uint_grow` but if you are rolling your own auto-grow logic, you would want to call that function on its own, or maybe `encoded_length`. The fancy API points like `Reader` and `Sizer` and `write_uint_grow` are not intended to be primitives, but rather best practices for using the static functions, which are the real primitives. Testing notes: This change passes a targeted test that runs `test/hotspot/jtreg/compiler/c2/Test6*.java` (about 50 tests) with `CONF=fastdebug` and `JTREG="JAVA_OPTIONS=-Xcomp -XX:+TraceDeoptimization"`. That run is chosen to deoptimize many times (about 39k), so as to exercise the pre-existing stack walk logic, which relies on compressed streams. Fault injection confirms that any JVM run crashes immediately if there is a bug in the encoding. It also passes tiers 1/2/3 (in a slightly earlier version) and all gtests (in the latest version). ------------- PR: https://git.openjdk.org/jdk/pull/10067 From jrose at openjdk.org Thu Sep 8 07:39:53 2022 From: jrose at openjdk.org (John R Rose) Date: Thu, 8 Sep 2022 07:39:53 GMT Subject: Integrated: 8292758: put support for UNSIGNED5 format into its own header file In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 18:20:42 GMT, John R Rose wrote: > Refactor code from inside of CompressedStream into its own unit. > > This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). > > Add gtests. This pull request has now been integrated. Changeset: 8d3399bf Author: John R Rose URL: https://git.openjdk.org/jdk/commit/8d3399bf5f354931b0c62d2ed8095e554be71680 Stats: 1257 lines in 9 files changed: 1100 ins; 128 del; 29 mod 8292758: put support for UNSIGNED5 format into its own header file Reviewed-by: dlong, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/10067 From thartmann at openjdk.org Thu Sep 8 07:48:47 2022 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 8 Sep 2022 07:48:47 GMT Subject: RFR: 8293287 add ReplayReduce flag [v3] In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 21:56:50 GMT, Dean Long wrote: >> Add an experimental flag to help developers "reduce" a replay file. >> >> As a first step, I plan to simulate reduced inlining. This will output multiple "compile" lines as if the first level of inlining never happened: >> A --> B --> C >> A --> D --> E >> becomes >> B --> C >> D --> E >> Developers can repeat iteratively until the replay crash no longer reproduces. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > remove support for pre-2013 replay files I'm wondering if this functionality should really be part of the VM. Wouldn't a simple script that regex-parses the compile statement of the replay file, iteratively removes inlines and runs replay compilation to check if the issue still reproduces, be more powerful and easier to maintain? It could be combined with also removing class loading statements. src/hotspot/share/opto/compile.cpp line 4583: > 4581: return; > 4582: } > 4583: // Enable interative replay file reduction Suggestion: // Enable iterative replay file reduction ------------- PR: https://git.openjdk.org/jdk/pull/10134 From kim.barrett at oracle.com Thu Sep 8 07:50:08 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 8 Sep 2022 07:50:08 +0000 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> Message-ID: > On Sep 7, 2022, at 5:30 AM, Andrew Haley wrote: > > On 9/7/22 05:41, Kim Barrett wrote: >> I?m puzzled by this change: >> https://bugs.openjdk.org/browse/JDK-8282322 >> 8282322: AArch64: Provide a means to eliminate all STREX family of instructions >> (2022-07-08, jdk20, no backports) >> It?s a followup to these changes: >> https://bugs.openjdk.org/browse/JDK-8261027 >> 8261027: AArch64: Support for LSE atomics C++ HotSpot code >> (2021-02-12, jdk17, backported to jdk11, but not jdk8) >> 8261649: AArch64: Optimize LSE atomics in C++ code >> (2021-02-19, jdk17, backported to jdk11, but not jdk8) >> [Also related is this >> https://bugs.openjdk.org/browse/JDK-8261660 >> AArch64: Race condition in stub code generation for LSE Atomics >> (2021-02-12, jdk17, superseded by 8261649)] >> which are essentially reimplementing gcc?s -moutline-atomics option. The point >> of doing this is to allow those changes to be used while building jdk with gcc >> versions that don't support -moutline-atomics, esp. for purposes of backports. >> (That option arrived with gcc8.5/gcc9.4/gcc10, enabled by default in gcc10. I >> guess some non-Oracle folks might still be using something earlier, esp. in >> the jdk17 timeframe when LSE support was being added.) > > Sure. The timing wasn't good: the outline-atomics patch went in to GCC > in September 2019, but was back-ported to GCC releases by May/June 2021. > Our patch was committed in Feb that year. I don?t have a problem with 8261027 and 8261649. Yeah, it?s kind of messy, but I think appropriate for the time. >> For jdk20+ (where 8282322 landed), I question whether the approach being taken >> here really makes sense. If one is willing to assume a relatively recent >> version of gcc is being used, then I think there is no reason to reimplement >> the effect of -moutline-atomics. We could undo all three of those changes, >> reverting back to using gcc __atomic intrinsics, and rely on -moutline-atomics >> (explicitly requested for gcc8/9). In that case, nothing like 8282322 is >> needed; just specify armv8.1-a or later when configuring the build (which is >> already needed to activate the current 8282322 behavior) and LSE will be used, >> regardless of -moutline-atomics (or if it is even supported, if you want to >> use rr with an old gcc version). >> That would be a lot simpler. It also makes it easier to make further changes. > True. It all feels a bit early to me, though. I don't think that OpenJDK has ever > needed so recent compiler features before. We've always been very conservative > about what we depend on. So it might be OK to do this, but (to me) it feels > like sailing close to the wind. We (Oracle) used to be extremely conservative about toolchain upgrades, but we got better. (Thank you, spectre and meltdown.) I admit my opinion is colored by that, and the benefits from it. Note that OpenJDK recently dropped support for Visual Studio 2017, now requiring some patch level of VS2019. That's a stronger restriction in a similar timeframe. (The dropped versions of VS cannot build the latest JDK.) Unlike that situation with VS, switching linux-aarch64 back to using __atomic intrinsics would still work if using an old toolchain, but possibly at reduced performance on spiffy new hardware. And I'm only proposing this going forward; backports need not apply. A benefit of such a change would be that if one knows what hardware is going to be used, one can compile specifically for that and get best performance for these operations for that hardware. I can easily imagine that being a common scenario. The current approach actively prevents that. How many folks are very conservative about gcc versions but not about JDK versions? And should we be catering to them at the expense of folks who are keeping up to date and willing to do tailored builds. > I'm curious, though: wouldn't atomic bitset ops be based on CAS? If so, you don't > need to care how CAS is implemented. We can write them as an Atomic::cmpxchg loop, just as we can write Atomic::add that way. But that isn't a particularly good way to write them. It's a loop over an ll/sc loop, or a loop over an LSE CAS instruction. Better is a direct ll/sc loop or an LSE bitop instruction. From duke at openjdk.org Thu Sep 8 08:15:28 2022 From: duke at openjdk.org (hev) Date: Thu, 8 Sep 2022 08:15:28 GMT Subject: RFR: 8293416: ZGC: Set mark bit with unconditional atomic ops [v3] In-Reply-To: References: Message-ID: > **Summary** > Support to set ZGC mark bit with unconditional atomic ops. > > **Motivation** > ZGC currently modify mark-bitmap by a conditional atomic operation (cmpxchg). This way is not optimal, which will retry the loop when cmpxchg fails. > > **Description** > First, This patch-set add an new unconditional atomic operation: Atomic::fetch_and_or, which is implemented in different ways for different CPU architectures: > > * Exclusive access: Non-nested loop > > > retry: > ll old_val, addr > or new_val, old_val, set_val > sc new_val, addr > beq retry > > > * Atomic access: One instruction > > > ldset old_val, set_val, addr > > > * Generic: Fallback to cmpxchg or use c++ __atomic_fetch_or > > **Testing** > * jtreg tests > * benchmark tests hev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - ZGC: Set mark bit with unconditional atomic ops - BitMap: Set bit with unconditional atomic ops - Atomic: Add bitset functions ------------- Changes: https://git.openjdk.org/jdk/pull/10182/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10182&range=02 Stats: 627 lines in 11 files changed: 578 ins; 3 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/10182.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10182/head:pull/10182 PR: https://git.openjdk.org/jdk/pull/10182 From duke at openjdk.org Thu Sep 8 08:24:53 2022 From: duke at openjdk.org (hev) Date: Thu, 8 Sep 2022 08:24:53 GMT Subject: RFR: 8293416: ZGC: Set mark bit with unconditional atomic ops [v3] In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 08:15:28 GMT, hev wrote: >> **Summary** >> Support to set ZGC mark bit with unconditional atomic ops. >> >> **Motivation** >> ZGC currently modify mark-bitmap by a conditional atomic operation (cmpxchg). This way is not optimal, which will retry the loop when cmpxchg fails. >> >> **Description** >> First, This patch-set add an new unconditional atomic operation: Atomic::fetch_and_or, which is implemented in different ways for different CPU architectures: >> >> * Exclusive access: Non-nested loop >> >> >> retry: >> ll old_val, addr >> or new_val, old_val, set_val >> sc new_val, addr >> beq retry >> >> >> * Atomic access: One instruction >> >> >> ldset old_val, set_val, addr >> >> >> * Generic: Fallback to cmpxchg or use c++ __atomic_fetch_or >> >> **Testing** >> * jtreg tests >> * benchmark tests > > hev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - ZGC: Set mark bit with unconditional atomic ops > - BitMap: Set bit with unconditional atomic ops > - Atomic: Add bitset functions Hello, I will rebase this patchset when JDK-8293117 (https://bugs.openjdk.org/browse/JDK-8293117) is done. Atomic: Add bitset functions(https://github.com/openjdk/jdk/pull/10182/commits/dc15c68d1ff0e5c7445b333d45dc562881f5687e) contains a few architecture (not all) implementations, and only for test. RFC, Thanks~ ------------- PR: https://git.openjdk.org/jdk/pull/10182 From fjiang at openjdk.org Thu Sep 8 08:32:58 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 8 Sep 2022 08:32:58 GMT Subject: RFR: 8293524: RISC-V: Use macro-assembler functions as appropriate In-Reply-To: References: Message-ID: <-nTSe9WMC2M2GneKjFB9H66TI5vpj45XeLvMfK38EQE=.95b1bb6a-0654-49fe-9c5a-cd8bfce7465e@github.com> On Thu, 8 Sep 2022 03:20:41 GMT, Fei Yang wrote: > Use of assember functions on riscv can be improved. For example, we use 'fence(0xf, 0xf)' in function TemplateInterpreterGenerator::generate_safept_entry_for to emit a full memory fence instruction. Here we should use 'membar(MacroAssembler::AnyAny)' instead, which would make the code more readable. This also replace some calls to 'li' with 'mv' so that it will be more consistent when moving integer constant. > > Testing: Tier1 tested on Linux-riscv64 SiFive Unmatched board. Nice clean up, thanks! (Not a JDK reviewer) ------------- Marked as reviewed by fjiang (Author). PR: https://git.openjdk.org/jdk/pull/10210 From stefank at openjdk.org Thu Sep 8 08:42:30 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 Sep 2022 08:42:30 GMT Subject: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT [v2] In-Reply-To: References: Message-ID: > During the discussion of [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was voiced that we should stop using INTPTR_FORMAT when printing pointers. > > Some background that could explain why some tend to use INTPTR_FORMAT instead of PTR_FORMAT: > > Both those format specifiers require an integer and the compiler barfs if you send in a pointer. We therefore have a utility function named p2i, which converts the pointer to an integer. So, everywhere we have to write print line like this: `print("my pointer: " PTR_FORMAT, p2i(my_pointer));`. Now, p2i returns an intptr_t, and it becomes natural for some to consider the type of the converted value (that we need because of the mentioned workaround), instead of the original type of the value. > > With this enhancement I'd like to clean up the code that I often work in, so that it uses PTR_FORMAT when printing pointers. I'm leaving the rest of the code base for others to consider cleaning up. > > Cleanups have been done in directories gc/, utilities/, memory/, and oops/. Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Remove redundant casts - More conversions - Merge remote-tracking branch 'upstream/master' into 8293304_replace_intptr_format - Fix oops/ - Fix memory/ - Fix utilities/ - Fix gc/ - Add SIZE_FORMAT_X_0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10141/files - new: https://git.openjdk.org/jdk/pull/10141/files/e3d8f643..153b0f24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10141&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10141&range=00-01 Stats: 45757 lines in 300 files changed: 22272 ins; 19201 del; 4284 mod Patch: https://git.openjdk.org/jdk/pull/10141.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10141/head:pull/10141 PR: https://git.openjdk.org/jdk/pull/10141 From stefank at openjdk.org Thu Sep 8 08:46:40 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 Sep 2022 08:46:40 GMT Subject: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT [v2] In-Reply-To: <0Nhq3dcg-Z0G4AYgpcHDGa4xMDHSSBC97eGtKmiw_bY=.934c0f0c-7c1a-4f90-9cce-91bcf0c2ac00@github.com> References: <0Nhq3dcg-Z0G4AYgpcHDGa4xMDHSSBC97eGtKmiw_bY=.934c0f0c-7c1a-4f90-9cce-91bcf0c2ac00@github.com> Message-ID: On Wed, 7 Sep 2022 22:06:11 GMT, Kim Barrett wrote: > Looks good. Thanks. > Also noticed some pre-existing unnecessary (void*) casts of the pointer argument to p2i. Not your problem, and not really appropriate for this change to do anything about them, but I really hate eye-catching cast junk like that. I agree. I cleaned out some of that. There's a lot of casts from `oop` to `void*` that are unnecessary after we rewrote the fastdebug oop class and/or `p2i`. > > There were also a few INTPTR_FORMAT uses that were left in place. All that I recall looked like they could/should instead be SIZE_FORMAT_X_0 or maybe even SIZE_FORMAT_X if the zero padding isn't useful. Leaving those for a later pass seems fine. I wonder how many INTPTR_FORMATs are left in the areas you worked on? I saw a lot of intptr_t/uintptr_t being printed with INTPRT_FORMAT, I don't think those should be changed to use SIZE_FORMAT_. I found and converted three more lingering INTPTR_FORMAT usages. We are now down to a little bit less then 30 usages of INTPTR_FORMAT in the directories relevant to this PR. Most in: g1HeapRegionAttr.hpp to print an index elfFile.hpp to print a integer typed address markWord.cpp to print the mark word stackChunk/instanceStackChunk files to print relative stack pointers ------------- PR: https://git.openjdk.org/jdk/pull/10141 From aboldtch at openjdk.org Thu Sep 8 09:02:51 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 8 Sep 2022 09:02:51 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v5] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 12:06:38 GMT, Axel Boldt-Christmas wrote: >> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. >> >> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. >> >> Testing: Oracle platforms tier 1-3 > > Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: > > - Push r10 using push and pop > - Fix Argument Comments @shqking @stooart-mon Your feedback have been addressed with code changes. Is there anything more you would like to add? @tschatzl @theRealAph @RealFYang The only change since your approval has been to change comments and argument names, as well as changed from `stp/ldp` to `push/pop` with `RegSet` for correctness. ------------- PR: https://git.openjdk.org/jdk/pull/10161 From aph at openjdk.org Thu Sep 8 09:22:46 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 8 Sep 2022 09:22:46 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v5] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 12:06:38 GMT, Axel Boldt-Christmas wrote: >> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. >> >> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. >> >> Testing: Oracle platforms tier 1-3 > > Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: > > - Push r10 using push and pop > - Fix Argument Comments Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10161 From rehn at openjdk.org Thu Sep 8 09:44:44 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 8 Sep 2022 09:44:44 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v2] In-Reply-To: References: Message-ID: > Please consider, only implemented on x64/aarch64 linux/windows. > > On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. > > Passes t1-7 with option forced on, also passes t1-4 as is in this PR. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Change header and constants handling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10123/files - new: https://git.openjdk.org/jdk/pull/10123/files/a270b0ff..7d5f26fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10123&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10123&range=00-01 Stats: 29 lines in 3 files changed: 6 ins; 19 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10123.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10123/head:pull/10123 PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Thu Sep 8 09:55:38 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 8 Sep 2022 09:55:38 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v2] In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 09:44:44 GMT, Robbin Ehn wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Change header and constants handling There is problem using AC_CHECK_DECL during cross-compiles, so I had to remove that until that is fixed. For now the enum value is hardcoded, it is the same on all platforms. Regarding the defines, it seems like it's only us that needs it for some x64 builds. If someone else needs it, they can just add it. Since that you not really happen, I this approach is fine? So now the membarrier is working on all Linux platforms. (but obviously local membarrier must be conditioned for any performance benefits) ------------- PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Thu Sep 8 09:55:42 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 8 Sep 2022 09:55:42 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v2] In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 13:36:31 GMT, Martin Doerr wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Change header and constants handling > > src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 36: > >> 34: // Syscall defined in kernel 4.3 >> 35: #if !defined(SYS_membarrier) >> 36: #define SYS_membarrier 324 > > I'd like to get rid of the platform checks in this generic linux file. > This number seems to be the only platform specific part: @TheRealMDoerr please have another look :) ------------- PR: https://git.openjdk.org/jdk/pull/10123 From mdoerr at openjdk.org Thu Sep 8 12:12:47 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 8 Sep 2022 12:12:47 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v2] In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 09:44:44 GMT, Robbin Ehn wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Change header and constants handling We need to support older kernel versions on PPC64 as well. And let's just make it usable on PPC64. Improves performance of trivial native calls by about 20%. diff --git a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp index 5a55d8f4dc2..0902c0f35ed 100644 --- a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp +++ b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp @@ -2147,7 +2147,9 @@ nmethod *SharedRuntime::generate_native_wrapper(MacroAssembler *masm, Label no_block, sync; // Force this write out before the read below. - __ fence(); + if (!UseSystemMemoryBarrier) { + __ fence(); + } Register sync_state_addr = r_temp_4; Register sync_state = r_temp_5; diff --git a/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp b/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp index bd4e1ce9932..260d99bef81 100644 --- a/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp +++ b/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp @@ -1436,7 +1436,9 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) { __ li(R0/*thread_state*/, _thread_in_native_trans); __ release(); __ stw(R0/*thread_state*/, thread_(thread_state)); - __ fence(); + if (!UseSystemMemoryBarrier) { + __ fence(); + } // Now before we return to java we must look for a current safepoint // (a new safepoint can not start since we entered native_trans). diff --git a/src/hotspot/os/linux/systemMemoryBarrier_linux.cpp b/src/hotspot/os/linux/systemMemoryBarrier_linux.cpp index 796b596c675..66f77818ebc 100644 --- a/src/hotspot/os/linux/systemMemoryBarrier_linux.cpp +++ b/src/hotspot/os/linux/systemMemoryBarrier_linux.cpp @@ -35,6 +35,8 @@ #ifndef SYS_membarrier #if defined(AMD64) #define SYS_membarrier 324 + #elif defined(PPC64) + #define SYS_membarrier 365 #else #error define SYS_membarrier for the arch #endif Btw. are spaces in front of `#` ok? Some old preprocessors might have problems with that. ------------- Changes requested by mdoerr (Reviewer). PR: https://git.openjdk.org/jdk/pull/10123 From coleenp at openjdk.org Thu Sep 8 12:32:42 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 8 Sep 2022 12:32:42 GMT Subject: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT [v2] In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 08:42:30 GMT, Stefan Karlsson wrote: >> During the discussion of [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was voiced that we should stop using INTPTR_FORMAT when printing pointers. >> >> Some background that could explain why some tend to use INTPTR_FORMAT instead of PTR_FORMAT: >> >> Both those format specifiers require an integer and the compiler barfs if you send in a pointer. We therefore have a utility function named p2i, which converts the pointer to an integer. So, everywhere we have to write print line like this: `print("my pointer: " PTR_FORMAT, p2i(my_pointer));`. Now, p2i returns an intptr_t, and it becomes natural for some to consider the type of the converted value (that we need because of the mentioned workaround), instead of the original type of the value. >> >> With this enhancement I'd like to clean up the code that I often work in, so that it uses PTR_FORMAT when printing pointers. I'm leaving the rest of the code base for others to consider cleaning up. >> >> Cleanups have been done in directories gc/, utilities/, memory/, and oops/. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Remove redundant casts > - More conversions > - Merge remote-tracking branch 'upstream/master' into 8293304_replace_intptr_format > - Fix oops/ > - Fix memory/ > - Fix utilities/ > - Fix gc/ > - Add SIZE_FORMAT_X_0 Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10141 From ayang at openjdk.org Thu Sep 8 13:39:05 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 8 Sep 2022 13:39:05 GMT Subject: RFR: 8293544: G1: Add comment in G1BarrierSetC1::pre_barrier Message-ID: A comment-only change in G1 pre-barrier to explain the redundant is-marking-active check. ------------- Commit messages: - g1-c1-comment Changes: https://git.openjdk.org/jdk/pull/10219/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10219&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293544 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10219.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10219/head:pull/10219 PR: https://git.openjdk.org/jdk/pull/10219 From stefank at openjdk.org Thu Sep 8 13:39:48 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 Sep 2022 13:39:48 GMT Subject: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT [v2] In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 08:42:30 GMT, Stefan Karlsson wrote: >> During the discussion of [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was voiced that we should stop using INTPTR_FORMAT when printing pointers. >> >> Some background that could explain why some tend to use INTPTR_FORMAT instead of PTR_FORMAT: >> >> Both those format specifiers require an integer and the compiler barfs if you send in a pointer. We therefore have a utility function named p2i, which converts the pointer to an integer. So, everywhere we have to write print line like this: `print("my pointer: " PTR_FORMAT, p2i(my_pointer));`. Now, p2i returns an intptr_t, and it becomes natural for some to consider the type of the converted value (that we need because of the mentioned workaround), instead of the original type of the value. >> >> With this enhancement I'd like to clean up the code that I often work in, so that it uses PTR_FORMAT when printing pointers. I'm leaving the rest of the code base for others to consider cleaning up. >> >> Cleanups have been done in directories gc/, utilities/, memory/, and oops/. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Remove redundant casts > - More conversions > - Merge remote-tracking branch 'upstream/master' into 8293304_replace_intptr_format > - Fix oops/ > - Fix memory/ > - Fix utilities/ > - Fix gc/ > - Add SIZE_FORMAT_X_0 Thanks for reviewing! ------------- PR: https://git.openjdk.org/jdk/pull/10141 From stefank at openjdk.org Thu Sep 8 13:39:49 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 Sep 2022 13:39:49 GMT Subject: Integrated: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 09:51:06 GMT, Stefan Karlsson wrote: > During the discussion of [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was voiced that we should stop using INTPTR_FORMAT when printing pointers. > > Some background that could explain why some tend to use INTPTR_FORMAT instead of PTR_FORMAT: > > Both those format specifiers require an integer and the compiler barfs if you send in a pointer. We therefore have a utility function named p2i, which converts the pointer to an integer. So, everywhere we have to write print line like this: `print("my pointer: " PTR_FORMAT, p2i(my_pointer));`. Now, p2i returns an intptr_t, and it becomes natural for some to consider the type of the converted value (that we need because of the mentioned workaround), instead of the original type of the value. > > With this enhancement I'd like to clean up the code that I often work in, so that it uses PTR_FORMAT when printing pointers. I'm leaving the rest of the code base for others to consider cleaning up. > > Cleanups have been done in directories gc/, utilities/, memory/, and oops/. This pull request has now been integrated. Changeset: 6bd27941 Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/6bd2794175bac3c221d9b514bea01b0faa7af4a6 Stats: 137 lines in 41 files changed: 6 ins; 0 del; 131 mod 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT Reviewed-by: kbarrett, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/10141 From stuefe at openjdk.org Thu Sep 8 16:16:36 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 8 Sep 2022 16:16:36 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v5] In-Reply-To: References: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com> Message-ID: On Wed, 7 Sep 2022 09:09:52 GMT, Johan Sj?l?n wrote: > >To be clear, you will only ever get a null if someone passes it in explicitly as Thread::current_or_null() should never be able to return null in the contexts you would use this RWL. > > > > Context: UL uses static initialization for LogTagSets, these use the RWLock and as such our thread system isn't initialized yet. It's not strictly necessary, as we can re-write things to not require this. > > > > Edit: Perhaps the right decision is to simply delay the initialization of LogTagSets. The early initialization of UL at lib load time is certainly a pain. But there are other things too, other code running before initialisation, and then there is the case of non-attached threads and signal handling, etc. I would be happy if this primitive was usable with Thread.current == Null. Otherwise you limit the future usefulness, and whatever code people use this lock in will also not be usable in these corner cases. If it does not cost too much complexity. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From vlivanov at openjdk.org Thu Sep 8 16:54:17 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 8 Sep 2022 16:54:17 GMT Subject: RFR: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files [v5] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 22:39:28 GMT, Vladimir Ivanov wrote: >> Move code related to AES and GHASH stubs from `stubGenerator_x86_64.cpp` into `stubGenerator_x86_64_aes.cpp` and `stubGenerator_x86_64_ghash.cpp` respectively. >> >> Testing: hs-tier1 - hs-tier4 > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > include Thanks for the reviews, Vladimir and Tobias. ------------- PR: https://git.openjdk.org/jdk/pull/10124 From vlivanov at openjdk.org Thu Sep 8 16:54:18 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 8 Sep 2022 16:54:18 GMT Subject: Integrated: 8293230: x86_64: Move AES and GHASH stub definitions into separate source files In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 17:11:20 GMT, Vladimir Ivanov wrote: > Move code related to AES and GHASH stubs from `stubGenerator_x86_64.cpp` into `stubGenerator_x86_64_aes.cpp` and `stubGenerator_x86_64_ghash.cpp` respectively. > > Testing: hs-tier1 - hs-tier4 This pull request has now been integrated. Changeset: 30d4145e Author: Vladimir Ivanov URL: https://git.openjdk.org/jdk/commit/30d4145e2edd2d3e4cbaa8b01f7639ab53bc0991 Stats: 7521 lines in 6 files changed: 3779 ins; 3721 del; 21 mod 8293230: x86_64: Move AES and GHASH stub definitions into separate source files Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/jdk/pull/10124 From vlivanov at openjdk.org Thu Sep 8 17:25:05 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 8 Sep 2022 17:25:05 GMT Subject: RFR: 8293329: x86: Improve handling of constants in AES/GHASH stubs [v4] In-Reply-To: References: Message-ID: > Pre-generating constants saves on startup and static/dynamic footprint a bit, plus simplifies bootstrapping logic. > > As a downside, constants aren't guaranteed to be always reachable anymore, but since they are used from stubs, finding a scratch register when needed is not a problem. > > Testing: > - [x] hs-tier1 - hs-tier4 w/ `-XX:+ForceUnreachable` > - [x] x86_32 build Vladimir Ivanov 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 stub.x86_64.aes.consts - Merge branch 'stub.x86_64.aes' into stub.x86_64.aes.consts - include - Merge branch 'stub.x86_64.aes' into stub.x86_64.aes.consts - Merge branch 'master' into stub.x86_64.aes - constants - Merge branch 'master' into stub.x86_64.aes - AESBlockSize - update - Refactor AES and GHASH stubs. - ... and 3 more: https://git.openjdk.org/jdk/compare/30d4145e...a603f29e ------------- Changes: https://git.openjdk.org/jdk/pull/10152/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10152&range=03 Stats: 508 lines in 6 files changed: 151 ins; 233 del; 124 mod Patch: https://git.openjdk.org/jdk/pull/10152.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10152/head:pull/10152 PR: https://git.openjdk.org/jdk/pull/10152 From rehn at openjdk.org Thu Sep 8 18:13:56 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 8 Sep 2022 18:13:56 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v3] In-Reply-To: References: Message-ID: > Please consider, only implemented on x64/aarch64 linux/windows. > > On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. > > Passes t1-7 with option forced on, also passes t1-4 as is in this PR. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: PPC64 port courtesy Martin Doerr ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10123/files - new: https://git.openjdk.org/jdk/pull/10123/files/7d5f26fd..c33d5414 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10123&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10123&range=01-02 Stats: 8 lines in 3 files changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10123.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10123/head:pull/10123 PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Thu Sep 8 18:13:56 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 8 Sep 2022 18:13:56 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v2] In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 12:10:34 GMT, Martin Doerr wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Change header and constants handling > > We need to support older kernel versions on PPC64 as well. And let's just make it usable on PPC64. Improves performance of trivial native calls by about 20%. > > diff --git a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp > index 5a55d8f4dc2..0902c0f35ed 100644 > --- a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp > +++ b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp > @@ -2147,7 +2147,9 @@ nmethod *SharedRuntime::generate_native_wrapper(MacroAssembler *masm, > Label no_block, sync; > > // Force this write out before the read below. > - __ fence(); > + if (!UseSystemMemoryBarrier) { > + __ fence(); > + } > > Register sync_state_addr = r_temp_4; > Register sync_state = r_temp_5; > diff --git a/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp b/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp > index bd4e1ce9932..260d99bef81 100644 > --- a/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp > +++ b/src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp > @@ -1436,7 +1436,9 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) { > __ li(R0/*thread_state*/, _thread_in_native_trans); > __ release(); > __ stw(R0/*thread_state*/, thread_(thread_state)); > - __ fence(); > + if (!UseSystemMemoryBarrier) { > + __ fence(); > + } > > // Now before we return to java we must look for a current safepoint > // (a new safepoint can not start since we entered native_trans). > diff --git a/src/hotspot/os/linux/systemMemoryBarrier_linux.cpp b/src/hotspot/os/linux/systemMemoryBarrier_linux.cpp > index 796b596c675..66f77818ebc 100644 > --- a/src/hotspot/os/linux/systemMemoryBarrier_linux.cpp > +++ b/src/hotspot/os/linux/systemMemoryBarrier_linux.cpp > @@ -35,6 +35,8 @@ > #ifndef SYS_membarrier > #if defined(AMD64) > #define SYS_membarrier 324 > + #elif defined(PPC64) > + #define SYS_membarrier 365 > #else > #error define SYS_membarrier for the arch > #endif > > Btw. are spaces in front of `#` ok? Some old preprocessors might have problems with that. @TheRealMDoerr thanks, applied. Do you want to be a reviewer or contributor? Regarding space: On Linux we had it for long time I think, see https://github.com/openjdk/jdk/blob/30d4145e2edd2d3e4cbaa8b01f7639ab53bc0991/src/hotspot/os/linux/os_linux.cpp#L306 ------------- PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Thu Sep 8 18:15:17 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 8 Sep 2022 18:15:17 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v3] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 17:49:59 GMT, Erik Joelsson wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> PPC64 port courtesy Martin Doerr > > Build changes look good. @erikj79 I had to remove the ac changes, so there is now no builds changes. We should probably remove you as reviewer, if you don't want to review the rest? :) ------------- PR: https://git.openjdk.org/jdk/pull/10123 From duke at openjdk.org Thu Sep 8 18:27:48 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Thu, 8 Sep 2022 18:27:48 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v5] In-Reply-To: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com> References: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com> Message-ID: On Mon, 29 Aug 2022 08:47:31 GMT, Johan Sj?l?n wrote: >> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? >> >> This PR does 3 things: >> >> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot >> * Adds some new utilities for writing multi-threaded tests. >> * Adds some tests for MRSW Mutex using these new utilities >> >> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 >> >> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Review comments People want: 1. Nullable threads 2. PlatformMonitor 3. Monitor 3. won't work with 1., as it requires a `Thread` thread, so that will require two different ReadWriteLocks (or method impls). When we pick 3. we also have to make a decision on whether to support waiting without safepoints or not, making the behavior of ReadWriteLock a bit more complicated and perhaps opaque. Developers reading the code using this lock should preferably know what it does and what the implications are of using it. The right answer is probably to make a `PlatformReadWriteLock` and a `ReadWriteLock`, going with convention here. So there are a lot of different choices to be made here. On top of that we have the actual implementation, whose issues are yet to be revealed to us. I'd like to quote David Holmes here: >Whether this RWL implementation will turn out to be useful for any existing subsystems without exhibiting performance pathologies or bad interactions with existing synchronization code is just something we will have to see. However, as we tend not to encourage unused code it would perhaps be better to delay integration of this until there is an *actual usecase ready for it*. I have a use case for this in UL. This is the use case which I will develop this patch towards. If new use cases arises, then patches can be made to this code to supply more use cases. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From erikj at openjdk.org Thu Sep 8 19:36:38 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 8 Sep 2022 19:36:38 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v3] In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 18:13:56 GMT, Robbin Ehn wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > PPC64 port courtesy Martin Doerr Ok I'm retracting my review. ------------- PR: https://git.openjdk.org/jdk/pull/10123 From mdoerr at openjdk.org Thu Sep 8 23:32:44 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 8 Sep 2022 23:32:44 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v3] In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 18:13:56 GMT, Robbin Ehn wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > PPC64 port courtesy Martin Doerr Thanks for integrating my PPC64 implementation. I prefer serving as reviewer. My contribution was rather small. The implementation LGTM. However, the test should pass in case of `MEMBARRIER_CMD_QUERY unsupported`. Note: I believe the test should also work in product builds when adding `commands.add("-XX:+UnlockDiagnosticVMOptions");`, but I don't insist on that. I leave you free to decide. ------------- Changes requested by mdoerr (Reviewer). PR: https://git.openjdk.org/jdk/pull/10123 From fyang at openjdk.org Fri Sep 9 00:19:48 2022 From: fyang at openjdk.org (Fei Yang) Date: Fri, 9 Sep 2022 00:19:48 GMT Subject: RFR: 8293524: RISC-V: Use macro-assembler functions as appropriate In-Reply-To: <2yxPwlehWfNYflxKSv56dY9JAUZQFUTXIUGIW4tqZNk=.d41a9b56-3862-42b2-bcc1-75c4cd077484@github.com> References: <2yxPwlehWfNYflxKSv56dY9JAUZQFUTXIUGIW4tqZNk=.d41a9b56-3862-42b2-bcc1-75c4cd077484@github.com> Message-ID: On Thu, 8 Sep 2022 06:16:29 GMT, Aleksey Shipilev wrote: >> Use of assember functions on riscv can be improved. For example, we use 'fence(0xf, 0xf)' in function TemplateInterpreterGenerator::generate_safept_entry_for to emit a full memory fence instruction. Here we should use 'membar(MacroAssembler::AnyAny)' instead, which would make the code more readable. This also replace some calls to 'li' with 'mv' so that it will be more consistent when moving integer constant. >> >> Testing: Tier1 tested on Linux-riscv64 SiFive Unmatched board. > > Marked as reviewed by shade (Reviewer). @shipilev @feilongjiang : Thanks for reviewing this. ------------- PR: https://git.openjdk.org/jdk/pull/10210 From fyang at openjdk.org Fri Sep 9 00:22:46 2022 From: fyang at openjdk.org (Fei Yang) Date: Fri, 9 Sep 2022 00:22:46 GMT Subject: Integrated: 8293524: RISC-V: Use macro-assembler functions as appropriate In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 03:20:41 GMT, Fei Yang wrote: > Use of assember functions on riscv can be improved. For example, we use 'fence(0xf, 0xf)' in function TemplateInterpreterGenerator::generate_safept_entry_for to emit a full memory fence instruction. Here we should use 'membar(MacroAssembler::AnyAny)' instead, which would make the code more readable. This also replace some calls to 'li' with 'mv' so that it will be more consistent when moving integer constant. > > Testing: Tier1 tested on Linux-riscv64 SiFive Unmatched board. This pull request has now been integrated. Changeset: 43e191d6 Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/43e191d64b0094cc1ece61929c32e017ee90c0c8 Stats: 78 lines in 13 files changed: 0 ins; 0 del; 78 mod 8293524: RISC-V: Use macro-assembler functions as appropriate Reviewed-by: shade, fjiang ------------- PR: https://git.openjdk.org/jdk/pull/10210 From vlivanov at openjdk.org Fri Sep 9 00:35:47 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 9 Sep 2022 00:35:47 GMT Subject: RFR: 8293329: x86: Improve handling of constants in AES/GHASH stubs [v5] In-Reply-To: References: Message-ID: > Pre-generating constants saves on startup and static/dynamic footprint a bit, plus simplifies bootstrapping logic. > > As a downside, constants aren't guaranteed to be always reachable anymore, but since they are used from stubs, finding a scratch register when needed is not a problem. > > Testing: > - [x] hs-tier1 - hs-tier4 w/ `-XX:+ForceUnreachable` > - [x] x86_32 build Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: fix merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10152/files - new: https://git.openjdk.org/jdk/pull/10152/files/a603f29e..7b465177 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10152&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10152&range=03-04 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10152.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10152/head:pull/10152 PR: https://git.openjdk.org/jdk/pull/10152 From vlivanov at openjdk.org Fri Sep 9 00:44:39 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 9 Sep 2022 00:44:39 GMT Subject: RFR: 8293329: x86: Improve handling of constants in AES/GHASH stubs [v5] In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 00:51:56 GMT, Vladimir Kozlov wrote: > I would like to see the effect on performance. In worst case constants will not be reachable always. Changes are fine if the effect is negligible. I ran AES microbenchmarks and didn't notice any noticeable difference between baseline and the patched version w/ `-XX:+ForceUnreachable` in throughput. ------------- PR: https://git.openjdk.org/jdk/pull/10152 From dlong at openjdk.org Fri Sep 9 01:33:02 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 9 Sep 2022 01:33:02 GMT Subject: RFR: 8293287 add ReplayReduce flag [v4] In-Reply-To: References: Message-ID: > Add an experimental flag to help developers "reduce" a replay file. > > As a first step, I plan to simulate reduced inlining. This will output multiple "compile" lines as if the first level of inlining never happened: > A --> B --> C > A --> D --> E > becomes > B --> C > D --> E > Developers can repeat iteratively until the replay crash no longer reproduces. Dean Long has updated the pull request incrementally with one additional commit since the last revision: fix typo Co-authored-by: Tobias Hartmann ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10134/files - new: https://git.openjdk.org/jdk/pull/10134/files/4ba53b45..d0340273 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10134&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10134&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10134.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10134/head:pull/10134 PR: https://git.openjdk.org/jdk/pull/10134 From dlong at openjdk.org Fri Sep 9 01:35:27 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 9 Sep 2022 01:35:27 GMT Subject: RFR: 8293287 add ReplayReduce flag [v3] In-Reply-To: References: Message-ID: <_7XcIch4uVJEa9WB_lUm3Yc3gJPQEAmQ6FNMwTVLHKo=.2b5aa570-199f-4cf8-8272-51bd4f7326f7@github.com> On Thu, 8 Sep 2022 07:46:23 GMT, Tobias Hartmann wrote: > I'm wondering if this functionality should really be part of the VM. Wouldn't a simple script that regex-parses the compile statement of the replay file, iteratively removes inlines and runs replay compilation to check if the issue still reproduces, be more powerful and easier to maintain? It could be combined with also removing class loading statements. Writing a script was my first attempt, but getting the parsing right would have taken more time than I wanted to invest, so I did what was quickest and easiest. I found it useful, so I thought checking it in might be useful to others, considering the code changes are small. One problem with an external script is that replay won't normally create a new replay file if -XX:+ReplayCompiles is on. So, some kind of JVM change is required. ------------- PR: https://git.openjdk.org/jdk/pull/10134 From kbarrett at openjdk.org Fri Sep 9 02:59:39 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 9 Sep 2022 02:59:39 GMT Subject: RFR: 8293544: G1: Add comment in G1BarrierSetC1::pre_barrier In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 13:30:58 GMT, Albert Mingkun Yang wrote: > A comment-only change in G1 pre-barrier to explain the redundant is-marking-active check. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/10219 From stuefe at openjdk.org Fri Sep 9 05:40:42 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 9 Sep 2022 05:40:42 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v5] In-Reply-To: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com> References: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com> Message-ID: <6mmC3ErQQCYIn3nhBfSlyq412H7ciZv1qgZsGViuTsQ=.fff7d776-7dc0-4736-9f8a-edb36dfb34a7@github.com> On Mon, 29 Aug 2022 08:47:31 GMT, Johan Sj?l?n wrote: >> May I please have a review for this PR which implements a `MRWMutex` class for Hotspot? >> >> This PR does 3 things: >> >> * Adds a port of ZGC's MRSW mutex (see [0]) to Hotspot >> * Adds some new utilities for writing multi-threaded tests. >> * Adds some tests for MRSW Mutex using these new utilities >> >> The ticket has some comments which might be worth checking out: https://bugs.openjdk.org/browse/JDK-8291714 >> >> [0] Original source code here: https://github.com/openjdk/zgc/blob/zgc_generational/src/hotspot/share/gc/z/zJNICritical.cpp > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Review comments > People want: > > 1. Nullable threads > 2. PlatformMonitor > 3. Monitor > 4. won't work with 1., as it requires a `Thread` thread, so that will require two different ReadWriteLocks (or method impls). > > When we pick 3. we also have to make a decision on whether to support waiting without safepoints or not, making the behavior of ReadWriteLock a bit more complicated and perhaps opaque. Developers reading the code using this lock should preferably know what it does and what the implications are of using it. > > The right answer is probably to make a `PlatformReadWriteLock` and a `ReadWriteLock`, going with convention here. > > So there are a lot of different choices to be made here. On top of that we have the actual implementation, whose issues are yet to be revealed to us. > > I'd like to quote David Holmes here: > > > Whether this RWL implementation will turn out to be useful for any existing subsystems without exhibiting performance pathologies or bad interactions with existing synchronization code is just something we will have to see. However, as we tend not to encourage unused code it would perhaps be better to delay integration of this until there is an _actual usecase ready for it_. > > I have a use case for this in UL. This is the use case which I will develop this patch towards. If new use cases arises, then patches can be made to this code to supply more use cases. My use case is for the NMT malloc site table, which gives us the same restrictions as UL (being pre-init-able). Note that even if you move UL initialization up, UL should still work without Thread==NULL in my opinion, since logging is one of the things that should work ideally always. BTW, I am trying to get this: https://github.com/openjdk/jdk/pull/10178 into JDK, which may give you an easy option to test the mark with Thread==NULL in gtests. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From sjohanss at openjdk.org Fri Sep 9 05:59:36 2022 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 9 Sep 2022 05:59:36 GMT Subject: RFR: 8293544: G1: Add comment in G1BarrierSetC1::pre_barrier In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 13:30:58 GMT, Albert Mingkun Yang wrote: > A comment-only change in G1 pre-barrier to explain the redundant is-marking-active check. Looks good. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.org/jdk/pull/10219 From aboldtch at openjdk.org Fri Sep 9 06:53:33 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 9 Sep 2022 06:53:33 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v9] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 08:35:58 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. >> >> _Update_ >> --- >> Testing after 11d9dd2: Oracle platforms tier 1-5 > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: > > - Merge remote-tracking branch 'upstream/master' into JDK-8291237 > - Add asserts and comments > - Merge remote-tracking branch 'upstream/master' into JDK-8291237 > - Add context active assert > - Cleanup comment > - Add list optimization > - Merge remote-tracking branch 'upstream/master' into JDK-8291237 > - Rename deoptimize_done enum value > - Add missing code from list revert > - Initial draft new terminology > - ... and 19 more: https://git.openjdk.org/jdk/compare/512fee1d...c35f5ed6 Just an update and a call for reviews. [JDK-8290025](https://bugs.openjdk.org/browse/JDK-8290025) / #9741 was merged in 030ed7e which makes this change easier to reson about as the lifetime of nmethods are simpler. The merge was tested on oracle platforms tier 1-5. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From rehn at openjdk.org Fri Sep 9 07:27:43 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 9 Sep 2022 07:27:43 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v4] In-Reply-To: References: Message-ID: > Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) > > On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. > > Passes t1-7 with option forced on, also passes t1-4 as is in this PR. Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into membar - Test fixes - PPC64 port courtesy Martin Doerr - Change header and constants handling - 8292591 - initial ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10123/files - new: https://git.openjdk.org/jdk/pull/10123/files/c33d5414..6b6ad161 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10123&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10123&range=02-03 Stats: 62884 lines in 744 files changed: 29519 ins; 29036 del; 4329 mod Patch: https://git.openjdk.org/jdk/pull/10123.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10123/head:pull/10123 PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Fri Sep 9 07:27:46 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 9 Sep 2022 07:27:46 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v3] In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 18:13:56 GMT, Robbin Ehn wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > PPC64 port courtesy Martin Doerr Great, thanks! Updated test, running a t1-2 on it. ------------- PR: https://git.openjdk.org/jdk/pull/10123 From fjiang at openjdk.org Fri Sep 9 08:39:41 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Fri, 9 Sep 2022 08:39:41 GMT Subject: RFR: 8293566: RISC-V: Clean up push and pop registers Message-ID: Currently, riscv port has two implementations of `push_reg` and `pop_reg`. The bitset version can be replaced with the RegSet version for better readability. For example, if we want to push x10 and x11, pushing register with bitset would be like: push_reg(0xc00, sp) while pushing register with RegSet will be more clear: push_reg(RegSet::of(x10, x11), sp); So we decide to remove the bitset version of push and pop registers. Testing: - hotspot and jdk ter1 on QEMU without new failures ------------- Commit messages: - clean up push and pop registers Changes: https://git.openjdk.org/jdk/pull/10227/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10227&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293566 Stats: 68 lines in 4 files changed: 0 ins; 32 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/10227.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10227/head:pull/10227 PR: https://git.openjdk.org/jdk/pull/10227 From aph-open at littlepinkcloud.com Fri Sep 9 09:24:32 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 9 Sep 2022 10:24:32 +0100 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> Message-ID: On 9/8/22 08:50, Kim Barrett wrote: >> On Sep 7, 2022, at 5:30 AM, Andrew Haley wrote: >> >> On 9/7/22 05:41, Kim Barrett wrote: >>> I?m puzzled by this change: >>> https://bugs.openjdk.org/browse/JDK-8282322 ... > >>> For jdk20+ (where 8282322 landed), I question whether the approach being taken >>> here really makes sense. If one is willing to assume a relatively recent >>> version of gcc is being used, then I think there is no reason to reimplement >>> the effect of -moutline-atomics. We could undo all three of those changes, >>> reverting back to using gcc __atomic intrinsics, and rely on -moutline-atomics >>> (explicitly requested for gcc8/9). In that case, nothing like 8282322 is >>> needed; just specify armv8.1-a or later when configuring the build (which is >>> already needed to activate the current 8282322 behavior) and LSE will be used, >>> regardless of -moutline-atomics (or if it is even supported, if you want to >>> use rr with an old gcc version). >>> >>> That would be a lot simpler. It also makes it easier to make further changes. >> True. It all feels a bit early to me, though. I don't think that OpenJDK has ever >> needed so recent compiler features before. We've always been very conservative >> about what we depend on. So it might be OK to do this, but (to me) it feels >> like sailing close to the wind. > > We (Oracle) used to be extremely conservative about toolchain upgrades, but we > got better. (Thank you, spectre and meltdown.) I admit my opinion is colored > by that, and the benefits from it. OK, so we have, in effect, a change of policy. That does make sense. > Note that OpenJDK recently dropped support for Visual Studio 2017, now > requiring some patch level of VS2019. That's a stronger restriction in a > similar timeframe. (The dropped versions of VS cannot build the latest JDK.) > > Unlike that situation with VS, switching linux-aarch64 back to using __atomic > intrinsics would still work if using an old toolchain, but possibly at reduced > performance on spiffy new hardware. And I'm only proposing this going forward; > backports need not apply. Don't under-estimate the effect of using LL/SC on some Arm hardware. In some cases it's so bad that it looks almost like the implementation is broken. Another thing to bear in mind is that we have some reports of relatively poor LSE performance on larger Huawei systems, so the mere presence of LSE atomics does not always tell us we should use them. We have a switch. As far as I can tell, outline-atomics doesn't support switching LSE off, but maybe some systems have local patches. [https://people.mpi-sws.org/~viktor/papers/netys2021-hmcs.pdf] Disclaimer: I haven't tested if this is true, and it might be out of date. > A benefit of such a change would be that if one knows what hardware is going > to be used, one can compile specifically for that and get best performance for > these operations for that hardware. I can easily imagine that being a common > scenario. The current approach actively prevents that. True, but the overhead is very low. It's two perfectly-predicted branches, about as near as you can get to zero in practice. Less overhead than outline-atomics. > How many folks are very conservative about gcc versions but not about JDK > versions? And should we be catering to them at the expense of folks who are > keeping up to date and willing to do tailored builds. That's an excellent question. I guess most Linux distros are now at 8.5, so perhaps there's no problem. >> I'm curious, though: wouldn't atomic bitset ops be based on CAS? If so, you don't >> need to care how CAS is implemented. > > We can write them as an Atomic::cmpxchg loop, just as we can write Atomic::add > that way. But that isn't a particularly good way to write them. It's a loop > over an ll/sc loop, or a loop over an LSE CAS instruction. Better is a direct > ll/sc loop or an LSE bitop instruction. Oh! Does LSE actually have the ops you need for this? So, if we revert to using the GCC intrinsics, we'd hurt performance on some systems, and we'd lose some control. On the other hand it'd be cleaner. Much cleaner. :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thartmann at openjdk.org Fri Sep 9 09:34:41 2022 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 9 Sep 2022 09:34:41 GMT Subject: RFR: 8293287 add ReplayReduce flag [v4] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 01:33:02 GMT, Dean Long wrote: >> Add an experimental flag to help developers "reduce" a replay file. >> >> As a first step, I plan to simulate reduced inlining. This will output multiple "compile" lines as if the first level of inlining never happened: >> A --> B --> C >> A --> D --> E >> becomes >> B --> C >> D --> E >> Developers can repeat iteratively until the replay crash no longer reproduces. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > fix typo > > Co-authored-by: Tobias Hartmann Okay, I'm fine with adding this functionality, if it's been helpful to you. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.org/jdk/pull/10134 From duke at openjdk.org Fri Sep 9 09:52:51 2022 From: duke at openjdk.org (hev) Date: Fri, 9 Sep 2022 09:52:51 GMT Subject: RFR: 8293416: ZGC: Set mark bit with unconditional atomic ops [v3] In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 08:15:28 GMT, hev wrote: >> **Summary** >> Support to set ZGC mark bit with unconditional atomic ops. >> >> **Motivation** >> ZGC currently modify mark-bitmap by a conditional atomic operation (cmpxchg). This way is not optimal, which will retry the loop when cmpxchg fails. >> >> **Description** >> First, This patch-set add an new unconditional atomic operation: Atomic::fetch_and_or, which is implemented in different ways for different CPU architectures: >> >> * Exclusive access: Non-nested loop >> >> >> retry: >> ll old_val, addr >> or new_val, old_val, set_val >> sc new_val, addr >> beq retry >> >> >> * Atomic access: One instruction >> >> >> ldset old_val, set_val, addr >> >> >> * Generic: Fallback to cmpxchg or use c++ __atomic_fetch_or >> >> **Testing** >> * jtreg tests >> * benchmark tests > > hev 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: > > - ZGC: Set mark bit with unconditional atomic ops > - BitMap: Set bit with unconditional atomic ops > - Atomic: Add bitset functions ## Micro Benchmark Benchmark: https://gist.github.com/heiher/6137c8df7038af1a4186994894f2eb2b ### How to run gcc -O3 -o bench atomic-flip-bit-bench.c -pthread perf stat ./bench cas perf stat ./bench amo ### Results Real time elapsed in seconds (Less is better) | CPU/Threads/Mode | Score 1 | Score 2 | Score 3 | Score 4 | Score 5 | Score 6 | |--------|--------|--------|--------|--------|--------|--------| | Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz | | 8-Thread CAS | 6.20 | 5.26 | 4.80 | 5.94 | 6.22 | 6.09 | | 8-Thread AMO | 1.20 | 1.30 | 1.13 | 1.33 | 1.32 | 1.17 | | HUAWEI Kunpeng 920 @ 2.60GHz | | 8-Thread CAS | 13.25 | 14.25 | 12.41 | 14.26 | 13.76 | 13.87 | | 8-Thread AMO | 4.78 | 4.70 | 5.02 | 5.05 | 5.16 | 4.77 | | 16-Thread CAS | 32.44 | 41.94 | 39.75 | 39.85 | 34.23 | 36.05 | | 16-Thread AMO | 9.03 | 8.98 | 9.30 | 9.63 | 9.19 | 9.38 | ------------- PR: https://git.openjdk.org/jdk/pull/10182 From mdoerr at openjdk.org Fri Sep 9 09:57:54 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 9 Sep 2022 09:57:54 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v4] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 07:27:43 GMT, Robbin Ehn wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into membar > - Test fixes > - PPC64 port courtesy Martin Doerr > - Change header and constants handling > - 8292591 - initial Thanks for the update! LGTM. I hope that no other platform with older linux kernel is still needed. src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 83: > 81: > 82: void LinuxSystemMemoryBarrier::emit() { > 83: int s = membarrier(MEMBARRIER_CMD_PRIVATE_EXPEDITED, 0, 0); Extra whitespace. Feel free to remove it. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Fri Sep 9 10:05:11 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 9 Sep 2022 10:05:11 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5] In-Reply-To: References: Message-ID: > Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) > > On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. > > Passes t1-7 with option forced on, also passes t1-4 as is in this PR. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Fixed ws ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10123/files - new: https://git.openjdk.org/jdk/pull/10123/files/6b6ad161..981a6cab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10123&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10123&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10123.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10123/head:pull/10123 PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Fri Sep 9 10:05:11 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 9 Sep 2022 10:05:11 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v4] In-Reply-To: References: Message-ID: <5ux-_sXaVTC4rI7me0JnL-Tfw5xavVYHnk5G3Tzh4RM=.da4941ba-4801-4939-9d0b-842e9e51d82f@github.com> On Fri, 9 Sep 2022 09:55:46 GMT, Martin Doerr wrote: > Thanks for the update! LGTM. I hope that no other platform with older linux kernel is still needed. Yes, thanks! > src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 83: > >> 81: >> 82: void LinuxSystemMemoryBarrier::emit() { >> 83: int s = membarrier(MEMBARRIER_CMD_PRIVATE_EXPEDITED, 0, 0); > > Extra whitespace. Feel free to remove it. Fixed thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10123 From ayang at openjdk.org Fri Sep 9 10:30:52 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 9 Sep 2022 10:30:52 GMT Subject: RFR: 8293416: ZGC: Set mark bit with unconditional atomic ops [v3] In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 08:15:28 GMT, hev wrote: >> **Summary** >> Support to set ZGC mark bit with unconditional atomic ops. >> >> **Motivation** >> ZGC currently modify mark-bitmap by a conditional atomic operation (cmpxchg). This way is not optimal, which will retry the loop when cmpxchg fails. >> >> **Description** >> First, This patch-set add an new unconditional atomic operation: Atomic::fetch_and_or, which is implemented in different ways for different CPU architectures: >> >> * Exclusive access: Non-nested loop >> >> >> retry: >> ll old_val, addr >> or new_val, old_val, set_val >> sc new_val, addr >> beq retry >> >> >> * Atomic access: One instruction >> >> >> ldset old_val, set_val, addr >> >> >> * Generic: Fallback to cmpxchg or use c++ __atomic_fetch_or >> >> **Testing** >> * jtreg tests >> * benchmark tests > > hev 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: > > - ZGC: Set mark bit with unconditional atomic ops > - BitMap: Set bit with unconditional atomic ops > - Atomic: Add bitset functions src/hotspot/share/gc/z/zBitMap.inline.hpp line 67: > 65: inc_live = false; > 66: return false; > 67: } The fast/slow paths are almost identical. I believe some numbers would be nice to justify the presence of the fast path. ------------- PR: https://git.openjdk.org/jdk/pull/10182 From eosterlund at openjdk.org Fri Sep 9 10:50:00 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 9 Sep 2022 10:50:00 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 10:05:11 GMT, Robbin Ehn wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed ws Marked as reviewed by eosterlund (Reviewer). This looks good to me. I looked through the code to see if I can find any additional thread state filtering that would now require the system memory barrier to work reliably, but could not find any. So it would seem that you found them all. ------------- PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Fri Sep 9 10:50:01 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 9 Sep 2022 10:50:01 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5] In-Reply-To: References: Message-ID: <2ufKWpdQr0K3sYIqM1a3NXCGU1y7za4tesEmJzD8HAM=.9d0a9d3d-acb8-4516-aabc-c615c2533ea1@github.com> On Fri, 9 Sep 2022 10:44:47 GMT, Erik ?sterlund wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed ws > > This looks good to me. I looked through the code to see if I can find any additional thread state filtering that would now require the system memory barrier to work reliably, but could not find any. So it would seem that you found them all. @fisk, great, thank you! ------------- PR: https://git.openjdk.org/jdk/pull/10123 From dmitry.chuyko at bell-sw.com Fri Sep 9 11:16:01 2022 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Fri, 9 Sep 2022 14:16:01 +0300 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: <0AAEC728-3D24-46FC-9D11-4A2F5FBD70FA@oracle.com> References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <0AAEC728-3D24-46FC-9D11-4A2F5FBD70FA@oracle.com> Message-ID: Yes, that looks like a cleaner approach. JDK-8282322 implementation just focused on keeping the patch simple. There are no concerns about really old GCCs. it simply would be nice to have a way to apply the change(s) to 17 which is buildable with recent enough versions. On Thu, Sep 8, 2022 at 7:35 AM Kim Barrett wrote: > On Sep 7, 2022, at 5:30 AM, Dmitry Chuyko > wrote: > > > > Hi Kim, > > > > The implementation of the main JDK-8261027 change doesn't just try to > provide the functionality when built with older GCC (or not GCC). What it > does is dynamically switch to a more advanced implementation if the > appropriate hardware capabilities were detected during the VM start. The > selected code is picked by the compiler. So there are 2 implementations and > non-LSE one is the default. This allows us to provide a single binary for > all supported ARM devices and get better performance where possible. > > That's close to what the __atomic intrinsics with -moutline-atomics do. > Except > the compiler intrinsic approach has various benefits accrued from being > built > into the compiler. (And the code that we need to maintain is much > simpler.) > > > From another hand, a less advanced implementation is always used > initially in the default configuration. As you noticed, JDK-8282322 just > makes it possible to create a build that uses the LSE variant from the > start. > > JDK-8282322 requires an appropriate -march or similar option. The intrinsic > approach gets the same desired effect (use only LSE) when such an option is > provided, but inline. That's one of the benefits. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at openjdk.org Fri Sep 9 11:44:46 2022 From: roland at openjdk.org (Roland Westrelin) Date: Fri, 9 Sep 2022 11:44:46 GMT Subject: RFR: 8292671: Hotspot Style Guide should allow covariant returns [v2] In-Reply-To: References: Message-ID: > The style guide explicitly lists covariant returns as a disallowed > feature of c++. I propose we allow that feature. > > This came up on the c2 side where, with JDK-8275201, I introduced some > uses of covariant returns at a number of locations in the c2 code > because I felt the code was cleaner that way. I wasn't aware it was > mentioned on the style guide. This was noticed by another openjdk > contributor and I prepared a change to revert the use of covariant > returns I had introduced: > > https://github.com/openjdk/jdk/pull/9237 > > But it feels that change actually makes the code less clear and > comments on the PR indicates some other contributors feel the same > way. > > It's unclear to me why covariant returns are disallowed in the first > place and the (few) contributors I asked don't seem to know either. So > I propose simply allowing covariant returns. Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision: remove Covariant return types from list of allowed features ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9941/files - new: https://git.openjdk.org/jdk/pull/9941/files/fea33592..ec5f1ac0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9941&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9941&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9941.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9941/head:pull/9941 PR: https://git.openjdk.org/jdk/pull/9941 From roland at openjdk.org Fri Sep 9 11:44:47 2022 From: roland at openjdk.org (Roland Westrelin) Date: Fri, 9 Sep 2022 11:44:47 GMT Subject: RFR: 8292671: Hotspot Style Guide should allow covariant returns In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 14:12:05 GMT, Roland Westrelin wrote: > The style guide explicitly lists covariant returns as a disallowed > feature of c++. I propose we allow that feature. > > This came up on the c2 side where, with JDK-8275201, I introduced some > uses of covariant returns at a number of locations in the c2 code > because I felt the code was cleaner that way. I wasn't aware it was > mentioned on the style guide. This was noticed by another openjdk > contributor and I prepared a change to revert the use of covariant > returns I had introduced: > > https://github.com/openjdk/jdk/pull/9237 > > But it feels that change actually makes the code less clear and > comments on the PR indicates some other contributors feel the same > way. > > It's unclear to me why covariant returns are disallowed in the first > place and the (few) contributors I asked don't seem to know either. So > I propose simply allowing covariant returns. Thanks for the reviews ------------- PR: https://git.openjdk.org/jdk/pull/9941 From roland at openjdk.org Fri Sep 9 11:44:49 2022 From: roland at openjdk.org (Roland Westrelin) Date: Fri, 9 Sep 2022 11:44:49 GMT Subject: RFR: 8292671: Hotspot Style Guide should allow covariant returns [v2] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 05:02:48 GMT, Kim Barrett wrote: >> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision: >> >> remove Covariant return types from list of allowed features > > doc/hotspot-style.md line 1073: > >> 1071: ([n2544](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2544.pdf)) >> 1072: >> 1073: * Covariant return types > > Covariant return types are a C++03 feature, so are covered by the blanket > permission for such here: > https://github.com/openjdk/jdk/blame/master/doc/hotspot-style.md#L385-L386 > > So the exclusion could be just deleted, rather than changing to explicit > permission. Though an argument for explicit permission is to make the removal > of the long-standing exclusion more obvious. I'm fine with either, but > thought it was worth mentioning. Thanks for the clarification. I removed the explicit permission. ------------- PR: https://git.openjdk.org/jdk/pull/9941 From roland at openjdk.org Fri Sep 9 11:46:17 2022 From: roland at openjdk.org (Roland Westrelin) Date: Fri, 9 Sep 2022 11:46:17 GMT Subject: Integrated: 8292671: Hotspot Style Guide should allow covariant returns In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 14:12:05 GMT, Roland Westrelin wrote: > The style guide explicitly lists covariant returns as a disallowed > feature of c++. I propose we allow that feature. > > This came up on the c2 side where, with JDK-8275201, I introduced some > uses of covariant returns at a number of locations in the c2 code > because I felt the code was cleaner that way. I wasn't aware it was > mentioned on the style guide. This was noticed by another openjdk > contributor and I prepared a change to revert the use of covariant > returns I had introduced: > > https://github.com/openjdk/jdk/pull/9237 > > But it feels that change actually makes the code less clear and > comments on the PR indicates some other contributors feel the same > way. > > It's unclear to me why covariant returns are disallowed in the first > place and the (few) contributors I asked don't seem to know either. So > I propose simply allowing covariant returns. This pull request has now been integrated. Changeset: 3dd94f33 Author: Roland Westrelin URL: https://git.openjdk.org/jdk/commit/3dd94f33b2dddf8ea28805499d110c2347476c19 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod 8292671: Hotspot Style Guide should allow covariant returns Reviewed-by: jrose, kbarrett, stuefe, kvn, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/9941 From ihse at openjdk.org Fri Sep 9 13:56:31 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 Sep 2022 13:56:31 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 10:05:11 GMT, Robbin Ehn wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed ws I apologize that the build support was not in place to properly use the header file when present. It turned out that this was the first time we actually ran into a well-known (by me and Erik, at least ;-)) deficiency in the build system, where the split between the target and the build toolchain never were made fully complete. ------------- PR: https://git.openjdk.org/jdk/pull/10123 From pchilanomate at openjdk.org Fri Sep 9 16:35:44 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 9 Sep 2022 16:35:44 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 10:05:11 GMT, Robbin Ehn wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed ws Looks good to me! I think we can avoid always emitting the memory barrier for the JFR sampler if we move it inside the thread_state_in_native() case and then re-read the state after the barrier. ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.org/jdk/pull/10123 From dcubed at openjdk.org Fri Sep 9 16:54:58 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 9 Sep 2022 16:54:58 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 10:05:11 GMT, Robbin Ehn wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed ws Changes requested by dcubed (Reviewer). src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp line 1086: > 1084: > 1085: if (!UseSystemMemoryBarrier) { > 1086: // Force this write out before the read below In other places where this comment exists and you added the `if (!UseSystemMemoryBarrier) {`, you left the comment above the if-statement. Why move it this time? src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 22: > 20: * or visit www.oracle.com if you need additional information or have any > 21: * questions. > 22: * Nit: extra "*" blank line in the header should be deleted. src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 29: > 27: #include "logging/log.hpp" > 28: #include "utilities/debug.hpp" > 29: #include "utilities/systemMemoryBarrier.hpp" "runtime/os.hpp" should be after "logging/log.hpp". src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 51: > 49: MEMBARRIER_CMD_PRIVATE_EXPEDITED = (1 << 3), > 50: MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED = (1 << 4), > 51: }; Does there need to be some form of "#ifndef XXX" ... "#endif" bracketing for when we eventually reach systems running kernel 4.14? src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 63: > 61: > 62: static int membarrier(int cmd, unsigned int flags, int cpu_id) { > 63: return syscall(SYS_membarrier, cmd, flags, cpu_id); // cpu_id only on >=5.10 nit: need space before "5.10". src/hotspot/os/linux/systemMemoryBarrier_linux.hpp line 22: > 20: * or visit www.oracle.com if you need additional information or have any > 21: * questions. > 22: * Nit: extra "*" blank line in the header should be deleted. src/hotspot/os/linux/systemMemoryBarrier_linux.hpp line 26: > 24: > 25: #ifndef SHARE_UTILITIES_SYSTEMMEMORYBARRIER_LINUX_HPP > 26: #define SHARE_UTILITIES_SYSTEMMEMORYBARRIER_LINUX_HPP This file is not in "share/utilities" so this should be: #ifndef OS_LINUX_SYSTEMMEMORYBARRIER_LINUX_HPP #define OS_LINUX_SYSTEMMEMORYBARRIER_LINUX_HPP src/hotspot/os/linux/systemMemoryBarrier_linux.hpp line 36: > 34: }; > 35: > 36: #endif // SHARE_UTILITIES_SYSTEMMEMORYBARRIER_LINUX_HPP This should be: #endif // OS_LINUX_SYSTEMMEMORYBARRIER_LINUX_HPP src/hotspot/os/windows/systemMemoryBarrier_windows.cpp line 22: > 20: * or visit www.oracle.com if you need additional information or have any > 21: * questions. > 22: * Nit: extra "*" blank line in the header should be deleted. src/hotspot/os/windows/systemMemoryBarrier_windows.cpp line 29: > 27: > 28: #include > 29: #include Should these be alpha sorted? src/hotspot/os/windows/systemMemoryBarrier_windows.hpp line 22: > 20: * or visit www.oracle.com if you need additional information or have any > 21: * questions. > 22: * Nit: extra "*" blank line in the header should be deleted. src/hotspot/os/windows/systemMemoryBarrier_windows.hpp line 26: > 24: > 25: #ifndef SHARE_UTILITIES_SYSTEMMEMORYBARRIER_WINDOWS_HPP > 26: #define SHARE_UTILITIES_SYSTEMMEMORYBARRIER_WINDOWS_HPP This file is not in "share/utilities" so this should be: #ifndef OS_WINDOWS_SYSTEMMEMORYBARRIER_WINDOWS_HPP #define OS_WINDOWS_SYSTEMMEMORYBARRIER_WINDOWS_HPP src/hotspot/os/windows/systemMemoryBarrier_windows.hpp line 36: > 34: }; > 35: > 36: #endif // SHARE_UTILITIES_SYSTEMMEMORYBARRIER_WINDOWS_HPP This should be: #endif // OS_WINDOWS_SYSTEMMEMORYBARRIER_WINDOWS_HPP src/hotspot/share/runtime/globals.hpp line 1298: > 1296: \ > 1297: product(bool, UseSystemMemoryBarrier, false, EXPERIMENTAL, \ > 1298: "Try enable system memory barrier") \ typo: s/Try enable/Try to enable/ src/hotspot/share/runtime/handshake.cpp line 380: > 378: if (UseSystemMemoryBarrier) { > 379: SystemMemoryBarrier::emit(); > 380: } It's not clear to me why this emit() is here. src/hotspot/share/runtime/threads.cpp line 559: > 557: if (UseSystemMemoryBarrier) { > 558: if (!SystemMemoryBarrier::initialize()) { > 559: // UseSystemMemoryBarrier = false; Delete the commented out line? Or was this done for testing? Or??? src/hotspot/share/runtime/threads.cpp line 560: > 558: if (!SystemMemoryBarrier::initialize()) { > 559: // UseSystemMemoryBarrier = false; > 560: vm_shutdown_during_initialization("Failed to initialize request system memory barrier synchronization."); typo: s/initialize request system/initialize the requested system/ src/hotspot/share/utilities/systemMemoryBarrier.hpp line 22: > 20: * or visit www.oracle.com if you need additional information or have any > 21: * questions. > 22: * Nit: extra "*" blank line in the header should be deleted. test/hotspot/jtreg/runtime/handshake/HandshakeTransitionTest.java line 32: > 30: * @test HandshakeTransitionTest > 31: * @summary This does a sanity test of the poll in the native wrapper. > 32: * @requires vm.debug Why was this deleted? Have you tested this with release bits? test/hotspot/jtreg/runtime/handshake/SystemMembarHandshakeTransitionTest.java line 22: > 20: * or visit www.oracle.com if you need additional information or have any > 21: * questions. > 22: * Nit: extra "*" blank line in the header should be deleted. test/hotspot/jtreg/runtime/handshake/SystemMembarHandshakeTransitionTest.java line 27: > 25: import jdk.test.lib.Utils; > 26: import jdk.test.lib.process.ProcessTools; > 27: import jdk.test.lib.process.OutputAnalyzer; Should these be in alpha sort order? test/hotspot/jtreg/runtime/handshake/SystemMembarHandshakeTransitionTest.java line 57: > 55: commands.addAll(Arrays.asList(args)); > 56: commands.add("HandshakeTransitionTest$Test"); > 57: ProcessBuilder pb = ProcessTools.createTestJvm(commands); Please make sure the new test is run with 'release' bits. ------------- PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Fri Sep 9 17:43:49 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 9 Sep 2022 17:43:49 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 16:25:54 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed ws > > src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 51: > >> 49: MEMBARRIER_CMD_PRIVATE_EXPEDITED = (1 << 3), >> 50: MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED = (1 << 4), >> 51: }; > > Does there need to be some form of "#ifndef XXX" ... "#endif" bracketing > for when we eventually reach systems running kernel 4.14? The plan is when the build system fully supports AC_CHECK_DECL, auto conf will check this for and set a define. ------------- PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Fri Sep 9 17:48:49 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 9 Sep 2022 17:48:49 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5] In-Reply-To: References: Message-ID: <2dreYEqDY3ZWk5TCtjv49YYZ898LBBAfzgAXfePRoEY=.bcf7a3f4-35e2-43b5-b3fe-87a06ed5b776@github.com> On Fri, 9 Sep 2022 16:32:03 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed ws > > src/hotspot/os/windows/systemMemoryBarrier_windows.cpp line 29: > >> 27: >> 28: #include >> 29: #include > > Should these be alpha sorted? On some windows setups processthreadsapi.h needs a define from windows.h. (otherwise it do not know what arch we are compiling on) (this is a bug in the windows headers) This file only needs processthreadsapi.h according to the docs. ------------- PR: https://git.openjdk.org/jdk/pull/10123 From coleenp at openjdk.org Fri Sep 9 17:57:43 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 9 Sep 2022 17:57:43 GMT Subject: RFR: 8288473: Remove unused frame::set_pc_preserve_deopt methods Message-ID: Please review this trivial change to remove unused functions. ------------- Commit messages: - 8288473: Remove unused frame::set_pc_preserve_deopt methods Changes: https://git.openjdk.org/jdk/pull/10233/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10233&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288473 Stats: 18 lines in 2 files changed: 0 ins; 17 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10233.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10233/head:pull/10233 PR: https://git.openjdk.org/jdk/pull/10233 From rpressler at openjdk.org Fri Sep 9 18:04:44 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Fri, 9 Sep 2022 18:04:44 GMT Subject: RFR: 8288473: Remove unused frame::set_pc_preserve_deopt methods In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 17:48:48 GMT, Coleen Phillimore wrote: > Please review this trivial change to remove unused functions. Marked as reviewed by rpressler (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/10233 From rehn at openjdk.org Fri Sep 9 18:08:47 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 9 Sep 2022 18:08:47 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 16:36:34 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed ws > > src/hotspot/share/runtime/handshake.cpp line 380: > >> 378: if (UseSystemMemoryBarrier) { >> 379: SystemMemoryBarrier::emit(); >> 380: } > > It's not clear to me why this emit() is here. add_operation() arms poll. try_process() reads JavaThread state. Since are allowing the CPU to do reordering of instructions, try_process() can see e.g. state in_native after arming the poll. Normally this would be safe, but since we now allow reordering it's not. By emitting the system membar we know that if we see in_native that thread will see the armed poll. Long comment from me above, but yes it's not clear that add_operation() and try_process() are effected by this race when using system membar. ------------- PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Fri Sep 9 18:26:49 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 9 Sep 2022 18:26:49 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v6] In-Reply-To: References: Message-ID: > Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) > > On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. > > Passes t1-7 with option forced on, also passes t1-4 as is in this PR. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Fixes for Dan ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10123/files - new: https://git.openjdk.org/jdk/pull/10123/files/981a6cab..092a3acf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10123&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10123&range=04-05 Stats: 16 lines in 7 files changed: 3 ins; 4 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/10123.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10123/head:pull/10123 PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Fri Sep 9 18:26:51 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 9 Sep 2022 18:26:51 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 16:31:30 GMT, Patricio Chilano Mateo wrote: > Looks good to me! I think we can avoid always emitting the memory barrier for the JFR sampler if we move it inside the thread_state_in_native() case and then re-read the state after the barrier. Thanks! If we can make the sampler performance better when using sysmembar it would be good. ------------- PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Fri Sep 9 18:27:01 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 9 Sep 2022 18:27:01 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 16:21:40 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed ws > > src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp line 1086: > >> 1084: >> 1085: if (!UseSystemMemoryBarrier) { >> 1086: // Force this write out before the read below > > In other places where this comment exists and you added the > `if (!UseSystemMemoryBarrier) {`, you left the comment above > the if-statement. Why move it this time? Fixed > src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 29: > >> 27: #include "logging/log.hpp" >> 28: #include "utilities/debug.hpp" >> 29: #include "utilities/systemMemoryBarrier.hpp" > > "runtime/os.hpp" should be after "logging/log.hpp". Fixed > src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 63: > >> 61: >> 62: static int membarrier(int cmd, unsigned int flags, int cpu_id) { >> 63: return syscall(SYS_membarrier, cmd, flags, cpu_id); // cpu_id only on >=5.10 > > nit: need space before "5.10". Fixed > src/hotspot/os/linux/systemMemoryBarrier_linux.hpp line 26: > >> 24: >> 25: #ifndef SHARE_UTILITIES_SYSTEMMEMORYBARRIER_LINUX_HPP >> 26: #define SHARE_UTILITIES_SYSTEMMEMORYBARRIER_LINUX_HPP > > This file is not in "share/utilities" so this should be: > > #ifndef OS_LINUX_SYSTEMMEMORYBARRIER_LINUX_HPP > #define OS_LINUX_SYSTEMMEMORYBARRIER_LINUX_HPP Fixed > src/hotspot/os/linux/systemMemoryBarrier_linux.hpp line 36: > >> 34: }; >> 35: >> 36: #endif // SHARE_UTILITIES_SYSTEMMEMORYBARRIER_LINUX_HPP > > This should be: > > #endif // OS_LINUX_SYSTEMMEMORYBARRIER_LINUX_HPP Fixed > src/hotspot/os/windows/systemMemoryBarrier_windows.hpp line 26: > >> 24: >> 25: #ifndef SHARE_UTILITIES_SYSTEMMEMORYBARRIER_WINDOWS_HPP >> 26: #define SHARE_UTILITIES_SYSTEMMEMORYBARRIER_WINDOWS_HPP > > This file is not in "share/utilities" so this should be: > > #ifndef OS_WINDOWS_SYSTEMMEMORYBARRIER_WINDOWS_HPP > #define OS_WINDOWS_SYSTEMMEMORYBARRIER_WINDOWS_HPP Fixed > src/hotspot/os/windows/systemMemoryBarrier_windows.hpp line 36: > >> 34: }; >> 35: >> 36: #endif // SHARE_UTILITIES_SYSTEMMEMORYBARRIER_WINDOWS_HPP > > This should be: > > #endif // OS_WINDOWS_SYSTEMMEMORYBARRIER_WINDOWS_HPP Fixed > src/hotspot/share/runtime/globals.hpp line 1298: > >> 1296: \ >> 1297: product(bool, UseSystemMemoryBarrier, false, EXPERIMENTAL, \ >> 1298: "Try enable system memory barrier") \ > > typo: s/Try enable/Try to enable/ Fixed > src/hotspot/share/runtime/threads.cpp line 559: > >> 557: if (UseSystemMemoryBarrier) { >> 558: if (!SystemMemoryBarrier::initialize()) { >> 559: // UseSystemMemoryBarrier = false; > > Delete the commented out line? Or was this done for testing? Or??? Yes, thanks, fixed. > src/hotspot/share/runtime/threads.cpp line 560: > >> 558: if (!SystemMemoryBarrier::initialize()) { >> 559: // UseSystemMemoryBarrier = false; >> 560: vm_shutdown_during_initialization("Failed to initialize request system memory barrier synchronization."); > > typo: s/initialize request system/initialize the requested system/ Fixed > test/hotspot/jtreg/runtime/handshake/SystemMembarHandshakeTransitionTest.java line 27: > >> 25: import jdk.test.lib.Utils; >> 26: import jdk.test.lib.process.ProcessTools; >> 27: import jdk.test.lib.process.OutputAnalyzer; > > Should these be in alpha sort order? Fixed > test/hotspot/jtreg/runtime/handshake/SystemMembarHandshakeTransitionTest.java line 57: > >> 55: commands.addAll(Arrays.asList(args)); >> 56: commands.add("HandshakeTransitionTest$Test"); >> 57: ProcessBuilder pb = ProcessTools.createTestJvm(commands); > > Please make sure the new test is run with 'release' bits. Yes it does. ------------- PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Fri Sep 9 18:27:03 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 9 Sep 2022 18:27:03 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v6] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 16:44:30 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > test/hotspot/jtreg/runtime/handshake/HandshakeTransitionTest.java line 32: > >> 30: * @test HandshakeTransitionTest >> 31: * @summary This does a sanity test of the poll in the native wrapper. >> 32: * @requires vm.debug > > Why was this deleted? > Have you tested this with release bits? Martin asked if we could add the diagnostics flag and make the test(s) runnable in release build. (higher chance of a race happening in release) So I did that, and tested it locally. ------------- PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Fri Sep 9 18:45:36 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 9 Sep 2022 18:45:36 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5] In-Reply-To: References: Message-ID: <54YCnbqtN7QB4lOuMhQVU2JfvoTjZWQ0pv3XE5IPyS0=.9c7d1171-8493-4f64-bd52-d44183d7d789@github.com> On Fri, 9 Sep 2022 16:52:24 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed ws > > Changes requested by dcubed (Reviewer). @dcubed-ojdk thanks for reviewing, I think I got all! > src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 22: > >> 20: * or visit www.oracle.com if you need additional information or have any >> 21: * questions. >> 22: * > > Nit: extra "*" blank line in the header should be deleted. We have some variation, those files I look at same to have this style, so I'll leave it. ------------- PR: https://git.openjdk.org/jdk/pull/10123 From dlong at openjdk.org Fri Sep 9 18:46:56 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 9 Sep 2022 18:46:56 GMT Subject: RFR: 8293287 add ReplayReduce flag [v4] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 01:33:02 GMT, Dean Long wrote: >> Add an experimental flag to help developers "reduce" a replay file. >> >> As a first step, I plan to simulate reduced inlining. This will output multiple "compile" lines as if the first level of inlining never happened: >> A --> B --> C >> A --> D --> E >> becomes >> B --> C >> D --> E >> Developers can repeat iteratively until the replay crash no longer reproduces. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > fix typo > > Co-authored-by: Tobias Hartmann Thanks Tobias and Vladimir. ------------- PR: https://git.openjdk.org/jdk/pull/10134 From dlong at openjdk.org Fri Sep 9 18:49:46 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 9 Sep 2022 18:49:46 GMT Subject: Integrated: 8293287 add ReplayReduce flag In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 01:20:26 GMT, Dean Long wrote: > Add an experimental flag to help developers "reduce" a replay file. > > As a first step, I plan to simulate reduced inlining. This will output multiple "compile" lines as if the first level of inlining never happened: > A --> B --> C > A --> D --> E > becomes > B --> C > D --> E > Developers can repeat iteratively until the replay crash no longer reproduces. This pull request has now been integrated. Changeset: dbec22b8 Author: Dean Long URL: https://git.openjdk.org/jdk/commit/dbec22b84b0ffce447b43271e12ed7d0eed6c387 Stats: 135 lines in 9 files changed: 41 ins; 88 del; 6 mod 8293287: add ReplayReduce flag Reviewed-by: kvn, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/10134 From dcubed at openjdk.org Fri Sep 9 18:56:51 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 9 Sep 2022 18:56:51 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v6] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 18:26:49 GMT, Robbin Ehn wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixes for Dan Marked as reviewed by dcubed (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10123 From dcubed at openjdk.org Fri Sep 9 18:56:54 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 9 Sep 2022 18:56:54 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 17:39:35 GMT, Robbin Ehn wrote: >> src/hotspot/os/linux/systemMemoryBarrier_linux.cpp line 51: >> >>> 49: MEMBARRIER_CMD_PRIVATE_EXPEDITED = (1 << 3), >>> 50: MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED = (1 << 4), >>> 51: }; >> >> Does there need to be some form of "#ifndef XXX" ... "#endif" bracketing >> for when we eventually reach systems running kernel 4.14? > > The plan is when the build system fully supports AC_CHECK_DECL, auto conf will check this for and set a define. Thanks for the explanation! >> src/hotspot/share/runtime/handshake.cpp line 380: >> >>> 378: if (UseSystemMemoryBarrier) { >>> 379: SystemMemoryBarrier::emit(); >>> 380: } >> >> It's not clear to me why this emit() is here. > > add_operation() arms poll. > try_process() reads JavaThread state. > > Since are allowing the CPU to do reordering of instructions, try_process() can see e.g. state in_native after arming the poll. > Normally this would be safe, but since we now allow reordering it's not. > By emitting the system membar we know that if we see in_native that thread will see the armed poll. > > EDIT: > You can also see long comment from me above. > But yes it's not clear that add_operation() and try_process() are effected by this race when using system membar. How about a comment above the emit(): // Separate the poll() in add_operation() above() from the read of JavaThread state // in the try_process() call below. >> test/hotspot/jtreg/runtime/handshake/SystemMembarHandshakeTransitionTest.java line 57: >> >>> 55: commands.addAll(Arrays.asList(args)); >>> 56: commands.add("HandshakeTransitionTest$Test"); >>> 57: ProcessBuilder pb = ProcessTools.createTestJvm(commands); >> >> Please make sure the new test is run with 'release' bits. > > Yes it does. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10123 From dcubed at openjdk.org Fri Sep 9 19:01:45 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 9 Sep 2022 19:01:45 GMT Subject: RFR: 8288473: Remove unused frame::set_pc_preserve_deopt methods In-Reply-To: References: Message-ID: <4CxpcOsqfpU5aJEwBad7CO_Rhbpx_3VjXsKX_2KUb_w=.9ebce075-783d-453a-9191-346e7699be6c@github.com> On Fri, 9 Sep 2022 17:48:48 GMT, Coleen Phillimore wrote: > Please review this trivial change to remove unused functions. Thumbs up! I agree this is a trivial fix so you don't have to wait 24 hours. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/10233 From coleenp at openjdk.org Fri Sep 9 19:36:29 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 9 Sep 2022 19:36:29 GMT Subject: RFR: 8288473: Remove unused frame::set_pc_preserve_deopt methods In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 17:48:48 GMT, Coleen Phillimore wrote: > Please review this trivial change to remove unused functions. Thanks Ron and Dan. I'm waiting for GHA to finish then I'll push. ------------- PR: https://git.openjdk.org/jdk/pull/10233 From dcubed at openjdk.org Fri Sep 9 19:37:49 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 9 Sep 2022 19:37:49 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread [v2] In-Reply-To: References: Message-ID: <4mPJ1Noq06Km9zQFBhCL6ENKn1vxMBUu6bZtknY5YMY=.7e19aab9-839b-4f86-a266-4ee1418a663b@github.com> On Tue, 6 Sep 2022 08:42:13 GMT, Kevin Walls wrote: >> This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). >> >> A JVMTI operation could call threadObj() and clear the Windows GetLastError value. >> >> Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Comment update I agree with your choices in your partial [BACKOUT] of: [JDK-8289091](https://bugs.openjdk.org/browse/JDK-8289091) move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() Thanks for adding the new test. I like it. Concerning: > More follow up needed about the last error reset caused by GC. Have you filed a follow up bug in hotspot/gc for that issue? Thumbs up on this fix and new test. test/jdk/com/sun/jdi/JdbLastErrorTest.java line 42: > 40: import java.lang.foreign.SymbolLookup; > 41: import java.lang.invoke.MethodHandle; > 42: import java.lang.foreign.ValueLayout; L41 and L42 should be swapped for proper alpha sort order. test/jdk/com/sun/jdi/JdbLastErrorTest.java line 60: > 58: FunctionDescriptor.ofVoid(ValueLayout.JAVA_INT)); > 59: > 60: for (int i=0; i<10; i++) { nit: should be space around '=' and '<'. test/jdk/com/sun/jdi/JdbLastErrorTest.java line 61: > 59: > 60: for (int i=0; i<10; i++) { > 61: setLastError.invoke(42); If you use final variable for the '42', then you can use the variable here on L61 and below on L64. Then you can call is something cool: static final int THE_ANSWER = 42; // ... to life, the universe and everything! ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/10147 From coleenp at openjdk.org Fri Sep 9 20:22:50 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 9 Sep 2022 20:22:50 GMT Subject: RFR: 8288473: Remove unused frame::set_pc_preserve_deopt methods In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 17:48:48 GMT, Coleen Phillimore wrote: > Please review this trivial change to remove unused functions. All GHA platforms built. Thanks for the reviews. ------------- PR: https://git.openjdk.org/jdk/pull/10233 From coleenp at openjdk.org Fri Sep 9 20:22:50 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 9 Sep 2022 20:22:50 GMT Subject: Integrated: 8288473: Remove unused frame::set_pc_preserve_deopt methods In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 17:48:48 GMT, Coleen Phillimore wrote: > Please review this trivial change to remove unused functions. This pull request has now been integrated. Changeset: 91d00b30 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/91d00b3022b8bb59ce04fb5f214e3deb93590f46 Stats: 18 lines in 2 files changed: 0 ins; 17 del; 1 mod 8288473: Remove unused frame::set_pc_preserve_deopt methods Reviewed-by: rpressler, dcubed ------------- PR: https://git.openjdk.org/jdk/pull/10233 From kim.barrett at oracle.com Fri Sep 9 21:50:35 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 9 Sep 2022 21:50:35 +0000 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> Message-ID: <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> > On Sep 9, 2022, at 5:24 AM, Andrew Haley wrote: > > On 9/8/22 08:50, Kim Barrett wrote: >> We (Oracle) used to be extremely conservative about toolchain upgrades, but we >> got better. (Thank you, spectre and meltdown.) I admit my opinion is colored >> by that, and the benefits from it. > > OK, so we have, in effect, a change of policy. That does make sense. That's a change in Oracle/JPG policy. Of course, other vendors may have other policies. But I would think a linux-aarch64 vendor/distro that is tracking up-to-date JDK versions would likely also be tracking reasonably up-to-date gcc versions. > Don't under-estimate the effect of using LL/SC on some Arm hardware. In some > cases it's so bad that it looks almost like the implementation is broken. > > Another thing to bear in mind is that we have some reports of relatively > poor LSE performance on larger Huawei systems, so the mere presence of LSE > atomics does not always tell us we should use them. We have a switch. > > As far as I can tell, outline-atomics doesn't support switching LSE off, but > maybe some systems have local patches. I'd expect that to be something that would be dealt with by -mcpu, and automatically by -moutline-atomics (if not now, then eventually - a hardware vendor has a vested interest in optimizing gcc). But yes, maybe that kind of configuration is not (yet) well handled. >> A benefit of such a change would be that if one knows what hardware is going >> to be used, one can compile specifically for that and get best performance for >> these operations for that hardware. I can easily imagine that being a common >> scenario. The current approach actively prevents that. > > True, but the overhead is very low. It's two perfectly-predicted branches, > about as near as you can get to zero in practice. Less overhead than > outline-atomics. It's more than that, because of register shuffling going in to and out of the out-of-line helper routine (whoever supplies that routine). How measureable is it? I don't know. >> How many folks are very conservative about gcc versions but not about JDK >> versions? And should we be catering to them at the expense of folks who are >> keeping up to date and willing to do tailored builds. > > That's an excellent question. I guess most Linux distros are now at 8.5, > so perhaps there's no problem. That would be my hope/guess, but it's not something I personally track. >>> I'm curious, though: wouldn't atomic bitset ops be based on CAS? If so, you don't >>> need to care how CAS is implemented. >> We can write them as an Atomic::cmpxchg loop, just as we can write Atomic::add >> that way. But that isn't a particularly good way to write them. It's a loop >> over an ll/sc loop, or a loop over an LSE CAS instruction. Better is a direct >> ll/sc loop or an LSE bitop instruction. > > Oh! Does LSE actually have the ops you need for this? Yes! > So, if we revert to using the GCC intrinsics, we'd hurt performance on some > systems, and we'd lose some control. On the other hand it'd be cleaner. Much > cleaner. :-) Exactly. So what do folks think? Obviously, I can add support for the bitops using the existing structure (even though I'd rather not) and we can revisit this somewhat messy situation again later. Or we can clean up the code now. From sspitsyn at openjdk.org Sat Sep 10 00:18:47 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 10 Sep 2022 00:18:47 GMT Subject: RFR: 8293339: vm/jvmti/StopThread/stop001/stop00103 crashes with SIGSEGV in Continuation::is_continuation_mounted Message-ID: I was not able to reproduce this issue in thousands of mach5 runs on multiple platforms. However, the root cause seems to be pretty simple. A JvmtiVTMSTransitionDisabler needs to be added to make the JVM TI StopThread function to be VTMS (Virtual Thread Mount state) transition safe. So the fix is a one-liner: diff --git a/src/hotspot/share/prims/jvmtiEnv.cpp b/src/hotspot/share/prims/jvmtiEnv.cpp index a9efe01c92e..f5e9176230a 100644 --- a/src/hotspot/share/prims/jvmtiEnv.cpp +++ b/src/hotspot/share/prims/jvmtiEnv.cpp @@ -1182,6 +1182,8 @@ JvmtiEnv::ResumeAllVirtualThreads(jint except_count, const jthread* except_list) jvmtiError JvmtiEnv::StopThread(jthread thread, jobject exception) { JavaThread* current_thread = JavaThread::current(); + + JvmtiVTMSTransitionDisabler disabler; ThreadsListHandle tlh(current_thread); JavaThread* java_thread = NULL; oop thread_oop = NULL; ------------- Commit messages: - 8293339: vm/jvmti/StopThread/stop001/stop00103 crashes with SIGSEGV in Continuation::is_continuation_mounted Changes: https://git.openjdk.org/jdk/pull/10235/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10235&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293339 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10235.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10235/head:pull/10235 PR: https://git.openjdk.org/jdk/pull/10235 From duke at openjdk.org Sat Sep 10 00:34:37 2022 From: duke at openjdk.org (duke) Date: Sat, 10 Sep 2022 00:34:37 GMT Subject: Withdrawn: 8263377: Store method handle linkers in the 'non-nmethods' heap In-Reply-To: References: Message-ID: On Tue, 17 May 2022 23:19:54 GMT, Yi-Fan Tsai wrote: > 8263377: Store method handle linkers in the 'non-nmethods' heap This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/8760 From dcubed at openjdk.org Sat Sep 10 15:13:54 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 10 Sep 2022 15:13:54 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v3] In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 20:09:05 GMT, Alex Menkov wrote: >> The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) >> >> cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. >> After successful RedefineClasses it should be reset. >> The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated test. comments, code reorg I like the fact that the fix is small and I really like the new test. I only have minor comments and a couple of questions. Please run these changes thru Tier[456] since that's where JVM/TI tests run in different configs w/ different options. src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4333: > 4331: > 4332: if (scratch_class->get_cached_class_file() != the_class->get_cached_class_file()) { > 4333: // 1. the_class doesn't have a cache yet, scratch_class does have. typo: s/does have./does have a cache./ src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4337: > 4335: // are multiple concurrent RetransformClasses calls on different threads. > 4336: // the_class and scratch_class have the same cached bytes, but different buffers. > 4337: // In such cases we need to deallocate one of the buffer. typo: s/the buffer/the buffers/ src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4338: > 4336: // the_class and scratch_class have the same cached bytes, but different buffers. > 4337: // In such cases we need to deallocate one of the buffer. > 4338: // 3. RedefineClasses and the_class has cached bytes from previous transformation. typo: s/has cached/have cached/ typo: s/from previous/from a previous/ src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4340: > 4338: // 3. RedefineClasses and the_class has cached bytes from previous transformation. > 4339: // In the case we need to use class bytes from scratch_class. > 4340: if (the_class->get_cached_class_file() != 0) { s/!= 0/!= nullptr/ test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 174: > 172: throw new RuntimeException("Redefine error (ver = " + ver + ")"); > 173: } > 174: // verity ClassFileLoadHook get expected class bytes typos: s/verity/verify/ s/get/gets the/ test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 197: > 195: int testCase; > 196: try { > 197: testCase= Integer.valueOf(args[0]); nit: please add space before '=' test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 215: > 213: redefine(1); // cached class bytes are not set > 214: retransform(2, 1); // sets cached class bytes to ver 1 > 215: redefine(3); // resets cached class bytes Perhaps: ```// resets cached class bytes to nullptr``` test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 224: > 222: redefine(1); // cached class bytes are not set > 223: retransform(2, 1); // sets cached class bytes to ver 1 > 224: redefine(3); // resets cached class bytes Perhaps: ```// resets cached class bytes to nullptr``` test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 232: > 230: test("Retransform-Redefine-Retransform-Retransform", () -> { > 231: retransform(1, 0); // sets cached class bytes to ver 0 (initially loaded) > 232: redefine(2); // resets cached class bytes Perhaps: ```// resets cached class bytes to nullptr``` test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 240: > 238: case 5: > 239: test("Redefine-Retransform-Redefine-Retransform with CFLH", () -> { > 240: redefine(1, 5); // CFLH sets cached class bytes to ver 1 I'm having trouble understanding why the CFLH version is '5' here. Update: I _think_ this is just to have the CFLH return a different version of the class bytes before the RedefineClasses() call does its work. I don't understand why you want to do this... test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 242: > 240: redefine(1, 5); // CFLH sets cached class bytes to ver 1 > 241: retransform(2, 1); // uses existing cache > 242: redefine(3, 6); // resets cached class bytes, I'm having trouble understanding why the CFLH version is '6' here. Update: I _think_ this is just to have the CFLH return a different version of the class bytes before the RedefineClasses() call does its work. I don't understand why you want to do this... Perhaps: ```// resets cached class bytes to nullptr,``` test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 251: > 249: test("Retransform-Redefine-Retransform-Retransform with CFLH", () -> { > 250: retransform(1, 0); // sets cached class bytes to ver 0 (initially loaded) > 251: redefine(2, 5); // resets cached class bytes, I'm having trouble understanding why the CFLH version is '5' here. Update: I _think_ this is just to have the CFLH return a different version of the class bytes before the RedefineClasses() call does its work. I don't understand why you want to do this... Perhaps ```// resets cached class bytes to nullptr,``` test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 26: > 24: #include > 25: #include > 26: #include Should be in alpha sort order? test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 48: > 46: } > 47: > 48: class ClassFileLoadHookHelper { A short comment describing the purpose of the `ClassFileLoadHookHelper` would be helpful to folks that only have a high level understanding of RedefineClasses() and RetransformClasses(). You did a very good job encapsulating support for a complicated sets of APIs into this helper. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 215: > 213: caps.can_redefine_classes = 1; > 214: caps.can_retransform_classes = 1; > 215: jvmti->AddCapabilities(&caps); Why no error check here? ------------- Changes requested by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/10032 From fyang at openjdk.org Sun Sep 11 01:09:01 2022 From: fyang at openjdk.org (Fei Yang) Date: Sun, 11 Sep 2022 01:09:01 GMT Subject: RFR: 8293566: RISC-V: Clean up push and pop registers In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 08:31:02 GMT, Feilong Jiang wrote: > Currently, riscv port has two implementations of `push_reg` and `pop_reg`. > The bitset version can be replaced with the RegSet version for better readability. > > For example, if we want to push x10 and x11, pushing register with bitset would be like: > > push_reg(0xc00, sp) > > > while pushing register with RegSet will be more clear: > > push_reg(RegSet::of(x10, x11), sp); > > > So we decide to remove the bitset version of push and pop registers. > > Testing: > > - hotspot and jdk ter1 on QEMU without new failures Thanks for the cleanup. I have two comments here. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 955: > 953: > 954: unsigned char regs[32]; > 955: int count = bitset_to_regs(regset.bits(), regs); I think it's better to have a zero-check for regs.bits() before we run into the loop in MacroAssembler::bitset_to_regs. So I would suggest make the old API "int MacroAssembler::push_reg(unsigned int bitset, Register stack)" a private member function and implement the new API as: void MacroAssembler::push_reg(RegSet regset, Register stack) { if (regs.bits()) push_reg(regs.bits(), stack); } Similar for pop_reg and other APIs here. src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 484: > 482: #ifdef COMPILER2 > 483: void push_vp(VectorRegSet regset, Register stack); > 484: void pop_vp(VectorRegSet regset, Register stack); The function name push_vp / pop_vp look a bit strange to me. I think we should rename them to push_v / pop_v. ------------- Changes requested by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10227 From fjiang at openjdk.org Sun Sep 11 02:07:55 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Sun, 11 Sep 2022 02:07:55 GMT Subject: RFR: 8293566: RISC-V: Clean up push and pop registers [v2] In-Reply-To: References: Message-ID: > Currently, riscv port has two implementations of `push_reg` and `pop_reg`. > The bitset version can be replaced with the RegSet version for better readability. > > For example, if we want to push x10 and x11, pushing register with bitset would be like: > > push_reg(0xc00, sp) > > > while pushing register with RegSet will be more clear: > > push_reg(RegSet::of(x10, x11), sp); > > > So we decide to remove the bitset version of push and pop registers. > > Testing: > > - hotspot and jdk ter1 on QEMU without new failures Feilong Jiang has updated the pull request incrementally with two additional commits since the last revision: - fix comment - restore bitset routine ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10227/files - new: https://git.openjdk.org/jdk/pull/10227/files/25a10eee..441d50c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10227&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10227&range=00-01 Stats: 47 lines in 3 files changed: 25 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/10227.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10227/head:pull/10227 PR: https://git.openjdk.org/jdk/pull/10227 From fjiang at openjdk.org Sun Sep 11 02:17:38 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Sun, 11 Sep 2022 02:17:38 GMT Subject: RFR: 8293566: RISC-V: Clean up push and pop registers [v3] In-Reply-To: References: Message-ID: > Currently, riscv port has two implementations of `push_reg` and `pop_reg`. > The bitset version can be replaced with the RegSet version for better readability. > > For example, if we want to push x10 and x11, pushing register with bitset would be like: > > push_reg(0xc00, sp) > > > while pushing register with RegSet will be more clear: > > push_reg(RegSet::of(x10, x11), sp); > > > Testing: > > - hotspot and jdk ter1 on QEMU without new failures Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: fix return size of push_v/pop_v ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10227/files - new: https://git.openjdk.org/jdk/pull/10227/files/441d50c6..5dd1c9ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10227&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10227&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10227.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10227/head:pull/10227 PR: https://git.openjdk.org/jdk/pull/10227 From fjiang at openjdk.org Sun Sep 11 02:24:05 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Sun, 11 Sep 2022 02:24:05 GMT Subject: RFR: 8293566: RISC-V: Clean up push and pop registers [v3] In-Reply-To: References: Message-ID: On Sun, 11 Sep 2022 01:03:14 GMT, Fei Yang wrote: >> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix return size of push_v/pop_v > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 955: > >> 953: >> 954: unsigned char regs[32]; >> 955: int count = bitset_to_regs(regset.bits(), regs); > > I think it's better to have a zero-check for regs.bits() before we run into the loop in MacroAssembler::bitset_to_regs. So I would suggest make the old API "int MacroAssembler::push_reg(unsigned int bitset, Register stack)" a private member function and implement the new API as: > > void MacroAssembler::push_reg(RegSet regset, Register stack) { if (regs.bits()) push_reg(regs.bits(), stack); } > > Similar for pop_reg and other APIs here. Done, keep the old bitset verison and make them private. > src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 484: > >> 482: #ifdef COMPILER2 >> 483: void push_vp(VectorRegSet regset, Register stack); >> 484: void pop_vp(VectorRegSet regset, Register stack); > > The function name push_vp / pop_vp look a bit strange to me. I think we should rename them to push_v / pop_v. Done, renamed to `push_v/pop_v`. ------------- PR: https://git.openjdk.org/jdk/pull/10227 From fjiang at openjdk.org Mon Sep 12 02:29:52 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Mon, 12 Sep 2022 02:29:52 GMT Subject: RFR: 8293566: RISC-V: Clean up push and pop registers [v4] In-Reply-To: References: Message-ID: > Currently, riscv port has two implementations of `push_reg` and `pop_reg`. > The bitset version can be replaced with the RegSet version for better readability. > > For example, if we want to push x10 and x11, pushing register with bitset would be like: > > push_reg(0xc00, sp) > > > while pushing register with RegSet will be more clear: > > push_reg(RegSet::of(x10, x11), sp); > > > Testing: > > - hotspot and jdk ter1 on QEMU without new failures Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: add comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10227/files - new: https://git.openjdk.org/jdk/pull/10227/files/5dd1c9ef..82765710 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10227&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10227&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10227.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10227/head:pull/10227 PR: https://git.openjdk.org/jdk/pull/10227 From fjiang at openjdk.org Mon Sep 12 02:34:56 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Mon, 12 Sep 2022 02:34:56 GMT Subject: RFR: 8293566: RISC-V: Clean up push and pop registers [v5] In-Reply-To: References: Message-ID: <5lizafw-lLfG0eVda9HRcR6luI36yMlCmW3zPnKtoec=.0af61ab8-34b5-45b1-98eb-522e93b1bc66@github.com> > Currently, riscv port has two implementations of `push_reg` and `pop_reg`. > The bitset version can be replaced with the RegSet version for better readability. > > For example, if we want to push x10 and x11, pushing register with bitset would be like: > > push_reg(0xc00, sp) > > > while pushing register with RegSet will be more clear: > > push_reg(RegSet::of(x10, x11), sp); > > > Testing: > > - hotspot and jdk ter1 on QEMU without new failures Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10227/files - new: https://git.openjdk.org/jdk/pull/10227/files/82765710..ebc74573 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10227&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10227&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10227.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10227/head:pull/10227 PR: https://git.openjdk.org/jdk/pull/10227 From fyang at openjdk.org Mon Sep 12 02:51:42 2022 From: fyang at openjdk.org (Fei Yang) Date: Mon, 12 Sep 2022 02:51:42 GMT Subject: RFR: 8293566: RISC-V: Clean up push and pop registers [v5] In-Reply-To: <5lizafw-lLfG0eVda9HRcR6luI36yMlCmW3zPnKtoec=.0af61ab8-34b5-45b1-98eb-522e93b1bc66@github.com> References: <5lizafw-lLfG0eVda9HRcR6luI36yMlCmW3zPnKtoec=.0af61ab8-34b5-45b1-98eb-522e93b1bc66@github.com> Message-ID: On Mon, 12 Sep 2022 02:34:56 GMT, Feilong Jiang wrote: >> Currently, riscv port has two implementations of `push_reg` and `pop_reg`. >> The bitset version can be replaced with the RegSet version for better readability. >> >> For example, if we want to push x10 and x11, pushing register with bitset would be like: >> >> push_reg(0xc00, sp) >> >> >> while pushing register with RegSet will be more clear: >> >> push_reg(RegSet::of(x10, x11), sp); >> >> >> Testing: >> >> - hotspot and jdk ter1 on QEMU without new failures > > Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: > > fix Updated change looks good. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10227 From rehn at openjdk.org Mon Sep 12 07:20:54 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 12 Sep 2022 07:20:54 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v7] In-Reply-To: References: Message-ID: > Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) > > On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. > > Passes t1-7 with option forced on, also passes t1-4 as is in this PR. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Added comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10123/files - new: https://git.openjdk.org/jdk/pull/10123/files/092a3acf..4045f21c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10123&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10123&range=05-06 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10123.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10123/head:pull/10123 PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Mon Sep 12 07:20:55 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 12 Sep 2022 07:20:55 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v6] In-Reply-To: References: Message-ID: <7y7xTQ5Z-VGQN8WZ-WedEjTaUUhL0prViiRlUvMMEmw=.013ded91-6a38-433b-adb0-91ff2fb943f5@github.com> On Fri, 9 Sep 2022 18:54:29 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixes for Dan > > Marked as reviewed by dcubed (Reviewer). Thanks @dcubed-ojdk ! ------------- PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Mon Sep 12 07:20:56 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 12 Sep 2022 07:20:56 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 18:54:18 GMT, Daniel D. Daugherty wrote: >> add_operation() arms poll. >> try_process() reads JavaThread state. >> >> Since are allowing the CPU to do reordering of instructions, try_process() can see e.g. state in_native after arming the poll. >> Normally this would be safe, but since we now allow reordering it's not. >> By emitting the system membar we know that if we see in_native that thread will see the armed poll. >> >> EDIT: >> You can also see long comment from me above. >> But yes it's not clear that add_operation() and try_process() are effected by this race when using system membar. > > How about a comment above the emit(): > // Separate the poll() in add_operation() above() from the read of JavaThread state > // in the try_process() call below. Fixed ------------- PR: https://git.openjdk.org/jdk/pull/10123 From kevinw at openjdk.org Mon Sep 12 08:30:43 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 12 Sep 2022 08:30:43 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread [v2] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 08:42:13 GMT, Kevin Walls wrote: >> This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). >> >> A JVMTI operation could call threadObj() and clear the Windows GetLastError value. >> >> Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Comment update Thanks Chris, David and Dan. Dan, will update with those changes shortly, and now I know this one is going in I'll get that other stress test I had into a new JBS bug and link it. ------------- PR: https://git.openjdk.org/jdk/pull/10147 From duke at openjdk.org Mon Sep 12 08:49:18 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 12 Sep 2022 08:49:18 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable [v3] In-Reply-To: References: Message-ID: > Hi! > > Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. > > When I've left ResourceMarks in place I've also commented which calls requires them. > > This passes tier1, tier2 tests. Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Track invariant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10142/files - new: https://git.openjdk.org/jdk/pull/10142/files/24dd048c..0532bedf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=01-02 Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10142.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10142/head:pull/10142 PR: https://git.openjdk.org/jdk/pull/10142 From kevinw at openjdk.org Mon Sep 12 09:41:27 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 12 Sep 2022 09:41:27 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread [v3] In-Reply-To: References: Message-ID: > This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). > > A JVMTI operation could call threadObj() and clear the Windows GetLastError value. > > Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: nits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10147/files - new: https://git.openjdk.org/jdk/pull/10147/files/8de54561..30cf2b16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10147&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10147&range=01-02 Stats: 8 lines in 1 file changed: 4 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10147.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10147/head:pull/10147 PR: https://git.openjdk.org/jdk/pull/10147 From duke at openjdk.org Mon Sep 12 10:05:52 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 12 Sep 2022 10:05:52 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable [v4] In-Reply-To: References: Message-ID: > Hi! > > Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. > > When I've left ResourceMarks in place I've also commented which calls requires them. > > This passes tier1, tier2 tests. Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Remove invariant tracking Too much depends on this invariant not being met. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10142/files - new: https://git.openjdk.org/jdk/pull/10142/files/0532bedf..700f91b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=02-03 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10142.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10142/head:pull/10142 PR: https://git.openjdk.org/jdk/pull/10142 From shade at openjdk.org Mon Sep 12 10:05:54 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 12 Sep 2022 10:05:54 GMT Subject: RFR: 8293566: RISC-V: Clean up push and pop registers [v5] In-Reply-To: <5lizafw-lLfG0eVda9HRcR6luI36yMlCmW3zPnKtoec=.0af61ab8-34b5-45b1-98eb-522e93b1bc66@github.com> References: <5lizafw-lLfG0eVda9HRcR6luI36yMlCmW3zPnKtoec=.0af61ab8-34b5-45b1-98eb-522e93b1bc66@github.com> Message-ID: <0ng9PBxridZR70yDqgWXh_U6Ndwlbi5emq5FlDKkhiU=.b6c24e83-8e12-4f24-97cf-958b7525ebe5@github.com> On Mon, 12 Sep 2022 02:34:56 GMT, Feilong Jiang wrote: >> Currently, riscv port has two implementations of `push_reg` and `pop_reg`. >> The bitset version can be replaced with the RegSet version for better readability. >> >> For example, if we want to push x10 and x11, pushing register with bitset would be like: >> >> push_reg(0xc00, sp) >> >> >> while pushing register with RegSet will be more clear: >> >> push_reg(RegSet::of(x10, x11), sp); >> >> >> Testing: >> >> - hotspot and jdk ter1 on QEMU without new failures > > Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: > > fix Looks good to me. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10227 From ayang at openjdk.org Mon Sep 12 10:06:51 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 12 Sep 2022 10:06:51 GMT Subject: RFR: 8293544: G1: Add comment in G1BarrierSetC1::pre_barrier In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 13:30:58 GMT, Albert Mingkun Yang wrote: > A comment-only change in G1 pre-barrier to explain the redundant is-marking-active check. Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/10219 From ayang at openjdk.org Mon Sep 12 10:09:51 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 12 Sep 2022 10:09:51 GMT Subject: Integrated: 8293544: G1: Add comment in G1BarrierSetC1::pre_barrier In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 13:30:58 GMT, Albert Mingkun Yang wrote: > A comment-only change in G1 pre-barrier to explain the redundant is-marking-active check. This pull request has now been integrated. Changeset: d5aae010 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/d5aae0103a7c12db31f671dc9feb0976e13e4047 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod 8293544: G1: Add comment in G1BarrierSetC1::pre_barrier Reviewed-by: kbarrett, sjohanss ------------- PR: https://git.openjdk.org/jdk/pull/10219 From mdoerr at openjdk.org Mon Sep 12 10:10:58 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 12 Sep 2022 10:10:58 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v7] In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 07:20:54 GMT, Robbin Ehn wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Added comment Thanks for the cleanup and improved comments! LGTM. I think omitting the fence in `transition_from_native` would be an interesting follow-up for the future as these transitions are not uncommon (and also used by JIT compiler threads). ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.org/jdk/pull/10123 From rehn at openjdk.org Mon Sep 12 10:20:03 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 12 Sep 2022 10:20:03 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v7] In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 10:08:41 GMT, Martin Doerr wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment > > Thanks for the cleanup and improved comments! LGTM. > I think omitting the fence in `transition_from_native` would be an interesting follow-up for the future as these transitions are not uncommon (and also used by JIT compiler threads). Thanks again @TheRealMDoerr! Yes, I agree that is a good candidate! ------------- PR: https://git.openjdk.org/jdk/pull/10123 From tschatzl at openjdk.org Mon Sep 12 10:34:18 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 12 Sep 2022 10:34:18 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Message-ID: <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> > Hi all, > > can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? > > This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. > > Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' of gh:tschatzl/jdk into 8256265-parallel-evac-failure - disable G1EvacuationFailureALot by default again - Remove unneeded clear metadata phase - Remove debug code - More refactoring - Initial cleanup - some refactoring, fix clearing of opt index in cset - fix test - some cleanup - Cleanup, phase names, fixes - ... and 2 more: https://git.openjdk.org/jdk/compare/37df5f56...2628451d ------------- Changes: https://git.openjdk.org/jdk/pull/9980/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9980&range=01 Stats: 498 lines in 22 files changed: 271 ins; 97 del; 130 mod Patch: https://git.openjdk.org/jdk/pull/9980.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9980/head:pull/9980 PR: https://git.openjdk.org/jdk/pull/9980 From duke at openjdk.org Mon Sep 12 11:14:41 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 12 Sep 2022 11:14:41 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable [v4] In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 10:05:52 GMT, Johan Sj?l?n wrote: >> Hi! >> >> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. >> >> When I've left ResourceMarks in place I've also commented which calls requires them. >> >> This passes tier1, tier2 tests. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Remove invariant tracking > > Too much depends on this invariant not being met. I wanted to add an invariant that the stringStream is not used after ``::base()` is called, but that invariant is broken in production (in a safe manner), so it can't be added. ------------- PR: https://git.openjdk.org/jdk/pull/10142 From ayang at openjdk.org Mon Sep 12 11:53:43 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 12 Sep 2022 11:53:43 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> Message-ID: On Mon, 12 Sep 2022 10:34:18 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? >> >> This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. >> >> Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge branch 'master' of gh:tschatzl/jdk into 8256265-parallel-evac-failure > - disable G1EvacuationFailureALot by default again > - Remove unneeded clear metadata phase > - Remove debug code > - More refactoring > - Initial cleanup > - some refactoring, fix clearing of opt index in cset > - fix test > - some cleanup > - Cleanup, phase names, fixes > - ... and 2 more: https://git.openjdk.org/jdk/compare/37df5f56...2628451d src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2948: > 2946: > 2947: void G1CollectedHeap::clear_bitmap_for_region(HeapRegion* hr, bool update_tams) { > 2948: concurrent_mark()->clear_bitmap_for_region(hr, update_tams); Instead of adding one more arg, I wonder if it's clearer to move the operation on `tams` to higher-level caller(s). src/hotspot/share/gc/g1/g1EvacFailure.cpp line 254: > 252: _chunk_size = static_cast(HeapRegion::GrainWords / _num_chunks_per_region); > 253: > 254: log_debug(gc, ergo)("Initializing removing self forwards with %u chunks per region given %u workers", `num_workers` seems to be used only for logging; I wonder if this can be dropped or moved to another place. It's odd that this task reports #workers but others don't. src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 632: > 630: // Mark the failing object in the marking bitmap and later use the bitmap to handle > 631: // evacuation failure recovery. > 632: _g1h->mark_evac_failure_object(_worker_id, old, word_sz); The same live-size is calculated again in `process_chunk`, isn't it? src/hotspot/share/gc/g1/g1RemSet.cpp line 112: > 110: // Testing showed that 64 for 1M/2M region, 128 for 4M/8M regions, 256 for 16/32M regions, > 111: // and so on seems to be such a good trade-off. > 112: static uint get_chunks_per_region(uint log_region_size) { I actually think the concrete examples (`64 for 1M/2M region ...`) make this method easy to comprehend. Could you keep them? src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 373: > 371: bool do_heap_region(HeapRegion* r) override { > 372: G1CollectedHeap::heap()->clear_bitmap_for_region(r, false /* update_tams */); > 373: return false; I wonder if it's possible to assert `tams == bottom` here. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From fyang at openjdk.org Mon Sep 12 13:40:48 2022 From: fyang at openjdk.org (Fei Yang) Date: Mon, 12 Sep 2022 13:40:48 GMT Subject: RFR: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at [v5] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 12:06:38 GMT, Axel Boldt-Christmas wrote: >> Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. >> >> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. >> >> Testing: Oracle platforms tier 1-3 > > Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: > > - Push r10 using push and pop > - Fix Argument Comments Marked as reviewed by fyang (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10161 From dcubed at openjdk.org Mon Sep 12 14:40:46 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 12 Sep 2022 14:40:46 GMT Subject: RFR: 8292591: Experimentally add back barrier-less Java thread transitions [v7] In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 07:20:54 GMT, Robbin Ehn wrote: >> Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) >> >> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. >> >> Passes t1-7 with option forced on, also passes t1-4 as is in this PR. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Added comment Marked as reviewed by dcubed (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10123 From duke at openjdk.org Mon Sep 12 15:36:47 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Mon, 12 Sep 2022 15:36:47 GMT Subject: RFR: 8293618: x86: Wrong code generation in class Assembler Message-ID: Hi, This patch fixes some issues in the code generation of x86 assembler: - `Assembler::testl` misses `prefix(dst)` - `Assembler::addw` misses the 0x66 prefix - `Assembler::emit_operand` needs the length of the instruction from the address operand, this is often forgotten, making this parameter explicit to prevent potential issues - The assembler should not do optimisations that change the actual emitted instructions, these should be moved to `MacroAssembler` instead AFAICT there is no failure due to these mistakes. Please take a look and give reviews. Thanks you very much. ------------- Commit messages: - fix code generation Changes: https://git.openjdk.org/jdk/pull/10240/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10240&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293618 Stats: 540 lines in 5 files changed: 62 ins; 25 del; 453 mod Patch: https://git.openjdk.org/jdk/pull/10240.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10240/head:pull/10240 PR: https://git.openjdk.org/jdk/pull/10240 From cjplummer at openjdk.org Mon Sep 12 17:52:43 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Sep 2022 17:52:43 GMT Subject: RFR: 8293339: vm/jvmti/StopThread/stop001/stop00103 crashes with SIGSEGV in Continuation::is_continuation_mounted In-Reply-To: References: Message-ID: On Sat, 10 Sep 2022 00:05:22 GMT, Serguei Spitsyn wrote: > I was not able to reproduce this issue in thousands of mach5 runs on multiple platforms. However, the root cause seems to be pretty simple. A JvmtiVTMSTransitionDisabler needs to be added to make the JVM TI StopThread function to be VTMS (Virtual Thread Mount state) transition safe. > > So the fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmtiEnv.cpp b/src/hotspot/share/prims/jvmtiEnv.cpp > index a9efe01c92e..f5e9176230a 100644 > --- a/src/hotspot/share/prims/jvmtiEnv.cpp > +++ b/src/hotspot/share/prims/jvmtiEnv.cpp > @@ -1182,6 +1182,8 @@ JvmtiEnv::ResumeAllVirtualThreads(jint except_count, const jthread* except_list) > jvmtiError > JvmtiEnv::StopThread(jthread thread, jobject exception) { > JavaThread* current_thread = JavaThread::current(); > + > + JvmtiVTMSTransitionDisabler disabler; > ThreadsListHandle tlh(current_thread); > JavaThread* java_thread = NULL; > oop thread_oop = NULL; Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10235 From shade at openjdk.org Mon Sep 12 18:04:07 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 12 Sep 2022 18:04:07 GMT Subject: RFR: 8293660: Fix frame::sender_for_compiled_frame frame size assert Message-ID: The condition and assert messages are contradicting each other here: frame frame::sender_for_compiled_frame(RegisterMap* map) const { ... assert(_cb->frame_size() >= 0, "must have non-zero frame size"); intptr_t* sender_sp = unextended_sp() + _cb->frame_size(); I found this in x86_32 Loom port, where a entry generator bug caused zero-sized frames. I believe the assert message is correct, and the condition is not: sender SP should be different from (unextended) SP. In fact, if allowed to proceed, the tests can then fail the later assert, assuming `sp() == unextended_sp()`: assert(sender_sp != sp(), "must have changed"); This code predates OpenJDK history, and assert was copy-pasted in this form to many arches. Additional testing: - [x] Linux x86_64 fastdebug `tier1` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/10242/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10242&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293660 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10242.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10242/head:pull/10242 PR: https://git.openjdk.org/jdk/pull/10242 From eastigeevich at openjdk.org Mon Sep 12 18:57:35 2022 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Mon, 12 Sep 2022 18:57:35 GMT Subject: RFR: 8287394: AArch64: Remove cbuf parameter from far_call/far_jump/trampoline_call Message-ID: `far_call`/`far_jump`/`trampoline_call` have parameter `cbuf` with the default value `NULL`. We always call `far_call`/`far_jump` with `NULL`. We call `trampoline_call` with either `NULL` or the `CodeBuffer` currently used by `MacroAssembler`. If not `NULL` we mark a trampoline call position. Andrew Haley(@theRealAph) in https://github.com/openjdk/jdk/pull/8564#discussion_r871062342 suggests to remove it. This PR removes the parameter. In the case of `trampoline_call` we explicitly return the position of the generated trampoline calls. All places using the position of the generated trampoline call are updated. Tested with release and fastdebug builds: - `gtest`: Passed. - `tier1`/`tier2`: Passed. ------------- Commit messages: - 8287394: AArch64: Remove the cbuf argument from far_call/far_jump/trampoline_call Changes: https://git.openjdk.org/jdk/pull/10244/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10244&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287394 Stats: 27 lines in 5 files changed: 0 ins; 9 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/10244.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10244/head:pull/10244 PR: https://git.openjdk.org/jdk/pull/10244 From amenkov at openjdk.org Mon Sep 12 20:12:05 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 12 Sep 2022 20:12:05 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v4] In-Reply-To: References: Message-ID: > The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) > > cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. > After successful RedefineClasses it should be reset. > The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Dan's feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10032/files - new: https://git.openjdk.org/jdk/pull/10032/files/9bc08346..fa7aca43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=02-03 Stats: 27 lines in 3 files changed: 12 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/10032.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10032/head:pull/10032 PR: https://git.openjdk.org/jdk/pull/10032 From amenkov at openjdk.org Mon Sep 12 20:17:55 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 12 Sep 2022 20:17:55 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v3] In-Reply-To: References: Message-ID: On Sat, 10 Sep 2022 15:11:33 GMT, Daniel D. Daugherty wrote: > I like the fact that the fix is small and I really like the new test. I only have minor comments and a couple of questions. Thank you for the review > Please run these changes thru Tier[456] since that's where JVM/TI tests run in different configs w/ different options. In progress > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4333: > >> 4331: >> 4332: if (scratch_class->get_cached_class_file() != the_class->get_cached_class_file()) { >> 4333: // 1. the_class doesn't have a cache yet, scratch_class does have. > > typo: s/does have./does have a cache./ Fixed > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4337: > >> 4335: // are multiple concurrent RetransformClasses calls on different threads. >> 4336: // the_class and scratch_class have the same cached bytes, but different buffers. >> 4337: // In such cases we need to deallocate one of the buffer. > > typo: s/the buffer/the buffers/ fixed > typo: s/has cached/have cached/ The comment is about processing RedefineClasses when the_class has cached bytes. So it should be "has" > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4340: > >> 4338: // 3. RedefineClasses and the_class has cached bytes from previous transformation. >> 4339: // In the case we need to use class bytes from scratch_class. >> 4340: if (the_class->get_cached_class_file() != 0) { > > s/!= 0/!= nullptr/ fixed. > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 174: > >> 172: throw new RuntimeException("Redefine error (ver = " + ver + ")"); >> 173: } >> 174: // verity ClassFileLoadHook get expected class bytes > > typos: s/verity/verify/ > s/get/gets the/ fixed > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 197: > >> 195: int testCase; >> 196: try { >> 197: testCase= Integer.valueOf(args[0]); > > nit: please add space before '=' fixed. > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 215: > >> 213: redefine(1); // cached class bytes are not set >> 214: retransform(2, 1); // sets cached class bytes to ver 1 >> 215: redefine(3); // resets cached class bytes > > Perhaps: > ```// resets cached class bytes to nullptr``` done > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 224: > >> 222: redefine(1); // cached class bytes are not set >> 223: retransform(2, 1); // sets cached class bytes to ver 1 >> 224: redefine(3); // resets cached class bytes > > Perhaps: > ```// resets cached class bytes to nullptr``` done > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 232: > >> 230: test("Retransform-Redefine-Retransform-Retransform", () -> { >> 231: retransform(1, 0); // sets cached class bytes to ver 0 (initially loaded) >> 232: redefine(2); // resets cached class bytes > > Perhaps: > ```// resets cached class bytes to nullptr``` done > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 26: > >> 24: #include >> 25: #include >> 26: #include > > Should be in alpha sort order? done > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 48: > >> 46: } >> 47: >> 48: class ClassFileLoadHookHelper { > > A short comment describing the purpose of the `ClassFileLoadHookHelper` would > be helpful to folks that only have a high level understanding of RedefineClasses() > and RetransformClasses(). > > You did a very good job encapsulating support for a complicated sets of APIs > into this helper. Added short description > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 215: > >> 213: caps.can_redefine_classes = 1; >> 214: caps.can_retransform_classes = 1; >> 215: jvmti->AddCapabilities(&caps); > > Why no error check here? Added ------------- PR: https://git.openjdk.org/jdk/pull/10032 From amenkov at openjdk.org Mon Sep 12 20:30:04 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 12 Sep 2022 20:30:04 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v5] In-Reply-To: References: Message-ID: > The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) > > cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. > After successful RedefineClasses it should be reset. > The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: s/verity/verify/ ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10032/files - new: https://git.openjdk.org/jdk/pull/10032/files/fa7aca43..13264736 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10032.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10032/head:pull/10032 PR: https://git.openjdk.org/jdk/pull/10032 From amenkov at openjdk.org Mon Sep 12 20:30:05 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 12 Sep 2022 20:30:05 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v3] In-Reply-To: References: Message-ID: <8quzXh-4dzhc3QOdxICE7br12AsKJbLMfSU_55X1mRQ=.fa398076-a388-4c70-906f-fdc1cfc301ba@github.com> On Sat, 10 Sep 2022 14:39:54 GMT, Daniel D. Daugherty wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> updated test. comments, code reorg > > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 240: > >> 238: case 5: >> 239: test("Redefine-Retransform-Redefine-Retransform with CFLH", () -> { >> 240: redefine(1, 5); // CFLH sets cached class bytes to ver 1 > > I'm having trouble understanding why the CFLH version is '5' here. > Update: I _think_ this is just to have the CFLH return a different version > of the class bytes before the RedefineClasses() call does its work. I > don't understand why you want to do this... Test cases 1-4 are from the bug description. I added test cases 5 & 6 to verify additional code paths - they are the same as 3 & 4, but in RedefineClasses we provide new class bytes in CFLH. I.e. in cases 3 and 4 after RedefineClasses classes have no cached bytes and class bytes are reconstituted in the subsequent Retransform; In case 5 and 6 cache_bytes buffer is created during RedefineClasses, RetransformClasses use existing cache. > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 242: > >> 240: redefine(1, 5); // CFLH sets cached class bytes to ver 1 >> 241: retransform(2, 1); // uses existing cache >> 242: redefine(3, 6); // resets cached class bytes, > > I'm having trouble understanding why the CFLH version is '6' here. > Update: I _think_ this is just to have the CFLH return a different version > of the class bytes before the RedefineClasses() call does its work. I > don't understand why you want to do this... > > Perhaps: > ```// resets cached class bytes to nullptr,``` Fixed the comment > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 251: > >> 249: test("Retransform-Redefine-Retransform-Retransform with CFLH", () -> { >> 250: retransform(1, 0); // sets cached class bytes to ver 0 (initially loaded) >> 251: redefine(2, 5); // resets cached class bytes, > > I'm having trouble understanding why the CFLH version is '5' here. > Update: I _think_ this is just to have the CFLH return a different version > of the class bytes before the RedefineClasses() call does its work. I > don't understand why you want to do this... > > Perhaps > ```// resets cached class bytes to nullptr,``` Fixed the comment ------------- PR: https://git.openjdk.org/jdk/pull/10032 From lmesnik at openjdk.org Mon Sep 12 21:50:39 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 12 Sep 2022 21:50:39 GMT Subject: RFR: 8293339: vm/jvmti/StopThread/stop001/stop00103 crashes with SIGSEGV in Continuation::is_continuation_mounted In-Reply-To: References: Message-ID: On Sat, 10 Sep 2022 00:05:22 GMT, Serguei Spitsyn wrote: > I was not able to reproduce this issue in thousands of mach5 runs on multiple platforms. However, the root cause seems to be pretty simple. A JvmtiVTMSTransitionDisabler needs to be added to make the JVM TI StopThread function to be VTMS (Virtual Thread Mount state) transition safe. > > So the fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmtiEnv.cpp b/src/hotspot/share/prims/jvmtiEnv.cpp > index a9efe01c92e..f5e9176230a 100644 > --- a/src/hotspot/share/prims/jvmtiEnv.cpp > +++ b/src/hotspot/share/prims/jvmtiEnv.cpp > @@ -1182,6 +1182,8 @@ JvmtiEnv::ResumeAllVirtualThreads(jint except_count, const jthread* except_list) > jvmtiError > JvmtiEnv::StopThread(jthread thread, jobject exception) { > JavaThread* current_thread = JavaThread::current(); > + > + JvmtiVTMSTransitionDisabler disabler; > ThreadsListHandle tlh(current_thread); > JavaThread* java_thread = NULL; > oop thread_oop = NULL; Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10235 From sspitsyn at openjdk.org Mon Sep 12 21:57:01 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 12 Sep 2022 21:57:01 GMT Subject: RFR: 8293339: vm/jvmti/StopThread/stop001/stop00103 crashes with SIGSEGV in Continuation::is_continuation_mounted In-Reply-To: References: Message-ID: On Sat, 10 Sep 2022 00:05:22 GMT, Serguei Spitsyn wrote: > I was not able to reproduce this issue in thousands of mach5 runs on multiple platforms. However, the root cause seems to be pretty simple. A JvmtiVTMSTransitionDisabler needs to be added to make the JVM TI StopThread function to be VTMS (Virtual Thread Mount state) transition safe. > > So the fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmtiEnv.cpp b/src/hotspot/share/prims/jvmtiEnv.cpp > index a9efe01c92e..f5e9176230a 100644 > --- a/src/hotspot/share/prims/jvmtiEnv.cpp > +++ b/src/hotspot/share/prims/jvmtiEnv.cpp > @@ -1182,6 +1182,8 @@ JvmtiEnv::ResumeAllVirtualThreads(jint except_count, const jthread* except_list) > jvmtiError > JvmtiEnv::StopThread(jthread thread, jobject exception) { > JavaThread* current_thread = JavaThread::current(); > + > + JvmtiVTMSTransitionDisabler disabler; > ThreadsListHandle tlh(current_thread); > JavaThread* java_thread = NULL; > oop thread_oop = NULL; Chris and Leonid, thank you for review! ------------- PR: https://git.openjdk.org/jdk/pull/10235 From sspitsyn at openjdk.org Mon Sep 12 21:59:31 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 12 Sep 2022 21:59:31 GMT Subject: Integrated: 8293339: vm/jvmti/StopThread/stop001/stop00103 crashes with SIGSEGV in Continuation::is_continuation_mounted In-Reply-To: References: Message-ID: On Sat, 10 Sep 2022 00:05:22 GMT, Serguei Spitsyn wrote: > I was not able to reproduce this issue in thousands of mach5 runs on multiple platforms. However, the root cause seems to be pretty simple. A JvmtiVTMSTransitionDisabler needs to be added to make the JVM TI StopThread function to be VTMS (Virtual Thread Mount state) transition safe. > > So the fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmtiEnv.cpp b/src/hotspot/share/prims/jvmtiEnv.cpp > index a9efe01c92e..f5e9176230a 100644 > --- a/src/hotspot/share/prims/jvmtiEnv.cpp > +++ b/src/hotspot/share/prims/jvmtiEnv.cpp > @@ -1182,6 +1182,8 @@ JvmtiEnv::ResumeAllVirtualThreads(jint except_count, const jthread* except_list) > jvmtiError > JvmtiEnv::StopThread(jthread thread, jobject exception) { > JavaThread* current_thread = JavaThread::current(); > + > + JvmtiVTMSTransitionDisabler disabler; > ThreadsListHandle tlh(current_thread); > JavaThread* java_thread = NULL; > oop thread_oop = NULL; This pull request has now been integrated. Changeset: d3f7e3b4 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/d3f7e3b41779427a0765bdd40a3627cb0490cbce Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8293339: vm/jvmti/StopThread/stop001/stop00103 crashes with SIGSEGV in Continuation::is_continuation_mounted Reviewed-by: cjplummer, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/10235 From kvn at openjdk.org Mon Sep 12 22:07:03 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 12 Sep 2022 22:07:03 GMT Subject: RFR: 8293329: x86: Improve handling of constants in AES/GHASH stubs [v5] In-Reply-To: References: Message-ID: <57vjopa9yEuDW7N_EMOSqafSifvD8uemizDCMlHFYOA=.46cf6a86-5dad-468b-8020-a2b027a6b557@github.com> On Fri, 9 Sep 2022 00:35:47 GMT, Vladimir Ivanov wrote: >> Pre-generating constants saves on startup and static/dynamic footprint a bit, plus simplifies bootstrapping logic. >> >> As a downside, constants aren't guaranteed to be always reachable anymore, but since they are used from stubs, finding a scratch register when needed is not a problem. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 w/ `-XX:+ForceUnreachable` >> - [x] x86_32 build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > fix merge Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10152 From kvn at openjdk.org Mon Sep 12 22:07:03 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 12 Sep 2022 22:07:03 GMT Subject: RFR: 8293329: x86: Improve handling of constants in AES/GHASH stubs [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 00:40:53 GMT, Vladimir Ivanov wrote: > > I would like to see the effect on performance. In worst case constants will not be reachable always. Changes are fine if the effect is negligible. > > I ran AES microbenchmarks and didn't notice any noticeable difference between baseline and the patched version w/ `-XX:+ForceUnreachable` in throughput. Good. ------------- PR: https://git.openjdk.org/jdk/pull/10152 From vlivanov at openjdk.org Mon Sep 12 22:55:54 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 12 Sep 2022 22:55:54 GMT Subject: RFR: 8293329: x86: Improve handling of constants in AES/GHASH stubs [v5] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 00:35:47 GMT, Vladimir Ivanov wrote: >> Pre-generating constants saves on startup and static/dynamic footprint a bit, plus simplifies bootstrapping logic. >> >> As a downside, constants aren't guaranteed to be always reachable anymore, but since they are used from stubs, finding a scratch register when needed is not a problem. >> >> Testing: >> - [x] hs-tier1 - hs-tier4 w/ `-XX:+ForceUnreachable` >> - [x] x86_32 build > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > fix merge Thanks for the review, Vladimir. ------------- PR: https://git.openjdk.org/jdk/pull/10152 From vlivanov at openjdk.org Mon Sep 12 22:55:55 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 12 Sep 2022 22:55:55 GMT Subject: Integrated: 8293329: x86: Improve handling of constants in AES/GHASH stubs In-Reply-To: References: Message-ID: <90QU-3ofXWXhxD5_osyjVSRQH9iG0BifEvpHkukGhlM=.32e17d0b-bc04-4449-83f1-2cd6874a818d@github.com> On Fri, 2 Sep 2022 23:24:32 GMT, Vladimir Ivanov wrote: > Pre-generating constants saves on startup and static/dynamic footprint a bit, plus simplifies bootstrapping logic. > > As a downside, constants aren't guaranteed to be always reachable anymore, but since they are used from stubs, finding a scratch register when needed is not a problem. > > Testing: > - [x] hs-tier1 - hs-tier4 w/ `-XX:+ForceUnreachable` > - [x] x86_32 build This pull request has now been integrated. Changeset: 155b10ae Author: Vladimir Ivanov URL: https://git.openjdk.org/jdk/commit/155b10ae86efa6543d3192e201d14f1e06c3e39d Stats: 503 lines in 6 files changed: 152 ins; 227 del; 124 mod 8293329: x86: Improve handling of constants in AES/GHASH stubs Reviewed-by: kvn ------------- PR: https://git.openjdk.org/jdk/pull/10152 From fjiang at openjdk.org Tue Sep 13 00:56:50 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 13 Sep 2022 00:56:50 GMT Subject: RFR: 8293566: RISC-V: Clean up push and pop registers [v5] In-Reply-To: References: <5lizafw-lLfG0eVda9HRcR6luI36yMlCmW3zPnKtoec=.0af61ab8-34b5-45b1-98eb-522e93b1bc66@github.com> Message-ID: <5cYVtQLcUCby7oczP98_9FHgQcT3U7IFt_vLBu-u6cI=.4564e93d-6efc-403b-af93-cb256ac1f73b@github.com> On Mon, 12 Sep 2022 02:47:43 GMT, Fei Yang wrote: >> Feilong Jiang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix > > Updated change looks good. Thanks. @RealFYang @shipilev --Thanks for reviewing! ------------- PR: https://git.openjdk.org/jdk/pull/10227 From fjiang at openjdk.org Tue Sep 13 01:10:17 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 13 Sep 2022 01:10:17 GMT Subject: Integrated: 8293566: RISC-V: Clean up push and pop registers In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 08:31:02 GMT, Feilong Jiang wrote: > Currently, riscv port has two implementations of `push_reg` and `pop_reg`. > The bitset version can be replaced with the RegSet version for better readability. > > For example, if we want to push x10 and x11, pushing register with bitset would be like: > > push_reg(0xc00, sp) > > > while pushing register with RegSet will be more clear: > > push_reg(RegSet::of(x10, x11), sp); > > > Testing: > > - hotspot and jdk ter1 on QEMU without new failures This pull request has now been integrated. Changeset: 68645ebf Author: Feilong Jiang Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/68645ebffb28605fa2c6afef11f8265fd350b5cb Stats: 63 lines in 5 files changed: 13 ins; 18 del; 32 mod 8293566: RISC-V: Clean up push and pop registers Reviewed-by: fyang, shade ------------- PR: https://git.openjdk.org/jdk/pull/10227 From dzhang at openjdk.org Tue Sep 13 02:47:26 2022 From: dzhang at openjdk.org (Dingli Zhang) Date: Tue, 13 Sep 2022 02:47:26 GMT Subject: RFR: JDK-8293676: riscv: Trampoline not created for far runtime targets outside small CodeCache Message-ID: Follow up [JDK-8286314](https://bugs.openjdk.org/browse/JDK-8286314), this case also exists in riscv. `relocInfo::runtime_call_type` calls can have targets inside or outside CodeCache. If offsets to the targets are not in range, trampoline calls must be used. Currently trampolines for calls are generated based on the size of CodeCache and the maximum possible branch range. If the size of CodeCache is smaller than the range, no trampoline is generated. This works well if a target is inside CodeCache. It does not work if a target is outside CodeCache and CodeCache size is smaller than the maximum possible branch range. ## Testing: - hotspot/jdk tier1 on unmatched board ------------- Commit messages: - Port JDK-8286314 to RISC-V Changes: https://git.openjdk.org/jdk/pull/10246/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10246&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293676 Stats: 17 lines in 1 file changed: 15 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10246.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10246/head:pull/10246 PR: https://git.openjdk.org/jdk/pull/10246 From duke at openjdk.org Tue Sep 13 03:11:34 2022 From: duke at openjdk.org (hev) Date: Tue, 13 Sep 2022 03:11:34 GMT Subject: RFR: 8293416: ZGC: Set mark bit with unconditional atomic ops [v3] In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 08:15:28 GMT, hev wrote: >> **Summary** >> Support to set ZGC mark bit with unconditional atomic ops. >> >> **Motivation** >> ZGC currently modify mark-bitmap by a conditional atomic operation (cmpxchg). This way is not optimal, which will retry the loop when cmpxchg fails. >> >> **Description** >> First, This patch-set add an new unconditional atomic operation: Atomic::fetch_and_or, which is implemented in different ways for different CPU architectures: >> >> * Exclusive access: Non-nested loop >> >> >> retry: >> ll old_val, addr >> or new_val, old_val, set_val >> sc new_val, addr >> beq retry >> >> >> * Atomic access: One instruction >> >> >> ldset old_val, set_val, addr >> >> >> * Generic: Fallback to cmpxchg or use c++ __atomic_fetch_or >> >> **Testing** >> * jtreg tests >> * benchmark tests > > hev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - ZGC: Set mark bit with unconditional atomic ops > - BitMap: Set bit with unconditional atomic ops > - Atomic: Add bitset functions ## Micro Benchmark 2 Benchmark: https://gist.github.com/heiher/a57c787e2f2d4f313df8cdf13086824e ### How to run gcc -O3 -o bench atomic-mark-bench.c -pthread perf stat ./bench norm perf stat ./bench fast ### Results Real time elapsed in seconds (Less is better) | CPU/Threads/Mode | Score 1 | Score 2 | Score 3 | Score 4 | Score 5 | Score 6 | |--------|--------|--------|--------|--------|--------|--------| | Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz | | 16-Thread NORM | 40.89 | 39.74 | 41.26 | 41.70 | 41.30 | 41.48 | | 16-Thread FAST | 0.03 | 0.03 | 0.03 | 0.03 | 0.03 | 0.03 | | HUAWEI Kunpeng 920 @ 2.60GHz | | 16-Thread NORM | 98.44 | 94.73 | 99.05 | 93.95 | 97.34 | 94.95 | | 16-Thread FAST | 0.11 | 0.11 | 0.11 | 0.11 | 0.11 | 0.11 | ------------- PR: https://git.openjdk.org/jdk/pull/10182 From dlong at openjdk.org Tue Sep 13 03:14:44 2022 From: dlong at openjdk.org (Dean Long) Date: Tue, 13 Sep 2022 03:14:44 GMT Subject: RFR: 8293660: Fix frame::sender_for_compiled_frame frame size assert In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 17:56:17 GMT, Aleksey Shipilev wrote: > The condition and assert messages are contradicting each other here: > > > frame frame::sender_for_compiled_frame(RegisterMap* map) const { > ... > assert(_cb->frame_size() >= 0, "must have non-zero frame size"); > intptr_t* sender_sp = unextended_sp() + _cb->frame_size(); > > > I found this in x86_32 Loom port, where a entry generator bug caused zero-sized frames. I believe the assert message is correct, and the condition is not: sender SP should be different from (unextended) SP. In fact, if allowed to proceed, the tests can then fail the later assert, assuming `sp() == unextended_sp()`: > > > assert(sender_sp != sp(), "must have changed"); > > > This code predates OpenJDK history, and assert was copy-pasted in this form to many arches. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` This looks fine. You could probably even use >= 2. More correct would probably be >= metadata_words, but some ports are setting that value to 0, which will probably break things with loom. There are also some places under hotspot/agent/src/share/classes that are doing the equivalent in Java: Assert.that(cb.getFrameSize() > 0, "CodeBlob must have non-zero frame size"); which would probably be low-risk to fix in this PR if you wanted. ------------- Marked as reviewed by dlong (Reviewer). PR: https://git.openjdk.org/jdk/pull/10242 From duke at openjdk.org Tue Sep 13 03:14:45 2022 From: duke at openjdk.org (hev) Date: Tue, 13 Sep 2022 03:14:45 GMT Subject: RFR: 8293416: ZGC: Set mark bit with unconditional atomic ops [v3] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 10:26:45 GMT, Albert Mingkun Yang wrote: >> hev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - ZGC: Set mark bit with unconditional atomic ops >> - BitMap: Set bit with unconditional atomic ops >> - Atomic: Add bitset functions > > src/hotspot/share/gc/z/zBitMap.inline.hpp line 67: > >> 65: inc_live = false; >> 66: return false; >> 67: } > > The fast/slow paths are almost identical. I believe some numbers would be nice to justify the presence of the fast path. I think so. Atomic operations are more expensive than normal memory loads. This is why should split to fast and slow path, although they are almost Identical. The micro benchmark 2 shows it. ------------- PR: https://git.openjdk.org/jdk/pull/10182 From yadongwang at openjdk.org Tue Sep 13 03:15:44 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Tue, 13 Sep 2022 03:15:44 GMT Subject: RFR: JDK-8293676: riscv: Trampoline not created for far runtime targets outside small CodeCache In-Reply-To: References: Message-ID: <9fQJE4dIs25i6ythqY6MQ7FHaKGlK6_ct8vGv3gy8oU=.cd0277d6-884f-4503-9c52-c336d906b20a@github.com> On Tue, 13 Sep 2022 02:41:12 GMT, Dingli Zhang wrote: > Follow up [JDK-8286314](https://bugs.openjdk.org/browse/JDK-8286314), this case also exists in riscv. > > `relocInfo::runtime_call_type` calls can have targets inside or outside CodeCache. If offsets to the targets are not in range, trampoline calls must be used. Currently trampolines for calls are generated based on the size of CodeCache and the maximum possible branch range. If the size of CodeCache is smaller than the range, no trampoline is generated. This works well if a target is inside CodeCache. It does not work if a target is outside CodeCache and CodeCache size is smaller than the maximum possible branch range. > > ## Testing: > > - hotspot/jdk tier1 on unmatched board src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2831: > 2829: address longest_branch_start = (target < CodeCache::low_bound()) ? CodeCache::high_bound() - NativeInstruction::instruction_size > 2830: : CodeCache::low_bound(); > 2831: need_trampoline = !reachable_from_branch_at(longest_branch_start, target); We have only +/-1Mb range in the riscv architecture, which is not enough for CodeCache in most case. In contrast, the branch range is 128 Mb in AArch64. So, is this modification necessary for the rv port? ------------- PR: https://git.openjdk.org/jdk/pull/10246 From shade at openjdk.org Tue Sep 13 06:08:33 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Sep 2022 06:08:33 GMT Subject: RFR: 8293660: Fix frame::sender_for_compiled_frame frame size assert [v2] In-Reply-To: References: Message-ID: > The condition and assert messages are contradicting each other here: > > > frame frame::sender_for_compiled_frame(RegisterMap* map) const { > ... > assert(_cb->frame_size() >= 0, "must have non-zero frame size"); > intptr_t* sender_sp = unextended_sp() + _cb->frame_size(); > > > I found this in x86_32 Loom port, where a entry generator bug caused zero-sized frames. I believe the assert message is correct, and the condition is not: sender SP should be different from (unextended) SP. In fact, if allowed to proceed, the tests can then fail the later assert, assuming `sp() == unextended_sp()`: > > > assert(sender_sp != sp(), "must have changed"); > > > This code predates OpenJDK history, and assert was copy-pasted in this form to many arches. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Also fix SA agent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10242/files - new: https://git.openjdk.org/jdk/pull/10242/files/be483145..b9d0390f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10242&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10242&range=00-01 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10242.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10242/head:pull/10242 PR: https://git.openjdk.org/jdk/pull/10242 From shade at openjdk.org Tue Sep 13 06:08:35 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Sep 2022 06:08:35 GMT Subject: RFR: 8293660: Fix frame::sender_for_compiled_frame frame size assert [v2] In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 03:10:59 GMT, Dean Long wrote: > This looks fine. You could probably even use >= 2. More correct would probably be >= metadata_words, > but some ports are setting that value to 0, which will probably break things with loom. Yeah, I'd prefer to keep the most accepting form. It seems we really want to catch the zero case to guarantee stack walking progress. > There are also some places under hotspot/agent/src/share/classes that are doing the equivalent in Java: > Assert.that(cb.getFrameSize() > 0, "CodeBlob must have non-zero frame size"); > which would probably be low-risk to fix in this PR if you wanted. Fixed those in new commit. ------------- PR: https://git.openjdk.org/jdk/pull/10242 From dzhang at openjdk.org Tue Sep 13 06:45:53 2022 From: dzhang at openjdk.org (Dingli Zhang) Date: Tue, 13 Sep 2022 06:45:53 GMT Subject: RFR: JDK-8293676: riscv: Trampoline not created for far runtime targets outside small CodeCache In-Reply-To: <9fQJE4dIs25i6ythqY6MQ7FHaKGlK6_ct8vGv3gy8oU=.cd0277d6-884f-4503-9c52-c336d906b20a@github.com> References: <9fQJE4dIs25i6ythqY6MQ7FHaKGlK6_ct8vGv3gy8oU=.cd0277d6-884f-4503-9c52-c336d906b20a@github.com> Message-ID: <5N7fge2YoLp_q6OBuFI2OWsXqmfLwYfIQ8HBTbw7hxU=.0879ae2c-c27f-4d62-abc9-3ea83393cfde@github.com> On Tue, 13 Sep 2022 03:12:12 GMT, Yadong Wang wrote: >> Follow up [JDK-8286314](https://bugs.openjdk.org/browse/JDK-8286314), this case also exists in riscv. >> >> `relocInfo::runtime_call_type` calls can have targets inside or outside CodeCache. If offsets to the targets are not in range, trampoline calls must be used. Currently trampolines for calls are generated based on the size of CodeCache and the maximum possible branch range. If the size of CodeCache is smaller than the range, no trampoline is generated. This works well if a target is inside CodeCache. It does not work if a target is outside CodeCache and CodeCache size is smaller than the maximum possible branch range. >> >> ## Testing: >> >> - hotspot/jdk tier1 on unmatched board > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2831: > >> 2829: address longest_branch_start = (target < CodeCache::low_bound()) ? CodeCache::high_bound() - NativeInstruction::instruction_size >> 2830: : CodeCache::low_bound(); >> 2831: need_trampoline = !reachable_from_branch_at(longest_branch_start, target); > > We have only +/-1Mb range in the riscv architecture, which is not enough for CodeCache in most case. In contrast, the branch range is 128 Mb in AArch64. So, is this modification necessary for the rv port? Hi @yadongw , thanks for reviewing. Indeed in riscv64 CodeCache is basically not smaller than branch range (CodeCache initial size is usually 48M by default and the reserved size is usually 240M by default), in riscv64 this optimization seems to be not too meaningful, I apologize for my oversight and I will close this PR. Thanks again. ------------- PR: https://git.openjdk.org/jdk/pull/10246 From dzhang at openjdk.org Tue Sep 13 06:45:54 2022 From: dzhang at openjdk.org (Dingli Zhang) Date: Tue, 13 Sep 2022 06:45:54 GMT Subject: Withdrawn: JDK-8293676: riscv: Trampoline not created for far runtime targets outside small CodeCache In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 02:41:12 GMT, Dingli Zhang wrote: > Follow up [JDK-8286314](https://bugs.openjdk.org/browse/JDK-8286314), this case also exists in riscv. > > `relocInfo::runtime_call_type` calls can have targets inside or outside CodeCache. If offsets to the targets are not in range, trampoline calls must be used. Currently trampolines for calls are generated based on the size of CodeCache and the maximum possible branch range. If the size of CodeCache is smaller than the range, no trampoline is generated. This works well if a target is inside CodeCache. It does not work if a target is outside CodeCache and CodeCache size is smaller than the maximum possible branch range. > > ## Testing: > > - hotspot/jdk tier1 on unmatched board This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10246 From shade at openjdk.org Tue Sep 13 07:03:03 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Sep 2022 07:03:03 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 Message-ID: The bug manifests on PPC64, since `section_by_name` is protected by `#if defined(PPC64) && !defined(ABI_ELFv2)`: * For target hotspot_variant-server_libjvm_objs_elfFile.o: ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/10247/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10247&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293680 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10247.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10247/head:pull/10247 PR: https://git.openjdk.org/jdk/pull/10247 From jiefu at openjdk.org Tue Sep 13 07:13:38 2022 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 13 Sep 2022 07:13:38 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 06:55:34 GMT, Aleksey Shipilev wrote: > The bug manifests on PPC64, since `section_by_name` is protected by `#if defined(PPC64) && !defined(ABI_ELFv2)`: > > > * For target hotspot_variant-server_libjvm_objs_elfFile.o: src/hotspot/share/utilities/elfFile.cpp line 37: > 35: #include "logging/log.hpp" > 36: #include "memory/allocation.inline.hpp" > 37: #include "memory/resourceArea.hpp" Shall we only include `resourceArea.hpp` for `defined(PPC64) && !defined(ABI_ELFv2)`? ------------- PR: https://git.openjdk.org/jdk/pull/10247 From kbarrett at openjdk.org Tue Sep 13 07:22:03 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 13 Sep 2022 07:22:03 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 06:55:34 GMT, Aleksey Shipilev wrote: > The bug manifests on PPC64, since `section_by_name` is protected by `#if defined(PPC64) && !defined(ABI_ELFv2)`: > > > * For target hotspot_variant-server_libjvm_objs_elfFile.o: Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10247 From shade at openjdk.org Tue Sep 13 07:22:03 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Sep 2022 07:22:03 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 07:11:22 GMT, Jie Fu wrote: >> The bug manifests on PPC64, since `section_by_name` is protected by `#if defined(PPC64) && !defined(ABI_ELFv2)`: >> >> >> * For target hotspot_variant-server_libjvm_objs_elfFile.o: > > src/hotspot/share/utilities/elfFile.cpp line 37: > >> 35: #include "logging/log.hpp" >> 36: #include "memory/allocation.inline.hpp" >> 37: #include "memory/resourceArea.hpp" > > Shall we only include `resourceArea.hpp` for `defined(PPC64) && !defined(ABI_ELFv2)`? I don't like complicated include guards in include blocks, so I'd prefer not to. ------------- PR: https://git.openjdk.org/jdk/pull/10247 From kbarrett at openjdk.org Tue Sep 13 07:22:03 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 13 Sep 2022 07:22:03 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 07:16:40 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/utilities/elfFile.cpp line 37: >> >>> 35: #include "logging/log.hpp" >>> 36: #include "memory/allocation.inline.hpp" >>> 37: #include "memory/resourceArea.hpp" >> >> Shall we only include `resourceArea.hpp` for `defined(PPC64) && !defined(ABI_ELFv2)`? > > I don't like complicated include guards in include blocks, so I'd prefer not to. I agree with @shipilev on this. ------------- PR: https://git.openjdk.org/jdk/pull/10247 From kevinw at openjdk.org Tue Sep 13 07:38:02 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 13 Sep 2022 07:38:02 GMT Subject: Integrated: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 14:47:35 GMT, Kevin Walls wrote: > This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). > > A JVMTI operation could call threadObj() and clear the Windows GetLastError value. > > Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. This pull request has now been integrated. Changeset: dfc16e04 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/dfc16e047f1f8adaa8510574d00bf9f958902c43 Stats: 105 lines in 3 files changed: 101 ins; 0 del; 4 mod 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread Reviewed-by: cjplummer, dholmes, dcubed ------------- PR: https://git.openjdk.org/jdk/pull/10147 From mdoerr at openjdk.org Tue Sep 13 07:46:43 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 13 Sep 2022 07:46:43 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 06:55:34 GMT, Aleksey Shipilev wrote: > The bug manifests on PPC64, since `section_by_name` is protected by `#if defined(PPC64) && !defined(ABI_ELFv2)`: > > > * For target hotspot_variant-server_libjvm_objs_elfFile.o: Thanks for fixing! Build has worked for us without this fix because of PCH. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.org/jdk/pull/10247 From shade at openjdk.org Tue Sep 13 07:56:18 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Sep 2022 07:56:18 GMT Subject: RFR: 8293660: Fix frame::sender_for_compiled_frame frame size assert [v3] In-Reply-To: References: Message-ID: > The condition and assert messages are contradicting each other here: > > > frame frame::sender_for_compiled_frame(RegisterMap* map) const { > ... > assert(_cb->frame_size() >= 0, "must have non-zero frame size"); > intptr_t* sender_sp = unextended_sp() + _cb->frame_size(); > > > I found this in x86_32 Loom port, where a entry generator bug caused zero-sized frames. I believe the assert message is correct, and the condition is not: sender SP should be different from (unextended) SP. In fact, if allowed to proceed, the tests can then fail the later assert, assuming `sp() == unextended_sp()`: > > > assert(sender_sp != sp(), "must have changed"); > > > This code predates OpenJDK history, and assert was copy-pasted in this form to many arches. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: - Wrong PR :) - AArch64 part ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10242/files - new: https://git.openjdk.org/jdk/pull/10242/files/b9d0390f..b72caaf6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10242&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10242&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10242.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10242/head:pull/10242 PR: https://git.openjdk.org/jdk/pull/10242 From ayang at openjdk.org Tue Sep 13 08:18:36 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 13 Sep 2022 08:18:36 GMT Subject: RFR: 8293416: ZGC: Set mark bit with unconditional atomic ops [v3] In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 03:12:28 GMT, hev wrote: >> src/hotspot/share/gc/z/zBitMap.inline.hpp line 67: >> >>> 65: inc_live = false; >>> 66: return false; >>> 67: } >> >> The fast/slow paths are almost identical. I believe some numbers would be nice to justify the presence of the fast path. > > I think so. Atomic operations are more expensive than normal memory loads. This is why should split to fast and slow path, although they are almost Identical. The micro benchmark 2 shows it. Thank you for the benchmark results; they are convincing, IMO. ------------- PR: https://git.openjdk.org/jdk/pull/10182 From sjohanss at openjdk.org Tue Sep 13 08:33:00 2022 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 13 Sep 2022 08:33:00 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> Message-ID: On Mon, 12 Sep 2022 11:39:06 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' of gh:tschatzl/jdk into 8256265-parallel-evac-failure >> - disable G1EvacuationFailureALot by default again >> - Remove unneeded clear metadata phase >> - Remove debug code >> - More refactoring >> - Initial cleanup >> - some refactoring, fix clearing of opt index in cset >> - fix test >> - some cleanup >> - Cleanup, phase names, fixes >> - ... and 2 more: https://git.openjdk.org/jdk/compare/37df5f56...2628451d > > src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2948: > >> 2946: >> 2947: void G1CollectedHeap::clear_bitmap_for_region(HeapRegion* hr, bool update_tams) { >> 2948: concurrent_mark()->clear_bitmap_for_region(hr, update_tams); > > Instead of adding one more arg, I wonder if it's clearer to move the operation on `tams` to higher-level caller(s). I agree with Albert, I think moving `hr->note_end_of_clearing();` out of `G1ConcurrentMark::clear_bitmap_for_region()` and handle it where needed is a cleaner approach. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From rehn at openjdk.org Tue Sep 13 08:35:19 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 13 Sep 2022 08:35:19 GMT Subject: Integrated: 8292591: Experimentally add back barrier-less Java thread transitions In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 16:47:58 GMT, Robbin Ehn wrote: > Please consider, only implemented on x64/aarch64 linux/windows. (@TheRealMDoerr have now contributed PPC64) > > On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled. > > Passes t1-7 with option forced on, also passes t1-4 as is in this PR. This pull request has now been integrated. Changeset: 1e1db5de Author: Robbin Ehn URL: https://git.openjdk.org/jdk/commit/1e1db5debd5e37650d7d7345544104a9050f418c Stats: 405 lines in 20 files changed: 377 ins; 1 del; 27 mod 8292591: Experimentally add back barrier-less Java thread transitions Reviewed-by: mdoerr, eosterlund, pchilanomate, dcubed ------------- PR: https://git.openjdk.org/jdk/pull/10123 From aph at openjdk.org Tue Sep 13 08:46:40 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 13 Sep 2022 08:46:40 GMT Subject: RFR: 8287394: AArch64: Remove cbuf parameter from far_call/far_jump/trampoline_call In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 18:50:23 GMT, Evgeny Astigeevich wrote: > `far_call`/`far_jump`/`trampoline_call` have parameter `cbuf` with the default value `NULL`. We always call `far_call`/`far_jump` with `NULL`. We call `trampoline_call` with either `NULL` or the `CodeBuffer` currently used by `MacroAssembler`. If not `NULL` we mark a trampoline call position. > > Andrew Haley(@theRealAph) in https://github.com/openjdk/jdk/pull/8564#discussion_r871062342 suggests to remove it. > > This PR removes the parameter. In the case of `trampoline_call` we explicitly return the position of the generated trampoline calls. All places using the position of the generated trampoline call are updated. > > Tested with release and fastdebug builds: > - `gtest`: Passed. > - `tier1`/`tier2`: Passed. Thanks. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.org/jdk/pull/10244 From tschatzl at openjdk.org Tue Sep 13 09:15:48 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 09:15:48 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> Message-ID: <8FZn7UcgdYaLlHPB661he5VDOS8-JANhHLTG5uIkiQU=.56c41b23-9b52-42ed-8d0b-bf22f15bebd4@github.com> On Mon, 12 Sep 2022 11:48:04 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' of gh:tschatzl/jdk into 8256265-parallel-evac-failure >> - disable G1EvacuationFailureALot by default again >> - Remove unneeded clear metadata phase >> - Remove debug code >> - More refactoring >> - Initial cleanup >> - some refactoring, fix clearing of opt index in cset >> - fix test >> - some cleanup >> - Cleanup, phase names, fixes >> - ... and 2 more: https://git.openjdk.org/jdk/compare/37df5f56...2628451d > > src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 632: > >> 630: // Mark the failing object in the marking bitmap and later use the bitmap to handle >> 631: // evacuation failure recovery. >> 632: _g1h->mark_evac_failure_object(_worker_id, old, word_sz); > > The same live-size is calculated again in `process_chunk`, isn't it? You mean the one (ultimately) recorded in the `G1ConcurrentMark::_live_bytes` array and the one for the statistics in `G1RemoveSelfForwardsInChunksTask::process_chunk`? You probably suggest to merge them somehow to do this work once too? I do not think this is worth, particularly because `process_chunk` only collects live bytes per thread without any synchronization (it does collect dead bytes with synchronization). So you could use that value (the total dead bytes) or vice versa to update `G1ConcurrentMark::_live_bytes` at the end of collection, but * `G1ConcurrentMark::_live_bytes` (the sum) isn't actually gathered here, but again these are basically per-thread values (using the mark-stats cache), so otoh the update is inexpensive (nothing compared to the `par_mark` in `mark_evac_failure_object`), and otoh it can't be used for updating `HeapRegion::_garbage_bytes` directly. This would need to flush buffers somewhere before doing that. * the collected `HeapRegion::_garbage_bytes` could be used at the end to update `G1ConcurrentMark::_live_bytes`, but it does not seem to be worth the complexity adding another phase somewhere else. Also it would require another `G1ConcurrentMark` API entry just for that which I do not see worth doing. I.e. I do not think it is worth optimizing something that trivial and add the required code complexity. I would prefer to decrease code complexity. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From tschatzl at openjdk.org Tue Sep 13 09:36:36 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 09:36:36 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> Message-ID: On Tue, 13 Sep 2022 08:30:51 GMT, Stefan Johansson wrote: >> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2948: >> >>> 2946: >>> 2947: void G1CollectedHeap::clear_bitmap_for_region(HeapRegion* hr, bool update_tams) { >>> 2948: concurrent_mark()->clear_bitmap_for_region(hr, update_tams); >> >> Instead of adding one more arg, I wonder if it's clearer to move the operation on `tams` to higher-level caller(s). > > I agree with Albert, I think moving `hr->note_end_of_clearing();` out of `G1ConcurrentMark::clear_bitmap_for_region()` and handle it where needed is a cleaner approach. This is a workaround for now as I intend to make `G1ConcurrentMark` owner of TAMSes (like TARSes) and then remove that clumsy workaround (i.e. `HeapRegion::note_end_of_clearing` will be empty/obsolete and that call removed). Beginning with that change the TAMS of a region should be part of the bitmap of that region, so the additional parameter for `clear_bitmap_for_region` seems obvious to me. The reason why this parameter is actually needed becomes clear with listing the usage locations. * `G1ClearBitmapHRClosure` which is a helper of `G1ConcurrentMark?; obviously that one may access TAMSes directly as well as the bitmap. * `G1RemSet::G1ClearBitmapClosure` which clears bitmaps for to-be-evacuated old regions. Their TAMS needs to be reset obviously as they will be evacuated and freed (in the regular case). Actually also only required because of the bitmap reuse for evacuation failure. * `ClearRetainedRegionBitmaps::ClearRetainedRegionBitmapsClosure` is that odd-one-out here; as we reuse the bitmap for evacuation failure we need to ask the owner of the bitmap/tams to please not do the usual thing. The name `update_tams` for the parameter is probably bad, I'll rename it to `clear_tams`, and `HeapRegion::note_end_of_marking` to something similar while the discussion is ongoing. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From tschatzl at openjdk.org Tue Sep 13 09:46:52 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 09:46:52 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> Message-ID: On Mon, 12 Sep 2022 11:40:10 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' of gh:tschatzl/jdk into 8256265-parallel-evac-failure >> - disable G1EvacuationFailureALot by default again >> - Remove unneeded clear metadata phase >> - Remove debug code >> - More refactoring >> - Initial cleanup >> - some refactoring, fix clearing of opt index in cset >> - fix test >> - some cleanup >> - Cleanup, phase names, fixes >> - ... and 2 more: https://git.openjdk.org/jdk/compare/37df5f56...2628451d > > src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 373: > >> 371: bool do_heap_region(HeapRegion* r) override { >> 372: G1CollectedHeap::heap()->clear_bitmap_for_region(r, false /* update_tams */); >> 373: return false; > > I wonder if it's possible to assert `tams == bottom` here. No, after some thinking. G1 clears TAMSes during concurrent clearing of the bitmap. This marking phase is already concurrent to the mixed phase. We could reset TAMS anyway though. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From sspitsyn at openjdk.org Tue Sep 13 09:54:29 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 13 Sep 2022 09:54:29 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v5] In-Reply-To: References: Message-ID: <14hiQId61qMjRFoYpdaAy-AXxiMW2vgsMcW0l92V-5I=.75648ba6-cd01-4301-a852-c3b3836895fd@github.com> On Mon, 12 Sep 2022 20:30:04 GMT, Alex Menkov wrote: >> The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) >> >> cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. >> After successful RedefineClasses it should be reset. >> The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > s/verity/verify/ I've posted one minor comment. Otherwise, it is good. Thanks, Serguei test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 222: > 220: caps.can_retransform_classes = 1; > 221: res = jvmti->AddCapabilities(&caps); > 222: if (res != JVMTI_ERROR_NONE) { The type of res is jint. It is better to use a variable of type jvmtiError. I've missed this initially. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10032 From tschatzl at openjdk.org Tue Sep 13 10:10:52 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 10:10:52 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> Message-ID: On Tue, 13 Sep 2022 09:44:35 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 373: >> >>> 371: bool do_heap_region(HeapRegion* r) override { >>> 372: G1CollectedHeap::heap()->clear_bitmap_for_region(r, false /* update_tams */); >>> 373: return false; >> >> I wonder if it's possible to assert `tams == bottom` here. > > No, after some thinking. G1 clears TAMSes during concurrent clearing of the bitmap. This marking phase is already concurrent to the mixed phase. We could reset TAMS anyway though. On second thought, yes bottom should be tams for regions in the collection set (of which retained regions are a subset). ------------- PR: https://git.openjdk.org/jdk/pull/9980 From sjohanss at openjdk.org Tue Sep 13 10:34:08 2022 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 13 Sep 2022 10:34:08 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> Message-ID: <0igwirPVUP-Jn5lLa6yf2L0Rm0MMHigyT8Il9ZceqH8=.e0295c04-2417-42d9-8fd9-a3267bcbe177@github.com> On Mon, 12 Sep 2022 10:34:18 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? >> >> This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. >> >> Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge branch 'master' of gh:tschatzl/jdk into 8256265-parallel-evac-failure > - disable G1EvacuationFailureALot by default again > - Remove unneeded clear metadata phase > - Remove debug code > - More refactoring > - Initial cleanup > - some refactoring, fix clearing of opt index in cset > - fix test > - some cleanup > - Cleanup, phase names, fixes > - ... and 2 more: https://git.openjdk.org/jdk/compare/37df5f56...2628451d Looks good, this code has really improve over the last 6 months (since I looked at it before my leave) and I just have a few small comments/suggestions. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 3308: > 3306: } else { > 3307: _cm->raw_mark_in_bitmap(obj); > 3308: } I think `raw_mark_in_bitmap(worker, obj, size)` isn't that raw if we add the liveness calculation so I think we should either give that wrapper another name or do something like this: Suggestion: _cm->raw_mark_in_bitmap(obj); if (collector_state()->in_concurrent_start_gc()) { _cm->add_to_liveness(worker_id, obj, obj_size); } src/hotspot/share/gc/g1/g1EvacFailure.cpp line 108: > 106: > 107: // Caches the currently accumulated number of garbage words found in this heap region. > 108: // Avoids direct (frequent) atomic operations on the HeapRegion's garbage counter. Just to be sure we need this, we have seen problems calling `note_self_forwarding_removal_end_par(...)` on return from `process_chunk(...)`? src/hotspot/share/gc/g1/g1EvacFailure.hpp line 66: > 64: }; > 65: > 66: #endif // SHARE_GC_G1_G1EVACFAILURE_HPP Suggestion: #endif // SHARE_GC_G1_G1EVACFAILURE_HPP src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp line 106: > 104: _gc_par_phases[MergePSS] = new WorkerDataArray("MergePSS", "Merge Per-Thread State (ms):", max_gc_threads); > 105: _gc_par_phases[RestoreRetainedRegions] = new WorkerDataArray("RestoreRetainedRegions", "Restore Retained Regions (ms):", max_gc_threads); > 106: _gc_par_phases[RemoveSelfForwardsInChunks] = new WorkerDataArray("RemoveSelfForwardsInChunks", "Remove Self Forwards In Chunks (ms):", max_gc_threads); Is the "In Chunks" part really interesting to users? We do mention chunks below so the info is there. And if we could come up with a more user friendly name than "Remove Self Forwards" that would probably be good as well. Some thing like "Clean/Fix Failed Regions" maybe. src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 112: > 110: double worker_cost() const override { > 111: assert(_evac_failure_regions->evacuation_failed(), "Should not call this if not executed"); > 112: return _evac_failure_regions->num_regions_failed_evacuation() * G1PerRetainedRegionThreads; It feels a bit wrong to have a flag for this, or at least I'm not sure if the number of thread only should be connected to the number of regions only. Instead maybe we should look at the to total size for those regions. Now with the chunking there will be a lot more work items than regions so we should be able to look at size which to me looks like a better metric. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From tschatzl at openjdk.org Tue Sep 13 10:47:50 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 10:47:50 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: <0igwirPVUP-Jn5lLa6yf2L0Rm0MMHigyT8Il9ZceqH8=.e0295c04-2417-42d9-8fd9-a3267bcbe177@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> <0igwirPVUP-Jn5lLa6yf2L0Rm0MMHigyT8Il9ZceqH8=.e0295c04-2417-42d9-8fd9-a3267bcbe177@github.com> Message-ID: <7zSaHO-Euyb8AXnc_yBkKOvn1mW8nYCGviGcdfMfaBk=.9e6e4cba-72a9-4f1f-a01e-359ff22930e3@github.com> On Tue, 13 Sep 2022 09:46:20 GMT, Stefan Johansson wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' of gh:tschatzl/jdk into 8256265-parallel-evac-failure >> - disable G1EvacuationFailureALot by default again >> - Remove unneeded clear metadata phase >> - Remove debug code >> - More refactoring >> - Initial cleanup >> - some refactoring, fix clearing of opt index in cset >> - fix test >> - some cleanup >> - Cleanup, phase names, fixes >> - ... and 2 more: https://git.openjdk.org/jdk/compare/37df5f56...2628451d > > src/hotspot/share/gc/g1/g1EvacFailure.cpp line 108: > >> 106: >> 107: // Caches the currently accumulated number of garbage words found in this heap region. >> 108: // Avoids direct (frequent) atomic operations on the HeapRegion's garbage counter. > > Just to be sure we need this, we have seen problems calling `note_self_forwarding_removal_end_par(...)` on return from `process_chunk(...)`? I think that's it. We expect few failed regions (1-2) with pinned regions, so many threads working on the same region at the same time. If you want we can drop the cache, I did not (re-)measure. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From tschatzl at openjdk.org Tue Sep 13 10:56:45 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 10:56:45 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: <0igwirPVUP-Jn5lLa6yf2L0Rm0MMHigyT8Il9ZceqH8=.e0295c04-2417-42d9-8fd9-a3267bcbe177@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> <0igwirPVUP-Jn5lLa6yf2L0Rm0MMHigyT8Il9ZceqH8=.e0295c04-2417-42d9-8fd9-a3267bcbe177@github.com> Message-ID: <6iDnVurV_sXilKMKkmM3ls4k8N6cRGt-sroRZ2Z9lDU=.04989f34-0cbf-4072-9f70-a7063a74b20c@github.com> On Tue, 13 Sep 2022 10:10:04 GMT, Stefan Johansson wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' of gh:tschatzl/jdk into 8256265-parallel-evac-failure >> - disable G1EvacuationFailureALot by default again >> - Remove unneeded clear metadata phase >> - Remove debug code >> - More refactoring >> - Initial cleanup >> - some refactoring, fix clearing of opt index in cset >> - fix test >> - some cleanup >> - Cleanup, phase names, fixes >> - ... and 2 more: https://git.openjdk.org/jdk/compare/37df5f56...2628451d > > src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp line 106: > >> 104: _gc_par_phases[MergePSS] = new WorkerDataArray("MergePSS", "Merge Per-Thread State (ms):", max_gc_threads); >> 105: _gc_par_phases[RestoreRetainedRegions] = new WorkerDataArray("RestoreRetainedRegions", "Restore Retained Regions (ms):", max_gc_threads); >> 106: _gc_par_phases[RemoveSelfForwardsInChunks] = new WorkerDataArray("RemoveSelfForwardsInChunks", "Remove Self Forwards In Chunks (ms):", max_gc_threads); > > Is the "In Chunks" part really interesting to users? We do mention chunks below so the info is there. > > And if we could come up with a more user friendly name than "Remove Self Forwards" that would probably be good as well. Some thing like "Clean/Fix Failed Regions" maybe. I can see your point about the "InChunks" postfix; however I would prefer to keep the phase meaningful wrt to what it does. Neither "Remove Self Forwards" or "Fix Failed Regions" helps end users in a big way, but the former helps at least us understand at a glance what this phase does without needing to translate "Fix Failed Regions" to "this phase removes the self forwards". ------------- PR: https://git.openjdk.org/jdk/pull/9980 From tschatzl at openjdk.org Tue Sep 13 10:59:48 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 10:59:48 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: <0igwirPVUP-Jn5lLa6yf2L0Rm0MMHigyT8Il9ZceqH8=.e0295c04-2417-42d9-8fd9-a3267bcbe177@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> <0igwirPVUP-Jn5lLa6yf2L0Rm0MMHigyT8Il9ZceqH8=.e0295c04-2417-42d9-8fd9-a3267bcbe177@github.com> Message-ID: On Tue, 13 Sep 2022 10:30:35 GMT, Stefan Johansson wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' of gh:tschatzl/jdk into 8256265-parallel-evac-failure >> - disable G1EvacuationFailureALot by default again >> - Remove unneeded clear metadata phase >> - Remove debug code >> - More refactoring >> - Initial cleanup >> - some refactoring, fix clearing of opt index in cset >> - fix test >> - some cleanup >> - Cleanup, phase names, fixes >> - ... and 2 more: https://git.openjdk.org/jdk/compare/37df5f56...2628451d > > src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 112: > >> 110: double worker_cost() const override { >> 111: assert(_evac_failure_regions->evacuation_failed(), "Should not call this if not executed"); >> 112: return _evac_failure_regions->num_regions_failed_evacuation() * G1PerRetainedRegionThreads; > > It feels a bit wrong to have a flag for this, or at least I'm not sure if the number of thread only should be connected to the number of regions only. Instead maybe we should look at the to total size for those regions. Now with the chunking there will be a lot more work items than regions so we should be able to look at size which to me looks like a better metric. Something like `G1CollectedHeap::get_chunks_per_region() / MAGIC_FACTOR` I guess? ------------- PR: https://git.openjdk.org/jdk/pull/9980 From tschatzl at openjdk.org Tue Sep 13 11:13:47 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 11:13:47 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v3] In-Reply-To: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Message-ID: > Hi all, > > can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? > > This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. > > Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: sjohanss, albert review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9980/files - new: https://git.openjdk.org/jdk/pull/9980/files/2628451d..a529f6d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9980&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9980&range=01-02 Stats: 58 lines in 12 files changed: 10 ins; 12 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/9980.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9980/head:pull/9980 PR: https://git.openjdk.org/jdk/pull/9980 From sjohanss at openjdk.org Tue Sep 13 11:22:52 2022 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 13 Sep 2022 11:22:52 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: <7zSaHO-Euyb8AXnc_yBkKOvn1mW8nYCGviGcdfMfaBk=.9e6e4cba-72a9-4f1f-a01e-359ff22930e3@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> <0igwirPVUP-Jn5lLa6yf2L0Rm0MMHigyT8Il9ZceqH8=.e0295c04-2417-42d9-8fd9-a3267bcbe177@github.com> <7zSaHO-Euyb8AXnc_yBkKOvn1mW8nYCGviGcdfMfaBk=.9e6e4cba-72a9-4f1f-a01e-359ff22930e3@github.com> Message-ID: On Tue, 13 Sep 2022 10:44:10 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1EvacFailure.cpp line 108: >> >>> 106: >>> 107: // Caches the currently accumulated number of garbage words found in this heap region. >>> 108: // Avoids direct (frequent) atomic operations on the HeapRegion's garbage counter. >> >> Just to be sure we need this, we have seen problems calling `note_self_forwarding_removal_end_par(...)` on return from `process_chunk(...)`? > > I think that's it. We expect few failed regions (1-2) with pinned regions, so many threads working on the same region at the same time. If you want we can drop the cache, I did not (re-)measure. I would prefer to drop it if not needed. From the comment it sounds like the cache was created to avoid updating the global value for each "garbage area", but a middle road would be to update the global value after each chunk. How much work is it to re-measure? >> src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp line 106: >> >>> 104: _gc_par_phases[MergePSS] = new WorkerDataArray("MergePSS", "Merge Per-Thread State (ms):", max_gc_threads); >>> 105: _gc_par_phases[RestoreRetainedRegions] = new WorkerDataArray("RestoreRetainedRegions", "Restore Retained Regions (ms):", max_gc_threads); >>> 106: _gc_par_phases[RemoveSelfForwardsInChunks] = new WorkerDataArray("RemoveSelfForwardsInChunks", "Remove Self Forwards In Chunks (ms):", max_gc_threads); >> >> Is the "In Chunks" part really interesting to users? We do mention chunks below so the info is there. >> >> And if we could come up with a more user friendly name than "Remove Self Forwards" that would probably be good as well. Some thing like "Clean/Fix Failed Regions" maybe. > > I can see your point about the "InChunks" postfix; however I would prefer to keep the phase meaningful wrt to what it does. Neither "Remove Self Forwards" or "Fix Failed Regions" helps end users in a big way, but the former helps at least us understand at a glance what this phase does without needing to translate "Fix Failed Regions" to "this phase removes the self forwards". Sure, that's a fair point. Logging at this level requires some knowledge to be fully meaningful as well. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From aboldtch at openjdk.org Tue Sep 13 11:25:33 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 13 Sep 2022 11:25:33 GMT Subject: Integrated: 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 10:09:09 GMT, Axel Boldt-Christmas wrote: > Add a second tmp register to the BarrierSetAssembler::load_at GC API for aarch64. > > Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. > > Testing: Oracle platforms tier 1-3 This pull request has now been integrated. Changeset: 725f41ff Author: Axel Boldt-Christmas Committer: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/725f41ffd4b137aef3f83700b4e181e9d93368d4 Stats: 104 lines in 14 files changed: 7 ins; 2 del; 95 mod 8293351: Add second tmp register to aarch64 BarrierSetAssembler::load_at Reviewed-by: aph, tschatzl, fyang ------------- PR: https://git.openjdk.org/jdk/pull/10161 From sjohanss at openjdk.org Tue Sep 13 11:28:55 2022 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 13 Sep 2022 11:28:55 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> <0igwirPVUP-Jn5lLa6yf2L0Rm0MMHigyT8Il9ZceqH8=.e0295c04-2417-42d9-8fd9-a3267bcbe177@github.com> Message-ID: On Tue, 13 Sep 2022 10:57:37 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 112: >> >>> 110: double worker_cost() const override { >>> 111: assert(_evac_failure_regions->evacuation_failed(), "Should not call this if not executed"); >>> 112: return _evac_failure_regions->num_regions_failed_evacuation() * G1PerRetainedRegionThreads; >> >> It feels a bit wrong to have a flag for this, or at least I'm not sure if the number of thread only should be connected to the number of regions only. Instead maybe we should look at the to total size for those regions. Now with the chunking there will be a lot more work items than regions so we should be able to look at size which to me looks like a better metric. > > Something like `G1CollectedHeap::get_chunks_per_region() / MAGIC_FACTOR` I guess? Yes, that would be better and times the number of regions. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From tschatzl at openjdk.org Tue Sep 13 11:39:48 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 11:39:48 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> <0igwirPVUP-Jn5lLa6yf2L0Rm0MMHigyT8Il9ZceqH8=.e0295c04-2417-42d9-8fd9-a3267bcbe177@github.com> <7zSaHO-Euyb8AXnc_yBkKOvn1mW8nYCGviGcdfMfaBk=.9e6e4cba-72a9-4f1f-a01e-359ff22930e3@github.com> Message-ID: On Tue, 13 Sep 2022 11:17:07 GMT, Stefan Johansson wrote: >> I think that's it. We expect few failed regions (1-2) with pinned regions, so many threads working on the same region at the same time. If you want we can drop the cache, I did not (re-)measure. > > I would prefer to drop it if not needed. From the comment it sounds like the cache was created to avoid updating the global value for each "garbage area", but a middle road would be to update the global value after each chunk. How much work is it to re-measure? I intend to work and measure in this area again soon'ish so I'll have plenty of opportunity to see if makes a difference. For this change I'll remove the cache. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From ayang at openjdk.org Tue Sep 13 11:57:11 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 13 Sep 2022 11:57:11 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v3] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Message-ID: On Tue, 13 Sep 2022 11:13:47 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? >> >> This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. >> >> Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > sjohanss, albert review src/hotspot/share/gc/g1/g1EvacFailureRegions.inline.hpp line 41: > 39: HeapRegion* hr = g1h->region_at(region_idx); > 40: G1CollectorState* state = g1h->collector_state(); > 41: hr->note_self_forwarding_removal_start(state->in_concurrent_start_gc()); It's unclear to me why it's called *here* -- we are still in the evacuation phase, self-forwarding-removal occurs in post-evacuation, isn't it? src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 140: > 138: add_parallel_task(restore_retained_regions_task); > 139: > 140: restore_retained_regions_task->initialize(); Could this be merged in its constructor? ------------- PR: https://git.openjdk.org/jdk/pull/9980 From ayang at openjdk.org Tue Sep 13 11:57:12 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 13 Sep 2022 11:57:12 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: <8FZn7UcgdYaLlHPB661he5VDOS8-JANhHLTG5uIkiQU=.56c41b23-9b52-42ed-8d0b-bf22f15bebd4@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> <8FZn7UcgdYaLlHPB661he5VDOS8-JANhHLTG5uIkiQU=.56c41b23-9b52-42ed-8d0b-bf22f15bebd4@github.com> Message-ID: On Tue, 13 Sep 2022 09:12:05 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 632: >> >>> 630: // Mark the failing object in the marking bitmap and later use the bitmap to handle >>> 631: // evacuation failure recovery. >>> 632: _g1h->mark_evac_failure_object(_worker_id, old, word_sz); >> >> The same live-size is calculated again in `process_chunk`, isn't it? > > You mean the one (ultimately) recorded in the `G1ConcurrentMark::_live_bytes` array and the one for the statistics in `G1RemoveSelfForwardsInChunksTask::process_chunk`? > You probably suggest to merge them somehow to do this work once too? > > I do not think this is worth, particularly because `process_chunk` only collects live bytes per thread without any synchronization (it does collect dead bytes with synchronization). > So you could use that value (the total dead bytes) or vice versa to update `G1ConcurrentMark::_live_bytes` at the end of collection, but > * `G1ConcurrentMark::_live_bytes` (the sum) isn't actually gathered here, but again these are basically per-thread values (using the mark-stats cache), so otoh the update is inexpensive (nothing compared to the `par_mark` in `mark_evac_failure_object`), and otoh it can't be used for updating `HeapRegion::_garbage_bytes` directly. This would need to flush buffers somewhere before doing that. > * the collected `HeapRegion::_garbage_bytes` could be used at the end to update `G1ConcurrentMark::_live_bytes`, but it does not seem to be worth the complexity adding another phase somewhere else. Also it would require another `G1ConcurrentMark` API entry just for that which I do not see worth doing. > > I.e. I do not think it is worth optimizing something that trivial and add the required code complexity. I would prefer to decrease code complexity. I was thinking sth like: void HeapRegion::note_self_forwarding_removal_end_par(size_t garbage_bytes) { Atomic::store(&_live_bytes, region_size - _garbage_bytes, ...); Atomic::add(&_garbage_bytes, garbage_bytes, memory_order_relaxed); } ------------- PR: https://git.openjdk.org/jdk/pull/9980 From stuefe at openjdk.org Tue Sep 13 12:24:57 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 13 Sep 2022 12:24:57 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 06:55:34 GMT, Aleksey Shipilev wrote: > The bug manifests on PPC64, since `section_by_name` is protected by `#if defined(PPC64) && !defined(ABI_ELFv2)`: > > > * For target hotspot_variant-server_libjvm_objs_elfFile.o: I removed the include because we should not use RA in these functions. Please do not re-add it. See https://github.com/openjdk/jdk/pull/10158 . Looks like I just forgot to fix up PPCBE. The better fix would be not to use RA. ------------- PR: https://git.openjdk.org/jdk/pull/10247 From tschatzl at openjdk.org Tue Sep 13 12:28:08 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 12:28:08 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v3] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Message-ID: On Tue, 13 Sep 2022 11:53:47 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> sjohanss, albert review > > src/hotspot/share/gc/g1/g1EvacFailureRegions.inline.hpp line 41: > >> 39: HeapRegion* hr = g1h->region_at(region_idx); >> 40: G1CollectorState* state = g1h->collector_state(); >> 41: hr->note_self_forwarding_removal_start(state->in_concurrent_start_gc()); > > It's unclear to me why it's called *here* -- we are still in the evacuation phase, self-forwarding-removal occurs in post-evacuation, isn't it? > void HeapRegion::note_self_forwarding_removal_end_par(size_t garbage_bytes) { Atomic::store(&_live_bytes, region_size - _garbage_bytes, ...); Atomic::add(&_garbage_bytes, garbage_bytes, memory_order_relaxed); } This comment seems to be duplicated, I'll answer in the other question. > It's unclear to me why it's [`note_self_forwarding_removal_start`] called here -- we are still in the evacuation phase, self-forwarding-removal occurs in post-evacuation, isn't it? `note_self_forwarding_removal_start` prepares for self forwarding removal which is unavoidable at that point for that region. Previously the call to this method during self forward removal was easily possible because one thread only every worked on a single region. The original code had an extra phase that iterated over all regions just for that, which has been removed [here](https://github.com/openjdk/jdk/pull/7047/commits/1003c77cfebc3a72f409d2ebff41b8a74c3e4495) I think, and this call placed here because of lack of other really good options (that are more complicated). I will rename the methods/comments. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From tschatzl at openjdk.org Tue Sep 13 12:40:56 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 12:40:56 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> <8FZn7UcgdYaLlHPB661he5VDOS8-JANhHLTG5uIkiQU=.56c41b23-9b52-42ed-8d0b-bf22f15bebd4@github.com> Message-ID: On Tue, 13 Sep 2022 11:49:36 GMT, Albert Mingkun Yang wrote: >> You mean the one (ultimately) recorded in the `G1ConcurrentMark::_live_bytes` array and the one for the statistics in `G1RemoveSelfForwardsInChunksTask::process_chunk`? >> You probably suggest to merge them somehow to do this work once too? >> >> I do not think this is worth, particularly because `process_chunk` only collects live bytes per thread without any synchronization (it does collect dead bytes with synchronization). >> So you could use that value (the total dead bytes) or vice versa to update `G1ConcurrentMark::_live_bytes` at the end of collection, but >> * `G1ConcurrentMark::_live_bytes` (the sum) isn't actually gathered here, but again these are basically per-thread values (using the mark-stats cache), so otoh the update is inexpensive (nothing compared to the `par_mark` in `mark_evac_failure_object`), and otoh it can't be used for updating `HeapRegion::_garbage_bytes` directly. This would need to flush buffers somewhere before doing that. >> * the collected `HeapRegion::_garbage_bytes` could be used at the end to update `G1ConcurrentMark::_live_bytes`, but it does not seem to be worth the complexity adding another phase somewhere else. Also it would require another `G1ConcurrentMark` API entry just for that which I do not see worth doing. >> >> I.e. I do not think it is worth optimizing something that trivial and add the required code complexity. I would prefer to decrease code complexity. > > I was thinking sth like: > > void HeapRegion::note_self_forwarding_removal_end_par(size_t garbage_bytes) { > Atomic::store(&_live_bytes, region_size - _garbage_bytes, ...); > Atomic::add(&_garbage_bytes, garbage_bytes, memory_order_relaxed); > } Live-bytes are required to be updated for the marking, i.e. within the concurrent start pause. `HeapRegion` never had `_live_bytes`, only `_marked_bytes` which you probably meant. `_marked_bytes` has been removed in [JDK-8290357](https://bugs.openjdk.org/browse/JDK-8290357) because it's not required to actually store that value. It has only ever been used to determine the result of `HeapRegion::live_bytes()` (iirc), and its always `top() - garbage_bytes()` (see my comments in https://github.com/openjdk/jdk/pull/9511 for the reasons). At the end of marking the marked bytes (or actually `HeapRegion::_garbage_bytes`) are set by the `Remark` pause based on its `live/marked_bytes`. So we need to update the marking's `_live_bytes` here so that the values add up in the end (without using extra storage somewhere). Actually I think now that we do not strictly need to update `HeapRegion::_garbage_bytes` in evacuation failure handling; updating the value for the marking is sufficient as we only use it (apart from some logging) for determining the region's gc efficiency. That one is strictly using the information from the latest marking (just completed), so that update isn't really necessary. I can remove this if wanted, but if so I'd prefer to do that separately. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From tschatzl at openjdk.org Tue Sep 13 12:53:22 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 12:53:22 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v4] In-Reply-To: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Message-ID: > Hi all, > > can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? > > This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. > > Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: sjohanns, ayang review 2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9980/files - new: https://git.openjdk.org/jdk/pull/9980/files/a529f6d6..1259cf15 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9980&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9980&range=02-03 Stats: 84 lines in 7 files changed: 12 ins; 54 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/9980.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9980/head:pull/9980 PR: https://git.openjdk.org/jdk/pull/9980 From tschatzl at openjdk.org Tue Sep 13 12:53:22 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 12:53:22 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> <0igwirPVUP-Jn5lLa6yf2L0Rm0MMHigyT8Il9ZceqH8=.e0295c04-2417-42d9-8fd9-a3267bcbe177@github.com> Message-ID: On Tue, 13 Sep 2022 11:24:54 GMT, Stefan Johansson wrote: >> Something like `G1CollectedHeap::get_chunks_per_region() / MAGIC_FACTOR` I guess? > > Yes, that would be better and times the number of regions. Done in the latest change. However I kept a diagnostic flag to allow tuning of that. I'll do some more testing to see whether it makes a difference. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From ayang at openjdk.org Tue Sep 13 13:46:46 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 13 Sep 2022 13:46:46 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v4] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Message-ID: On Tue, 13 Sep 2022 12:53:22 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? >> >> This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. >> >> Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > sjohanns, ayang review 2 Instead of calling `note_end_of_clearing` in `G1ConcurrentMark::clear_bitmap_for_region`, I wonder if moving it (`note_end_of_clearing`) to a higher-level caller (`G1ClearBitmapClosure`) is a bit nicer. This way, `G1ConcurrentMark::clear_bitmap_for_region` does exactly what its name suggests, nothing more&less. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 3303: > 3301: } > 3302: > 3303: void G1CollectedHeap::mark_evac_failure_object(uint worker_id, const oop obj, size_t obj_size) const { Can we assert the obj is _not_ marked as a pre-condition? src/hotspot/share/gc/g1/g1EvacFailure.hpp line 45: > 43: CHeapBitMap _chunk_bitmap; > 44: > 45: // Initialized outside of the constructor because the number of workers is unknown This comment is obsolete I believe. src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 117: > 115: > 116: return ((double)G1CollectedHeap::get_chunks_per_region() / G1RestoreRetainedRegionChunksPerWorker) * > 117: _evac_failure_regions->num_regions_failed_evacuation(); I think the following is a bit cleaner. size_t total_chunks = get_chunks_per_region() * _evac_failure_regions->num_regions_failed_evacuation(); return (double) total_chunks / G1RestoreRetainedRegionChunksPerWorker; src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 138: > 136: add_parallel_task(G1CollectedHeap::heap()->rem_set()->create_cleanup_after_scan_heap_roots_task()); > 137: if (evacuation_failed) { > 138: RestoreRetainedRegionsTask* restore_retained_regions_task = new RestoreRetainedRegionsTask(evac_failure_regions); `restore_retained_regions_task` is not really used/needed, right? ------------- PR: https://git.openjdk.org/jdk/pull/9980 From ayang at openjdk.org Tue Sep 13 13:57:51 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 13 Sep 2022 13:57:51 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> <8FZn7UcgdYaLlHPB661he5VDOS8-JANhHLTG5uIkiQU=.56c41b23-9b52-42ed-8d0b-bf22f15bebd4@github.com> Message-ID: On Tue, 13 Sep 2022 12:38:35 GMT, Thomas Schatzl wrote: >> I was thinking sth like: >> >> void HeapRegion::note_self_forwarding_removal_end_par(size_t garbage_bytes) { >> Atomic::store(&_live_bytes, region_size - _garbage_bytes, ...); >> Atomic::add(&_garbage_bytes, garbage_bytes, memory_order_relaxed); >> } > > Live-bytes are required to be updated for the marking, i.e. within the concurrent start pause. `HeapRegion` never had `_live_bytes`, only `_marked_bytes` which you probably meant. > > `_marked_bytes` has been removed in [JDK-8290357](https://bugs.openjdk.org/browse/JDK-8290357) because it's not required to actually store that value. It has only ever been used for some unnecessary reasons (see my comments in https://github.com/openjdk/jdk/pull/9511 for the removal reasons). > > At the end of marking the marked bytes (or actually `HeapRegion::_garbage_bytes`) are set by the `Remark` pause based on its `live/marked_bytes`. So we need to update the marking's `_live_bytes` here so that the values add up in the end (without using extra storage somewhere). > > Actually I think now that we do not strictly need to update `HeapRegion::_garbage_bytes` in evacuation failure handling; updating the value for the marking is sufficient as we only use it (apart from some logging) for determining the region's gc efficiency. That one is strictly using the information from the latest marking (just completed), so that update isn't really necessary. I can remove this if wanted, but if so I'd prefer to do that separately. I see; I was assuming `_live_bytes` and `_garbage_bytes` live in the same class/context/entity. In current impl, `_live_bytes` lives in CM while `_garbage_bytes` in `HeapRegion`, which is quite confusing IMO. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From mdoerr at openjdk.org Tue Sep 13 15:08:46 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 13 Sep 2022 15:08:46 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 06:55:34 GMT, Aleksey Shipilev wrote: > The bug manifests on PPC64, since `section_by_name` is protected by `#if defined(PPC64) && !defined(ABI_ELFv2)`: > > > * For target hotspot_variant-server_libjvm_objs_elfFile.o: Oh, seems like the `ResourceMark` is no longer needed. At least, I can't see anything left which would need it after https://github.com/openjdk/jdk/pull/10158. ------------- PR: https://git.openjdk.org/jdk/pull/10247 From tschatzl at openjdk.org Tue Sep 13 15:25:49 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 15:25:49 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <50p1Qy-GYLowSnkbR8uqXvG49ByZqKeoanNsw5i7Ulo=.22eaf463-b5ac-458c-b851-2408227b5b0e@github.com> <8FZn7UcgdYaLlHPB661he5VDOS8-JANhHLTG5uIkiQU=.56c41b23-9b52-42ed-8d0b-bf22f15bebd4@github.com> Message-ID: On Tue, 13 Sep 2022 13:54:05 GMT, Albert Mingkun Yang wrote: >> Live-bytes are required to be updated for the marking, i.e. within the concurrent start pause. `HeapRegion` never had `_live_bytes`, only `_marked_bytes` which you probably meant. >> >> `_marked_bytes` has been removed in [JDK-8290357](https://bugs.openjdk.org/browse/JDK-8290357) because it's not required to actually store that value. It has only ever been used for some unnecessary reasons (see my comments in https://github.com/openjdk/jdk/pull/9511 for the removal reasons). >> >> At the end of marking the marked bytes (or actually `HeapRegion::_garbage_bytes`) are set by the `Remark` pause based on its `live/marked_bytes`. So we need to update the marking's `_live_bytes` here so that the values add up in the end (without using extra storage somewhere). >> >> Actually I think now that we do not strictly need to update `HeapRegion::_garbage_bytes` in evacuation failure handling; updating the value for the marking is sufficient as we only use it (apart from some logging) for determining the region's gc efficiency. That one is strictly using the information from the latest marking (just completed), so that update isn't really necessary. I can remove this if wanted, but if so I'd prefer to do that separately. > > I see; I was assuming `_live_bytes` and `_garbage_bytes` live in the same class/context/entity. In current impl, `_live_bytes` lives in CM while `_garbage_bytes` in `HeapRegion`, which is quite confusing IMO. There has never been a `_live_bytes` as implied by the name anywhere (there is a getter on `HeapRegion` that (still) calculates an upper bound on the number of live bytes in a region; it uses `_garbage_bytes` to determine that). The use of `_live_bytes` is maybe a misnomer in the marking code (but for marking only something below TAMS is relevant). I am open to renaming it (separately). In `HeapRegion` the name of this counter has always been `_marked_bytes` which meant "marked bytes below TAMS". TAMS is something that is only useful (and valid) during marking, a `_marked_bytes` on `HeapRegion` is imho very questionable (because `tams == bottom` most of the time). I.e. having nonzero marked bytes in `[bottom, tams[` where `tams == bottom` is even more inconsistent. Marked bytes for a region only has meaning with an associated TAMS. That's why it's gone, and it is unnecessary to store in the first place as the removal change showed. Garbage bytes is the lower bound of dead objects between [bottom, top[, which has meaning regardless of other temporary marking data like TAMS. This is one reason I am suggesting to (also) move TAMS out of `HeapRegion`. I only wanted to wait with that until after this change; another that TAMS is intrinsically linked to the bitmap (and marking) so it should be managed (like TARS) by `G1ConcurrentMark`, and hence cleared with the bitmap in one go. That G1 messes with the bitmap for evacuation failure handling is from an abstraction POV not good, but overall acceptable. Maybe the `clear_bitmap_for_region()` method should (already) be called something like `clear_marking_data_in_region()`? ------------- PR: https://git.openjdk.org/jdk/pull/9980 From kvn at openjdk.org Tue Sep 13 15:51:41 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 13 Sep 2022 15:51:41 GMT Subject: RFR: 8293618: x86: Wrong code generation in class Assembler In-Reply-To: References: Message-ID: <_kM8UYL9zISDQHbZvarO7JcppFHv07wJT-1nUS3YN2o=.24570e77-b958-434a-b683-21cfcddc7777@github.com> On Mon, 12 Sep 2022 15:30:01 GMT, Quan Anh Mai wrote: > Hi, > > This patch fixes some issues in the code generation of x86 assembler: > > - `Assembler::testl` misses `prefix(dst)` > - `Assembler::addw` misses the 0x66 prefix > - `Assembler::emit_operand` needs the length of the instruction from the address operand, this is often forgotten, making this parameter explicit to prevent potential issues > - The assembler should not do optimisations that change the actual emitted instructions, these should be moved to `MacroAssembler` instead > > AFAICT there is no failure due to these mistakes. Please take a look and give reviews. > Thanks you very much. Seems reasonable. I will test it. ------------- PR: https://git.openjdk.org/jdk/pull/10240 From tschatzl at openjdk.org Tue Sep 13 16:00:05 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 16:00:05 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v5] In-Reply-To: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Message-ID: <3ElpM4J3e32RLtJNBphsI3qJWJ6_cwT5ToiV6ZrXZQg=.8c0a3e11-0a98-4bbd-8dfe-5ffc1d1e600b@github.com> > Hi all, > > can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? > > This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. > > Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: - clear_bitmap_for_region() -> clear_mark_data_for_region() - ayang review 3 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9980/files - new: https://git.openjdk.org/jdk/pull/9980/files/1259cf15..3363fca0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9980&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9980&range=03-04 Stats: 34 lines in 9 files changed: 8 ins; 8 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/9980.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9980/head:pull/9980 PR: https://git.openjdk.org/jdk/pull/9980 From tschatzl at openjdk.org Tue Sep 13 16:06:53 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 13 Sep 2022 16:06:53 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v5] In-Reply-To: <3ElpM4J3e32RLtJNBphsI3qJWJ6_cwT5ToiV6ZrXZQg=.8c0a3e11-0a98-4bbd-8dfe-5ffc1d1e600b@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <3ElpM4J3e32RLtJNBphsI3qJWJ6_cwT5ToiV6ZrXZQg=.8c0a3e11-0a98-4bbd-8dfe-5ffc1d1e600b@github.com> Message-ID: <__F2U0aP34MsHbjXQrteQ-sOQ-kIAzEkjLeDQOp1I5Q=.a67eadf6-ae68-4abb-885d-d8656c7de0c5@github.com> On Tue, 13 Sep 2022 16:00:05 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? >> >> This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. >> >> Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - clear_bitmap_for_region() -> clear_mark_data_for_region() > - ayang review 3 The last commit prospectively renames `clear_bitmap_for_region()`. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From shade at openjdk.org Tue Sep 13 16:49:14 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Sep 2022 16:49:14 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 [v2] In-Reply-To: References: Message-ID: > The bug manifests on PPC64, since `section_by_name` is protected by `#if defined(PPC64) && !defined(ABI_ELFv2)`: > > > * For target hotspot_variant-server_libjvm_objs_elfFile.o: Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Remove ResourceMark instead ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10247/files - new: https://git.openjdk.org/jdk/pull/10247/files/b3b2cb80..9fba80d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10247&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10247&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10247.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10247/head:pull/10247 PR: https://git.openjdk.org/jdk/pull/10247 From kbarrett at openjdk.org Tue Sep 13 16:49:14 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 13 Sep 2022 16:49:14 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 [v2] In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 16:45:41 GMT, Aleksey Shipilev wrote: >> The bug manifests on PPC64, since `section_by_name` is protected by `#if defined(PPC64) && !defined(ABI_ELFv2)`: >> >> >> * For target hotspot_variant-server_libjvm_objs_elfFile.o: > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Remove ResourceMark instead Withdrawing my review, leaving it to others. ------------- PR: https://git.openjdk.org/jdk/pull/10247 From shade at openjdk.org Tue Sep 13 16:49:14 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Sep 2022 16:49:14 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 In-Reply-To: References: Message-ID: <6uniOwUFwe0ViAz90cY6op_7vlkoGVAZMSJWIBUWLdY=.3676e89f-c21c-4c87-b722-3e3658961835@github.com> On Tue, 13 Sep 2022 06:55:34 GMT, Aleksey Shipilev wrote: > The bug manifests on PPC64, since `section_by_name` is protected by `#if defined(PPC64) && !defined(ABI_ELFv2)`: > > > * For target hotspot_variant-server_libjvm_objs_elfFile.o: Oh, I see. Let's remove `ResourceMark` then, like in new commit? I don't have a PPC64BE machine to test it, though. ------------- PR: https://git.openjdk.org/jdk/pull/10247 From shade at openjdk.org Tue Sep 13 17:01:43 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Sep 2022 17:01:43 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 [v2] In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 16:45:41 GMT, Kim Barrett wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove ResourceMark instead > > Withdrawing my review, leaving it to others. > @kimbarrett Only the author (@shipilev) is allowed to issue the `reviewer` command. Ah-ha, gotcha! Welcome to PPC64 maintainers team, @kimbarrett! ;) ------------- PR: https://git.openjdk.org/jdk/pull/10247 From shade at openjdk.org Tue Sep 13 17:01:44 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Sep 2022 17:01:44 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 [v2] In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 16:55:40 GMT, Aleksey Shipilev wrote: >> Withdrawing my review, leaving it to others. > >> @kimbarrett Only the author (@shipilev) is allowed to issue the `reviewer` command. > > Ah-ha, gotcha! Welcome to PPC64 maintainers team, @kimbarrett! ;) > @shipilev There are no manually specified reviewers associated with this pull request. Current credited reviewers are: Nevermind, I think bots have updated the reviewer list, based on "Approved" -> "Comment" change. ------------- PR: https://git.openjdk.org/jdk/pull/10247 From eastigeevich at openjdk.org Tue Sep 13 17:22:28 2022 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Tue, 13 Sep 2022 17:22:28 GMT Subject: Integrated: 8287394: AArch64: Remove cbuf parameter from far_call/far_jump/trampoline_call In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 18:50:23 GMT, Evgeny Astigeevich wrote: > `far_call`/`far_jump`/`trampoline_call` have parameter `cbuf` with the default value `NULL`. We always call `far_call`/`far_jump` with `NULL`. We call `trampoline_call` with either `NULL` or the `CodeBuffer` currently used by `MacroAssembler`. If not `NULL` we mark a trampoline call position. > > Andrew Haley(@theRealAph) in https://github.com/openjdk/jdk/pull/8564#discussion_r871062342 suggests to remove it. > > This PR removes the parameter. In the case of `trampoline_call` we explicitly return the position of the generated trampoline calls. All places using the position of the generated trampoline call are updated. > > Tested with release and fastdebug builds: > - `gtest`: Passed. > - `tier1`/`tier2`: Passed. This pull request has now been integrated. Changeset: 90390222 Author: Evgeny Astigeevich URL: https://git.openjdk.org/jdk/commit/90390222bd215ff10040ecde5efcdf33a05f33ae Stats: 27 lines in 5 files changed: 0 ins; 9 del; 18 mod 8287394: AArch64: Remove cbuf parameter from far_call/far_jump/trampoline_call Reviewed-by: aph ------------- PR: https://git.openjdk.org/jdk/pull/10244 From stuefe at openjdk.org Tue Sep 13 17:43:49 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 13 Sep 2022 17:43:49 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 [v2] In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 16:49:14 GMT, Aleksey Shipilev wrote: >> The bug manifests on PPC64, since `section_by_name` is protected by `#if defined(PPC64) && !defined(ABI_ELFv2)`: >> >> >> * For target hotspot_variant-server_libjvm_objs_elfFile.o: > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Remove ResourceMark instead Good and trivial. Thanks, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/10247 From mdoerr at openjdk.org Tue Sep 13 18:25:41 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 13 Sep 2022 18:25:41 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 [v2] In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 16:49:14 GMT, Aleksey Shipilev wrote: >> The bug manifests on PPC64, since `section_by_name` is protected by `#if defined(PPC64) && !defined(ABI_ELFv2)`: >> >> >> * For target hotspot_variant-server_libjvm_objs_elfFile.o: > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Remove ResourceMark instead Marked as reviewed by mdoerr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10247 From shade at openjdk.org Tue Sep 13 18:31:42 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Sep 2022 18:31:42 GMT Subject: RFR: 8293660: Fix frame::sender_for_compiled_frame frame size assert [v3] In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 07:56:18 GMT, Aleksey Shipilev wrote: >> The condition and assert messages are contradicting each other here: >> >> >> frame frame::sender_for_compiled_frame(RegisterMap* map) const { >> ... >> assert(_cb->frame_size() >= 0, "must have non-zero frame size"); >> intptr_t* sender_sp = unextended_sp() + _cb->frame_size(); >> >> >> I found this in x86_32 Loom port, where a entry generator bug caused zero-sized frames. I believe the assert message is correct, and the condition is not: sender SP should be different from (unextended) SP. In fact, if allowed to proceed, the tests can then fail the later assert, assuming `sp() == unextended_sp()`: >> >> >> assert(sender_sp != sp(), "must have changed"); >> >> >> This code predates OpenJDK history, and assert was copy-pasted in this form to many arches. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `tier1` > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - Wrong PR :) > - AArch64 part Any other reviews? ------------- PR: https://git.openjdk.org/jdk/pull/10242 From jonathanjoo at google.com Tue Sep 13 19:52:59 2022 From: jonathanjoo at google.com (Jonathan Joo) Date: Tue, 13 Sep 2022 15:52:59 -0400 Subject: Container-aware heap sizing for OpenJDK Message-ID: Hello hotspot-dev and hotspot-gc-dev, My name is Jonathan, and I'm working on the Java Platform Team at Google. Here, we are working on a project to address Java container memory issues, as we noticed that a significant number of Java servers hit container OOM issues due to people incorrectly tuning their heap size with respect to the container size. Because our containers have other RAM consumers which fluctuate over time, it is often difficult to determine a priori what is an appropriate Xmx to set for a particular server. We set about trying to solve this by dynamically adjusting the Java heap/gc behavior based on the container usage information that we pass into the JVM. We have seen promising results so far, reducing container OOMs by a significant amount, and oftentimes also reducing average heap usage (with the tradeoff of more CPU time spent doing GC). Below (under the dotted line) is a more detailed explanation of our initial approach. Does this sound like something that may be useful for the general OpenJDK community? If so, would some of you be open to further discussion? I would also like to better understand what container environments look like outside of Google, to see how we could modify our approach for the more general case. Thank you! Jonathan ------------------------------------------------------------------------ Introduction: Adaptable Heap Sizing (AHS) is a project internal to Google that is meant to simplify configuration and improve the stability of applications in container environments. The key is that in a containerized environment, we have access to container usage and limit information. This can be used as a signal to modify Java heap behavior, helping prevent container OOMs. Problem: - Containers at Google must be properly sized to not only the JVM heap, but other memory consumers as well. These consumers include non-heap Java (e.g. native code allocations), and simultaneously running non-Java processes. - Common antipattern we see here at Google: - We have an application running into container OOMs. - An engineer raises both container memory limit and Xmx by the same amount, since there appears to be insufficient memory. - The application has reduced container OOMs, but is still prone to them, since G1 continues to use most of Xmx. - This results in many jobs being configured with much more RAM than they need, but still running into container OOM issues. Hypothesis: - For preventing container OOM: Why can't heap expansions be bounded by the remaining free space in the container? - For preventing the `unnecessarily high Xmx` antipattern: Why can't target heap size be set based on GC CPU overhead? - From our work on Adaptable Heap Sizing, it appears they can! Design: - We add two manageable flags in the JVM - Current maximum heap expansion size - Current target heap size - A separate thread runs alongside the JVM, querying: - Container memory usage/limits - GC CPU overhead metrics from the JVM. - This thread then uses this information to calculate new values for the two new JVM flags, and continually updates them at runtime. - The `Current maximum heap expansion size` informs the JVM what is the maximum amount we can expand the heap by, while staying within container limits. This is a hard limit, and trying to expand more than this amount results in behavior equivalent to hitting the Xmx limit. - The `Current target heap size` is a soft target value, which is used to resize the heap (when possible) so as to bring GC CPU overhead toward its target value. Results: - At Google, we have found that this design works incredibly well in our initial rollout, even for large and complex workloads. - After deploying this to dozens of applications: - Significant memory savings for previously misconfigured jobs (many of which reduced their heap usage by 50% or more) - Significantly reduced occurrences of container OOM (100% reduction in vast majority of cases) - No correctness issues - No latency regressions* - We plan to deploy AHS across a much wider subset of applications by EOY '22. *Caveats: - Enabling this feature might require tuning of the newly introduced default GC CPU overhead target to avoid regressions. - Time spent doing GC for an application may increase significantly (though generally we've seen in practice that even if this is the case, end-to-end latency does not increase a noticeable amount) - Enabling AHS results in frequent heap resizings, but we have not seen evidence of any negative effects as a result of these more frequent heap resizings. - AHS is not necessarily a replacement for proper JVM tuning, but should generally work better than an untuned or improperly tuned configuration. - AHS is not intended for every possible workload, and there could be pathological cases where AHS results in worse behavior. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kvn at openjdk.org Tue Sep 13 20:29:45 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 13 Sep 2022 20:29:45 GMT Subject: RFR: 8293660: Fix frame::sender_for_compiled_frame frame size assert [v3] In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 07:56:18 GMT, Aleksey Shipilev wrote: >> The condition and assert messages are contradicting each other here: >> >> >> frame frame::sender_for_compiled_frame(RegisterMap* map) const { >> ... >> assert(_cb->frame_size() >= 0, "must have non-zero frame size"); >> intptr_t* sender_sp = unextended_sp() + _cb->frame_size(); >> >> >> I found this in x86_32 Loom port, where a entry generator bug caused zero-sized frames. I believe the assert message is correct, and the condition is not: sender SP should be different from (unextended) SP. In fact, if allowed to proceed, the tests can then fail the later assert, assuming `sp() == unextended_sp()`: >> >> >> assert(sender_sp != sp(), "must have changed"); >> >> >> This code predates OpenJDK history, and assert was copy-pasted in this form to many arches. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `tier1` > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - Wrong PR :) > - AArch64 part Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10242 From amenkov at openjdk.org Tue Sep 13 21:03:13 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 13 Sep 2022 21:03:13 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v6] In-Reply-To: References: Message-ID: > The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) > > cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. > After successful RedefineClasses it should be reset. > The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Use jvmtiError for JVMTI function results ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10032/files - new: https://git.openjdk.org/jdk/pull/10032/files/13264736..d853f23f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=04-05 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10032.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10032/head:pull/10032 PR: https://git.openjdk.org/jdk/pull/10032 From amenkov at openjdk.org Tue Sep 13 21:09:50 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 13 Sep 2022 21:09:50 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v5] In-Reply-To: <14hiQId61qMjRFoYpdaAy-AXxiMW2vgsMcW0l92V-5I=.75648ba6-cd01-4301-a852-c3b3836895fd@github.com> References: <14hiQId61qMjRFoYpdaAy-AXxiMW2vgsMcW0l92V-5I=.75648ba6-cd01-4301-a852-c3b3836895fd@github.com> Message-ID: On Tue, 13 Sep 2022 09:49:58 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> s/verity/verify/ > > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 222: > >> 220: caps.can_retransform_classes = 1; >> 221: res = jvmti->AddCapabilities(&caps); >> 222: if (res != JVMTI_ERROR_NONE) { > > The type of res is jint. It is better to use a variable of type jvmtiError. I've missed this initially. Fixed ------------- PR: https://git.openjdk.org/jdk/pull/10032 From kbarrett at openjdk.org Wed Sep 14 00:49:35 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 14 Sep 2022 00:49:35 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal Message-ID: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal 8155996: Improve concurrent refinement green zone control 8134303: Introduce -XX:-G1UseConcRefinement Please review this change to the control of concurrent refinement. This new controller takes a different approach to the problem, addressing a number of issues. The old controller used a multiple of the target number of cards to determine the range over which increasing numbers of refinement threads should be activated, and finally activating mutator refinement. This has a variety of problems. It doesn't account for the processing rate, the rate of new dirty cards, or the time available to perform the processing. This often leads to unnecessary spikes in the number of running refinement threads. It also tends to drive the pending number to the target quickly and keep it there, removing the benefit from having pending dirty cards filter out new cards for nearby writes. It can't delay and leave excess cards in the queue because it could be a long time before another buffer is enqueued. The old controller was triggered by mutator threads enqueing card buffers, when the number of cards in the queue exceeded a threshold near the target. This required a complex activation protocol between the mutators and the refinement threads. With the new controller there is a primary refinement thread that periodically estimates how many refinement threads need to be running to reach the target in time for the next GC, along with whether to also activate mutator refinement. If the primary thread stops running because it isn't currently needed, it sleeps for a period and reevaluates on wakeup. This eliminates any involvement in the activation of refinement threads by mutator threads. The estimate of how many refinement threads are needed uses a prediction of time until the next GC, the number of buffered cards, the predicted rate of new dirty cards, and the predicted refinement rate. The number of running threads is adjusted based on these periodically performed estimates. This new approach allows more dirty cards to be left in the queue until late in the mutator phase, typically reducing the rate of new dirty cards, which reduces the amount of concurrent refinement work needed. It also smooths out the number of running refinement threads, eliminating the unnecessarily large spikes that are common with the old method. One benefit is that the number of refinement threads (lazily) allocated is often much lower now. (This plus UseDynamicNumberOfGCThreads mitigates the problem described in JDK-8153225.) This change also provides a new method for calculating for the number of dirty cards that should be pending at the start of a GC. While this calculation is conceptually distinct from the thread control, the two were significanly intertwined in the old controller. Changing this calculation separately and first would have changed the behavior of the old controller in ways that might have introduced regressions. Changing it after the thread control was changed would have made it more difficult to test and measure the thread control in a desirable configuration. The old calculation had various problems that are described in JDK-8155996. In particular, it can get more or less stuck at low values, and is slow to respond to changes. The old controller provided a number of product options, none of which were very useful for real applications, and none of which are very applicable to the new controller. All of these are being obsoleted. -XX:-G1UseAdaptiveConcRefinement -XX:G1ConcRefinementGreenZone= -XX:G1ConcRefinementYellowZone= -XX:G1ConcRefinementRedZone= -XX:G1ConcRefinementThresholdStep= The new controller *could* use G1ConcRefinementGreenZone to provide a fixed value for the target number of cards, though it is poorly named for that. A configuration that was useful for some kinds of debugging and testing was to disable G1UseAdaptiveConcRefinement and set g1ConcRefinementGreenZone to a very large value, effectively disabling concurrent refinement. To support this use case with the new controller, the -XX:-G1UseConcRefinement diagnostic option has been added (see JDK-8155996). The other options are meaningless for the new controller. Because of these option changes, a CSR and a release note need to accompany this change. Testing: mach5 tier1-6 various performance tests. local (linux-x64) tier1 with -XX:-G1UseConcRefinement Performance testing found no regressions, but also little or no improvement with default options, which was expected. With default options most of our performance tests do very little concurrent refinement. And even for those that do, while the old controller had a number of problems, the impact of those problems is small and hard to measure for most applications. When reducing G1RSetUpdatingPauseTimePercent the new controller seems to fare better, particularly when also reducing MaxGCPauseMillis. specjbb2015 with MaxGCPauseMillis=75 and G1RSetUpdatingPauseTimePercent=3 (and other options held constant) showed a statistically significant improvement of about 4.5% for critical-jOPS. Using the changed controller, the difference between this configuration and the default is fairly small, while the baseline shows significant degradation with the more restrictive options. For all tests and configurations the new controller often creates many fewer refinement threads. ------------- Commit messages: - update copyrights - new concurrent refinement control - estimate available eden bytes - record cards collected by concatenate_logs - improve GC refinement logging - cleanup CRTC init/delete Changes: https://git.openjdk.org/jdk/pull/10256/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10256&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8137022 Stats: 1376 lines in 19 files changed: 613 ins; 521 del; 242 mod Patch: https://git.openjdk.org/jdk/pull/10256.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10256/head:pull/10256 PR: https://git.openjdk.org/jdk/pull/10256 From kvn at openjdk.org Wed Sep 14 02:20:28 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 14 Sep 2022 02:20:28 GMT Subject: RFR: 8293618: x86: Wrong code generation in class Assembler In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 15:30:01 GMT, Quan Anh Mai wrote: > Hi, > > This patch fixes some issues in the code generation of x86 assembler: > > - `Assembler::testl` misses `prefix(dst)` > - `Assembler::addw` misses the 0x66 prefix > - `Assembler::emit_operand` needs the length of the instruction from the address operand, this is often forgotten, making this parameter explicit to prevent potential issues > - The assembler should not do optimisations that change the actual emitted instructions, these should be moved to `MacroAssembler` instead > > AFAICT there is no failure due to these mistakes. Please take a look and give reviews. > Thanks you very much. Testing passed. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10240 From dzhang at openjdk.org Wed Sep 14 03:16:33 2022 From: dzhang at openjdk.org (Dingli Zhang) Date: Wed, 14 Sep 2022 03:16:33 GMT Subject: RFR: 8293770: RISC-V: Reuse runtime call trampolines Message-ID: Follow up [JDK-8280152](https://bugs.openjdk.org/browse/JDK-8280152), this case also exists in riscv. Benchmark als, chi-square, dec-tree, log-regression, naive-bayes, page-rank, fj-kmeans, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~2.1% reduction on average. ## Testing: - hotspot and jdk tier1 on unmatched board without new failures - hotspot/jtreg/compiler/sharedstubs/SharedTrampolineTest.java with fastdebug on qemu ## Results #### Results from [Renaissance 0.14.1](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.1) - riscv64 +--------------------------------------------------------------------------------------------------------+ | | Before | After | | Benchmark |---------------------------------------------------------------------------------------| | | non-profiled nmethods | profiled nmethods | non-profiled nmethods | profiled nmethods | +----------------+-----------------------+-------------------+-----------------------+-------------------| | als | 15628 | 39421 | 12341 | 26681 | | chi-square | 6349 | 20268 | 6033 | 20252 | | dec-tree | 11058 | 42443 | 10774 | 43880 | | log-regression | 10939 | 38237 | 12071 | 44199 | | naive-bayes | 9023 | 29563 | 9294 | 30948 | | page-rank | 6054 | 17041 | 5812 | 17353 | | fj-kmeans | 692 | 2893 | 651 | 3354 | | reactors | 2126 | 4073 | 1876 | 4106 | | future-genetic | 1306 | 4118 | 1226 | 4142 | | mnemonics | 726 | 2659 | 706 | 2684 | | dotty | 26059 | 24417 | 24585 | 25379 | | scala-kmeans | 564 | 3122 | 543 | 3132 | | finagle-http | 6188 | 12455 | 6102 | 12295 | | sum | 96712 | 240710 | 92014 | 238405 | +--------------------------------------------------------------------------------------------------------+ ------------- Commit messages: - Port JDK-8280152 to RISC-V Changes: https://git.openjdk.org/jdk/pull/10260/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10260&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293770 Stats: 66 lines in 4 files changed: 60 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10260/head:pull/10260 PR: https://git.openjdk.org/jdk/pull/10260 From fyang at openjdk.org Wed Sep 14 03:17:23 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 14 Sep 2022 03:17:23 GMT Subject: RFR: 8293769: RISC-V: Add a second temporary register for BarrierSetAssembler::load_at Message-ID: This is similar to https://bugs.openjdk.org/browse/JDK-8293351 Add a second temporary register for BarrierSetAssembler::load_at GC API on riscv64. Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. Testing: Tier1-3 tested on Linux-riscv64 SiFive Unmatched board. ------------- Commit messages: - 8293769: RISC-V: Add a second temporary register for BarrierSetAssembler::load_at Changes: https://git.openjdk.org/jdk/pull/10261/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10261&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293769 Stats: 327 lines in 13 files changed: 9 ins; 108 del; 210 mod Patch: https://git.openjdk.org/jdk/pull/10261.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10261/head:pull/10261 PR: https://git.openjdk.org/jdk/pull/10261 From fjiang at openjdk.org Wed Sep 14 03:42:42 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 14 Sep 2022 03:42:42 GMT Subject: RFR: 8293769: RISC-V: Add a second temporary register for BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 03:09:16 GMT, Fei Yang wrote: > This is similar to https://bugs.openjdk.org/browse/JDK-8293351 > Add a second temporary register for BarrierSetAssembler::load_at GC API on riscv64. > Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. > > Testing: Tier1-3 tested on Linux-riscv64 SiFive Unmatched board. Looks good to me. Thanks for the cleanup. ------------- Marked as reviewed by fjiang (Author). PR: https://git.openjdk.org/jdk/pull/10261 From shade at openjdk.org Wed Sep 14 05:40:47 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Sep 2022 05:40:47 GMT Subject: RFR: 8293680: PPC64BE build failure after JDK-8293344 [v2] In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 16:49:14 GMT, Aleksey Shipilev wrote: >> The bug manifests on PPC64, since `section_by_name` is protected by `#if defined(PPC64) && !defined(ABI_ELFv2)`: >> >> >> * For target hotspot_variant-server_libjvm_objs_elfFile.o: > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Remove ResourceMark instead Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10247 From shade at openjdk.org Wed Sep 14 05:40:48 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Sep 2022 05:40:48 GMT Subject: Integrated: 8293680: PPC64BE build failure after JDK-8293344 In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 06:55:34 GMT, Aleksey Shipilev wrote: > The bug manifests on PPC64, since `section_by_name` is protected by `#if defined(PPC64) && !defined(ABI_ELFv2)`: > > > * For target hotspot_variant-server_libjvm_objs_elfFile.o: This pull request has now been integrated. Changeset: b3461c18 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/b3461c188a1d364a71e2ef7f6b2ccc29dd3ac66f Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8293680: PPC64BE build failure after JDK-8293344 Reviewed-by: mdoerr, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/10247 From sspitsyn at openjdk.org Wed Sep 14 05:42:50 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Sep 2022 05:42:50 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v6] In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 21:03:13 GMT, Alex Menkov wrote: >> The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) >> >> cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. >> After successful RedefineClasses it should be reset. >> The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Use jvmtiError for JVMTI function results Thank you for the update! It looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10032 From shade at openjdk.org Wed Sep 14 05:44:47 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Sep 2022 05:44:47 GMT Subject: RFR: 8293660: Fix frame::sender_for_compiled_frame frame size assert [v3] In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 07:56:18 GMT, Aleksey Shipilev wrote: >> The condition and assert messages are contradicting each other here: >> >> >> frame frame::sender_for_compiled_frame(RegisterMap* map) const { >> ... >> assert(_cb->frame_size() >= 0, "must have non-zero frame size"); >> intptr_t* sender_sp = unextended_sp() + _cb->frame_size(); >> >> >> I found this in x86_32 Loom port, where a entry generator bug caused zero-sized frames. I believe the assert message is correct, and the condition is not: sender SP should be different from (unextended) SP. In fact, if allowed to proceed, the tests can then fail the later assert, assuming `sp() == unextended_sp()`: >> >> >> assert(sender_sp != sp(), "must have changed"); >> >> >> This code predates OpenJDK history, and assert was copy-pasted in this form to many arches. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug `tier1` > > Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: > > - Wrong PR :) > - AArch64 part Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/10242 From shade at openjdk.org Wed Sep 14 05:48:46 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Sep 2022 05:48:46 GMT Subject: Integrated: 8293660: Fix frame::sender_for_compiled_frame frame size assert In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 17:56:17 GMT, Aleksey Shipilev wrote: > The condition and assert messages are contradicting each other here: > > > frame frame::sender_for_compiled_frame(RegisterMap* map) const { > ... > assert(_cb->frame_size() >= 0, "must have non-zero frame size"); > intptr_t* sender_sp = unextended_sp() + _cb->frame_size(); > > > I found this in x86_32 Loom port, where a entry generator bug caused zero-sized frames. I believe the assert message is correct, and the condition is not: sender SP should be different from (unextended) SP. In fact, if allowed to proceed, the tests can then fail the later assert, assuming `sp() == unextended_sp()`: > > > assert(sender_sp != sp(), "must have changed"); > > > This code predates OpenJDK history, and assert was copy-pasted in this form to many arches. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` This pull request has now been integrated. Changeset: 60f59a4a Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/60f59a4a8808abf1a8896ca122a1f8120c9f5527 Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod 8293660: Fix frame::sender_for_compiled_frame frame size assert Reviewed-by: dlong, kvn ------------- PR: https://git.openjdk.org/jdk/pull/10242 From duke at openjdk.org Wed Sep 14 05:52:46 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Wed, 14 Sep 2022 05:52:46 GMT Subject: RFR: 8293618: x86: Wrong code generation in class Assembler In-Reply-To: References: Message-ID: <2x2H_y5oKWa4DfKPHmeMwWPpblnmpYh-r_h5Sw1Ouic=.f767b1b8-4aba-4422-97bf-10c4f8fddbe3@github.com> On Wed, 14 Sep 2022 02:17:17 GMT, Vladimir Kozlov wrote: >> Hi, >> >> This patch fixes some issues in the code generation of x86 assembler: >> >> - `Assembler::testl` misses `prefix(dst)` >> - `Assembler::addw` misses the 0x66 prefix >> - `Assembler::emit_operand` needs the length of the instruction from the address operand, this is often forgotten, making this parameter explicit to prevent potential issues >> - The assembler should not do optimisations that change the actual emitted instructions, these should be moved to `MacroAssembler` instead >> >> AFAICT there is no failure due to these mistakes. Please take a look and give reviews. >> Thanks you very much. > > Testing passed. @vnkozlov Thanks a lot for your testing. ------------- PR: https://git.openjdk.org/jdk/pull/10240 From shade at openjdk.org Wed Sep 14 06:43:35 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Sep 2022 06:43:35 GMT Subject: RFR: 8293769: RISC-V: Add a second temporary register for BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 03:09:16 GMT, Fei Yang wrote: > This is similar to https://bugs.openjdk.org/browse/JDK-8293351 > Add a second temporary register for BarrierSetAssembler::load_at GC API on riscv64. > Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. > > Testing: Tier1-3 tested on Linux-riscv64 SiFive Unmatched board. Looks fine, but I have a question. src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp line 318: > 316: __ push_call_clobbered_registers(); > 317: > 318: satb_write_barrier_pre(masm, noreg, dst, xthread, tmp, t0, true, false); Is `tmp` not `t0` here? I expected to see `t1` in this diff. Maybe I am missing something. ------------- PR: https://git.openjdk.org/jdk/pull/10261 From duke at openjdk.org Wed Sep 14 07:32:34 2022 From: duke at openjdk.org (duke) Date: Wed, 14 Sep 2022 07:32:34 GMT Subject: Withdrawn: 8241503: C2: Share MacroAssembler between mach nodes during code emission In-Reply-To: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com> References: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com> Message-ID: On Tue, 7 Jun 2022 23:36:23 GMT, Cesar Soares wrote: > Hi there, can I please get some reviews on this change? The patch is to make the code reuse the same C2_MacroAssembler object during the emission of CPU instructions of a given compilation. > > As you'll see the change affects all backends. I've done my best to keep the changes minimal/simple. > > I tested this locally on Linux x86_64, x86_32 and MacOS Arm32, and ARM64. > > **I need help testing the changes on PPC, S390, and RISCV**. I cross-compiled the JVM locally and the builds are all succeeding, but I couldn't use an emulator (yet) or any real hardware (no access to one) to test the changes on these platforms. I see that GitHub actions do some tests on S390 and PPC but the tests seem to not be extensive. > > Thanks in advance, > Cesar This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9074 From fyang at openjdk.org Wed Sep 14 08:11:32 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 14 Sep 2022 08:11:32 GMT Subject: RFR: 8293769: RISC-V: Add a second temporary register for BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 06:41:25 GMT, Aleksey Shipilev wrote: >> This is similar to https://bugs.openjdk.org/browse/JDK-8293351 >> Add a second temporary register for BarrierSetAssembler::load_at GC API on riscv64. >> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. >> >> Testing: Tier1-3 tested on Linux-riscv64 SiFive Unmatched board. > > src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp line 318: > >> 316: __ push_call_clobbered_registers(); >> 317: >> 318: satb_write_barrier_pre(masm, noreg, dst, xthread, tmp, t0, true, false); > > Is `tmp` not `t0` here? I expected to see `t1` in this diff. Maybe I am missing something. I don't think 'tmp' is 't0' here since we are asserting they are different registers in ShenandoahBarrierSetAssembler::satb_write_barrier_pre [1]. And I also run non-trivial benchmark work loads like Dacapo, Specjvm and Specjbb using ShenandoahGC with fastdebug build for these changes. [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp#L111 ------------- PR: https://git.openjdk.org/jdk/pull/10261 From fyang at openjdk.org Wed Sep 14 09:04:28 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 14 Sep 2022 09:04:28 GMT Subject: RFR: 8293769: RISC-V: Add a second temporary register for BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 08:03:12 GMT, Fei Yang wrote: >> src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp line 318: >> >>> 316: __ push_call_clobbered_registers(); >>> 317: >>> 318: satb_write_barrier_pre(masm, noreg, dst, xthread, tmp, t0, true, false); >> >> Is `tmp` not `t0` here? I expected to see `t1` in this diff. Maybe I am missing something. > > I don't think 'tmp' is 't0' here since we are asserting they are different registers in ShenandoahBarrierSetAssembler::satb_write_barrier_pre [1]. And I also run non-trivial benchmark work loads like Dacapo, Specjvm and Specjbb using ShenandoahGC with fastdebug build for these changes. > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp#L111 PS: Also eyeballed all possible callers of ShenandoahBarrierSetAssembler::satb_write_barrier_pre and I think we are safe here :-) ------------- PR: https://git.openjdk.org/jdk/pull/10261 From tschatzl at openjdk.org Wed Sep 14 09:24:54 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 14 Sep 2022 09:24:54 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v4] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Message-ID: On Tue, 13 Sep 2022 13:43:13 GMT, Albert Mingkun Yang wrote: > Instead of calling `note_end_of_clearing` in `G1ConcurrentMark::clear_bitmap_for_region`, I wonder if moving it (`note_end_of_clearing`) to a higher-level caller (`G1ClearBitmapClosure`) is a bit nicer. This way, `G1ConcurrentMark::clear_bitmap_for_region` does exactly what its name suggests, nothing more&less. Here's a branch that explicitly sets TAMS: https://github.com/openjdk/jdk/compare/master...tschatzl:jdk:submit/8256265-parallel-evac-failure-alt?expand=1 The last commit (https://github.com/openjdk/jdk/commit/b77bb2f46d144345bdcb7b70156eba6491a3d00b) implements the suggested change. This omits that call in the second invocation of `G1CollectedHeap::clear_bitmap_for_region()` because TAMS must be `bottom()` at that point. I do not think this difference is the heart of this review and should not be preventing progress :) Let's postpone the discussion whether TAMS should be part of `G1ConcurrentMark` or not to another day. So I would be happy to use that going forward for this review. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From adinn at redhat.com Wed Sep 14 09:25:48 2022 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 14 Sep 2022 10:25:48 +0100 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> Message-ID: Hi Andrew/Kim, On 09/09/2022 22:50, Kim Barrett wrote: >> On Sep 9, 2022, at 5:24 AM, Andrew Haley wrote: . . . >> So, if we revert to using the GCC intrinsics, we'd hurt performance on some >> systems, and we'd lose some control. On the other hand it'd be cleaner. Much >> cleaner. :-) > > Exactly. > > So what do folks think? > > Obviously, I can add support for the bitops using the existing structure (even > though I'd rather not) and we can revisit this somewhat messy situation again > later. Or we can clean up the code now. I am swayed by Kim's arguments that we should clean this up now. This is technical debt and the changes Kim wants to make imply an interest rate hike (extra development and maintenance). The potential for a performance hit on some (mostly legacy?) HW is unfortunate but I am not convinced it would matter much for most apps. Also, this change need not be backported which means there will still be a legacy LTS version for deployed applications where the change does make a noticeable difference to performance. A-and ... as Kim suggests, it may still be possible to configure a way around problematic hardware by passing the appropriate switches to gcc. If that is all the argument against then I definitely prefer simplifying this now. regards, Andrew Dinn ----------- From shade at openjdk.org Wed Sep 14 09:28:35 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Sep 2022 09:28:35 GMT Subject: RFR: 8293769: RISC-V: Add a second temporary register for BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 03:09:16 GMT, Fei Yang wrote: > This is similar to https://bugs.openjdk.org/browse/JDK-8293351 > Add a second temporary register for BarrierSetAssembler::load_at GC API on riscv64. > Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. > > Testing: Tier1-3 tested on Linux-riscv64 SiFive Unmatched board. Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10261 From shade at openjdk.org Wed Sep 14 09:28:38 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 14 Sep 2022 09:28:38 GMT Subject: RFR: 8293769: RISC-V: Add a second temporary register for BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: <2q-VKmsT6PcBevvtunpKXHP0ejDr-yzBVsFmn_0gYg4=.6e06020d-2a15-4ca1-90bc-0b159446a8ad@github.com> On Wed, 14 Sep 2022 09:01:12 GMT, Fei Yang wrote: >> I don't think 'tmp' is 't0' here since we are asserting they are different registers in ShenandoahBarrierSetAssembler::satb_write_barrier_pre [1]. And I also run non-trivial benchmark work loads like Dacapo, Specjvm and Specjbb using ShenandoahGC with fastdebug build for these changes. >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp#L111 > > PS: Also eyeballed all possible callers of ShenandoahBarrierSetAssembler::satb_write_barrier_pre and I think we are safe here :-) Okay then! ------------- PR: https://git.openjdk.org/jdk/pull/10261 From aph-open at littlepinkcloud.com Wed Sep 14 09:30:43 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Wed, 14 Sep 2022 10:30:43 +0100 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> Message-ID: <416c7338-2dff-7997-c95f-c9e1c74de180@littlepinkcloud.com> On 9/14/22 10:25, Andrew Dinn wrote: > I am swayed by Kim's arguments that we should clean this up now. This is > technical debt and the changes Kim wants to make imply an interest rate > hike (extra development and maintenance). OK, thanks. It seems to me to be more balanced: the current version has (slightly) better performance and is more configurable, but I take your point about maintenance. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ayang at openjdk.org Wed Sep 14 09:34:19 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 14 Sep 2022 09:34:19 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v5] In-Reply-To: <3ElpM4J3e32RLtJNBphsI3qJWJ6_cwT5ToiV6ZrXZQg=.8c0a3e11-0a98-4bbd-8dfe-5ffc1d1e600b@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <3ElpM4J3e32RLtJNBphsI3qJWJ6_cwT5ToiV6ZrXZQg=.8c0a3e11-0a98-4bbd-8dfe-5ffc1d1e600b@github.com> Message-ID: On Tue, 13 Sep 2022 16:00:05 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? >> >> This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. >> >> Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - clear_bitmap_for_region() -> clear_mark_data_for_region() > - ayang review 3 > another that TAMS is intrinsically linked to the bitmap (and marking) so it should be managed (like TARS) by G1ConcurrentMark I don't think tams and the bitmap are _intrinsically_ linked; they are two independent entities. Only in the marking context, are they linked. tams is intrinsically linked to marking but not the bitmap. > That G1 messes with the bitmap for evacuation failure handling is from an abstraction POV not good, but overall acceptable (and adds these warts). I don't view it as a leaky abstraction, since the bitmap is not really tied to marking in my mind. Recording evac-fail objs in the bitmap is completely isolated from the use of the bitmap during concurrent-marking. > This omits that call in the second invocation of G1CollectedHeap::clear_bitmap_for_region() because TAMS must be bottom() at that point. That's one of the reasons why I suggested moving tams assignment out. > I do not think this difference is the heart of this review and should not be preventing progress :) Agree; this is not a blocker. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From sgehwolf at redhat.com Wed Sep 14 09:53:46 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 14 Sep 2022 11:53:46 +0200 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: References: Message-ID: <34ad5f099c3ade9216abce7875a47e9b5fd67a08.camel@redhat.com> Hi, On Tue, 2022-09-13 at 15:16 -0400, Jonathan Joo wrote: > Hello hotspot-dev and hotspot-gc-dev, > > My name is Jonathan, and I'm working on the Java Platform Team at > Google. Here, we are working on a project to address Java container > memory issues, as we noticed that a significant number of Java > servers hit container OOM issues due to people incorrectly tuning > their heap size with respect to the container size. Because our > containers have other RAM consumers which fluctuate over time, it is > often difficult to determine a priori what is an appropriate Xmx to > set for a particular server.? > > We set about trying to solve this by dynamically adjusting the Java > heap/gc behavior based on the container usage information that we > pass into the JVM. We have seen promising results so far, reducing > container OOMs by a significant amount, and oftentimes also reducing > average heap usage (with the tradeoff of more CPU time spent doing > GC).? > > Below (under the dotted line) is a more detailed explanation of our > initial approach. Does this sound like something that may be useful > for the general OpenJDK community? If so, would some of you be open > to further discussion? I would also like to better understand what > container environments look like outside of Google, to see how we > could modify our approach for the more general case. It seems an interesting proposal and I'd be interested in your work. A few questions: 1. How is AHS enabled? Is it on by default or is it opt-in? 2. Is the prototype working for all GCs available in OpenJDK or specific to G1? 3. Would this be a Linux only feature? Thanks, Severin > Thank you! > > Jonathan > --------------------------------------------------------------------- > ---Introduction:Adaptable Heap Sizing (AHS) is a project internal to > Google that is meant to simplify configuration and improve the > stability of applications in container environments. The key is that > in a containerized environment, we have access to container usage and > limit information. This can be used as a signal to modify Java heap > behavior, helping prevent container OOMs. > Problem: * Containers at Google must be properly sized to not only > the JVM heap, but other memory consumers as well. These consumers > include non-heap Java (e.g. native code allocations), and > simultaneously running non-Java processes.? > ?* Common antipattern we see here at Google:? > ????- We have an application running into container OOMs.? > ????- An engineer raises both container memory limit and Xmx by the > same amount, since there appears to be insufficient memory. > ????- The application has reduced container OOMs, but is still prone > to them, since G1 continues to use most of Xmx. > ?* This results in many jobs being configured with much more RAM than > they need, but still running into container OOM issues. > Hypothesis: * For preventing container OOM: Why can't heap expansions > be bounded by the remaining free space in the container? > ?* For preventing the `unnecessarily high Xmx` antipattern: Why can't > target heap size be set based on GC CPU overhead? > ?* From our work on Adaptable Heap Sizing, it appears they can! > Design: * We add two manageable flags in the JVM > ????- Current maximum heap expansion size > ????- Current target heap size > ?* A separate thread runs alongside the JVM, querying: > ????- Container memory usage/limits > ????- GC CPU overhead metrics from the JVM. > ?* This thread then uses this information to calculate new values for > the two new JVM flags, and continually updates them at runtime. > ?* The `Current maximum heap expansion size` informs the JVM what is > the maximum amount we can expand the heap by, while staying within > container limits. This is a hard limit, and trying to expand more > than this amount results in behavior equivalent to hitting the Xmx > limit. > ?* The `Current target heap size` is a soft target value, which is > used to resize the heap (when possible) so as to bring GC CPU > overhead toward its target value.? > > Results: * At Google, we have found that this design works incredibly > well in our initial rollout, even for large and complex workloads. > ?* After deploying this to dozens of applications: > ????- Significant memory savings for previously misconfigured jobs > (many of which reduced their heap usage by 50% or more) > ????- Significantly reduced occurrences of container OOM (100% > reduction in vast majority of cases) > ????- No correctness issues > ????- No latency regressions* > ????- We plan to deploy AHS across a much wider subset of > applications by EOY '22. > > *Caveats:? * Enabling this feature might require tuning of the newly > introduced default GC CPU overhead target to avoid regressions. > ?* Time spent doing GC for an application may increase significantly > (though generally we've seen in practice that even if this is the > case, end-to-end latency does not increase a noticeable amount) > ?* Enabling AHS results in frequent heap resizings, but we have not > seen evidence of any negative effects as a result of these more > frequent heap resizings. > ?* AHS is not necessarily a replacement for proper JVM tuning, but > should generally work better than an untuned or improperly tuned > configuration. > ?* AHS is not intended for every possible workload, and there could > be pathological cases where AHS results in worse behavior. From tschatzl at openjdk.org Wed Sep 14 10:26:41 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 14 Sep 2022 10:26:41 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v5] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> <3ElpM4J3e32RLtJNBphsI3qJWJ6_cwT5ToiV6ZrXZQg=.8c0a3e11-0a98-4bbd-8dfe-5ffc1d1e600b@github.com> Message-ID: On Wed, 14 Sep 2022 09:31:15 GMT, Albert Mingkun Yang wrote: > > another that TAMS is intrinsically linked to the bitmap (and marking) so it should be managed (like TARS) by G1ConcurrentMark > > I don't think tams and the bitmap are _intrinsically_ linked; they are two independent entities. Only in the marking context, are they linked. tams is intrinsically linked to marking but not the bitmap. I see the use of the (marking) bitmap during evacuation failure as an optimization of memory usage. Evacuation failure and marking are completely different concerns and in an ideal world should not share data structures. > > > That G1 messes with the bitmap for evacuation failure handling is from an abstraction POV not good, but overall acceptable (and adds these warts). > > I don't view it as a leaky abstraction, since the bitmap is not really tied to marking in my mind. Recording evac-fail objs in the bitmap is completely isolated from the use of the bitmap during concurrent-marking. We can probably only use the marking bitmap for evac-fail objs because we made the (prior, well reasoned) design decision to completely separate mixed collection and marking. Marking in the mixed phase could be implemented (and actually iirc it has been possible and working in JDK7/8. At least I remember some bug which fixed some accidental enabling of that for a time...). Then this reuse might have been a problem. In the currently only case where concurrent marking overlaps the mixed phase (Concurrent Clear for Next Mark) it just happens to be okay to clear the bitmap twice, once at gc start and then in the concurrent phase. The marking bitmap contents (per region) are also only valid between bottom and tams of a region; that the bitmap always covers the whole region is an implementation detail (and something I actually would like to experiment with to get rid of at some point - why keep around so much memory if it isn't used? There are often regions that do not contain live objects at all, why have backing storage committed bitmaps for them in advance? Or humongous objects, is it efficient to commit the whole area they span for a single mark at the header?). There are also some marking algorithm improvements (with desirable properties) that add a little bit more per-region helper data structures that might need to be reset at that point. Potentially having to enumerate all of these for clearing at all of the places where we now use `clear_bitmap_for_region` seems cumbersome and error-prone. Clearing additional data might be some extra work, but from whatever I've seen so far it isn't relevant. This is why in my view the (per-region) bitmap and tams are both by definition marking related data structures, and should be treated as intrinsically linked. Imho evac-failure simply barges in and reuses them out of convenience (in some way) ;-) > > > This omits that call in the second invocation of G1CollectedHeap::clear_bitmap_for_region() because TAMS must be bottom() at that point. > > That's one of the reasons why I suggested moving tams assignment out. I found that not only doing the absolutely necessary thing very often makes the code clearer, allowing to raise the abstraction level for the code, i.e. "clear all marking data for region" vs. "clear bitmap for region". In this case the overhead is an assignment to a single variable in addition to clearing kBs of bitmap data... ------------- PR: https://git.openjdk.org/jdk/pull/9980 From thomas.stuefe at gmail.com Wed Sep 14 10:55:24 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 14 Sep 2022 12:55:24 +0200 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: <34ad5f099c3ade9216abce7875a47e9b5fd67a08.camel@redhat.com> References: <34ad5f099c3ade9216abce7875a47e9b5fd67a08.camel@redhat.com> Message-ID: On Wed, Sep 14, 2022 at 11:53 AM Severin Gehwolf wrote: > Hi, > > On Tue, 2022-09-13 at 15:16 -0400, Jonathan Joo wrote: > > Hello hotspot-dev and hotspot-gc-dev, > > > > My name is Jonathan, and I'm working on the Java Platform Team at > > Google. Here, we are working on a project to address Java container > > memory issues, as we noticed that a significant number of Java > > servers hit container OOM issues due to people incorrectly tuning > > their heap size with respect to the container size. Because our > > containers have other RAM consumers which fluctuate over time, it is > > often difficult to determine a priori what is an appropriate Xmx to > > set for a particular server. > > > > We set about trying to solve this by dynamically adjusting the Java > > heap/gc behavior based on the container usage information that we > > pass into the JVM. We have seen promising results so far, reducing > > container OOMs by a significant amount, and oftentimes also reducing > > average heap usage (with the tradeoff of more CPU time spent doing > > GC). > > > > Below (under the dotted line) is a more detailed explanation of our > > initial approach. Does this sound like something that may be useful > > for the general OpenJDK community? If so, would some of you be open > > to further discussion? I would also like to better understand what > > container environments look like outside of Google, to see how we > > could modify our approach for the more general case. > > It seems an interesting proposal and I'd be interested in your work. A > few questions: > > 1. How is AHS enabled? Is it on by default or is it opt-in? > 2. Is the prototype working for all GCs available in OpenJDK or > specific to G1? > 3. Would this be a Linux only feature? > > Thanks, > Severin > > > ... we are also interested. Can you describe the adjustment logic in more detail or is there a public prototypec? Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From tschatzl at openjdk.org Wed Sep 14 10:55:50 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 14 Sep 2022 10:55:50 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v6] In-Reply-To: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Message-ID: > Hi all, > > can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? > > This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. > > Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: sjohanss, ayang review 4 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9980/files - new: https://git.openjdk.org/jdk/pull/9980/files/3363fca0..10082a13 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9980&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9980&range=04-05 Stats: 15 lines in 7 files changed: 2 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9980.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9980/head:pull/9980 PR: https://git.openjdk.org/jdk/pull/9980 From fjiang at openjdk.org Wed Sep 14 11:07:29 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 14 Sep 2022 11:07:29 GMT Subject: RFR: 8293770: RISC-V: Reuse runtime call trampolines In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 02:58:42 GMT, Dingli Zhang wrote: > Follow up [JDK-8280152](https://bugs.openjdk.org/browse/JDK-8280152), this case also exists in riscv. > > Benchmark als, chi-square, dec-tree, log-regression, naive-bayes, page-rank, fj-kmeans, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~2.1% reduction on average. > > ## Testing: > > - hotspot and jdk tier1 on unmatched board without new failures > - hotspot/jtreg/compiler/sharedstubs/SharedTrampolineTest.java with fastdebug on qemu > > > ## Results > #### Results from [Renaissance 0.14.1](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.1) > > - riscv64 > > +--------------------------------------------------------------------------------------------------------+ > | | Before | After | > | Benchmark |---------------------------------------------------------------------------------------| > | | non-profiled nmethods | profiled nmethods | non-profiled nmethods | profiled nmethods | > +----------------+-----------------------+-------------------+-----------------------+-------------------| > | als | 15628 | 39421 | 12341 | 26681 | > | chi-square | 6349 | 20268 | 6033 | 20252 | > | dec-tree | 11058 | 42443 | 10774 | 43880 | > | log-regression | 10939 | 38237 | 12071 | 44199 | > | naive-bayes | 9023 | 29563 | 9294 | 30948 | > | page-rank | 6054 | 17041 | 5812 | 17353 | > | fj-kmeans | 692 | 2893 | 651 | 3354 | > | reactors | 2126 | 4073 | 1876 | 4106 | > | future-genetic | 1306 | 4118 | 1226 | 4142 | > | mnemonics | 726 | 2659 | 706 | 2684 | > | dotty | 26059 | 24417 | 24585 | 25379 | > | scala-kmeans | 564 | 3122 | 543 | 3132 | > | finagle-http | 6188 | 12455 | 6102 | 12295 | > | sum | 96712 | 240710 | 92014 | 238405 | > +--------------------------------------------------------------------------------------------------------+ Marked as reviewed by fjiang (Author). ------------- PR: https://git.openjdk.org/jdk/pull/10260 From ayang at openjdk.org Wed Sep 14 11:22:55 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 14 Sep 2022 11:22:55 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v6] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Message-ID: On Wed, 14 Sep 2022 10:55:50 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? >> >> This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. >> >> Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > sjohanss, ayang review 4 Just some minor comments. src/hotspot/share/gc/g1/g1EvacFailure.cpp line 209: > 207: } > 208: > 209: void G1RemoveSelfForwardsTask::initialize() { Any particular reason why this is not part of the constructor? src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 117: > 115: > 116: double chunks_per_thread = (double)G1CollectedHeap::get_chunks_per_region() / G1RestoreRetainedRegionChunksPerWorker; > 117: return chunks_per_thread * _evac_failure_regions->num_regions_failed_evacuation(); The calculation is correct, but the var name is wrong. `chunks/region / chunks/worker == workers/region` then `workers/region * region == workers`. This method returns the optimal number of workers. (PS: I still think doing multiplication is easier to reason, but that can be subjective.) ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.org/jdk/pull/9980 From coleenp at openjdk.org Wed Sep 14 11:28:08 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 14 Sep 2022 11:28:08 GMT Subject: RFR: 8288474: Move EventContinuationFreezeOld from try_freeze_fast to freeze_slow Message-ID: <3lXMF0TmKkRJn2-XsO_tEk7MPmlA14n1R8fMFIaaQBY=.a481d3bd-d694-4276-9682-7ce467f8ca7b@github.com> This moves the event ContinuationFreezeOld to freeze_slow so it's reported on the different paths to freeze_slow, and renames the events Continuation*Old/Continuation*Slow and Continuation*Young/Continuation*Fast to reflect that they're on the fast/slow paths. I turned on CONT_JFR and fixed some bugs and turned it back off again. Some output: $ jfr summary hotspot-pid-31671-id-1-2022_09_13_19_42_01.jfr | grep Continuation jdk.ContinuationThaw 12193 211929 jdk.ContinuationThawFast 10139 165420 jdk.ContinuationFreeze 3196 57135 jdk.ContinuationFreezeFast 2788 46397 jdk.ContinuationThawSlow 2054 28543 jdk.ContinuationFreezeSlow 408 5688 Tested locally and with tier7 which seems to run JFR tests. ------------- Commit messages: - Turn off CONT_JFR - 8288474: Move EventContinuationFreezeOld from try_freeze_fast to freeze_slow Changes: https://git.openjdk.org/jdk/pull/10254/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10254&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288474 Stats: 42 lines in 4 files changed: 9 ins; 8 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/10254.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10254/head:pull/10254 PR: https://git.openjdk.org/jdk/pull/10254 From rpressler at openjdk.org Wed Sep 14 11:48:50 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Wed, 14 Sep 2022 11:48:50 GMT Subject: RFR: 8288474: Move EventContinuationFreezeOld from try_freeze_fast to freeze_slow In-Reply-To: <3lXMF0TmKkRJn2-XsO_tEk7MPmlA14n1R8fMFIaaQBY=.a481d3bd-d694-4276-9682-7ce467f8ca7b@github.com> References: <3lXMF0TmKkRJn2-XsO_tEk7MPmlA14n1R8fMFIaaQBY=.a481d3bd-d694-4276-9682-7ce467f8ca7b@github.com> Message-ID: <4tCWvQHAGXwigPcQViD3rzZFxPzuWy5ngdzE1DWsoyg=.494afb53-437a-413c-ac3d-7fc560953d26@github.com> On Tue, 13 Sep 2022 20:22:58 GMT, Coleen Phillimore wrote: > This moves the event ContinuationFreezeOld to freeze_slow so it's reported on the different paths to freeze_slow, and renames the events Continuation*Old/Continuation*Slow and Continuation*Young/Continuation*Fast to reflect that they're on the fast/slow paths. I turned on CONT_JFR and fixed some bugs and turned it back off again. Some output: > > $ jfr summary hotspot-pid-31671-id-1-2022_09_13_19_42_01.jfr | grep Continuation > jdk.ContinuationThaw 12193 211929 > jdk.ContinuationThawFast 10139 165420 > jdk.ContinuationFreeze 3196 57135 > jdk.ContinuationFreezeFast 2788 46397 > jdk.ContinuationThawSlow 2054 28543 > jdk.ContinuationFreezeSlow 408 5688 > > Tested locally and with tier7 which seems to run JFR tests. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 723: > 721: #if CONT_JFR > 722: EventContinuationFreezeSlow e; > 723: if (e.should_commit()) { Committing the event should happen at the end of the method to measure the time. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1855: > 1853: #if CONT_JFR > 1854: EventContinuationThawSlow e; > 1855: if (e.should_commit()) { Committing the event should be done at the end of the method. ------------- PR: https://git.openjdk.org/jdk/pull/10254 From duke at openjdk.org Wed Sep 14 12:01:42 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 14 Sep 2022 12:01:42 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable [v5] In-Reply-To: References: Message-ID: > Hi! > > Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. > > When I've left ResourceMarks in place I've also commented which calls requires them. > > This passes tier1, tier2 tests. Johan Sj?l?n has updated the pull request incrementally with two additional commits since the last revision: - Change base to internal_string - Add invariant tracking in new method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10142/files - new: https://git.openjdk.org/jdk/pull/10142/files/700f91b4..4685ff32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=03-04 Stats: 62 lines in 27 files changed: 8 ins; 0 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/10142.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10142/head:pull/10142 PR: https://git.openjdk.org/jdk/pull/10142 From duke at openjdk.org Wed Sep 14 12:01:44 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 14 Sep 2022 12:01:44 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable [v4] In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 10:05:52 GMT, Johan Sj?l?n wrote: >> Hi! >> >> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. >> >> When I've left ResourceMarks in place I've also commented which calls requires them. >> >> This passes tier1, tier2 tests. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Remove invariant tracking > > Too much depends on this invariant not being met. Having a 2nd go at invariant tracking by introducing a new function `internal_string`. I imagine that a future RFE would rename `base` to `raw_string` and that `as_string` is split into `heap_string` and `resource_string`. This would make the interface clearer, imho. ------------- PR: https://git.openjdk.org/jdk/pull/10142 From duke at openjdk.org Wed Sep 14 12:03:52 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 14 Sep 2022 12:03:52 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable [v6] In-Reply-To: References: Message-ID: > Hi! > > Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. > > When I've left ResourceMarks in place I've also commented which calls requires them. > > This passes tier1, tier2 tests. Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Missed fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10142/files - new: https://git.openjdk.org/jdk/pull/10142/files/4685ff32..f7e2a8a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10142.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10142/head:pull/10142 PR: https://git.openjdk.org/jdk/pull/10142 From tschatzl at openjdk.org Wed Sep 14 12:11:14 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 14 Sep 2022 12:11:14 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v7] In-Reply-To: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Message-ID: > Hi all, > > can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? > > This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. > > Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: ayang review 5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9980/files - new: https://git.openjdk.org/jdk/pull/9980/files/10082a13..d1febe71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9980&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9980&range=05-06 Stats: 30 lines in 3 files changed: 11 ins; 16 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9980.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9980/head:pull/9980 PR: https://git.openjdk.org/jdk/pull/9980 From coleenp at openjdk.org Wed Sep 14 12:21:28 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 14 Sep 2022 12:21:28 GMT Subject: RFR: 8288474: Move EventContinuationFreezeOld from try_freeze_fast to freeze_slow In-Reply-To: <4tCWvQHAGXwigPcQViD3rzZFxPzuWy5ngdzE1DWsoyg=.494afb53-437a-413c-ac3d-7fc560953d26@github.com> References: <3lXMF0TmKkRJn2-XsO_tEk7MPmlA14n1R8fMFIaaQBY=.a481d3bd-d694-4276-9682-7ce467f8ca7b@github.com> <4tCWvQHAGXwigPcQViD3rzZFxPzuWy5ngdzE1DWsoyg=.494afb53-437a-413c-ac3d-7fc560953d26@github.com> Message-ID: On Wed, 14 Sep 2022 11:45:42 GMT, Ron Pressler wrote: >> This moves the event ContinuationFreezeOld to freeze_slow so it's reported on the different paths to freeze_slow, and renames the events Continuation*Old/Continuation*Slow and Continuation*Young/Continuation*Fast to reflect that they're on the fast/slow paths. I turned on CONT_JFR and fixed some bugs and turned it back off again. Some output: >> >> $ jfr summary hotspot-pid-31671-id-1-2022_09_13_19_42_01.jfr | grep Continuation >> jdk.ContinuationThaw 12193 211929 >> jdk.ContinuationThawFast 10139 165420 >> jdk.ContinuationFreeze 3196 57135 >> jdk.ContinuationFreezeFast 2788 46397 >> jdk.ContinuationThawSlow 2054 28543 >> jdk.ContinuationFreezeSlow 408 5688 >> >> Tested locally and with tier7 which seems to run JFR tests. > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 723: > >> 721: #if CONT_JFR >> 722: EventContinuationFreezeSlow e; >> 723: if (e.should_commit()) { > > Committing the event should happen at the end of the method to measure the time. That makes sense but the time recorded for these is startTime: jdk.ContinuationThawSlow { startTime = 11:54:23.301 (2022-09-14) id = 4260565248 eventThread = "MainThread" (javaThreadId = 36) } ------------- PR: https://git.openjdk.org/jdk/pull/10254 From coleenp at openjdk.org Wed Sep 14 12:21:29 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 14 Sep 2022 12:21:29 GMT Subject: RFR: 8288474: Move EventContinuationFreezeOld from try_freeze_fast to freeze_slow In-Reply-To: References: <3lXMF0TmKkRJn2-XsO_tEk7MPmlA14n1R8fMFIaaQBY=.a481d3bd-d694-4276-9682-7ce467f8ca7b@github.com> <4tCWvQHAGXwigPcQViD3rzZFxPzuWy5ngdzE1DWsoyg=.494afb53-437a-413c-ac3d-7fc560953d26@github.com> Message-ID: On Wed, 14 Sep 2022 12:12:01 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 723: >> >>> 721: #if CONT_JFR >>> 722: EventContinuationFreezeSlow e; >>> 723: if (e.should_commit()) { >> >> Committing the event should happen at the end of the method to measure the time. > > That makes sense but the time recorded for these is startTime: > jdk.ContinuationThawSlow { > startTime = 11:54:23.301 (2022-09-14) > id = 4260565248 > eventThread = "MainThread" (javaThreadId = 36) > } jdk.ContinuationThawFast { startTime = 11:54:23.360 (2022-09-14) id = 4259803872 full = false size = 48 eventThread = "MainThread" (javaThreadId = 36) } jdk.ContinuationThaw { startTime = 11:54:23.360 (2022-09-14) duration = 0.00675 ms carrierThread = "MainThread" (javaThreadId = 36) continuationClass = Fuzz$2 (classLoader = app) interpretedFrames = 0 size = 64 bytes eventThread = "MainThread" (javaThreadId = 36) } Also the fast version is start time. The duration is reported for the non Fast/Slow events. ------------- PR: https://git.openjdk.org/jdk/pull/10254 From rpressler at openjdk.org Wed Sep 14 12:27:44 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Wed, 14 Sep 2022 12:27:44 GMT Subject: RFR: 8288474: Move EventContinuationFreezeOld from try_freeze_fast to freeze_slow In-Reply-To: <3lXMF0TmKkRJn2-XsO_tEk7MPmlA14n1R8fMFIaaQBY=.a481d3bd-d694-4276-9682-7ce467f8ca7b@github.com> References: <3lXMF0TmKkRJn2-XsO_tEk7MPmlA14n1R8fMFIaaQBY=.a481d3bd-d694-4276-9682-7ce467f8ca7b@github.com> Message-ID: On Tue, 13 Sep 2022 20:22:58 GMT, Coleen Phillimore wrote: > This moves the event ContinuationFreezeOld to freeze_slow so it's reported on the different paths to freeze_slow, and renames the events Continuation*Old/Continuation*Slow and Continuation*Young/Continuation*Fast to reflect that they're on the fast/slow paths. I turned on CONT_JFR and fixed some bugs and turned it back off again. Some output: > > $ jfr summary hotspot-pid-31671-id-1-2022_09_13_19_42_01.jfr | grep Continuation > jdk.ContinuationThaw 12193 211929 > jdk.ContinuationThawFast 10139 165420 > jdk.ContinuationFreeze 3196 57135 > jdk.ContinuationFreezeFast 2788 46397 > jdk.ContinuationThawSlow 2054 28543 > jdk.ContinuationFreezeSlow 408 5688 > > Tested locally and with tier7 which seems to run JFR tests. Marked as reviewed by rpressler (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/10254 From sjohanss at openjdk.org Wed Sep 14 12:44:36 2022 From: sjohanss at openjdk.org (Stefan Johansson) Date: Wed, 14 Sep 2022 12:44:36 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v7] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Message-ID: <1wSew26znZT03HsRs2_aXS5uAVVSDCu84cdFyKYFBfU=.046734ea-26cb-4b26-ab2f-0dbb94b5cedd@github.com> On Wed, 14 Sep 2022 12:11:14 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? >> >> This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. >> >> Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > ayang review 5 Looks good. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.org/jdk/pull/9980 From stuefe at openjdk.org Wed Sep 14 12:57:37 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 14 Sep 2022 12:57:37 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable [v6] In-Reply-To: References: Message-ID: <7GN_5qAEZr9HjWItusy4UGLENSTyGRDADf7pVFdES84=.0567293e-927d-4281-ac99-500b767c9c3b@github.com> On Wed, 14 Sep 2022 12:03:52 GMT, Johan Sj?l?n wrote: >> Hi! >> >> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. >> >> When I've left ResourceMarks in place I've also commented which calls requires them. >> >> This passes tier1, tier2 tests. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Missed fixes Hi Johan, please be aware that changes like these across the code base makes downporting more painful. So I would only do wholesale renames and replacements where the benefit clearly outweighs the downporting costs. About your last iteration, yes, I think requiring base() to freeze the stream is a bit much. How about renaming "internal_string" to "freeze" // Freezes stringStream (no further modifications possible) and returns pointer to it. // No-op if stream is frozen already. const char* freeze(); "freeze" is snappy and clear in its meaning. And in release builds I also would freeze, allowing no further changes, apart from the debug-only assert. Since writes potentially reallocate the buffer, the char ptr may be invalid, better to have incomplete stringStream output than C-heap corruption (as improbable as it is). ------------- PR: https://git.openjdk.org/jdk/pull/10142 From stuefe at openjdk.org Wed Sep 14 12:59:42 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 14 Sep 2022 12:59:42 GMT Subject: RFR: JDK-8293402: hs-err file printer should reattempt stack trace printing if it fails In-Reply-To: References: Message-ID: <3R1LDuv00EcfhcbVsEvpxrJhCxj-Z32Q2RAugJx708w=.38c2ac29-acf7-49ab-b088-c50602bad0f8@github.com> On Tue, 6 Sep 2022 08:05:23 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews for this small improvement. > > The call stack may be the most important part of an hs-err file. We recently introduced printing of source information (https://bugs.openjdk.org/browse/JDK-8242181) which is nice but makes stack printing more vulnerable for two reasons: > - we may crash due to a programmer error (e.g. https://bugs.openjdk.org/browse/JDK-8293344) > - we may timeout on very slow machines/file systems when the source information are parsed from the debug info (we have seen those problems in the past) > > Therefore, VMError should retry stack printing without source information if the first attempt to print failed. > > Examples: > > Step timeouts while retrieving source info: > > > 24 --------------- T H R E A D --------------- > 25 > 26 Current thread (0x00007f70ac028bd0): JavaThread "main" [_thread_in_vm, id=565259, stack(0x00007f70b0587000,0x00007f70b0688000)] > 27 > 28 Stack: [0x00007f70b0587000,0x00007f70b0688000], sp=0x00007f70b0686cf0, free space=1023k > 29 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 30 V [libjvm.so+0x1cd41c1] VMError::controlled_crash(int)+0x241 > 31 [timeout occurred during error reporting in step "printing native stack (with source info)"] after 30 s. > 32 > 33 Retrying call stack printing without source information... > 34 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 35 V [libjvm.so+0x1cd41c1] VMError::controlled_crash(int)+0x241 > 36 V [libjvm.so+0x11cbe45] JNI_CreateJavaVM+0x5b5 > 37 C [libjli.so+0x4013] JavaMain+0x93 > 38 C [libjli.so+0x800d] ThreadJavaMain+0xd > 39 > > > > Step crashes while retrieving source info: > > > 24 --------------- T H R E A D --------------- > 25 > 26 Current thread (0x00007fc000028bd0): JavaThread "main" [_thread_in_vm, id=569254, stack(0x00007fc00573c000,0x00007fc00583d000)] > 27 > 28 Stack: [0x00007fc00573c000,0x00007fc00583d000], sp=0x00007fc00583bcf0, free space=1023k > 29 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 30 V [libjvm.so+0x1cd41e1] VMError::controlled_crash(int)+0x241 > 31 [error occurred during error reporting (printing native stack (with source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fc006694d78] > 32 > 33 > 34 Retrying call stack printing without source information... > 35 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 36 V [libjvm.so+0x1cd41e1] VMError::controlled_crash(int)+0x241 > 37 V [libjvm.so+0x11cbe65] JNI_CreateJavaVM+0x5b5 > 38 C [libjli.so+0x4013] JavaMain+0x93 > 39 C [libjli.so+0x800d] ThreadJavaMain+0xd > > > > Thanks, Thomas Friendly ping for a second review. Change is rather simple. ------------- PR: https://git.openjdk.org/jdk/pull/10179 From stuefe at openjdk.org Wed Sep 14 13:02:25 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 14 Sep 2022 13:02:25 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp Message-ID: Arguments.cpp has several size parsing functions which would be useful in other areas of the hotspot, e.g. in NMT. It would be nice to have them factored out into utilities, to reuse the code and to unify memory size handling. Gtests would be good too. To simplify reviews, I split the patch into two commits. The first commit (https://github.com/openjdk/jdk/pull/10252/commits/700e77e8d1469a2fc3d6611072c4b07aa34ab8e6) contains the unchanged code move without functional changes. The second commit (https://github.com/openjdk/jdk/pull/10252/commits/76b4f6f30cc316fd966da60ff6601f54eeb394bf) contains the functional changes I did, as well as the new gtest. ------------- Commit messages: - Actual changes + tests - Verbatim move, no fixes Changes: https://git.openjdk.org/jdk/pull/10252/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10252&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293711 Stats: 494 lines in 6 files changed: 376 ins; 109 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/10252.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10252/head:pull/10252 PR: https://git.openjdk.org/jdk/pull/10252 From duke at openjdk.org Wed Sep 14 13:32:46 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 14 Sep 2022 13:32:46 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable [v7] In-Reply-To: References: Message-ID: > Hi! > > Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. > > When I've left ResourceMarks in place I've also commented which calls requires them. > > This passes tier1, tier2 tests. Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Rename to freeze ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10142/files - new: https://git.openjdk.org/jdk/pull/10142/files/f7e2a8a7..673bad51 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10142&range=05-06 Stats: 61 lines in 27 files changed: 1 ins; 0 del; 60 mod Patch: https://git.openjdk.org/jdk/pull/10142.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10142/head:pull/10142 PR: https://git.openjdk.org/jdk/pull/10142 From duke at openjdk.org Wed Sep 14 13:32:49 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 14 Sep 2022 13:32:49 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable [v6] In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 12:03:52 GMT, Johan Sj?l?n wrote: >> Hi! >> >> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. >> >> When I've left ResourceMarks in place I've also commented which calls requires them. >> >> This passes tier1, tier2 tests. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Missed fixes Hi Thomas, Thank you for your input. I agree, freeze is snappy. I applied your suggestion. ------------- PR: https://git.openjdk.org/jdk/pull/10142 From asmehra at redhat.com Wed Sep 14 14:34:59 2022 From: asmehra at redhat.com (Ashutosh Mehra) Date: Wed, 14 Sep 2022 10:34:59 -0400 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: References: Message-ID: Hi Jonathan, Thanks for sharing your work here. I have a few questions to understand the idea better. > - > > Containers at Google must be properly sized to not only the JVM heap, > but other memory consumers as well. These consumers include non-heap Java > (e.g. native code allocations), and simultaneously running non-Java > processes. > > How is the container memory limit being determined? Does that process take into account non-Java processes running in the container as well? > - > > We have an application running into container OOMs. > - > > An engineer raises both container memory limit and Xmx by the same > amount, since there appears to be insufficient memory. > > If I understand it correctly, the problem appears to be that when the JVM tries to expand the heap within Xmx limits, as there are other non-Java processes consuming memory, the total used memory of the container reaches the container limit and results in container OOMs. It makes sense to raise the container memory limit, but what is the need to raise the Xmx by the same amount? > - > > For preventing container OOM: Why can't heap expansions be bounded by > the remaining free space in the container? > > I am wondering if Java heap expansion is always the cause of container OOM? As you mentioned earlier, there are other non-Java processes and other components in Java that consume native heap. I believe they too can be the source of container OOM. If so, then bounding the heap expansion would not cover all the cases. Time spent doing GC for an application may increase significantly (though > generally we've seen in practice that even if this is the case, end-to-end > latency does not increase a noticeable amount) > I guess it really depends on how much room is left for java heap expansion, which brings us back to right sizing the container memory limt. Regards, Ashutosh Mehra On Tue, Sep 13, 2022 at 3:54 PM Jonathan Joo wrote: > Hello hotspot-dev and hotspot-gc-dev, > > My name is Jonathan, and I'm working on the Java Platform Team at Google. > Here, we are working on a project to address Java container memory issues, > as we noticed that a significant number of Java servers hit container OOM > issues due to people incorrectly tuning their heap size with respect to the > container size. Because our containers have other RAM consumers which > fluctuate over time, it is often difficult to determine a priori what is an > appropriate Xmx to set for a particular server. > > We set about trying to solve this by dynamically adjusting the Java > heap/gc behavior based on the container usage information that we pass into > the JVM. We have seen promising results so far, reducing container OOMs by > a significant amount, and oftentimes also reducing average heap usage (with > the tradeoff of more CPU time spent doing GC). > > Below (under the dotted line) is a more detailed explanation of our > initial approach. Does this sound like something that may be useful for the > general OpenJDK community? If so, would some of you be open to further > discussion? I would also like to better understand what container > environments look like outside of Google, to see how we could modify our > approach for the more general case. > > Thank you! > > > Jonathan > ------------------------------------------------------------------------ > Introduction: > > Adaptable Heap Sizing (AHS) is a project internal to Google that is meant > to simplify configuration and improve the stability of applications in > container environments. The key is that in a containerized environment, we > have access to container usage and limit information. This can be used as a > signal to modify Java heap behavior, helping prevent container OOMs. > Problem: > > - > > Containers at Google must be properly sized to not only the JVM heap, > but other memory consumers as well. These consumers include non-heap Java > (e.g. native code allocations), and simultaneously running non-Java > processes. > - > > Common antipattern we see here at Google: > - > > We have an application running into container OOMs. > - > > An engineer raises both container memory limit and Xmx by the same > amount, since there appears to be insufficient memory. > - > > The application has reduced container OOMs, but is still prone to > them, since G1 continues to use most of Xmx. > - > > This results in many jobs being configured with much more RAM than > they need, but still running into container OOM issues. > > Hypothesis: > > - > > For preventing container OOM: Why can't heap expansions be bounded by > the remaining free space in the container? > - > > For preventing the `unnecessarily high Xmx` antipattern: Why can't > target heap size be set based on GC CPU overhead? > - > > From our work on Adaptable Heap Sizing, it appears they can! > > Design: > > - > > We add two manageable flags in the JVM > - > > Current maximum heap expansion size > - > > Current target heap size > - > > A separate thread runs alongside the JVM, querying: > - > > Container memory usage/limits > - > > GC CPU overhead metrics from the JVM. > - > > This thread then uses this information to calculate new values for the > two new JVM flags, and continually updates them at runtime. > - > > The `Current maximum heap expansion size` informs the JVM what is the > maximum amount we can expand the heap by, while staying within container > limits. This is a hard limit, and trying to expand more than this amount > results in behavior equivalent to hitting the Xmx limit. > - > > The `Current target heap size` is a soft target value, which is used to > resize the heap (when possible) so as to bring GC CPU overhead toward its > target value. > > > Results: > > - > > At Google, we have found that this design works incredibly well in our > initial rollout, even for large and complex workloads. > - > > After deploying this to dozens of applications: > - > > Significant memory savings for previously misconfigured jobs (many > of which reduced their heap usage by 50% or more) > - > > Significantly reduced occurrences of container OOM (100% reduction > in vast majority of cases) > - > > No correctness issues > - > > No latency regressions* > - > > We plan to deploy AHS across a much wider subset of applications by > EOY '22. > > > *Caveats: > > - Enabling this feature might require tuning of the newly introduced > default GC CPU overhead target to avoid regressions. > - > > Time spent doing GC for an application may increase significantly > (though generally we've seen in practice that even if this is the case, > end-to-end latency does not increase a noticeable amount) > - > > Enabling AHS results in frequent heap resizings, but we have not seen > evidence of any negative effects as a result of these more frequent heap > resizings. > - > > AHS is not necessarily a replacement for proper JVM tuning, but should > generally work better than an untuned or improperly tuned configuration. > - > > AHS is not intended for every possible workload, and there could be > pathological cases where AHS results in worse behavior. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsamersoff at openjdk.org Wed Sep 14 15:43:43 2022 From: dsamersoff at openjdk.org (Dmitry Samersoff) Date: Wed, 14 Sep 2022 15:43:43 GMT Subject: RFR: JDK-8293402: hs-err file printer should reattempt stack trace printing if it fails In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 08:05:23 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews for this small improvement. > > The call stack may be the most important part of an hs-err file. We recently introduced printing of source information (https://bugs.openjdk.org/browse/JDK-8242181) which is nice but makes stack printing more vulnerable for two reasons: > - we may crash due to a programmer error (e.g. https://bugs.openjdk.org/browse/JDK-8293344) > - we may timeout on very slow machines/file systems when the source information are parsed from the debug info (we have seen those problems in the past) > > Therefore, VMError should retry stack printing without source information if the first attempt to print failed. > > Examples: > > Step timeouts while retrieving source info: > > > 24 --------------- T H R E A D --------------- > 25 > 26 Current thread (0x00007f70ac028bd0): JavaThread "main" [_thread_in_vm, id=565259, stack(0x00007f70b0587000,0x00007f70b0688000)] > 27 > 28 Stack: [0x00007f70b0587000,0x00007f70b0688000], sp=0x00007f70b0686cf0, free space=1023k > 29 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 30 V [libjvm.so+0x1cd41c1] VMError::controlled_crash(int)+0x241 > 31 [timeout occurred during error reporting in step "printing native stack (with source info)"] after 30 s. > 32 > 33 Retrying call stack printing without source information... > 34 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 35 V [libjvm.so+0x1cd41c1] VMError::controlled_crash(int)+0x241 > 36 V [libjvm.so+0x11cbe45] JNI_CreateJavaVM+0x5b5 > 37 C [libjli.so+0x4013] JavaMain+0x93 > 38 C [libjli.so+0x800d] ThreadJavaMain+0xd > 39 > > > > Step crashes while retrieving source info: > > > 24 --------------- T H R E A D --------------- > 25 > 26 Current thread (0x00007fc000028bd0): JavaThread "main" [_thread_in_vm, id=569254, stack(0x00007fc00573c000,0x00007fc00583d000)] > 27 > 28 Stack: [0x00007fc00573c000,0x00007fc00583d000], sp=0x00007fc00583bcf0, free space=1023k > 29 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 30 V [libjvm.so+0x1cd41e1] VMError::controlled_crash(int)+0x241 > 31 [error occurred during error reporting (printing native stack (with source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fc006694d78] > 32 > 33 > 34 Retrying call stack printing without source information... > 35 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 36 V [libjvm.so+0x1cd41e1] VMError::controlled_crash(int)+0x241 > 37 V [libjvm.so+0x11cbe65] JNI_CreateJavaVM+0x5b5 > 38 C [libjli.so+0x4013] JavaMain+0x93 > 39 C [libjli.so+0x800d] ThreadJavaMain+0xd > > > > Thanks, Thomas Marked as reviewed by dsamersoff (Reviewer). src/hotspot/share/utilities/vmError.cpp line 854: > 852: } > 853: > 854: STEP("retry printing native stack (no source info)") Should we move STEP under if (print_native_stack_succeeded) ? ------------- PR: https://git.openjdk.org/jdk/pull/10179 From stuefe at openjdk.org Wed Sep 14 16:40:43 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 14 Sep 2022 16:40:43 GMT Subject: RFR: JDK-8293402: hs-err file printer should reattempt stack trace printing if it fails In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 15:39:18 GMT, Dmitry Samersoff wrote: >> Hi, >> >> may I have reviews for this small improvement. >> >> The call stack may be the most important part of an hs-err file. We recently introduced printing of source information (https://bugs.openjdk.org/browse/JDK-8242181) which is nice but makes stack printing more vulnerable for two reasons: >> - we may crash due to a programmer error (e.g. https://bugs.openjdk.org/browse/JDK-8293344) >> - we may timeout on very slow machines/file systems when the source information are parsed from the debug info (we have seen those problems in the past) >> >> Therefore, VMError should retry stack printing without source information if the first attempt to print failed. >> >> Examples: >> >> Step timeouts while retrieving source info: >> >> >> 24 --------------- T H R E A D --------------- >> 25 >> 26 Current thread (0x00007f70ac028bd0): JavaThread "main" [_thread_in_vm, id=565259, stack(0x00007f70b0587000,0x00007f70b0688000)] >> 27 >> 28 Stack: [0x00007f70b0587000,0x00007f70b0688000], sp=0x00007f70b0686cf0, free space=1023k >> 29 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> 30 V [libjvm.so+0x1cd41c1] VMError::controlled_crash(int)+0x241 >> 31 [timeout occurred during error reporting in step "printing native stack (with source info)"] after 30 s. >> 32 >> 33 Retrying call stack printing without source information... >> 34 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> 35 V [libjvm.so+0x1cd41c1] VMError::controlled_crash(int)+0x241 >> 36 V [libjvm.so+0x11cbe45] JNI_CreateJavaVM+0x5b5 >> 37 C [libjli.so+0x4013] JavaMain+0x93 >> 38 C [libjli.so+0x800d] ThreadJavaMain+0xd >> 39 >> >> >> >> Step crashes while retrieving source info: >> >> >> 24 --------------- T H R E A D --------------- >> 25 >> 26 Current thread (0x00007fc000028bd0): JavaThread "main" [_thread_in_vm, id=569254, stack(0x00007fc00573c000,0x00007fc00583d000)] >> 27 >> 28 Stack: [0x00007fc00573c000,0x00007fc00583d000], sp=0x00007fc00583bcf0, free space=1023k >> 29 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> 30 V [libjvm.so+0x1cd41e1] VMError::controlled_crash(int)+0x241 >> 31 [error occurred during error reporting (printing native stack (with source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fc006694d78] >> 32 >> 33 >> 34 Retrying call stack printing without source information... >> 35 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> 36 V [libjvm.so+0x1cd41e1] VMError::controlled_crash(int)+0x241 >> 37 V [libjvm.so+0x11cbe65] JNI_CreateJavaVM+0x5b5 >> 38 C [libjli.so+0x4013] JavaMain+0x93 >> 39 C [libjli.so+0x800d] ThreadJavaMain+0xd >> >> >> >> Thanks, Thomas > > src/hotspot/share/utilities/vmError.cpp line 854: > >> 852: } >> 853: >> 854: STEP("retry printing native stack (no source info)") > > Should we move STEP under if (print_native_stack_succeeded) ? Hi Dmitry, Thanks for the approval! > Should we move STEP under if (print_native_stack_succeeded) ? Wouldn't work, since STEP is defined as closing-bracket-condition-open-bracket, so it has to be at the first indentation level. ------------- PR: https://git.openjdk.org/jdk/pull/10179 From stuefe at openjdk.org Wed Sep 14 16:53:46 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 14 Sep 2022 16:53:46 GMT Subject: Integrated: JDK-8293402: hs-err file printer should reattempt stack trace printing if it fails In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 08:05:23 GMT, Thomas Stuefe wrote: > Hi, > > may I have reviews for this small improvement. > > The call stack may be the most important part of an hs-err file. We recently introduced printing of source information (https://bugs.openjdk.org/browse/JDK-8242181) which is nice but makes stack printing more vulnerable for two reasons: > - we may crash due to a programmer error (e.g. https://bugs.openjdk.org/browse/JDK-8293344) > - we may timeout on very slow machines/file systems when the source information are parsed from the debug info (we have seen those problems in the past) > > Therefore, VMError should retry stack printing without source information if the first attempt to print failed. > > Examples: > > Step timeouts while retrieving source info: > > > 24 --------------- T H R E A D --------------- > 25 > 26 Current thread (0x00007f70ac028bd0): JavaThread "main" [_thread_in_vm, id=565259, stack(0x00007f70b0587000,0x00007f70b0688000)] > 27 > 28 Stack: [0x00007f70b0587000,0x00007f70b0688000], sp=0x00007f70b0686cf0, free space=1023k > 29 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 30 V [libjvm.so+0x1cd41c1] VMError::controlled_crash(int)+0x241 > 31 [timeout occurred during error reporting in step "printing native stack (with source info)"] after 30 s. > 32 > 33 Retrying call stack printing without source information... > 34 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 35 V [libjvm.so+0x1cd41c1] VMError::controlled_crash(int)+0x241 > 36 V [libjvm.so+0x11cbe45] JNI_CreateJavaVM+0x5b5 > 37 C [libjli.so+0x4013] JavaMain+0x93 > 38 C [libjli.so+0x800d] ThreadJavaMain+0xd > 39 > > > > Step crashes while retrieving source info: > > > 24 --------------- T H R E A D --------------- > 25 > 26 Current thread (0x00007fc000028bd0): JavaThread "main" [_thread_in_vm, id=569254, stack(0x00007fc00573c000,0x00007fc00583d000)] > 27 > 28 Stack: [0x00007fc00573c000,0x00007fc00583d000], sp=0x00007fc00583bcf0, free space=1023k > 29 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 30 V [libjvm.so+0x1cd41e1] VMError::controlled_crash(int)+0x241 > 31 [error occurred during error reporting (printing native stack (with source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fc006694d78] > 32 > 33 > 34 Retrying call stack printing without source information... > 35 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 36 V [libjvm.so+0x1cd41e1] VMError::controlled_crash(int)+0x241 > 37 V [libjvm.so+0x11cbe65] JNI_CreateJavaVM+0x5b5 > 38 C [libjli.so+0x4013] JavaMain+0x93 > 39 C [libjli.so+0x800d] ThreadJavaMain+0xd > > > > Thanks, Thomas This pull request has now been integrated. Changeset: 95c7c556 Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/95c7c556a35378020177c8e64fd98416d5acc8e2 Stats: 21 lines in 3 files changed: 14 ins; 0 del; 7 mod 8293402: hs-err file printer should reattempt stack trace printing if it fails Reviewed-by: chagedorn, dsamersoff ------------- PR: https://git.openjdk.org/jdk/pull/10179 From vladimir.kozlov at oracle.com Wed Sep 14 17:54:17 2022 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Sep 2022 10:54:17 -0700 Subject: =?UTF-8?Q?CFV=3a_New_HotSpot_Group_Member=3a_Roberto_Casta=c3=b1eda?= =?UTF-8?Q?_Lozano?= Message-ID: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the HotSpot Group. Roberto is member of HotSpot compiler group at Oracle. Since 2020, he contributed a lot of changes to OpenJDK. He made very important updates and improvements to C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. Votes are due by Wednesday, September 28, 2022 at 10h50 PST. Only current Members of the HotSpot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Vladimir Kozlov [1] https://openjdk.org/census#rcastanedalo [2] https://openjdk.java.net/census#hotspot [3] https://openjdk.org/bylaws#member-vote From christian.hagedorn at oracle.com Wed Sep 14 18:00:17 2022 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Wed, 14 Sep 2022 20:00:17 +0200 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_HotSpot_Group_Member=3a_Roberto_Casta?= =?UTF-8?Q?=c3=b1eda_Lozano?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: <41e1b1bf-9176-a688-bb6a-a00045e7d17a@oracle.com> Vote: yes Best regards, Christian On 14.09.22 19:54, Vladimir Kozlov wrote: > I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the HotSpot Group. > > Roberto is member of HotSpot compiler group at Oracle. Since 2020, he contributed > a lot of changes to OpenJDK. He made very important updates and improvements to > C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 10h50 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] https://openjdk.org/census#rcastanedalo > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From vladimir.x.ivanov at oracle.com Wed Sep 14 18:05:39 2022 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 14 Sep 2022 11:05:39 -0700 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_HotSpot_Group_Member=3a_Roberto_Casta?= =?UTF-8?Q?=c3=b1eda_Lozano?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: <3ff514d9-7d04-b2c1-bf09-27d882422e6b@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 9/14/22 10:54, Vladimir Kozlov wrote: > I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the > HotSpot Group. From vladimir.kozlov at oracle.com Wed Sep 14 18:25:03 2022 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Sep 2022 11:25:03 -0700 Subject: CFV: New HotSpot Group Member: Tobias Holenstein Message-ID: I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot Group. Tobias is member of HotSpot compiler group at Oracle. Since 2021, he contributed 26 changes to HotSpot. Recently he is working on IR graph visualizer (IGV) improvements which helps C2 support a lot. Votes are due by Wednesday, September 28, 2022 at 11h25 PST. Only current Members of the HotSpot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Vladimir Kozlov PS: He is second Tobias in our group (Tobias Hartmann is first). [1] https://openjdk.org/census#tholenstein [2] https://openjdk.java.net/census#hotspot [3] https://openjdk.org/bylaws#member-vote From svkamath at openjdk.org Wed Sep 14 18:27:49 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Wed, 14 Sep 2022 18:27:49 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v6] In-Reply-To: References: <0im5_Of4jj3BHOipBt4VkAuX3327nQbKtW_sYnzcVUU=.0153ab0a-aa0c-4c12-a150-407a85cf8d0c@github.com> Message-ID: On Thu, 1 Sep 2022 21:17:30 GMT, Vladimir Kozlov wrote: >> Yes; I removed support for --release 7 in JDK 20 early today. >> >> >> On Thu, Sep 1, 2022 at 1:36 PM Paul Sandoz ***@***.***> wrote: >> >>> Likely requires a merge with master. >>> >>> ? >>> Reply to this email directly, view it on GitHub >>> , or >>> unsubscribe >>> >>> . >>> You are receiving this because you were mentioned.Message ID: >>> ***@***.***> >>> > >> Yes; I removed support for --release 7 in JDK 20 early today. > > Yes, I missed that my merge of master did not apply because I modified tests, Joe fixed, to test his changes. > > Resubmitting testing after resolving the issue. Still missed parentheses issue should be fixed. @vnkozlov Hi Vladimir, does the patch look good to you? Please do let me know. Thank you. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From vladimir.x.ivanov at oracle.com Wed Sep 14 18:31:13 2022 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 14 Sep 2022 11:31:13 -0700 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: Vote: yes Best regards, Vladimir Ivanov On 9/14/22 11:25, Vladimir Kozlov wrote: > I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot Group. From pchilanomate at openjdk.org Wed Sep 14 18:55:40 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 14 Sep 2022 18:55:40 GMT Subject: RFR: 8288474: Move EventContinuationFreezeOld from try_freeze_fast to freeze_slow In-Reply-To: <3lXMF0TmKkRJn2-XsO_tEk7MPmlA14n1R8fMFIaaQBY=.a481d3bd-d694-4276-9682-7ce467f8ca7b@github.com> References: <3lXMF0TmKkRJn2-XsO_tEk7MPmlA14n1R8fMFIaaQBY=.a481d3bd-d694-4276-9682-7ce467f8ca7b@github.com> Message-ID: <0zsQlvqVuVS8dKgJ_rOwvncs8sOpcdOkljnbKrK0JP4=.110e51e5-bb5f-46e0-8ca8-cc7fe5fb88de@github.com> On Tue, 13 Sep 2022 20:22:58 GMT, Coleen Phillimore wrote: > This moves the event ContinuationFreezeOld to freeze_slow so it's reported on the different paths to freeze_slow, and renames the events Continuation*Old/Continuation*Slow and Continuation*Young/Continuation*Fast to reflect that they're on the fast/slow paths. I turned on CONT_JFR and fixed some bugs and turned it back off again. Some output: > > $ jfr summary hotspot-pid-31671-id-1-2022_09_13_19_42_01.jfr | grep Continuation > jdk.ContinuationThaw 12193 211929 > jdk.ContinuationThawFast 10139 165420 > jdk.ContinuationFreeze 3196 57135 > jdk.ContinuationFreezeFast 2788 46397 > jdk.ContinuationThawSlow 2054 28543 > jdk.ContinuationFreezeSlow 408 5688 > > Tested locally and with tier7 which seems to run JFR tests. Looks good to me! ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.org/jdk/pull/10254 From vladimir.kozlov at oracle.com Wed Sep 14 19:06:50 2022 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Sep 2022 12:06:50 -0700 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_HotSpot_Group_Member=3a_Roberto_Casta?= =?UTF-8?Q?=c3=b1eda_Lozano?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: <85f6a881-17df-90dc-b347-527c64d42e74@oracle.com> Vote: yes Thanks, Vladimir K On 9/14/22 10:54 AM, Vladimir Kozlov wrote: > I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the HotSpot Group. > > Roberto is member of HotSpot compiler group at Oracle. Since 2020, he contributed > a lot of changes to OpenJDK. He made very important updates and improvements to > C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 10h50 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] https://openjdk.org/census#rcastanedalo > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From vladimir.kozlov at oracle.com Wed Sep 14 19:07:40 2022 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Sep 2022 12:07:40 -0700 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: Vote: yes Thanks, Vladimir K On 9/14/22 11:25 AM, Vladimir Kozlov wrote: > I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot Group. > > Tobias is member of HotSpot compiler group at Oracle. Since 2021, he contributed > 26 changes to HotSpot. Recently he is working on IR graph visualizer (IGV) > improvements which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 11h25 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > PS: He is second Tobias in our group (Tobias Hartmann is first). > > [1] https://openjdk.org/census#tholenstein > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From jesper.wilhelmsson at oracle.com Wed Sep 14 19:10:16 2022 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 14 Sep 2022 19:10:16 +0000 Subject: =?utf-8?B?UmU6IENGVjogTmV3IEhvdFNwb3QgR3JvdXAgTWVtYmVyOiBSb2JlcnRvIENh?= =?utf-8?B?c3Rhw7FlZGEgTG96YW5v?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: <818FC399-FAAD-4294-8556-7C8CB22346AE@oracle.com> Vote: Yes /Jesper > On 14 Sep 2022, at 19:54, Vladimir Kozlov wrote: > > I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the HotSpot Group. > > Roberto is member of HotSpot compiler group at Oracle. Since 2020, he contributed > a lot of changes to OpenJDK. He made very important updates and improvements to > C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 10h50 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] https://openjdk.org/census#rcastanedalo > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From jesper.wilhelmsson at oracle.com Wed Sep 14 19:10:45 2022 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 14 Sep 2022 19:10:45 +0000 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: <7CFCC934-EB75-49ED-88C1-3969FE561D4E@oracle.com> Vote: Yes /Jesper > On 14 Sep 2022, at 20:25, Vladimir Kozlov wrote: > > I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot Group. > > Tobias is member of HotSpot compiler group at Oracle. Since 2021, he contributed > 26 changes to HotSpot. Recently he is working on IR graph visualizer (IGV) > improvements which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 11h25 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > PS: He is second Tobias in our group (Tobias Hartmann is first). > > [1] https://openjdk.org/census#tholenstein > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From mikael.vidstedt at oracle.com Wed Sep 14 19:57:08 2022 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 14 Sep 2022 19:57:08 +0000 Subject: =?utf-8?B?UmU6IENGVjogTmV3IEhvdFNwb3QgR3JvdXAgTWVtYmVyOiBSb2JlcnRvIENh?= =?utf-8?B?c3Rhw7FlZGEgTG96YW5v?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: Vote: yes Cheers, Mikael > On Sep 14, 2022, at 10:54 AM, Vladimir Kozlov wrote: > > I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the HotSpot Group. > > Roberto is member of HotSpot compiler group at Oracle. Since 2020, he contributed > a lot of changes to OpenJDK. He made very important updates and improvements to > C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 10h50 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] https://openjdk.org/census#rcastanedalo > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From mikael.vidstedt at oracle.com Wed Sep 14 19:57:25 2022 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 14 Sep 2022 19:57:25 +0000 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: Vote: yes Cheers, Mikael > On Sep 14, 2022, at 11:25 AM, Vladimir Kozlov wrote: > > I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot Group. > > Tobias is member of HotSpot compiler group at Oracle. Since 2021, he contributed > 26 changes to HotSpot. Recently he is working on IR graph visualizer (IGV) > improvements which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 11h25 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > PS: He is second Tobias in our group (Tobias Hartmann is first). > > [1] https://openjdk.org/census#tholenstein > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From serguei.spitsyn at oracle.com Wed Sep 14 20:01:34 2022 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Wed, 14 Sep 2022 20:01:34 +0000 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: Vote: yes -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Sep 14 20:02:43 2022 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Wed, 14 Sep 2022 20:02:43 +0000 Subject: =?iso-8859-1?Q?Re:_CFV:_New_HotSpot_Group_Member:_Roberto_Casta=F1eda_Loz?= =?iso-8859-1?Q?ano?= In-Reply-To: <3ff514d9-7d04-b2c1-bf09-27d882422e6b@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> <3ff514d9-7d04-b2c1-bf09-27d882422e6b@oracle.com> Message-ID: Vote: yes On 9/14/22 10:54, Vladimir Kozlov wrote: > I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the > HotSpot Group. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Wed Sep 14 20:07:20 2022 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 14 Sep 2022 16:07:20 -0400 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_HotSpot_Group_Member=3a_Roberto_Casta?= =?UTF-8?Q?=c3=b1eda_Lozano?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: <59a1de12-a95e-2d06-f5eb-778afe12ac66@oracle.com> Vote: yes On 9/14/22 1:54 PM, Vladimir Kozlov wrote: > I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the > HotSpot Group. > > Roberto is member of HotSpot compiler group at Oracle. Since 2020, he > contributed > a lot of changes to OpenJDK. He made very important updates and > improvements to > C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 10h50 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] https://openjdk.org/census#rcastanedalo > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From coleen.phillimore at oracle.com Wed Sep 14 20:07:32 2022 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 14 Sep 2022 16:07:32 -0400 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: Vote: yes On 9/14/22 2:25 PM, Vladimir Kozlov wrote: > I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot > Group. > > Tobias is member of HotSpot compiler group at Oracle. Since 2021, he > contributed > 26 changes to HotSpot. Recently he is working on IR graph visualizer > (IGV) > improvements which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 11h25 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > PS: He is second Tobias in our group (Tobias Hartmann is first). > > [1] https://openjdk.org/census#tholenstein > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From adinn at redhat.com Wed Sep 14 20:20:12 2022 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 14 Sep 2022 21:20:12 +0100 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_HotSpot_Group_Member=3a_Roberto_Casta?= =?UTF-8?Q?=c3=b1eda_Lozano?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: <805ef095-2351-2a4f-5480-5876ccd5aac4@redhat.com> Vote: yes On 14/09/2022 18:54, Vladimir Kozlov wrote: > I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the > HotSpot Group. > > Roberto is member of HotSpot compiler group at Oracle. Since 2020, he > contributed > a lot of changes to OpenJDK. He made very important updates and > improvements to > C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 10h50 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] https://openjdk.org/census#rcastanedalo > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From adinn at redhat.com Wed Sep 14 20:25:15 2022 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 14 Sep 2022 21:25:15 +0100 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_HotSpot_Group_Member=3a_Roberto_Casta?= =?UTF-8?Q?=c3=b1eda_Lozano?= In-Reply-To: <805ef095-2351-2a4f-5480-5876ccd5aac4@redhat.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> <805ef095-2351-2a4f-5480-5876ccd5aac4@redhat.com> Message-ID: On 14/09/2022 21:20, Andrew Dinn wrote: > Vote: yes Apologies, I misread this post. I am not a member of the Hotspot group so please disregard this invalid vote. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From dean.long at oracle.com Wed Sep 14 20:28:37 2022 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 14 Sep 2022 13:28:37 -0700 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_HotSpot_Group_Member=3a_Roberto_Casta?= =?UTF-8?Q?=c3=b1eda_Lozano?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: Vote: yes On 9/14/22 10:54 AM, Vladimir Kozlov wrote: > I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the > HotSpot Group. > > Roberto is member of HotSpot compiler group at Oracle. Since 2020, he > contributed > a lot of changes to OpenJDK. He made very important updates and > improvements to > C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 10h50 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] https://openjdk.org/census#rcastanedalo > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From dean.long at oracle.com Wed Sep 14 20:29:03 2022 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 14 Sep 2022 13:29:03 -0700 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: Vote: yes On 9/14/22 11:25 AM, Vladimir Kozlov wrote: > I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot Group. > > Tobias is member of HotSpot compiler group at Oracle. Since 2021, he > contributed > 26 changes to HotSpot. Recently he is working on IR graph visualizer (IGV) > improvements which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 11h25 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > PS: He is second Tobias in our group (Tobias Hartmann is first). > > [1] https://openjdk.org/census#tholenstein > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From fyang at openjdk.org Wed Sep 14 23:51:43 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 14 Sep 2022 23:51:43 GMT Subject: RFR: 8293769: RISC-V: Add a second temporary register for BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 03:40:30 GMT, Feilong Jiang wrote: >> This is similar to https://bugs.openjdk.org/browse/JDK-8293351 >> Add a second temporary register for BarrierSetAssembler::load_at GC API on riscv64. >> Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. >> >> Testing: Tier1-3 tested on Linux-riscv64 SiFive Unmatched board. > > Looks good to me. Thanks for the cleanup. @feilongjiang @shipilev : Thanks for reviewing this. Integrate then. ------------- PR: https://git.openjdk.org/jdk/pull/10261 From fyang at openjdk.org Wed Sep 14 23:53:07 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 14 Sep 2022 23:53:07 GMT Subject: Integrated: 8293769: RISC-V: Add a second temporary register for BarrierSetAssembler::load_at In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 03:09:16 GMT, Fei Yang wrote: > This is similar to https://bugs.openjdk.org/browse/JDK-8293351 > Add a second temporary register for BarrierSetAssembler::load_at GC API on riscv64. > Today G1 and Shenandoah uses a second temporary register. This will also be the case for generational ZGC. > > Testing: Tier1-3 tested on Linux-riscv64 SiFive Unmatched board. This pull request has now been integrated. Changeset: 7376c552 Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/7376c55219ce2107afb9197e2452e7122d86ef52 Stats: 327 lines in 13 files changed: 9 ins; 108 del; 210 mod 8293769: RISC-V: Add a second temporary register for BarrierSetAssembler::load_at Reviewed-by: fjiang, shade ------------- PR: https://git.openjdk.org/jdk/pull/10261 From kim.barrett at oracle.com Thu Sep 15 00:16:31 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 15 Sep 2022 00:16:31 +0000 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: <416c7338-2dff-7997-c95f-c9e1c74de180@littlepinkcloud.com> References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> <416c7338-2dff-7997-c95f-c9e1c74de180@littlepinkcloud.com> Message-ID: <0958C022-824B-4492-9D82-393F64965D5E@oracle.com> > On Sep 14, 2022, at 5:30 AM, Andrew Haley wrote: > > On 9/14/22 10:25, Andrew Dinn wrote: >> I am swayed by Kim's arguments that we should clean this up now. This is >> technical debt and the changes Kim wants to make imply an interest rate >> hike (extra development and maintenance). > > OK, thanks. It seems to me to be more balanced: the current version has > (slightly) better performance and is more configurable, but I take your > point about maintenance. OK, I'll file a JBS issue and put together a PR to make this switch. I *think* it can be done as a sequence of commits to revert prior commits, followed by a couple of newly developed commits to reinstate features like support for relaxed atomics. From fyang at openjdk.org Thu Sep 15 01:32:51 2022 From: fyang at openjdk.org (Fei Yang) Date: Thu, 15 Sep 2022 01:32:51 GMT Subject: RFR: 8293770: RISC-V: Reuse runtime call trampolines In-Reply-To: References: Message-ID: <112MEiewAEhd3JIMeHF5hK57gVulS9OupUQcqgk6Kuk=.f97439cf-3eef-41cf-9683-5d11bda611fc@github.com> On Wed, 14 Sep 2022 02:58:42 GMT, Dingli Zhang wrote: > Follow up [JDK-8280152](https://bugs.openjdk.org/browse/JDK-8280152), this case also exists in riscv. > > Benchmark als, chi-square, dec-tree, log-regression, naive-bayes, page-rank, fj-kmeans, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~2.1% reduction on average. > > ## Testing: > > - hotspot and jdk tier1 on unmatched board without new failures > - hotspot/jtreg/compiler/sharedstubs/SharedTrampolineTest.java with fastdebug on qemu > > > ## Results > #### Results from [Renaissance 0.14.1](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.1) > > - riscv64 > > +--------------------------------------------------------------------------------------------------------+ > | | Before | After | > | Benchmark |---------------------------------------------------------------------------------------| > | | non-profiled nmethods | profiled nmethods | non-profiled nmethods | profiled nmethods | > +----------------+-----------------------+-------------------+-----------------------+-------------------| > | als | 15628 | 39421 | 12341 | 26681 | > | chi-square | 6349 | 20268 | 6033 | 20252 | > | dec-tree | 11058 | 42443 | 10774 | 43880 | > | log-regression | 10939 | 38237 | 12071 | 44199 | > | naive-bayes | 9023 | 29563 | 9294 | 30948 | > | page-rank | 6054 | 17041 | 5812 | 17353 | > | fj-kmeans | 692 | 2893 | 651 | 3354 | > | reactors | 2126 | 4073 | 1876 | 4106 | > | future-genetic | 1306 | 4118 | 1226 | 4142 | > | mnemonics | 726 | 2659 | 706 | 2684 | > | dotty | 26059 | 24417 | 24585 | 25379 | > | scala-kmeans | 564 | 3122 | 543 | 3132 | > | finagle-http | 6188 | 12455 | 6102 | 12295 | > | sum | 96712 | 240710 | 92014 | 238405 | > +--------------------------------------------------------------------------------------------------------+ I have two comments here. src/hotspot/cpu/riscv/codeBuffer_riscv.cpp line 34: > 32: constexpr unsigned init_size = 8; > 33: constexpr unsigned max_size = 256; > 34: _shared_trampoline_requests = new SharedTrampolineRequests(init_size, max_size); I have the same concern here as [1]. Did you looked into it? [1] https://github.com/openjdk/jdk/pull/9405#pullrequestreview-1076140575 src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2819: > 2817: entry.rspec().type() == relocInfo::virtual_call_type, "wrong reloc type"); > 2818: > 2819: address target = entry.target(); We call far_branches() and entry.target() more than once here in this function, which could be simplified. I think we can set target according to result of far_branches() and plant a single jal(target) instead. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10260 From dzhang at openjdk.org Thu Sep 15 02:36:54 2022 From: dzhang at openjdk.org (Dingli Zhang) Date: Thu, 15 Sep 2022 02:36:54 GMT Subject: RFR: 8293770: RISC-V: Reuse runtime call trampolines In-Reply-To: <112MEiewAEhd3JIMeHF5hK57gVulS9OupUQcqgk6Kuk=.f97439cf-3eef-41cf-9683-5d11bda611fc@github.com> References: <112MEiewAEhd3JIMeHF5hK57gVulS9OupUQcqgk6Kuk=.f97439cf-3eef-41cf-9683-5d11bda611fc@github.com> Message-ID: On Thu, 15 Sep 2022 01:20:48 GMT, Fei Yang wrote: >> Follow up [JDK-8280152](https://bugs.openjdk.org/browse/JDK-8280152), this case also exists in riscv. >> >> Benchmark als, chi-square, dec-tree, log-regression, naive-bayes, page-rank, fj-kmeans, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~2.1% reduction on average. >> >> ## Testing: >> >> - hotspot and jdk tier1 on unmatched board without new failures >> - hotspot/jtreg/compiler/sharedstubs/SharedTrampolineTest.java with fastdebug on qemu >> >> >> ## Results >> #### Results from [Renaissance 0.14.1](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.1) >> >> - riscv64 >> >> +--------------------------------------------------------------------------------------------------------+ >> | | Before | After | >> | Benchmark |---------------------------------------------------------------------------------------| >> | | non-profiled nmethods | profiled nmethods | non-profiled nmethods | profiled nmethods | >> +----------------+-----------------------+-------------------+-----------------------+-------------------| >> | als | 15628 | 39421 | 12341 | 26681 | >> | chi-square | 6349 | 20268 | 6033 | 20252 | >> | dec-tree | 11058 | 42443 | 10774 | 43880 | >> | log-regression | 10939 | 38237 | 12071 | 44199 | >> | naive-bayes | 9023 | 29563 | 9294 | 30948 | >> | page-rank | 6054 | 17041 | 5812 | 17353 | >> | fj-kmeans | 692 | 2893 | 651 | 3354 | >> | reactors | 2126 | 4073 | 1876 | 4106 | >> | future-genetic | 1306 | 4118 | 1226 | 4142 | >> | mnemonics | 726 | 2659 | 706 | 2684 | >> | dotty | 26059 | 24417 | 24585 | 25379 | >> | scala-kmeans | 564 | 3122 | 543 | 3132 | >> | finagle-http | 6188 | 12455 | 6102 | 12295 | >> | sum | 96712 | 240710 | 92014 | 238405 | >> +--------------------------------------------------------------------------------------------------------+ > > src/hotspot/cpu/riscv/codeBuffer_riscv.cpp line 34: > >> 32: constexpr unsigned init_size = 8; >> 33: constexpr unsigned max_size = 256; >> 34: _shared_trampoline_requests = new SharedTrampolineRequests(init_size, max_size); > > I have the same concern here as [1]. Did you looked into it? > > [1] https://github.com/openjdk/jdk/pull/9405#pullrequestreview-1076140575 When I run the benchmark in Renaissance (0.14.1), the default number of compiler threads is 15 (related to the number of CPUs) and I have not found this problem so far. ------------- PR: https://git.openjdk.org/jdk/pull/10260 From dzhang at openjdk.org Thu Sep 15 02:42:53 2022 From: dzhang at openjdk.org (Dingli Zhang) Date: Thu, 15 Sep 2022 02:42:53 GMT Subject: RFR: 8293770: RISC-V: Reuse runtime call trampolines [v2] In-Reply-To: References: Message-ID: > Follow up [JDK-8280152](https://bugs.openjdk.org/browse/JDK-8280152), this case also exists in riscv. > > Benchmark als, chi-square, dec-tree, log-regression, naive-bayes, page-rank, fj-kmeans, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~2.1% reduction on average. > > ## Testing: > > - hotspot and jdk tier1 on unmatched board without new failures > - hotspot/jtreg/compiler/sharedstubs/SharedTrampolineTest.java with fastdebug on qemu > > > ## Results > #### Results from [Renaissance 0.14.1](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.1) > > - riscv64 > > +--------------------------------------------------------------------------------------------------------+ > | | Before | After | > | Benchmark |---------------------------------------------------------------------------------------| > | | non-profiled nmethods | profiled nmethods | non-profiled nmethods | profiled nmethods | > +----------------+-----------------------+-------------------+-----------------------+-------------------| > | als | 15628 | 39421 | 12341 | 26681 | > | chi-square | 6349 | 20268 | 6033 | 20252 | > | dec-tree | 11058 | 42443 | 10774 | 43880 | > | log-regression | 10939 | 38237 | 12071 | 44199 | > | naive-bayes | 9023 | 29563 | 9294 | 30948 | > | page-rank | 6054 | 17041 | 5812 | 17353 | > | fj-kmeans | 692 | 2893 | 651 | 3354 | > | reactors | 2126 | 4073 | 1876 | 4106 | > | future-genetic | 1306 | 4118 | 1226 | 4142 | > | mnemonics | 726 | 2659 | 706 | 2684 | > | dotty | 26059 | 24417 | 24585 | 25379 | > | scala-kmeans | 564 | 3122 | 543 | 3132 | > | finagle-http | 6188 | 12455 | 6102 | 12295 | > | sum | 96712 | 240710 | 92014 | 238405 | > +--------------------------------------------------------------------------------------------------------+ Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: Simplify targe related jal call in macroAssembler_riscv.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10260/files - new: https://git.openjdk.org/jdk/pull/10260/files/e324610a..0f46ec3f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10260&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10260&range=00-01 Stats: 6 lines in 1 file changed: 1 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10260/head:pull/10260 PR: https://git.openjdk.org/jdk/pull/10260 From dzhang at openjdk.org Thu Sep 15 02:48:52 2022 From: dzhang at openjdk.org (Dingli Zhang) Date: Thu, 15 Sep 2022 02:48:52 GMT Subject: RFR: 8293770: RISC-V: Reuse runtime call trampolines [v2] In-Reply-To: <112MEiewAEhd3JIMeHF5hK57gVulS9OupUQcqgk6Kuk=.f97439cf-3eef-41cf-9683-5d11bda611fc@github.com> References: <112MEiewAEhd3JIMeHF5hK57gVulS9OupUQcqgk6Kuk=.f97439cf-3eef-41cf-9683-5d11bda611fc@github.com> Message-ID: On Thu, 15 Sep 2022 01:27:12 GMT, Fei Yang wrote: > We call far_branches() and entry.target() more than once here in this function, which could be simplified. I think we can set target according to result of far_branches() and plant a single jal(target) instead. Done. Thanks for reviewing! ------------- PR: https://git.openjdk.org/jdk/pull/10260 From ioi.lam at oracle.com Thu Sep 15 05:19:13 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 14 Sep 2022 22:19:13 -0700 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: References: Message-ID: <9da7f9fd-62c3-5bab-c671-596b09f91bbb@oracle.com> Hi Jonathan, Thanks for starting this discussion. This is a topic that I am interested in as well. I think the general question is: "How do I use as much memory as possible for the JVM without getting OOM-killed". Traditionally, the JVM automatically picks an Xmx that's about 1/4 of the total physical RAM on the host. This is OK for for plain old servers or desktop environments that runs lots of processes. However, in containers which typically have a very small number of processes, such a default is too conservative. However, if you set the -Xmx too high, the total amount of memory used by the JVM can be unpredictable, because there are allocations inside and outside of the Java heap. Also, in your case, you have other processes running inside the same container that the JVM has no direct control upon. It makes sense for the JVM to dynamically adjust its size, but we should think about different scenarios to see what our goals should be - In the simplest case, you have a single JVM process running inside the container. How do you balance its Java heap vs non-Java heap usage? - If you have two JVM processes running inside the container, how do they coordinate? - If the fluctuation is caused by other processes, can the JVM react quickly (run GC and free up caches) to respond to quick spikes? Do we need to configure the container to allow temporarily over-budget (something like "you can be 100MB over budget for less than 20ms") so the JVM has time to shrink itself? - Conversely, how can a spiky process request the JVM to temporarily give up some memory? It seems to me that for the more complex scenarios, it's not enough for each individual JVM to make decisions on its own. We may need some sort of intra-process coordination. Thanks - Ioi On 9/13/2022 12:52 PM, Jonathan Joo wrote: > > Hello hotspot-dev and hotspot-gc-dev, > > > My name is Jonathan, and I'm working on the Java Platform Team at > Google. Here, we are working on a project to address Java container > memory issues, as we noticed that a significant number of Java servers > hit container OOM issues due to people incorrectly tuning their heap > size with respect to the container size. Because our containers have > other RAM consumers which fluctuate over time, it is often difficult > to determine a priori what is an appropriate Xmx to set for a > particular server. > > > We set about trying to solve this by dynamically adjusting the Java > heap/gc behavior based on the container usage information that we pass > into the JVM. We have seen promising results so far, reducing > container OOMs by a significant amount, and oftentimes also reducing > average heap usage (with the tradeoff of more CPU time spent doing GC). > > > Below (under the dotted line) is a more detailed explanation of our > initial approach. Does this sound like something that may be useful > for the general OpenJDK community? If so, would some of you be open to > further discussion? I would also like to better understand what > container environments look like outside of Google, to see how we > could modify our approach for the more general case. > > > Thank you! > > Jonathan > > > ------------------------------------------------------------------------ > > > Introduction: > > Adaptable Heap Sizing (AHS) is a project internal to Google that is > meant to simplify configuration and improve the stability of > applications in container environments. The key is that in a > containerized environment, we have access to container usage and limit > information. This can be used as a signal to modify Java heap > behavior, helping prevent container OOMs. > > > Problem: > > * > > Containers at Google must be properly sized to not only the JVM > heap, but other memory consumers as well. These consumers include > non-heap Java (e.g. native code allocations), and simultaneously > running non-Java processes. > > * > > Common antipattern we see here at Google: > > o > > We have an application running into container OOMs. > > o > > An engineer raises both container memory limit and Xmx by the > same amount, since there appears to be insufficient memory. > > o > > The application has reduced container OOMs, but is still prone > to them, since G1 continues to use most of Xmx. > > * > > This results in many jobs being configured with much more RAM than > they need, but still running into container OOM issues. > > > Hypothesis: > > * > > For preventing container OOM: Why can't heap expansions be bounded > by the remaining free space in the container? > > * > > For preventing the `unnecessarily high Xmx` antipattern: Why can't > target heap size be set based on GC CPU overhead? > > * > > From our work on Adaptable Heap Sizing, it appears they can! > > > Design: > > * > > We add two manageable flags in the JVM > > o > > Current maximum heap expansion size > > o > > Current target heap size > > * > > A separate thread runs alongside the JVM, querying: > > o > > Container memory usage/limits > > o > > GC CPU overhead metrics from the JVM. > > * > > This thread then uses this information to calculate new values for > the two new JVM flags, and continually updates them at runtime. > > * > > The `Current maximum heap expansion size` informs the JVM what is > the maximum amount we can expand the heap by, while staying within > container limits. This is a hard limit, and trying to expand more > than this amount results in behavior equivalent to hitting the Xmx > limit. > > * > > The `Current target heap size` is a soft target value, which is > used to resize the heap (when possible) so as to bring GC CPU > overhead toward its target value. > > > Results: > > * > > At Google, we have found that this design works incredibly well in > our initial rollout, even for large and complex workloads. > > * > > After deploying this to dozens of applications: > > o > > Significant memory savings for previously misconfigured jobs > (many of which reduced their heap usage by 50% or more) > > o > > Significantly reduced occurrences of container OOM (100% > reduction in vast majority of cases) > > o > > No correctness issues > > o > > No latency regressions* > > o > > We plan to deploy AHS across a much wider subset of > applications by EOY '22. > > > *Caveats: > > * > > > Enabling this feature might require tuning of the newly > introduced default GC CPU overhead target to avoid regressions. > > * > > Time spent doing GC for an application may increase significantly > (though generally we've seen in practice that even if this is the > case, end-to-end latency does not increase a noticeable amount) > > * > > Enabling AHS results in frequent heap resizings, but we have not > seen evidence of any negative effects as a result of these more > frequent heap resizings. > > * > > AHS is not necessarily a replacement for proper JVM tuning, but > should generally work better than an untuned or improperly tuned > configuration. > > * > > AHS is not intended for every possible workload, and there could > be pathological cases where AHS results in worse behavior. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.hagedorn at oracle.com Thu Sep 15 06:11:05 2022 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Thu, 15 Sep 2022 08:11:05 +0200 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: Vote: yes Best regards, Christian On 14.09.22 20:25, Vladimir Kozlov wrote: > I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot Group. > > Tobias is member of HotSpot compiler group at Oracle. Since 2021, he contributed > 26 changes to HotSpot. Recently he is working on IR graph visualizer (IGV) > improvements which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 11h25 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > PS: He is second Tobias in our group (Tobias Hartmann is first). > > [1] https://openjdk.org/census#tholenstein > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From fjiang at openjdk.org Thu Sep 15 06:24:19 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 15 Sep 2022 06:24:19 GMT Subject: RFR: 8293840: RISC-V: Remove cbuf parameter from far_call/far_jump/trampoline_call Message-ID: Follow up [JDK-8287394](https://bugs.openjdk.org/browse/JDK-8287394), remove cbuf parameter from far_call/far_jump/trampoline in riscv. Testing: - Tier1 passed on unmatched board with release build ------------- Commit messages: - Remove cbuf parameter from far_call/far_jump/trampoline_call Changes: https://git.openjdk.org/jdk/pull/10277/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10277&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293840 Stats: 19 lines in 4 files changed: 1 ins; 4 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/10277.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10277/head:pull/10277 PR: https://git.openjdk.org/jdk/pull/10277 From fjiang at openjdk.org Thu Sep 15 06:40:04 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 15 Sep 2022 06:40:04 GMT Subject: RFR: 8293770: RISC-V: Reuse runtime call trampolines [v2] In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 02:42:53 GMT, Dingli Zhang wrote: >> Follow up [JDK-8280152](https://bugs.openjdk.org/browse/JDK-8280152), this case also exists in riscv. >> >> Benchmark als, chi-square, dec-tree, log-regression, naive-bayes, page-rank, fj-kmeans, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~2.1% reduction on average. >> >> ## Testing: >> >> - hotspot and jdk tier1 on unmatched board without new failures >> - hotspot/jtreg/compiler/sharedstubs/SharedTrampolineTest.java with fastdebug on qemu >> >> >> ## Results >> #### Results from [Renaissance 0.14.1](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.1) >> >> - riscv64 >> >> +--------------------------------------------------------------------------------------------------------+ >> | | Before | After | >> | Benchmark |---------------------------------------------------------------------------------------| >> | | non-profiled nmethods | profiled nmethods | non-profiled nmethods | profiled nmethods | >> +----------------+-----------------------+-------------------+-----------------------+-------------------| >> | als | 15628 | 39421 | 12341 | 26681 | >> | chi-square | 6349 | 20268 | 6033 | 20252 | >> | dec-tree | 11058 | 42443 | 10774 | 43880 | >> | log-regression | 10939 | 38237 | 12071 | 44199 | >> | naive-bayes | 9023 | 29563 | 9294 | 30948 | >> | page-rank | 6054 | 17041 | 5812 | 17353 | >> | fj-kmeans | 692 | 2893 | 651 | 3354 | >> | reactors | 2126 | 4073 | 1876 | 4106 | >> | future-genetic | 1306 | 4118 | 1226 | 4142 | >> | mnemonics | 726 | 2659 | 706 | 2684 | >> | dotty | 26059 | 24417 | 24585 | 25379 | >> | scala-kmeans | 564 | 3122 | 543 | 3132 | >> | finagle-http | 6188 | 12455 | 6102 | 12295 | >> | sum | 96712 | 240710 | 92014 | 238405 | >> +--------------------------------------------------------------------------------------------------------+ > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Simplify targe related jal call in macroAssembler_riscv.cpp Copyright of codeBuffer_riscv.hpp should be update to 2022. ------------- PR: https://git.openjdk.org/jdk/pull/10260 From stefan.karlsson at oracle.com Thu Sep 15 06:43:10 2022 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 15 Sep 2022 08:43:10 +0200 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_HotSpot_Group_Member=3a_Roberto_Casta?= =?UTF-8?Q?=c3=b1eda_Lozano?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: <672e1ab8-e19e-1141-bfac-26e44a32429e@oracle.com> Vote: yes StefanK On 2022-09-14 19:54, Vladimir Kozlov wrote: > I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the > HotSpot Group. > > Roberto is member of HotSpot compiler group at Oracle. Since 2020, he > contributed > a lot of changes to OpenJDK. He made very important updates and > improvements to > C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 10h50 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] https://openjdk.org/census#rcastanedalo > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From fjiang at openjdk.org Thu Sep 15 07:17:47 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 15 Sep 2022 07:17:47 GMT Subject: RFR: 8287394: AArch64: Remove cbuf parameter from far_call/far_jump/trampoline_call In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 18:50:23 GMT, Evgeny Astigeevich wrote: > `far_call`/`far_jump`/`trampoline_call` have parameter `cbuf` with the default value `NULL`. We always call `far_call`/`far_jump` with `NULL`. We call `trampoline_call` with either `NULL` or the `CodeBuffer` currently used by `MacroAssembler`. If not `NULL` we mark a trampoline call position. > > Andrew Haley(@theRealAph) in https://github.com/openjdk/jdk/pull/8564#discussion_r871062342 suggests to remove it. > > This PR removes the parameter. In the case of `trampoline_call` we explicitly return the position of the generated trampoline calls. All places using the position of the generated trampoline call are updated. > > Tested with release and fastdebug builds: > - `gtest`: Passed. > - `tier1`/`tier2`: Passed. Hi @eastig, I'm doing the same cleanup on riscv port, and I noticed that you also removed `clear_inst_mark()` in `aarch64_enc_java_static_call` and `aarch64_enc_java_to_runtime`. Seem it was related to the removing of cbuf in `trampoline_call`, but there is still one `clear_inst_mark()` in `aarch64_enc_java_dynamic_call` [1]. So I dig into the `ic_call` and find out that it calls `trampoline_call` at last. If I was understanding correctly, it could be removed too, right? [1] https://github.com/openjdk/jdk/blob/eeb625e7095e65e64023cbfe05e579af90f4b638/src/hotspot/cpu/aarch64/aarch64.ad#L3661-L3674 ------------- PR: https://git.openjdk.org/jdk/pull/10244 From aph-open at littlepinkcloud.com Thu Sep 15 08:01:59 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Thu, 15 Sep 2022 09:01:59 +0100 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: <0958C022-824B-4492-9D82-393F64965D5E@oracle.com> References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> <416c7338-2dff-7997-c95f-c9e1c74de180@littlepinkcloud.com> <0958C022-824B-4492-9D82-393F64965D5E@oracle.com> Message-ID: <246e397f-2f10-84fa-19d7-65b1472606e9@littlepinkcloud.com> On 9/15/22 01:16, Kim Barrett wrote: > I*think* it can be done as a sequence of commits to revert prior commits, > followed by a couple of newly developed commits to reinstate features like > support for relaxed atomics. I expect so. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From tobias.hartmann at oracle.com Thu Sep 15 08:29:36 2022 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 15 Sep 2022 10:29:36 +0200 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: <4ebfac83-af44-a4c4-dd6f-e4cd9df87e72@oracle.com> Vote: yes Best regards, Tobias On 14.09.22 20:25, Vladimir Kozlov wrote: > I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot Group. > > Tobias is member of HotSpot compiler group at Oracle. Since 2021, he contributed > 26 changes to HotSpot. Recently he is working on IR graph visualizer (IGV) > improvements which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 11h25 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > PS: He is second Tobias in our group (Tobias Hartmann is first). > > [1] https://openjdk.org/census#tholenstein > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From tobias.hartmann at oracle.com Thu Sep 15 08:30:07 2022 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 15 Sep 2022 10:30:07 +0200 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_HotSpot_Group_Member=3a_Roberto_Casta?= =?UTF-8?Q?=c3=b1eda_Lozano?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: <5a401bd3-2887-f5cb-0039-11cb8cb6d91b@oracle.com> Vote: yes Best regards, Tobias On 14.09.22 19:54, Vladimir Kozlov wrote: > I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the HotSpot Group. > > Roberto is member of HotSpot compiler group at Oracle. Since 2020, he contributed > a lot of changes to OpenJDK. He made very important updates and improvements to > C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 10h50 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] https://openjdk.org/census#rcastanedalo > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From stefan.johansson at oracle.com Thu Sep 15 08:30:25 2022 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 15 Sep 2022 10:30:25 +0200 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_HotSpot_Group_Member=3a_Roberto_Casta?= =?UTF-8?Q?=c3=b1eda_Lozano?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: <6dbd7911-1c53-16a9-869b-bd2a797dbdc5@oracle.com> Vote: yes On 2022-09-14 19:54, Vladimir Kozlov wrote: > I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the > HotSpot Group. > > Roberto is member of HotSpot compiler group at Oracle. Since 2020, he > contributed > a lot of changes to OpenJDK. He made very important updates and > improvements to > C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 10h50 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] https://openjdk.org/census#rcastanedalo > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From markus.gronlund at oracle.com Thu Sep 15 09:32:27 2022 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 15 Sep 2022 09:32:27 +0000 Subject: =?utf-8?B?UkU6IENGVjogTmV3IEhvdFNwb3QgR3JvdXAgTWVtYmVyOiBSb2JlcnRvIENh?= =?utf-8?B?c3Rhw7FlZGEgTG96YW5v?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: Vote: yes -----Original Message----- From: hotspot-dev On Behalf Of Vladimir Kozlov Sent: den 14 september 2022 19:54 To: hotspot-dev Source Developers Subject: CFV: New HotSpot Group Member: Roberto Casta?eda Lozano I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the HotSpot Group. Roberto is member of HotSpot compiler group at Oracle. Since 2020, he contributed a lot of changes to OpenJDK. He made very important updates and improvements to C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. Votes are due by Wednesday, September 28, 2022 at 10h50 PST. Only current Members of the HotSpot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Vladimir Kozlov [1] https://openjdk.org/census#rcastanedalo [2] https://openjdk.java.net/census#hotspot [3] https://openjdk.org/bylaws#member-vote From markus.gronlund at oracle.com Thu Sep 15 09:33:17 2022 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 15 Sep 2022 09:33:17 +0000 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: Vote: yes -----Original Message----- From: hotspot-dev On Behalf Of Vladimir Kozlov Sent: den 14 september 2022 20:25 To: hotspot-dev Source Developers Subject: CFV: New HotSpot Group Member: Tobias Holenstein I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot Group. Tobias is member of HotSpot compiler group at Oracle. Since 2021, he contributed 26 changes to HotSpot. Recently he is working on IR graph visualizer (IGV) improvements which helps C2 support a lot. Votes are due by Wednesday, September 28, 2022 at 11h25 PST. Only current Members of the HotSpot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Vladimir Kozlov PS: He is second Tobias in our group (Tobias Hartmann is first). [1] https://openjdk.org/census#tholenstein [2] https://openjdk.java.net/census#hotspot [3] https://openjdk.org/bylaws#member-vote From leo.korinth at oracle.com Thu Sep 15 09:40:07 2022 From: leo.korinth at oracle.com (Leo Korinth) Date: Thu, 15 Sep 2022 11:40:07 +0200 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_HotSpot_Group_Member=3a_Roberto_Casta?= =?UTF-8?Q?=c3=b1eda_Lozano?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: <0b870b28-405b-1206-e5df-119ff297f794@oracle.com> Vote: yes /Leo On 14/09/2022 19:54, Vladimir Kozlov wrote: > I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the > HotSpot Group. > > Roberto is member of HotSpot compiler group at Oracle. Since 2020, he > contributed > a lot of changes to OpenJDK. He made very important updates and > improvements to > C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 10h50 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] https://openjdk.org/census#rcastanedalo > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From stefan.karlsson at oracle.com Thu Sep 15 09:52:02 2022 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 15 Sep 2022 11:52:02 +0200 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: <30f48eff-8735-6b3d-74fc-8166b11cd481@oracle.com> Vote: yes StefanK On 2022-09-14 20:25, Vladimir Kozlov wrote: > I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot > Group. > > Tobias is member of HotSpot compiler group at Oracle. Since 2021, he > contributed > 26 changes to HotSpot. Recently he is working on IR graph visualizer > (IGV) > improvements which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 11h25 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > PS: He is second Tobias in our group (Tobias Hartmann is first). > > [1] https://openjdk.org/census#tholenstein > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From tschatzl at openjdk.org Thu Sep 15 10:00:05 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 15 Sep 2022 10:00:05 GMT Subject: RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v7] In-Reply-To: References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Message-ID: On Wed, 14 Sep 2022 12:11:14 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? >> >> This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. >> >> Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > ayang review 5 Thanks for your reviews. Did a few tier1-4 runs that showed no issue. ------------- PR: https://git.openjdk.org/jdk/pull/9980 From tschatzl at openjdk.org Thu Sep 15 10:00:06 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 15 Sep 2022 10:00:06 GMT Subject: Integrated: 8256265: G1: Improve parallelism in regions that failed evacuation In-Reply-To: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> References: <50zVyvz9LvyBkvqHk8SiS0W-Ny3mosL5ZsDPoSJuf_k=.bd0a90a1-72f8-4d02-a67b-c20a7d8d7365@github.com> Message-ID: On Tue, 23 Aug 2022 13:29:31 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews on this change that makes the evacuation failure remove forwards phase split the work across threads within regions? > > This work is a continuation of PR#7047 from @Hamlin-Li and latest improvements from @albertnetymk in that thread. This is reflected in the first commit, I added a fair amount of changes to fix bugs and streamline the code. > > Testing: tier1-8 with G1EvacuationFailureALot enabled, tier1-5 as is This pull request has now been integrated. Changeset: 15cb1fb7 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/15cb1fb7885a2fb5d7e51796552bae5ce0708cf5 Stats: 482 lines in 22 files changed: 242 ins; 116 del; 124 mod 8256265: G1: Improve parallelism in regions that failed evacuation Co-authored-by: Hamlin Li Co-authored-by: Albert Mingkun Yang Reviewed-by: sjohanss, ayang ------------- PR: https://git.openjdk.org/jdk/pull/9980 From eastigeevich at openjdk.org Thu Sep 15 11:22:50 2022 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 15 Sep 2022 11:22:50 GMT Subject: RFR: 8287394: AArch64: Remove cbuf parameter from far_call/far_jump/trampoline_call In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 07:11:52 GMT, Feilong Jiang wrote: >> `far_call`/`far_jump`/`trampoline_call` have parameter `cbuf` with the default value `NULL`. We always call `far_call`/`far_jump` with `NULL`. We call `trampoline_call` with either `NULL` or the `CodeBuffer` currently used by `MacroAssembler`. If not `NULL` we mark a trampoline call position. >> >> Andrew Haley(@theRealAph) in https://github.com/openjdk/jdk/pull/8564#discussion_r871062342 suggests to remove it. >> >> This PR removes the parameter. In the case of `trampoline_call` we explicitly return the position of the generated trampoline calls. All places using the position of the generated trampoline call are updated. >> >> Tested with release and fastdebug builds: >> - `gtest`: Passed. >> - `tier1`/`tier2`: Passed. > > Hi @eastig, I'm doing the same cleanup on riscv port, and I noticed that you also removed `clear_inst_mark()` in `aarch64_enc_java_static_call` and `aarch64_enc_java_to_runtime`. > Seems it was related to the removing of cbuf in `trampoline_call`, but there is still one `clear_inst_mark()` in `aarch64_enc_java_dynamic_call` [1]. > So I dig into the `ic_call` and find out that it calls `trampoline_call` at last. If I was understanding correctly, it could be removed too, right? > > [1] https://github.com/openjdk/jdk/blob/eeb625e7095e65e64023cbfe05e579af90f4b638/src/hotspot/cpu/aarch64/aarch64.ad#L3661-L3674 Hi @feilongjiang, > So I dig into the ic_call and find out that it calls trampoline_call at last. If I was understanding correctly, it could be removed too, right? Yes, you are right. It should be deleted as well. Thank you for the finding. ------------- PR: https://git.openjdk.org/jdk/pull/10244 From eastigeevich at openjdk.org Thu Sep 15 11:43:47 2022 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Thu, 15 Sep 2022 11:43:47 GMT Subject: RFR: 8287394: AArch64: Remove cbuf parameter from far_call/far_jump/trampoline_call In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 18:50:23 GMT, Evgeny Astigeevich wrote: > `far_call`/`far_jump`/`trampoline_call` have parameter `cbuf` with the default value `NULL`. We always call `far_call`/`far_jump` with `NULL`. We call `trampoline_call` with either `NULL` or the `CodeBuffer` currently used by `MacroAssembler`. If not `NULL` we mark a trampoline call position. > > Andrew Haley(@theRealAph) in https://github.com/openjdk/jdk/pull/8564#discussion_r871062342 suggests to remove it. > > This PR removes the parameter. In the case of `trampoline_call` we explicitly return the position of the generated trampoline calls. All places using the position of the generated trampoline call are updated. > > Tested with release and fastdebug builds: > - `gtest`: Passed. > - `tier1`/`tier2`: Passed. I created https://bugs.openjdk.org/browse/JDK-8293856. ------------- PR: https://git.openjdk.org/jdk/pull/10244 From rehn at openjdk.org Thu Sep 15 11:49:43 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 15 Sep 2022 11:49:43 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable [v7] In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 13:32:46 GMT, Johan Sj?len wrote: >> Hi! >> >> Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. >> >> When I've left ResourceMarks in place I've also commented which calls requires them. >> >> This passes tier1, tier2 tests. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Rename to freeze Seems fine, thanks. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10142 From chagedorn at openjdk.org Thu Sep 15 12:05:56 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 15 Sep 2022 12:05:56 GMT Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed Message-ID: The DWARF debugging symbols emitted by Clang is different from what GCC is emitting. While GCC produces a complete `.debug_aranges` section (which is required in the DWARF parser), Clang does not. As a result, the DWARF parser cannot find the necessary information to proceed and create the line number information: The `.debug_aranges` section contains address range to compilation unit offset mappings. The parsing algorithm can just walk through all these entries to find the correct address range that contains the library offset of the current pc. This gives us the compilation unit offset into the `.debug_info` section from where we can proceed to parse the line number information. Without a complete `.debug_aranges` section, we fail with an assertion that we could not find the correct entry. Since [JDK-8293402](https://bugs.openjdk.org/browse/JDK-8293402), we will still get the complete stack trace at least. Nevertheless, we should still fix this assertion failure of course. But that would require a different parsing approach. We need to parse the entire `.debug_info` section instead to get to the correct compilation unit. This, however, would require a lot more work. I therefore suggest to disable DWARF parsing for Clang for now and file an RFE to support Clang in the future with a different parsing approach. I'm using the `__clang__` `ifdef` to bail out in `get_source_info()` and disable the `gtests`. I've noticed that we are currently running the `gtests` with `NOT PRODUCT` which I think is not necessary - the gtests should also work fine with product builds. I've corrected this as well but that could also be done separately. Thanks, Christian ------------- Commit messages: - 8293422: DWARF emitted by Clang cannot be parsed Changes: https://git.openjdk.org/jdk/pull/10287/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10287&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293422 Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10287.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10287/head:pull/10287 PR: https://git.openjdk.org/jdk/pull/10287 From coleenp at openjdk.org Thu Sep 15 12:11:42 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 15 Sep 2022 12:11:42 GMT Subject: RFR: 8288474: Move EventContinuationFreezeOld from try_freeze_fast to freeze_slow In-Reply-To: <3lXMF0TmKkRJn2-XsO_tEk7MPmlA14n1R8fMFIaaQBY=.a481d3bd-d694-4276-9682-7ce467f8ca7b@github.com> References: <3lXMF0TmKkRJn2-XsO_tEk7MPmlA14n1R8fMFIaaQBY=.a481d3bd-d694-4276-9682-7ce467f8ca7b@github.com> Message-ID: On Tue, 13 Sep 2022 20:22:58 GMT, Coleen Phillimore wrote: > This moves the event ContinuationFreezeOld to freeze_slow so it's reported on the different paths to freeze_slow, and renames the events Continuation*Old/Continuation*Slow and Continuation*Young/Continuation*Fast to reflect that they're on the fast/slow paths. I turned on CONT_JFR and fixed some bugs and turned it back off again. Some output: > > $ jfr summary hotspot-pid-31671-id-1-2022_09_13_19_42_01.jfr | grep Continuation > jdk.ContinuationThaw 12193 211929 > jdk.ContinuationThawFast 10139 165420 > jdk.ContinuationFreeze 3196 57135 > jdk.ContinuationFreezeFast 2788 46397 > jdk.ContinuationThawSlow 2054 28543 > jdk.ContinuationFreezeSlow 408 5688 > > Tested locally and with tier7 which seems to run JFR tests. Thanks Ron and Patricio! ------------- PR: https://git.openjdk.org/jdk/pull/10254 From coleenp at openjdk.org Thu Sep 15 12:14:21 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 15 Sep 2022 12:14:21 GMT Subject: Integrated: 8288474: Move EventContinuationFreezeOld from try_freeze_fast to freeze_slow In-Reply-To: <3lXMF0TmKkRJn2-XsO_tEk7MPmlA14n1R8fMFIaaQBY=.a481d3bd-d694-4276-9682-7ce467f8ca7b@github.com> References: <3lXMF0TmKkRJn2-XsO_tEk7MPmlA14n1R8fMFIaaQBY=.a481d3bd-d694-4276-9682-7ce467f8ca7b@github.com> Message-ID: <_LyJroK02aN7p57EQiGINQHurJvDpvnKCC08q2SPIZA=.a63064a6-2eb3-4089-bcdf-376b62d35cc6@github.com> On Tue, 13 Sep 2022 20:22:58 GMT, Coleen Phillimore wrote: > This moves the event ContinuationFreezeOld to freeze_slow so it's reported on the different paths to freeze_slow, and renames the events Continuation*Old/Continuation*Slow and Continuation*Young/Continuation*Fast to reflect that they're on the fast/slow paths. I turned on CONT_JFR and fixed some bugs and turned it back off again. Some output: > > $ jfr summary hotspot-pid-31671-id-1-2022_09_13_19_42_01.jfr | grep Continuation > jdk.ContinuationThaw 12193 211929 > jdk.ContinuationThawFast 10139 165420 > jdk.ContinuationFreeze 3196 57135 > jdk.ContinuationFreezeFast 2788 46397 > jdk.ContinuationThawSlow 2054 28543 > jdk.ContinuationFreezeSlow 408 5688 > > Tested locally and with tier7 which seems to run JFR tests. This pull request has now been integrated. Changeset: 6fca9ae0 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/6fca9ae04703103ff6832dbee9549c5512611c5e Stats: 42 lines in 4 files changed: 9 ins; 8 del; 25 mod 8288474: Move EventContinuationFreezeOld from try_freeze_fast to freeze_slow Reviewed-by: rpressler, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/10254 From volker.simonis at gmail.com Thu Sep 15 12:47:38 2022 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 15 Sep 2022 14:47:38 +0200 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: Vote: yes Vladimir Kozlov schrieb am Mi., 14. Sept. 2022, 20:25: > I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot Group. > > Tobias is member of HotSpot compiler group at Oracle. Since 2021, he > contributed > 26 changes to HotSpot. Recently he is working on IR graph visualizer (IGV) > improvements which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 11h25 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > PS: He is second Tobias in our group (Tobias Hartmann is first). > > [1] https://openjdk.org/census#tholenstein > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Thu Sep 15 14:55:30 2022 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 15 Sep 2022 14:55:30 +0000 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: Vote: yes Best regards, Martin Von: hotspot-dev im Auftrag von Vladimir Kozlov Datum: Mittwoch, 14. September 2022 um 20:25 An: hotspot-dev Source Developers Betreff: CFV: New HotSpot Group Member: Tobias Holenstein I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot Group. Tobias is member of HotSpot compiler group at Oracle. Since 2021, he contributed 26 changes to HotSpot. Recently he is working on IR graph visualizer (IGV) improvements which helps C2 support a lot. Votes are due by Wednesday, September 28, 2022 at 11h25 PST. Only current Members of the HotSpot Group [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Vladimir Kozlov PS: He is second Tobias in our group (Tobias Hartmann is first). [1] https://openjdk.org/census#tholenstein [2] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fcensus%23hotspot&data=05%7C01%7Cmartin.doerr%40sap.com%7C51d820ac01ac4a963b2408da967e8ca1%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C637987767516918059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ldo%2BsfHKD6xryku9w2DnDRnoqkxVi8%2B5YdTTe4l64So%3D&reserved=0 [3] https://openjdk.org/bylaws#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Thu Sep 15 15:23:54 2022 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 15 Sep 2022 15:23:54 +0000 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: Vote: yes igor > On Sep 14, 2022, at 11:25 AM, Vladimir Kozlov wrote: > > ?I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot Group. > > Tobias is member of HotSpot compiler group at Oracle. Since 2021, he contributed > 26 changes to HotSpot. Recently he is working on IR graph visualizer (IGV) > improvements which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 11h25 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > PS: He is second Tobias in our group (Tobias Hartmann is first). > > [1] https://openjdk.org/census#tholenstein > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From iris.clark at oracle.com Thu Sep 15 15:29:51 2022 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 15 Sep 2022 15:29:51 +0000 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: Vote: yes Iris -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathanjoo at google.com Thu Sep 15 20:51:55 2022 From: jonathanjoo at google.com (Jonathan Joo) Date: Thu, 15 Sep 2022 16:51:55 -0400 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: References: Message-ID: Hi Ashutosh, Thank you for the questions! How is the container memory limit being determined? Does that process take > into account non-Java processes running in the container as well? > In general, container memory limit at Google is determined through a trial-and-error process, where it takes into account all memory consumers. We generally start with lower limits, and as traffic increases, increase the limits. We also have some features that allow us to automatically come up with estimates for these values based on the workloads. It makes sense to raise the container memory limit, but what is the need to > raise the Xmx by the same amount? > It can be difficult to tell for someone not experienced in Java configuration to know whether the memory issues they are seeing are solved by providing more Java heap, or keeping the Java heap the same while increasing the container limit. The way we configure Java memory by default is by setting `Xmx = container_limit - non_heap_memory`, and thus if someone were to only raise the container limit and not also increase `non_heap_memory`, Xmx would also increase as well. So I would say that increasing Xmx is not always the intended action, but in general, demonstrates that it can be tricky to set everything in the right way. If so, then bounding the heap expansion would not cover all the cases. > Yes, that is true - a sudden increase in non-heap memory usage can still result in a container OOM. However in this scenario, AHS should decrease the proposed heap size (based on seeing that th container is getting full), and therefore run more GCs to try to keep the heap as low as possible to accommodate for this. But yes there are definitely pathological cases (for example, a sudden large spike in non-heap usage) where AHS cannot shrink the heap fast enough and still run into container OOMs. I guess it really depends on how much room is left for java heap expansion, > which brings us back to right sizing the container memory limt. > Agreed - once AHS is active, then we only really have to worry about right-sizing the container memory limit. But this is easier to do than trying to right-size both the container memory limit as well as the distribution of Java heap/non-heap! Thank you for taking the time to look through this and spark some discussion. Please feel free to ask any other questions you may have! ~ Jonathan On Wed, Sep 14, 2022 at 10:35 AM Ashutosh Mehra wrote: > Hi Jonathan, > > Thanks for sharing your work here. > I have a few questions to understand the idea better. > > >> - >> >> Containers at Google must be properly sized to not only the JVM heap, >> but other memory consumers as well. These consumers include non-heap Java >> (e.g. native code allocations), and simultaneously running non-Java >> processes. >> >> > How is the container memory limit being determined? Does that process take > into account non-Java processes running in the container as well? > > >> - >> >> We have an application running into container OOMs. >> - >> >> An engineer raises both container memory limit and Xmx by the same >> amount, since there appears to be insufficient memory. >> >> > If I understand it correctly, the problem appears to be that when the JVM > tries to expand the heap within Xmx limits, as there are other non-Java > processes consuming memory, > the total used memory of the container reaches the container limit and > results in container OOMs. > It makes sense to raise the container memory limit, but what is the need > to raise the Xmx by the same amount? > > >> - >> >> For preventing container OOM: Why can't heap expansions be bounded by >> the remaining free space in the container? >> >> > I am wondering if Java heap expansion is always the cause of container > OOM? > As you mentioned earlier, there are other non-Java processes and other > components in Java that consume native heap. I believe they too can be the > source of container OOM. > If so, then bounding the heap expansion would not cover all the cases. > > Time spent doing GC for an application may increase significantly (though >> generally we've seen in practice that even if this is the case, end-to-end >> latency does not increase a noticeable amount) >> > > I guess it really depends on how much room is left for java heap > expansion, which brings us back to right sizing the container memory limt. > > Regards, > Ashutosh Mehra > > On Tue, Sep 13, 2022 at 3:54 PM Jonathan Joo > wrote: > >> Hello hotspot-dev and hotspot-gc-dev, >> >> My name is Jonathan, and I'm working on the Java Platform Team at Google. >> Here, we are working on a project to address Java container memory issues, >> as we noticed that a significant number of Java servers hit container OOM >> issues due to people incorrectly tuning their heap size with respect to the >> container size. Because our containers have other RAM consumers which >> fluctuate over time, it is often difficult to determine a priori what is an >> appropriate Xmx to set for a particular server. >> >> We set about trying to solve this by dynamically adjusting the Java >> heap/gc behavior based on the container usage information that we pass into >> the JVM. We have seen promising results so far, reducing container OOMs by >> a significant amount, and oftentimes also reducing average heap usage (with >> the tradeoff of more CPU time spent doing GC). >> >> Below (under the dotted line) is a more detailed explanation of our >> initial approach. Does this sound like something that may be useful for the >> general OpenJDK community? If so, would some of you be open to further >> discussion? I would also like to better understand what container >> environments look like outside of Google, to see how we could modify our >> approach for the more general case. >> >> Thank you! >> >> >> Jonathan >> ------------------------------------------------------------------------ >> Introduction: >> >> Adaptable Heap Sizing (AHS) is a project internal to Google that is meant >> to simplify configuration and improve the stability of applications in >> container environments. The key is that in a containerized environment, we >> have access to container usage and limit information. This can be used as a >> signal to modify Java heap behavior, helping prevent container OOMs. >> Problem: >> >> - >> >> Containers at Google must be properly sized to not only the JVM heap, >> but other memory consumers as well. These consumers include non-heap Java >> (e.g. native code allocations), and simultaneously running non-Java >> processes. >> - >> >> Common antipattern we see here at Google: >> - >> >> We have an application running into container OOMs. >> - >> >> An engineer raises both container memory limit and Xmx by the same >> amount, since there appears to be insufficient memory. >> - >> >> The application has reduced container OOMs, but is still prone to >> them, since G1 continues to use most of Xmx. >> - >> >> This results in many jobs being configured with much more RAM than >> they need, but still running into container OOM issues. >> >> Hypothesis: >> >> - >> >> For preventing container OOM: Why can't heap expansions be bounded by >> the remaining free space in the container? >> - >> >> For preventing the `unnecessarily high Xmx` antipattern: Why can't >> target heap size be set based on GC CPU overhead? >> - >> >> From our work on Adaptable Heap Sizing, it appears they can! >> >> Design: >> >> - >> >> We add two manageable flags in the JVM >> - >> >> Current maximum heap expansion size >> - >> >> Current target heap size >> - >> >> A separate thread runs alongside the JVM, querying: >> - >> >> Container memory usage/limits >> - >> >> GC CPU overhead metrics from the JVM. >> - >> >> This thread then uses this information to calculate new values for >> the two new JVM flags, and continually updates them at runtime. >> - >> >> The `Current maximum heap expansion size` informs the JVM what is the >> maximum amount we can expand the heap by, while staying within container >> limits. This is a hard limit, and trying to expand more than this amount >> results in behavior equivalent to hitting the Xmx limit. >> - >> >> The `Current target heap size` is a soft target value, which is used to >> resize the heap (when possible) so as to bring GC CPU overhead toward its >> target value. >> >> >> Results: >> >> - >> >> At Google, we have found that this design works incredibly well in >> our initial rollout, even for large and complex workloads. >> - >> >> After deploying this to dozens of applications: >> - >> >> Significant memory savings for previously misconfigured jobs (many >> of which reduced their heap usage by 50% or more) >> - >> >> Significantly reduced occurrences of container OOM (100% reduction >> in vast majority of cases) >> - >> >> No correctness issues >> - >> >> No latency regressions* >> - >> >> We plan to deploy AHS across a much wider subset of applications >> by EOY '22. >> >> >> *Caveats: >> >> - Enabling this feature might require tuning of the newly introduced >> default GC CPU overhead target to avoid regressions. >> - >> >> Time spent doing GC for an application may increase significantly >> (though generally we've seen in practice that even if this is the case, >> end-to-end latency does not increase a noticeable amount) >> - >> >> Enabling AHS results in frequent heap resizings, but we have not seen >> evidence of any negative effects as a result of these more frequent heap >> resizings. >> - >> >> AHS is not necessarily a replacement for proper JVM tuning, but >> should generally work better than an untuned or improperly tuned >> configuration. >> - >> >> AHS is not intended for every possible workload, and there could be >> pathological cases where AHS results in worse behavior. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From iklam at openjdk.org Fri Sep 16 06:20:06 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 16 Sep 2022 06:20:06 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v8] In-Reply-To: References: Message-ID: > Current in gdb, you can print information about a class or method with something like > > > call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) > call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) > > > However, it's difficult to find a class or method by its name and print out its contents. > > This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. > > - `findclass()`: class name only > - `findmethod()`: class name and method name > - `findmethod2()`: class name and method name/signature > > I also cleaned up `BytecodeTracer` to remove unnecessary complexity. > > Here are some examples: > > > (gdb) call findclass("java/lang/Object", 0) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > > (gdb) call findclass("java/lang/Object", 1) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000658 : ()V > 0x00007fffb40010f0 finalize : ()V > 0x00007fffb4000f00 wait0 : (J)V > 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z > 0x00007fffb4000aa0 toString : ()Ljava/lang/String; > 0x00007fffb40007f0 hashCode : ()I > 0x00007fffb4000720 getClass : ()Ljava/lang/Class; > 0x00007fffb40009a0 clone : ()Ljava/lang/Object; > 0x00007fffb4000b50 notify : ()V > 0x00007fffb4000c20 notifyAll : ()V > 0x00007fffb4000e50 wait : (J)V > 0x00007fffb4001028 wait : (JI)V > 0x00007fffb4000d08 wait : ()V > > (gdb) call findclass("*ClassLoader", 0) > [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [....] > > (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000d08 wait : ()V > 0x00007fffb4000ce8 0 fast_aload_0 > 0x00007fffb4000ce9 1 lconst_0 > 0x00007fffb4000cea 2 invokevirtual 38 > 0x00007fffb4000ced 5 return Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: some code clean-up; added help message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9957/files - new: https://git.openjdk.org/jdk/pull/9957/files/57ce8604..1b338040 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=06-07 Stats: 34 lines in 3 files changed: 28 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9957/head:pull/9957 PR: https://git.openjdk.org/jdk/pull/9957 From volker.simonis at gmail.com Fri Sep 16 07:39:04 2022 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 16 Sep 2022 09:39:04 +0200 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: References: Message-ID: Hi Jonathan, thanks for starting this discussion. It's a relevant topic and we're definitely interested as well. I have a few questions: 1. Is there a public prototype available? 2. For which GCs have you implemented it? 3. On which platforms does it currently work? 4. Do you use information from procfs on Linux (or what else) to get the memory state of the system? 5. How often do you query the system and JVM state and update the settings? Is this (or can it be) correlated to the JVMs allocation rate? 6. Can you please explain your approach in some more detail (e.g. how does heap shrinking work)? I suppose you have "Current target heap size" <= "Current maximum heap expansion size" <= Xmx. I can understand how your monitoring thread updates "Current maximum heap expansion size" based on the systems memory usage. But it's harder to understand how you set "Current target heap size" based GC CPU overhead and when and how do you trigger heap resizing (both increasing and shrinking) based on these values? And why do you need two new variables? Wouldn't "Current target heap size" be enough" (also see next question for more context)? 7. What you propose is very similar to the CurrentMaxHeapSize proposed by "JEP draft: Dynamic Max Memory Limit" [1] except that the latter proposal misses the part about how to automatically set and update this value. 8. We already have "JEP 346: Promptly Return Unused Committed Memory from G1" [2] since JDK 12. Can you explain why this isn't enough? I.e. if the GC already returns as much heap memory as possible back to the system, what else can you do to further improve the situation? [1] https://openjdk.org/jeps/8204088 [2] https://openjdk.org/jeps/346 On Tue, Sep 13, 2022 at 9:17 PM Jonathan Joo wrote: > > Hello hotspot-dev and hotspot-gc-dev, > > > My name is Jonathan, and I'm working on the Java Platform Team at Google. Here, we are working on a project to address Java container memory issues, as we noticed that a significant number of Java servers hit container OOM issues due to people incorrectly tuning their heap size with respect to the container size. Because our containers have other RAM consumers which fluctuate over time, it is often difficult to determine a priori what is an appropriate Xmx to set for a particular server. > > > We set about trying to solve this by dynamically adjusting the Java heap/gc behavior based on the container usage information that we pass into the JVM. We have seen promising results so far, reducing container OOMs by a significant amount, and oftentimes also reducing average heap usage (with the tradeoff of more CPU time spent doing GC). > > > Below (under the dotted line) is a more detailed explanation of our initial approach. Does this sound like something that may be useful for the general OpenJDK community? If so, would some of you be open to further discussion? I would also like to better understand what container environments look like outside of Google, to see how we could modify our approach for the more general case. > > > Thank you! > > > Jonathan > > ------------------------------------------------------------------------ > > Introduction: > > Adaptable Heap Sizing (AHS) is a project internal to Google that is meant to simplify configuration and improve the stability of applications in container environments. The key is that in a containerized environment, we have access to container usage and limit information. This can be used as a signal to modify Java heap behavior, helping prevent container OOMs. > > Problem: > > Containers at Google must be properly sized to not only the JVM heap, but other memory consumers as well. These consumers include non-heap Java (e.g. native code allocations), and simultaneously running non-Java processes. > > Common antipattern we see here at Google: > > We have an application running into container OOMs. > > An engineer raises both container memory limit and Xmx by the same amount, since there appears to be insufficient memory. > > The application has reduced container OOMs, but is still prone to them, since G1 continues to use most of Xmx. > > This results in many jobs being configured with much more RAM than they need, but still running into container OOM issues. > > Hypothesis: > > For preventing container OOM: Why can't heap expansions be bounded by the remaining free space in the container? > > For preventing the `unnecessarily high Xmx` antipattern: Why can't target heap size be set based on GC CPU overhead? > > From our work on Adaptable Heap Sizing, it appears they can! > > Design: > > We add two manageable flags in the JVM > > Current maximum heap expansion size > > Current target heap size > > A separate thread runs alongside the JVM, querying: > > Container memory usage/limits > > GC CPU overhead metrics from the JVM. > > This thread then uses this information to calculate new values for the two new JVM flags, and continually updates them at runtime. > > The `Current maximum heap expansion size` informs the JVM what is the maximum amount we can expand the heap by, while staying within container limits. This is a hard limit, and trying to expand more than this amount results in behavior equivalent to hitting the Xmx limit. > > The `Current target heap size` is a soft target value, which is used to resize the heap (when possible) so as to bring GC CPU overhead toward its target value. > > > Results: > > At Google, we have found that this design works incredibly well in our initial rollout, even for large and complex workloads. > > After deploying this to dozens of applications: > > Significant memory savings for previously misconfigured jobs (many of which reduced their heap usage by 50% or more) > > Significantly reduced occurrences of container OOM (100% reduction in vast majority of cases) > > No correctness issues > > No latency regressions* > > We plan to deploy AHS across a much wider subset of applications by EOY '22. > > > *Caveats: > > Enabling this feature might require tuning of the newly introduced default GC CPU overhead target to avoid regressions. > > Time spent doing GC for an application may increase significantly (though generally we've seen in practice that even if this is the case, end-to-end latency does not increase a noticeable amount) > > Enabling AHS results in frequent heap resizings, but we have not seen evidence of any negative effects as a result of these more frequent heap resizings. > > AHS is not necessarily a replacement for proper JVM tuning, but should generally work better than an untuned or improperly tuned configuration. > > AHS is not intended for every possible workload, and there could be pathological cases where AHS results in worse behavior. From fyang at openjdk.org Fri Sep 16 07:43:48 2022 From: fyang at openjdk.org (Fei Yang) Date: Fri, 16 Sep 2022 07:43:48 GMT Subject: RFR: 8293840: RISC-V: Remove cbuf parameter from far_call/far_jump/trampoline_call In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 06:17:58 GMT, Feilong Jiang wrote: > Follow up [JDK-8287394](https://bugs.openjdk.org/browse/JDK-8287394), remove cbuf parameter from far_call/far_jump/trampoline in riscv. > > > Testing: > - Tier1 passed on unmatched board with release build Looks OK. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10277 From fjiang at openjdk.org Fri Sep 16 10:17:10 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Fri, 16 Sep 2022 10:17:10 GMT Subject: RFR: 8293840: RISC-V: Remove cbuf parameter from far_call/far_jump/trampoline_call In-Reply-To: References: Message-ID: On Fri, 16 Sep 2022 07:41:32 GMT, Fei Yang wrote: >> Follow up [JDK-8287394](https://bugs.openjdk.org/browse/JDK-8287394), remove cbuf parameter from far_call/far_jump/trampoline in riscv. >> >> >> Testing: >> - Tier1 passed on unmatched board with release build > > Looks OK. @RealFYang -- Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10277 From fjiang at openjdk.org Fri Sep 16 11:44:09 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Fri, 16 Sep 2022 11:44:09 GMT Subject: Integrated: 8293840: RISC-V: Remove cbuf parameter from far_call/far_jump/trampoline_call In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 06:17:58 GMT, Feilong Jiang wrote: > Follow up [JDK-8287394](https://bugs.openjdk.org/browse/JDK-8287394), remove cbuf parameter from far_call/far_jump/trampoline in riscv. > > > Testing: > - Tier1 passed on unmatched board with release build This pull request has now been integrated. Changeset: 5feca688 Author: Feilong Jiang Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/5feca688df0a1d4aad67cbe7faa6f31115676a81 Stats: 19 lines in 4 files changed: 1 ins; 4 del; 14 mod 8293840: RISC-V: Remove cbuf parameter from far_call/far_jump/trampoline_call Reviewed-by: fyang ------------- PR: https://git.openjdk.org/jdk/pull/10277 From stefan.karlsson at oracle.com Fri Sep 16 12:32:14 2022 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 16 Sep 2022 14:32:14 +0200 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: References: Message-ID: <9c3f86fe-6ff4-36ff-592a-762500ace58e@oracle.com> ZGC already has a manageable flag to support the proposed "current target heap size", called SoftMaxHeapSize. It would probably be good to use the same name for the other GCs. https://malloc.se/blog/zgc-softmaxheapsize StefanK On 2022-09-13 21:16, Jonathan Joo wrote: > > Hello hotspot-dev and hotspot-gc-dev, > > > My name is Jonathan, and I'm working on the Java Platform Team at > Google. Here, we are working on a project to address Java container > memory issues, as we noticed that a significant number of Java servers > hit container OOM issues due to people incorrectly tuning their heap > size with respect to the container size. Because our containers have > other RAM consumers which fluctuate over time, it is often difficult > to determine a priori what is an appropriate Xmx to set for a > particular server. > > > We set about trying to solve this by dynamically adjusting the Java > heap/gc behavior based on the container usage information that we pass > into the JVM. We have seen promising results so far, reducing > container OOMs by a significant amount, and oftentimes also reducing > average heap usage (with the tradeoff of more CPU time spent doing GC). > > > Below (under the dotted line) is a more detailed explanation of our > initial approach. Does this sound like something that may be useful > for the general OpenJDK community? If so, would some of you be open to > further discussion? I would also like to better understand what > container environments look like outside of Google, to see how we > could modify our approach for the more general case. > > > Thank you! > > Jonathan > > > ------------------------------------------------------------------------ > > > Introduction: > > Adaptable Heap Sizing (AHS) is a project internal to Google that is > meant to simplify configuration and improve the stability of > applications in container environments. The key is that in a > containerized environment, we have access to container usage and limit > information. This can be used as a signal to modify Java heap > behavior, helping prevent container OOMs. > > > Problem: > > * > > Containers at Google must be properly sized to not only the JVM > heap, but other memory consumers as well. These consumers include > non-heap Java (e.g. native code allocations), and simultaneously > running non-Java processes. > > * > > Common antipattern we see here at Google: > > o > > We have an application running into container OOMs. > > o > > An engineer raises both container memory limit and Xmx by the > same amount, since there appears to be insufficient memory. > > o > > The application has reduced container OOMs, but is still prone > to them, since G1 continues to use most of Xmx. > > * > > This results in many jobs being configured with much more RAM than > they need, but still running into container OOM issues. > > > Hypothesis: > > * > > For preventing container OOM: Why can't heap expansions be bounded > by the remaining free space in the container? > > * > > For preventing the `unnecessarily high Xmx` antipattern: Why can't > target heap size be set based on GC CPU overhead? > > * > > From our work on Adaptable Heap Sizing, it appears they can! > > > Design: > > * > > We add two manageable flags in the JVM > > o > > Current maximum heap expansion size > > o > > Current target heap size > > * > > A separate thread runs alongside the JVM, querying: > > o > > Container memory usage/limits > > o > > GC CPU overhead metrics from the JVM. > > * > > This thread then uses this information to calculate new values for > the two new JVM flags, and continually updates them at runtime. > > * > > The `Current maximum heap expansion size` informs the JVM what is > the maximum amount we can expand the heap by, while staying within > container limits. This is a hard limit, and trying to expand more > than this amount results in behavior equivalent to hitting the Xmx > limit. > > * > > The `Current target heap size` is a soft target value, which is > used to resize the heap (when possible) so as to bring GC CPU > overhead toward its target value. > > > Results: > > * > > At Google, we have found that this design works incredibly well in > our initial rollout, even for large and complex workloads. > > * > > After deploying this to dozens of applications: > > o > > Significant memory savings for previously misconfigured jobs > (many of which reduced their heap usage by 50% or more) > > o > > Significantly reduced occurrences of container OOM (100% > reduction in vast majority of cases) > > o > > No correctness issues > > o > > No latency regressions* > > o > > We plan to deploy AHS across a much wider subset of > applications by EOY '22. > > > *Caveats: > > * > > > Enabling this feature might require tuning of the newly > introduced default GC CPU overhead target to avoid regressions. > > * > > Time spent doing GC for an application may increase significantly > (though generally we've seen in practice that even if this is the > case, end-to-end latency does not increase a noticeable amount) > > * > > Enabling AHS results in frequent heap resizings, but we have not > seen evidence of any negative effects as a result of these more > frequent heap resizings. > > * > > AHS is not necessarily a replacement for proper JVM tuning, but > should generally work better than an untuned or improperly tuned > configuration. > > * > > AHS is not intended for every possible workload, and there could > be pathological cases where AHS results in worse behavior. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yzhu at openjdk.org Fri Sep 16 14:01:13 2022 From: yzhu at openjdk.org (Yanhong Zhu) Date: Fri, 16 Sep 2022 14:01:13 GMT Subject: RFR: 8293781: RISC-V: Clarify types of calls Message-ID: RISCV64 OpenJDK uses different types of calls in generated calls. It should be clarified what they are. And the PR also cleans up some out-of-date comments. ------------- Commit messages: - Clarify types of calls Changes: https://git.openjdk.org/jdk/pull/10311/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10311&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293781 Stats: 79 lines in 3 files changed: 70 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10311.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10311/head:pull/10311 PR: https://git.openjdk.org/jdk/pull/10311 From yzhu at openjdk.org Fri Sep 16 14:11:12 2022 From: yzhu at openjdk.org (Yanhong Zhu) Date: Fri, 16 Sep 2022 14:11:12 GMT Subject: RFR: 8293781: RISC-V: Clarify types of calls [v2] In-Reply-To: References: Message-ID: <4Ooino7aU7RWhNAqEzUm-26uuNAByVcZIZsxrZcQkQc=.8fe47075-0b01-44be-bff1-98c850186c48@github.com> > RISCV64 OpenJDK uses different types of calls in generated calls. It should be clarified what they are. And the PR also cleans up some out-of-date comments. Yanhong Zhu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: Clarify types of calls ------------- Changes: https://git.openjdk.org/jdk/pull/10311/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10311&range=01 Stats: 78 lines in 3 files changed: 69 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10311.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10311/head:pull/10311 PR: https://git.openjdk.org/jdk/pull/10311 From thomas.schatzl at oracle.com Fri Sep 16 14:12:28 2022 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 16 Sep 2022 16:12:28 +0200 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: References: Message-ID: Hi Jonathan, great to hear from you again :) On 13.09.22 21:52, Jonathan Joo wrote: > Hello hotspot-dev and hotspot-gc-dev, > > > My name is Jonathan, and I'm working on the Java Platform Team at > Google. Here, we are working on a project to address Java container > memory issues, as we noticed that a significant number of Java servers [...] > > Below (under the dotted line) is a more detailed explanation of our > initial approach. Does this sound like something that may be useful for > the general OpenJDK community? If so, would some of you be open to > further discussion? I would also like to better understand what Most of these suggestions seem to be fairly consistent with existing RFEs (e.g. [1], [2], [3], ...) that have been discussed before with you (e.g. in [4]) and been considered really nice to have iirc. > container environments look like outside of Google, to see how we could > modify our approach for the more general case. > [...] > * > > A separate thread runs alongside the JVM, querying: > > [...] I am not convinced that having a thread inside the JVM is really the best solution. Constantly querying the _environment_ for changes seems to be traditionally outside of the scope of the JVM. Doing so also opens a quite big can of worms, just re-iterating the concerns given in other comments like: * How is the container memory limit being determined? Does that process take into account non-Java processes running in the container as well? (Ashutosh Mehra) * If you have two (multiple) JVM processes running inside the container, how do they coordinate? (Ioi Lam) * The properties queried and the policies (e.g. which process should get preference if there are multiple?) are likely fairly specific to the deployment too, so is there really some one-size-fits-all policy here? (Volker Simonis) * I assume that so far you were only talking about G1/Linux support, and hoping the rest of the community jumping in... So at first glance, I question the advantages of putting the coordinator inside the JVM. The only one I can come up on the spot is: you do not have to deploy something extra. Using some external process (however it is distributed) seems to be a much more flexible option (not only in customizability but also in terms of the release cycle for it). I would suggest to at least separate this effort from improving the JVM capabilities. > * > > This thread then uses this information to calculate new values for > the two new JVM flags, and continually updates them at runtime. Since these flags were planned as manageable afair, any process could already change them as needed. > > * > > The `Current maximum heap expansion size` informs the JVM what is > the maximum amount we can expand the heap by, while staying within > container limits. This is a hard limit, and trying to expand more > than this amount results in behavior equivalent to hitting the Xmx > limit. This sounds like [2]. > > * > > The `Current target heap size` is a soft target value, which is used > to resize the heap (when possible) so as to bring GC CPU overhead > toward its target value. > See [1]. (As Stefan Karlsson mentioned, this functionality is already available in ZGC). > *Caveats: > > * Enabling this feature might require tuning of the newly > introduced default GC CPU overhead target to avoid regressions. > > * Time spent doing GC for an application may increase significantly > (though generally we've seen in practice that even if this is the > case, end-to-end latency does not increase a noticeable amount) > From the discussion in [4], JDK-8244603 has actually already been integrated. I have had some time to re-baseline the impact of [2] a few weeks ago, and actually I was planning to pick up some of that old work in the near future, but the impact ranges from nothing to very significant (-15% throughput for "simple" applications), and particularly some applications that exhibit a very "phased" behavior results show very bad behavior. I am seeing like -50% in criticaljops for SPECjbb2015 due to G1 being more aggressive with giving back memory to other users.... I am aware that nobody is running SPECjbb all the time, but just to mention that this is not work to be underestimated. Maybe your implementation of similar functionality fares much better in that area though. I think everyone is now already really curious to see your changes :) > * Enabling AHS results in frequent heap resizings, but we have not > seen evidence of any negative effects as a result of these more > frequent heap resizings. See above. > > * AHS is not necessarily a replacement for proper JVM tuning, but > should generally work better than an untuned or improperly tuned > configuration. Thanks, Thomas [1] https://bugs.openjdk.org/browse/JDK-8236073 [2] https://bugs.openjdk.org/browse/JDK-8204088 [3] https://bugs.openjdk.org/browse/JDK-8238687 [4] https://mail.openjdk.org/pipermail/hotspot-gc-dev/2021-May/035092.html From fjiang at openjdk.org Fri Sep 16 14:32:49 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Fri, 16 Sep 2022 14:32:49 GMT Subject: RFR: 8293781: RISC-V: Clarify types of calls [v2] In-Reply-To: <4Ooino7aU7RWhNAqEzUm-26uuNAByVcZIZsxrZcQkQc=.8fe47075-0b01-44be-bff1-98c850186c48@github.com> References: <4Ooino7aU7RWhNAqEzUm-26uuNAByVcZIZsxrZcQkQc=.8fe47075-0b01-44be-bff1-98c850186c48@github.com> Message-ID: On Fri, 16 Sep 2022 14:11:12 GMT, Yanhong Zhu wrote: >> RISCV64 OpenJDK uses different types of calls in generated calls. It should be clarified what they are. And the PR also cleans up some out-of-date comments. > > Yanhong Zhu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > Clarify types of calls Looks good, with one comment: src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 655: > 653: // of a direct call, which is used if the destination of a call is in range, > 654: // and a register-indirect call. It has the advantages of reaching anywhere in > 655: // the AArch64 address space and being patchable at runtime when the generated s/AArch64/RISC-V ------------- Changes requested by fjiang (Author). PR: https://git.openjdk.org/jdk/pull/10311 From sgehwolf at redhat.com Fri Sep 16 15:35:29 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 16 Sep 2022 17:35:29 +0200 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: References: Message-ID: On Fri, 2022-09-16 at 16:12 +0200, Thomas Schatzl wrote: > ? * How is the container memory limit being determined? Does that > process take into account non-Java processes running in the container as > well? (Ashutosh Mehra) As this seems to be a re-curring question, I now wonder what the original proposal was... To me the proposal sounded like solving spurious Linux kernel OOM kills, while also reducing wasted (unused) memory within a container. So given a container limit of A, the heap gets "right-sized" based on A. Let X be maximum heap, let Y be non-heap memory. Y may be non-heap memory from a separate process or the JVM. What we want is to dynamically adjust X based on A-Y, no? My understanding was that A was pre-determined by the application deployment team, X and Y are the variables. The JVM detects the limit (A) in that container e.g. by code from JDK-8146115. Y is determined by the same code (OSContainer::memory_usage_in_bytes). X needs to tuned for reduced waste. So in that context the container limit would be detected from the cgroups filesystem. Did I get that part wrong? Thanks, Severin From asmehra at redhat.com Fri Sep 16 16:41:01 2022 From: asmehra at redhat.com (Ashutosh Mehra) Date: Fri, 16 Sep 2022 12:41:01 -0400 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: References: Message-ID: Hi Severin, > So in that context the container limit would be detected from the > cgroups filesystem. > That's correct. My question was actually targeting the mechanism used to achieve A, not from within the JVM, but when deploying the containers. As Jonathan clarified in another thread that this is done by trial-and-error process. To quote his response, "In general, container memory limit at Google is determined through a trial-and-error process, where it takes into account all memory consumers. We generally start with lower limits, and as traffic increases, increase the limits. We also have some features that allow us to automatically come up with estimates for these values based on the workloads." Thanks, Ashutosh Mehra On Fri, Sep 16, 2022 at 11:36 AM Severin Gehwolf wrote: > On Fri, 2022-09-16 at 16:12 +0200, Thomas Schatzl wrote: > > * How is the container memory limit being determined? Does that > > process take into account non-Java processes running in the container as > > well? (Ashutosh Mehra) > > As this seems to be a re-curring question, I now wonder what the > original proposal was... > > To me the proposal sounded like solving spurious Linux kernel OOM > kills, while also reducing wasted (unused) memory within a container. > > So given a container limit of A, the heap gets "right-sized" based on > A. Let X be maximum heap, let Y be non-heap memory. Y may be non-heap > memory from a separate process or the JVM. What we want is to > dynamically adjust X based on A-Y, no? > > My understanding was that A was pre-determined by the application > deployment team, X and Y are the variables. The JVM detects the limit > (A) in that container e.g. by code from JDK-8146115. Y is determined by > the same code (OSContainer::memory_usage_in_bytes). X needs to tuned > for reduced waste. > > So in that context the container limit would be detected from the > cgroups filesystem. > > Did I get that part wrong? > > Thanks, > Severin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Fri Sep 16 17:41:35 2022 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Fri, 16 Sep 2022 10:41:35 -0700 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: References: Message-ID: Hi Jonathan, Very interesting experiment. This sizing issue is something that is befuddling a significant portion of those responsible for deploying containerized Java applications. Lio nicely points out that the old goal of "play nice" when configuring memory is in conflict with the new goal of "be greedy". Thus a re-visiting of memory sizing ergonomics is something that I certainly welcome. The cloud providers have been interested in better (for some weakly definition of better) memory resizing dynamics for quite some time so also a hot button topic. I'm not sure how much I have to add over what others have commented on but, I don't believe we need an inter-process communication, at least not in the first instance nor do we need a watcher thread (again, at least not in the first instance). The one thing that I see here, if I'm reading this correctly, is that there is a focus on total heap size. For generational collectors, like G1, young and tenured play two different roles and thus require different tuning strategies. Tuning young is about controlling the promotion of transients into tenured. The two big things that drive transients into tenured are undersized survivor space and frequency collections (accelerated aging). Thus young sizing should be heavily influenced by allocation rates. This is considerably different than tenured where the driving metric is live set size (LSS). Thus tenured should be LSS + some working space. From this, it follows that max heap will be the sum of the parts. From your description here, you're using CPU (GC overheads) to help you resize. Do you mind elaborating on how this works? Another side note is that you mention sizing is trial and error where you start small and then make bigger as needed. Might I suggest that a quicker way is to start large and then resize to smaller. The reason for doing this is because small clips the signals you need to look at to know how big things need to be. Starting big should give you a cleaner, unclipped signal to work with. Kind regards, Kirk On Tue, Sep 13, 2022 at 12:17 PM Jonathan Joo wrote: > Hello hotspot-dev and hotspot-gc-dev, > > My name is Jonathan, and I'm working on the Java Platform Team at Google. > Here, we are working on a project to address Java container memory issues, > as we noticed that a significant number of Java servers hit container OOM > issues due to people incorrectly tuning their heap size with respect to the > container size. Because our containers have other RAM consumers which > fluctuate over time, it is often difficult to determine a priori what is an > appropriate Xmx to set for a particular server. > > We set about trying to solve this by dynamically adjusting the Java > heap/gc behavior based on the container usage information that we pass into > the JVM. We have seen promising results so far, reducing container OOMs by > a significant amount, and oftentimes also reducing average heap usage (with > the tradeoff of more CPU time spent doing GC). > > Below (under the dotted line) is a more detailed explanation of our > initial approach. Does this sound like something that may be useful for the > general OpenJDK community? If so, would some of you be open to further > discussion? I would also like to better understand what container > environments look like outside of Google, to see how we could modify our > approach for the more general case. > > Thank you! > > > Jonathan > ------------------------------------------------------------------------ > Introduction: > > Adaptable Heap Sizing (AHS) is a project internal to Google that is meant > to simplify configuration and improve the stability of applications in > container environments. The key is that in a containerized environment, we > have access to container usage and limit information. This can be used as a > signal to modify Java heap behavior, helping prevent container OOMs. > Problem: > > - > > Containers at Google must be properly sized to not only the JVM heap, > but other memory consumers as well. These consumers include non-heap Java > (e.g. native code allocations), and simultaneously running non-Java > processes. > - > > Common antipattern we see here at Google: > - > > We have an application running into container OOMs. > - > > An engineer raises both container memory limit and Xmx by the same > amount, since there appears to be insufficient memory. > - > > The application has reduced container OOMs, but is still prone to > them, since G1 continues to use most of Xmx. > - > > This results in many jobs being configured with much more RAM than > they need, but still running into container OOM issues. > > Hypothesis: > > - > > For preventing container OOM: Why can't heap expansions be bounded by > the remaining free space in the container? > - > > For preventing the `unnecessarily high Xmx` antipattern: Why can't > target heap size be set based on GC CPU overhead? > - > > From our work on Adaptable Heap Sizing, it appears they can! > > Design: > > - > > We add two manageable flags in the JVM > - > > Current maximum heap expansion size > - > > Current target heap size > - > > A separate thread runs alongside the JVM, querying: > - > > Container memory usage/limits > - > > GC CPU overhead metrics from the JVM. > - > > This thread then uses this information to calculate new values for the > two new JVM flags, and continually updates them at runtime. > - > > The `Current maximum heap expansion size` informs the JVM what is the > maximum amount we can expand the heap by, while staying within container > limits. This is a hard limit, and trying to expand more than this amount > results in behavior equivalent to hitting the Xmx limit. > - > > The `Current target heap size` is a soft target value, which is used to > resize the heap (when possible) so as to bring GC CPU overhead toward its > target value. > > > Results: > > - > > At Google, we have found that this design works incredibly well in our > initial rollout, even for large and complex workloads. > - > > After deploying this to dozens of applications: > - > > Significant memory savings for previously misconfigured jobs (many > of which reduced their heap usage by 50% or more) > - > > Significantly reduced occurrences of container OOM (100% reduction > in vast majority of cases) > - > > No correctness issues > - > > No latency regressions* > - > > We plan to deploy AHS across a much wider subset of applications by > EOY '22. > > > *Caveats: > > - Enabling this feature might require tuning of the newly introduced > default GC CPU overhead target to avoid regressions. > - > > Time spent doing GC for an application may increase significantly > (though generally we've seen in practice that even if this is the case, > end-to-end latency does not increase a noticeable amount) > - > > Enabling AHS results in frequent heap resizings, but we have not seen > evidence of any negative effects as a result of these more frequent heap > resizings. > - > > AHS is not necessarily a replacement for proper JVM tuning, but should > generally work better than an untuned or improperly tuned configuration. > - > > AHS is not intended for every possible workload, and there could be > pathological cases where AHS results in worse behavior. > > -- Kind regards, Kirk Pepperdine http://www.kodewerk.com http://www.javaperformancetuning.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsjolen at openjdk.org Fri Sep 16 19:11:51 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 16 Sep 2022 19:11:51 GMT Subject: RFR: 8293251: Use stringStream::base() instead of as_string() when applicable [v6] In-Reply-To: <7GN_5qAEZr9HjWItusy4UGLENSTyGRDADf7pVFdES84=.0567293e-927d-4281-ac99-500b767c9c3b@github.com> References: <7GN_5qAEZr9HjWItusy4UGLENSTyGRDADf7pVFdES84=.0567293e-927d-4281-ac99-500b767c9c3b@github.com> Message-ID: On Wed, 14 Sep 2022 12:53:46 GMT, Thomas Stuefe wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Missed fixes > > Hi Johan, > > please be aware that changes like these across the code base makes downporting more painful. So I would only do wholesale renames and replacements where the benefit clearly outweighs the downporting costs. > > About your last iteration, yes, I think requiring base() to freeze the stream is a bit much. > > How about renaming "internal_string" to "freeze" > > > // Freezes stringStream (no further modifications possible) and returns pointer to it. > // No-op if stream is frozen already. > const char* freeze(); > > > "freeze" is snappy and clear in its meaning. And in release builds I also would freeze, allowing no further changes, apart from the debug-only assert. Since writes potentially reallocate the buffer, the char ptr may be invalid, better to have incomplete stringStream output than C-heap corruption (as improbable as it is). @tstuefe, @robehn Alright tests are passing :). Would any of you mind sponsoring? ------------- PR: https://git.openjdk.org/jdk/pull/10142 From jsjolen at openjdk.org Fri Sep 16 19:57:51 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 16 Sep 2022 19:57:51 GMT Subject: Integrated: 8293251: Use stringStream::base() instead of as_string() when applicable In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 11:20:59 GMT, Johan Sj?len wrote: > Hi! > > Please review this PR swapping out stringStream::as_string() with ::base() when applicable. With this change we avoid allocating a resource managed string copy. I also attempt to document the base function, as it is not safe to use any result returned from it if you subsequently call the stringStream's methods. > > When I've left ResourceMarks in place I've also commented which calls requires them. > > This passes tier1, tier2 tests. This pull request has now been integrated. Changeset: 4b8399b5 Author: Johan Sj?len Committer: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/4b8399b5f0b4dec2fa9452019cc9292bc6b57738 Stats: 76 lines in 27 files changed: 13 ins; 7 del; 56 mod 8293251: Use stringStream::base() instead of as_string() when applicable Reviewed-by: rehn ------------- PR: https://git.openjdk.org/jdk/pull/10142 From yzhu at openjdk.org Sat Sep 17 02:36:40 2022 From: yzhu at openjdk.org (Yanhong Zhu) Date: Sat, 17 Sep 2022 02:36:40 GMT Subject: RFR: 8293781: RISC-V: Clarify types of calls [v3] In-Reply-To: References: Message-ID: > RISCV64 OpenJDK uses different types of calls in generated calls. It should be clarified what they are. And the PR also cleans up some out-of-date comments. Yanhong Zhu has updated the pull request incrementally with one additional commit since the last revision: fix a typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10311/files - new: https://git.openjdk.org/jdk/pull/10311/files/5e99b407..9e77d750 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10311&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10311&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10311.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10311/head:pull/10311 PR: https://git.openjdk.org/jdk/pull/10311 From yzhu at openjdk.org Sat Sep 17 02:36:42 2022 From: yzhu at openjdk.org (Yanhong Zhu) Date: Sat, 17 Sep 2022 02:36:42 GMT Subject: RFR: 8293781: RISC-V: Clarify types of calls [v2] In-Reply-To: References: <4Ooino7aU7RWhNAqEzUm-26uuNAByVcZIZsxrZcQkQc=.8fe47075-0b01-44be-bff1-98c850186c48@github.com> Message-ID: On Fri, 16 Sep 2022 14:24:56 GMT, Feilong Jiang wrote: >> Yanhong Zhu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> Clarify types of calls > > src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 655: > >> 653: // of a direct call, which is used if the destination of a call is in range, >> 654: // and a register-indirect call. It has the advantages of reaching anywhere in >> 655: // the AArch64 address space and being patchable at runtime when the generated > > s/AArch64/RISC-V Done. ------------- PR: https://git.openjdk.org/jdk/pull/10311 From jwaters at openjdk.org Sat Sep 17 07:48:16 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 17 Sep 2022 07:48:16 GMT Subject: RFR: 8293595: tstrings::any() is missing an overload In-Reply-To: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com> References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com> Message-ID: On Fri, 9 Sep 2022 13:38:14 GMT, Julian Waters wrote: > tstrings::any() has an overload for std::wstring (if required) but is missing the corresponding operator overload for std::string, leaving only the templated one as a fallback, which will expand into a std::wostringstream << std::string operation. This isn't particularly safe on Windows, considering that JDK-8292008 and JDK-8247283 have been recently merged, and can sporadically cause build failures. This change simply adds the missing overload with the appropriate format handling that jpackage expects from std::string. Also contains minor name changes to fit the rest of the parameter names in the other overloads. Adding generic hotspot label since I don't know where this falls under, but it's likely not core-libs ------------- PR: https://git.openjdk.org/jdk/pull/10231 From yzhu at openjdk.org Sat Sep 17 08:23:42 2022 From: yzhu at openjdk.org (Yanhong Zhu) Date: Sat, 17 Sep 2022 08:23:42 GMT Subject: RFR: 8293781: RISC-V: Clarify types of calls [v4] In-Reply-To: References: Message-ID: > RISCV64 OpenJDK uses different types of calls in generated calls. It should be clarified what they are. And the PR also cleans up some out-of-date comments. > > HotSpot tier1 tests passed. Yanhong Zhu has updated the pull request incrementally with one additional commit since the last revision: modify comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10311/files - new: https://git.openjdk.org/jdk/pull/10311/files/9e77d750..49355876 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10311&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10311&range=02-03 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10311.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10311/head:pull/10311 PR: https://git.openjdk.org/jdk/pull/10311 From sspitsyn at openjdk.org Sun Sep 18 09:31:53 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sun, 18 Sep 2022 09:31:53 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions Message-ID: There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. There are a couple of details of this fix to highlight: - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. - Suspending threads in temporary transition is allowed. The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. ------------- Commit messages: - 8293613: need to properly handle and hide tmp VTMS transitions Changes: https://git.openjdk.org/jdk/pull/10321/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293613 Stats: 56 lines in 10 files changed: 49 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10321.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10321/head:pull/10321 PR: https://git.openjdk.org/jdk/pull/10321 From iklam at openjdk.org Mon Sep 19 04:46:20 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 19 Sep 2022 04:46:20 GMT Subject: RFR: 8293979: Resolve JVM_CONSTANT_Class references at CDS dump time Message-ID: Some `JVM_CONSTANT_Class` entries are guaranteed to resolve to the same value at both CDS dump time and run time: - Classes that are resolved during `vmClasses::resolve_all()`. These classes cannot be replaced by JVMTI agents at run time. - Supertypes -- at run time, a class `C` can be loaded from the CDS archive only if all of `C`'s super types are also loaded from the CDS archive. Therefore, we know that a `JVM_CONSTANT_Class` reference to a supertype of `C` must resolved to the same value at both CDS dump time and run time. By doing the resolution at dump time, we can speed up run time start-up by a little bit. The `ClassPrelinker` class added by this PR will also be used in future REFs for pre-resolving other constant pool entries. The ultimate goal is to resolve `invokedynamic` and `invokehandle` so we can significantly improve the start-up time of features such as Lambda expressions and String concatenation. See [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) ------------- Commit messages: - 8293979: Resolve JVM_CONSTANT_Class references at CDS dump time Changes: https://git.openjdk.org/jdk/pull/10330/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10330&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293979 Stats: 439 lines in 9 files changed: 386 ins; 39 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/10330.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10330/head:pull/10330 PR: https://git.openjdk.org/jdk/pull/10330 From tschatzl at openjdk.org Mon Sep 19 07:52:44 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 19 Sep 2022 07:52:44 GMT Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed In-Reply-To: References: Message-ID: <4Q4q2dCq0gNpJ_q6xmzOT3xQVK7iGBpXKnoJjw8rQuA=.1895b5b2-4e9b-4825-99f2-66ad072caa7b@github.com> On Thu, 15 Sep 2022 11:59:08 GMT, Christian Hagedorn wrote: > The DWARF debugging symbols emitted by Clang is different from what GCC is emitting. While GCC produces a complete `.debug_aranges` section (which is required in the DWARF parser), Clang does not. As a result, the DWARF parser cannot find the necessary information to proceed and create the line number information: > > The `.debug_aranges` section contains address range to compilation unit offset mappings. The parsing algorithm can just walk through all these entries to find the correct address range that contains the library offset of the current pc. This gives us the compilation unit offset into the `.debug_info` section from where we can proceed to parse the line number information. > > Without a complete `.debug_aranges` section, we fail with an assertion that we could not find the correct entry. Since [JDK-8293402](https://bugs.openjdk.org/browse/JDK-8293402), we will still get the complete stack trace at least. Nevertheless, we should still fix this assertion failure of course. But that would require a different parsing approach. We need to parse the entire `.debug_info` section instead to get to the correct compilation unit. This, however, would require a lot more work. > > I therefore suggest to disable DWARF parsing for Clang for now and file an RFE to support Clang in the future with a different parsing approach. I'm using the `__clang__` `ifdef` to bail out in `get_source_info()` and disable the `gtests`. I've noticed that we are currently running the `gtests` with `NOT PRODUCT` which I think is not necessary - the gtests should also work fine with product builds. I've corrected this as well but that could also be done separately. > > Thanks, > Christian >From https://discourse.llvm.org/t/clang-does-not-produce-full-debug-aranges-section-with-thinlto/64898/8, one needs to use `-gdwarf-aranges` with clang. However I am not sure whether we will hit that bug with "thin LTO" mentioned there (or others) if we use it. ------------- PR: https://git.openjdk.org/jdk/pull/10287 From xgong at openjdk.org Mon Sep 19 08:58:46 2022 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 19 Sep 2022 08:58:46 GMT Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector Message-ID: "`VectorSupport.indexVector()`" is used to compute a vector that contains the index values based on a given vector and a scale value (`i.e. index = vec + iota * scale`). This function is widely used in other APIs like "`VectorMask.indexInRange`" which is useful to the tail loop vectorization. And it can be easily implemented with the vector instructions. This patch adds the vector intrinsic implementation of it. The steps are: 1) Load the const "iota" vector. We extend the "`vector_iota_indices`" stubs from byte to other integral types. For floating point vectors, it needs an additional vector cast to get the right iota values. 2) Compute indexes with "`vec + iota * scale`" Here is the performance result to the new added micro benchmark on ARM NEON: Benchmark Gain IndexVectorBenchmark.byteIndexVector 1.477 IndexVectorBenchmark.doubleIndexVector 5.031 IndexVectorBenchmark.floatIndexVector 5.342 IndexVectorBenchmark.intIndexVector 5.529 IndexVectorBenchmark.longIndexVector 3.177 IndexVectorBenchmark.shortIndexVector 5.841 Please help to review and share the feedback! Thanks in advance! ------------- Commit messages: - 8293409: [vectorapi] Intrinsify VectorSupport.indexVector Changes: https://git.openjdk.org/jdk/pull/10332/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10332&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293409 Stats: 358 lines in 14 files changed: 328 ins; 6 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/10332.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10332/head:pull/10332 PR: https://git.openjdk.org/jdk/pull/10332 From sgehwolf at redhat.com Mon Sep 19 09:36:49 2022 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 19 Sep 2022 11:36:49 +0200 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: References: Message-ID: <8a41712c80b8925fa5d3c4ba33a72c50bb5fb8f5.camel@redhat.com> On Fri, 2022-09-16 at 12:41 -0400, Ashutosh Mehra wrote: > Hi Severin, > ? > > So in that context the container limit would be detected from the > > cgroups filesystem. > > That's correct. My question was actually targeting the mechanism used > to achieve A, not from within the JVM, but when deploying the > containers. OK, thanks. That aspect should be a non-goal of this proposal, IMO. Thanks, Severin From dnsimon at openjdk.org Mon Sep 19 10:56:52 2022 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 19 Sep 2022 10:56:52 GMT Subject: RFR: 8287373: remove unnecessary paddings in generated code [v4] In-Reply-To: References: Message-ID: On Fri, 10 Jun 2022 07:54:00 GMT, Boris Ulasevich wrote: >> The goal is to remove unnecessary paddings in generated code. The alignment of the [Stub Code] section is determined by the same value as the alignment of the [Entry Point] section: the CodeEntryAlignment parameter with default values 64B on AARCH, and 32B on AMD. >> >> Large entry alignment values are questionable for entry section. For example, Arm Neoverse N1 Software Optimization Guide recommends to align subroutines to 32B, while static compilers uses an even smaller value of 16B. However, with this change, I suggest to apply different (and smaller) values for [Constants] and [Stub Code] section alignments. This makes overall code 2% smaller on AARCH. >> >> The correctness of the changes is checked by jtreg. Performance tested by Renaissance and SpecJBB benchmarkds on AARCH and AMD. >> >> Example. Dummy method disassembly on AARCH, before vs after: >> >> [Verified Entry Point] | [Verified Entry Point] >> 78c63b80: nop | 7437e480: nop >> 78c63b84: sub x9, sp, #0x20, lsl #12 | 7437e484: sub x9, sp, #0x20, lsl #12 >> 78c63b88: str xzr, [x9] | 7437e488: str xzr, [x9] >> 78c63b8c: sub sp, sp, #0x20 | 7437e48c: sub sp, sp, #0x20 >> 78c63b90: stp x29, x30, [sp, #16] | 7437e490: stp x29, x30, [sp, #16] >> 78c63b94: orr w1, wzr, #0x10 | 7437e494: orr w1, wzr, #0x10 >> 78c63b98: bl 78343e00 | 7437e498: bl 73a61980 >> 78c63b9c: .inst 0x00000000 ; undefined | 7437e49c: .inst 0x00000000 ; undefined >> 78c63ba0: .inst 0x00000000 ; undefined | >> 78c63ba4: .inst 0x00000000 ; undefined | >> 78c63ba8: .inst 0x00000000 ; undefined | >> 78c63bac: .inst 0x00000000 ; undefined | >> 78c63bb0: .inst 0x00000000 ; undefined | >> 78c63bb4: .inst 0x00000000 ; undefined | >> 78c63bb8: .inst 0x00000000 ; undefined | >> 78c63bbc: .inst 0x00000000 ; undefined | >> [Stub Code] | [Stub Code] >> 78c63bc0: ldr x8, 78c63bc8 | 7437e4a0: ldr x8, 7437e4a8 >> 78c63bc4: br x8 | 7437e4a4: br x8 >> 78c63bc8: .inst 0x78343e00 ; undefined | 7437e4a8: .inst 0x73a61980 ; undefined >> 78c63bcc: .inst ; undefined | 7437e4ac: .inst ; undefined >> [Exception Handler] | [Exception Handler] >> 78c63bd0: b 783ee080 | 7437e4b0: b 73b0c100 >> [Deopt Handler Code] | [Deopt Handler Code] >> 78c63bd4: adr x30, 78c63bd4 | 7437e4b4: adr x30, 7437e4b4 >> 78c63bd8: b 78343ac0 | 7437e4b8: b 73a61620 >> 78c63bdc: .inst 0x00000000 ; undefined | 7437e4bc: .inst 0x00000000 ; undefined > > Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision: > > comment fix src/hotspot/share/asm/codeBuffer.hpp line 711: > 709: inline int CodeSection::alignment(int section) { > 710: if (section == CodeBuffer::SECT_CONSTS) { > 711: return (int) sizeof(jdouble); This breaks Graal which puts data items larger than a `jdouble` (e.g. 32-byte vector masks) into the constants section. ------------- PR: https://git.openjdk.org/jdk/pull/8453 From dnsimon at openjdk.org Mon Sep 19 11:03:57 2022 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 19 Sep 2022 11:03:57 GMT Subject: RFR: 8287373: remove unnecessary paddings in generated code [v4] In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 10:53:13 GMT, Doug Simon wrote: >> Boris Ulasevich has updated the pull request incrementally with one additional commit since the last revision: >> >> comment fix > > src/hotspot/share/asm/codeBuffer.hpp line 711: > >> 709: inline int CodeSection::alignment(int section) { >> 710: if (section == CodeBuffer::SECT_CONSTS) { >> 711: return (int) sizeof(jdouble); > > This breaks Graal which puts data items larger than a `jdouble` (e.g. 32-byte vector masks) into the constants section. I opened https://bugs.openjdk.org/browse/JDK-8293999 to track this. ------------- PR: https://git.openjdk.org/jdk/pull/8453 From stefank at openjdk.org Mon Sep 19 12:39:57 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 19 Sep 2022 12:39:57 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs Message-ID: We have this code code in our signal handler: #ifndef AMD64 // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs // This can happen in any running code (currently more frequently in // interpreter code but has been seen in compiled code) if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " "to unstable signal handling in this distribution."); } #endif // AMD64 This bug added that change: https://bugs.openjdk.java.net/browse/JDK-8004124 In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. We've been running with this patch in the Generational ZGC repository for over a year, without any problems. ------------- Commit messages: - 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs Changes: https://git.openjdk.org/jdk/pull/10340/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10340&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294003 Stats: 8 lines in 1 file changed: 6 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10340.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10340/head:pull/10340 PR: https://git.openjdk.org/jdk/pull/10340 From eosterlund at openjdk.org Mon Sep 19 13:00:56 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 19 Sep 2022 13:00:56 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> Message-ID: On Tue, 30 Aug 2022 23:40:32 GMT, Ashutosh Mehra wrote: > Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode. > > Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier. > The Access API is same as in ZGC [1], [2] > > [1] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/oops/oop.inline.hpp#L215 > [2] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/classfile/javaClasses.inline.hpp#L286 > > Test with fastdebug build: > > - [x] hotspot_loom > - [x] jdk_loom > - [x] hotspot_loom in Shenandoah IU mode > - [x] jdk_loom in Shenandoah IU mode > - [x] hotspot_loom in Shenandoah IU + aggressive > - [x] jdk_loom in Shenandoah IU + aggressive > > Signed-off-by: Ashutosh Mehra @rkennke ping! ------------- PR: https://git.openjdk.org/jdk/pull/10089 From jvernee at openjdk.org Mon Sep 19 15:22:53 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 19 Sep 2022 15:22:53 GMT Subject: RFR: 8290373: Enable lossy conversion warnings on Windows [v4] In-Reply-To: References: Message-ID: <7V3bi1uaGDP0zcBav2d2W7o5_Fw5yVNIHDwyRS8L_pA=.db186fe7-df7e-4703-9c51-3b57ae98388e@github.com> On Wed, 20 Jul 2022 14:18:49 GMT, Jorn Vernee wrote: >> This patch enables lossy conversion warnings (C4244 [1]) for hotspot on Windows/MSVC. Instead of fixing all warnings that were produced from this, I've instead locally disabled the warning in the files that produced warnings. This allows gradually making progress with cleaning up these warnings on a per-file basis, instead of trying to fix all of them in one shot. i.e. it is not meant as a long term solution, but as a way of allowing incremental progress. >> >> Out of the ~1100 files that make up hotspot on Windows x64 , ~290 have warnings for them disabled (not counting aarch64 files), which means that with this patch ~800 files are protected by enabling this warning globally. >> >> Warnings can be fixed in individual files, or groups of files in followup patches, and warnings for those files can be enabled. >> >> I'm working on a patch that does the same for GCC, but it produces warnings in about 150 more files, so I wanted to gather feedback on this approach before continuing with that. >> >> --- >> >> To disable warnings for a file, in most cases the following prelude is added after the last `#include` at the start of a file: >> >> PRAGMA_DIAG_PUSH >> PRAGMA_ALLOW_LOSSY_CONVERSIONS >> >> And then the following is added at the end of the file for cpp files, or before closing the header guard for hpp files: >> >> PRAGMA_DIAG_POP >> >> 1 notable exception are files produced by adlc, which had their code-gen modified to add these lines instead. There were also 2 files that include headers in the middle of the file (ostream.cpp & sharedRuntime.cpp), for which I've added the PRAGMA's after the include block at the start of the file instead. They only included system headers, for which disabling warnings doesn't matter any ways. >> >> [1]: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge branch 'master' into Warn_Narrow > - Polish pt2 > - Polish > - Remove PUSH POP from test files > - Remove PUSH POP from cpp files > - Rest of the tests > - More test > - AArch64 > - Disable for tests > - Fix apostrophe > - ... and 5 more: https://git.openjdk.org/jdk/compare/1c055076...fb276afd I don't think this will go anywhere, so I'll just close the PR. Thanks for the discussion on the idea! ------------- PR: https://git.openjdk.org/jdk/pull/9516 From jvernee at openjdk.org Mon Sep 19 15:22:53 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 19 Sep 2022 15:22:53 GMT Subject: Withdrawn: 8290373: Enable lossy conversion warnings on Windows In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 13:25:57 GMT, Jorn Vernee wrote: > This patch enables lossy conversion warnings (C4244 [1]) for hotspot on Windows/MSVC. Instead of fixing all warnings that were produced from this, I've instead locally disabled the warning in the files that produced warnings. This allows gradually making progress with cleaning up these warnings on a per-file basis, instead of trying to fix all of them in one shot. i.e. it is not meant as a long term solution, but as a way of allowing incremental progress. > > Out of the ~1100 files that make up hotspot on Windows x64 , ~290 have warnings for them disabled (not counting aarch64 files), which means that with this patch ~800 files are protected by enabling this warning globally. > > Warnings can be fixed in individual files, or groups of files in followup patches, and warnings for those files can be enabled. > > I'm working on a patch that does the same for GCC, but it produces warnings in about 150 more files, so I wanted to gather feedback on this approach before continuing with that. > > --- > > To disable warnings for a file, in most cases the following prelude is added after the last `#include` at the start of a file: > > PRAGMA_DIAG_PUSH > PRAGMA_ALLOW_LOSSY_CONVERSIONS > > And then the following is added at the end of the file for cpp files, or before closing the header guard for hpp files: > > PRAGMA_DIAG_POP > > 1 notable exception are files produced by adlc, which had their code-gen modified to add these lines instead. There were also 2 files that include headers in the middle of the file (ostream.cpp & sharedRuntime.cpp), for which I've added the PRAGMA's after the include block at the start of the file instead. They only included system headers, for which disabling warnings doesn't matter any ways. > > [1]: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9516 From rkennke at openjdk.org Mon Sep 19 17:14:44 2022 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 19 Sep 2022 17:14:44 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> Message-ID: On Tue, 30 Aug 2022 23:40:32 GMT, Ashutosh Mehra wrote: > Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode. > > Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier. > The Access API is same as in ZGC [1], [2] > > [1] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/oops/oop.inline.hpp#L215 > [2] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/classfile/javaClasses.inline.hpp#L286 > > Test with fastdebug build: > > - [x] hotspot_loom > - [x] jdk_loom > - [x] hotspot_loom in Shenandoah IU mode > - [x] jdk_loom in Shenandoah IU mode > - [x] hotspot_loom in Shenandoah IU + aggressive > - [x] jdk_loom in Shenandoah IU + aggressive > > Signed-off-by: Ashutosh Mehra Oh sorry, I've been deep in some other stuff. Thanks for reminding me. The change looks good. Does this mean we can now remove some of the GC specific paths in stack-chunk handling code? ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.org/jdk/pull/10089 From asemenyuk at openjdk.org Mon Sep 19 17:29:49 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 19 Sep 2022 17:29:49 GMT Subject: RFR: 8293595: tstrings::any() is missing an overload In-Reply-To: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com> References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com> Message-ID: On Fri, 9 Sep 2022 13:38:14 GMT, Julian Waters wrote: > tstrings::any() has an overload for std::wstring (if required) but is missing the corresponding operator overload for std::string, leaving only the templated one as a fallback, which will expand into a std::wostringstream << std::string operation. This isn't particularly safe on Windows, considering that JDK-8292008 and JDK-8247283 have been recently merged, and can sporadically cause build failures. This change simply adds the missing overload with the appropriate format handling that jpackage expects from std::string. Also contains minor name changes to fit the rest of the parameter names in the other overloads. Changes requested by asemenyuk (Reviewer). src/jdk.jpackage/share/native/common/tstrings.h line 363: > 361: return *this; > 362: } > 363: I guess you also need any& operator << (LPSTR v) { data << (v ? fromUtf8(v) : "NULL"); return *this; } any& operator << (LPCSTR v) { data << (v ? fromUtf8(v) : "NULL"); return *this; } to make a complete set of overloads ------------- PR: https://git.openjdk.org/jdk/pull/10231 From sspitsyn at openjdk.org Mon Sep 19 17:57:58 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 19 Sep 2022 17:57:58 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v2] In-Reply-To: References: Message-ID: > There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. > > There are a couple of details of this fix to highlight: > - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. > - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. > - Suspending threads in temporary transition is allowed. > > The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: some refactoring/renaming from Alan ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10321/files - new: https://git.openjdk.org/jdk/pull/10321/files/af80743a..7ff72d7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=00-01 Stats: 53 lines in 5 files changed: 27 ins; 12 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/10321.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10321/head:pull/10321 PR: https://git.openjdk.org/jdk/pull/10321 From jwaters at openjdk.org Mon Sep 19 18:10:53 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 19 Sep 2022 18:10:53 GMT Subject: RFR: 8293595: tstrings::any() is missing an overload In-Reply-To: References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com> Message-ID: <-LTFLRniQjzc1wQ9k3NHN2ZTVM07DV6PEf9IY9Ed6vM=.cdcdcc64-52ef-4363-b087-3efcca94c840@github.com> On Mon, 19 Sep 2022 17:27:29 GMT, Alexey Semenyuk wrote: >> tstrings::any() has an overload for std::wstring (if required) but is missing the corresponding operator overload for std::string, leaving only the templated one as a fallback, which will expand into a std::wostringstream << std::string operation. This isn't particularly safe on Windows, considering that JDK-8292008 and JDK-8247283 have been recently merged, and can sporadically cause build failures. This change simply adds the missing overload with the appropriate format handling that jpackage expects from std::string. Also contains minor name changes to fit the rest of the parameter names in the other overloads. > > src/jdk.jpackage/share/native/common/tstrings.h line 363: > >> 361: return *this; >> 362: } >> 363: > > I guess you also need > > any& operator << (LPSTR v) { > data << (v ? fromUtf8(v) : "NULL"); > return *this; > } > > any& operator << (LPCSTR v) { > data << (v ? fromUtf8(v) : "NULL"); > return *this; > } > > to make a complete set of overloads I deliberately left those 2 out since the comments accompanying them seem to suggest that they're Windows specific overloads that are there for different reasons (As opposed to the one this PR is aimed at, which takes in a regular std::wstring), moreover not providing overloads for them don't seem to be causing issues either. I'm unsure if adding them too would be correct, I'll wait for more reviews before doing so ------------- PR: https://git.openjdk.org/jdk/pull/10231 From sspitsyn at openjdk.org Mon Sep 19 19:18:57 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 19 Sep 2022 19:18:57 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: > There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. > > There are a couple of details of this fix to highlight: > - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. > - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. > - Suspending threads in temporary transition is allowed. > > The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fixed typo in VirtualThread.c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10321/files - new: https://git.openjdk.org/jdk/pull/10321/files/7ff72d7f..551d8d32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10321.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10321/head:pull/10321 PR: https://git.openjdk.org/jdk/pull/10321 From asemenyuk at openjdk.org Mon Sep 19 19:21:00 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 19 Sep 2022 19:21:00 GMT Subject: RFR: 8293595: tstrings::any() is missing an overload In-Reply-To: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com> References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com> Message-ID: On Fri, 9 Sep 2022 13:38:14 GMT, Julian Waters wrote: > tstrings::any() has an overload for std::wstring (if required) but is missing the corresponding operator overload for std::string, leaving only the templated one as a fallback, which will expand into a std::wostringstream << std::string operation. This isn't particularly safe on Windows, considering that JDK-8292008 and JDK-8247283 have been recently merged, and can sporadically cause build failures. This change simply adds the missing overload with the appropriate format handling that jpackage expects from std::string. Also contains minor name changes to fit the rest of the parameter names in the other overloads. Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10231 From asemenyuk at openjdk.org Mon Sep 19 19:21:00 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 19 Sep 2022 19:21:00 GMT Subject: RFR: 8293595: tstrings::any() is missing an overload In-Reply-To: <-LTFLRniQjzc1wQ9k3NHN2ZTVM07DV6PEf9IY9Ed6vM=.cdcdcc64-52ef-4363-b087-3efcca94c840@github.com> References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com> <-LTFLRniQjzc1wQ9k3NHN2ZTVM07DV6PEf9IY9Ed6vM=.cdcdcc64-52ef-4363-b087-3efcca94c840@github.com> Message-ID: On Mon, 19 Sep 2022 18:06:51 GMT, Julian Waters wrote: >> src/jdk.jpackage/share/native/common/tstrings.h line 363: >> >>> 361: return *this; >>> 362: } >>> 363: >> >> I guess you also need >> >> any& operator << (LPSTR v) { >> data << (v ? fromUtf8(v) : "NULL"); >> return *this; >> } >> >> any& operator << (LPCSTR v) { >> data << (v ? fromUtf8(v) : "NULL"); >> return *this; >> } >> >> to make a complete set of overloads > > I deliberately left those 2 out since the comments accompanying them seem to suggest that they're Windows specific overloads that are there for different reasons (As opposed to the one this PR is aimed at, which takes in a regular std::wstring), moreover not providing overloads for them don't seem to be causing issues either. I'm unsure if adding them too would be correct, I'll wait for more reviews before doing so I'm the author of these comments and basically the entire source file. You are right, it will work without the additional overloads. However the null pointers will be ignored (tested with G++ 7.4.0), but this is minor, probably implementation-specific and can be ignored. ------------- PR: https://git.openjdk.org/jdk/pull/10231 From iklam at openjdk.org Mon Sep 19 19:49:16 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 19 Sep 2022 19:49:16 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v9] In-Reply-To: References: Message-ID: > Current in gdb, you can print information about a class or method with something like > > > call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) > call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) > > > However, it's difficult to find a class or method by its name and print out its contents. > > This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. > > - `findclass()`: class name only > - `findmethod()`: class name and method name > - `findmethod2()`: class name and method name/signature > > I also cleaned up `BytecodeTracer` to remove unnecessary complexity. > > Here are some examples: > > > (gdb) call findclass("java/lang/Object", 0) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > > (gdb) call findclass("java/lang/Object", 1) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000658 : ()V > 0x00007fffb40010f0 finalize : ()V > 0x00007fffb4000f00 wait0 : (J)V > 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z > 0x00007fffb4000aa0 toString : ()Ljava/lang/String; > 0x00007fffb40007f0 hashCode : ()I > 0x00007fffb4000720 getClass : ()Ljava/lang/Class; > 0x00007fffb40009a0 clone : ()Ljava/lang/Object; > 0x00007fffb4000b50 notify : ()V > 0x00007fffb4000c20 notifyAll : ()V > 0x00007fffb4000e50 wait : (J)V > 0x00007fffb4001028 wait : (JI)V > 0x00007fffb4000d08 wait : ()V > > (gdb) call findclass("*ClassLoader", 0) > [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [....] > > (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000d08 wait : ()V > 0x00007fffb4000ce8 0 fast_aload_0 > 0x00007fffb4000ce9 1 lconst_0 > 0x00007fffb4000cea 2 invokevirtual 38 > 0x00007fffb4000ced 5 return Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: added functions for printing InstanceKlass* and Method* pointers directly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9957/files - new: https://git.openjdk.org/jdk/pull/9957/files/1b338040..adb390e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=07-08 Stats: 54 lines in 3 files changed: 45 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9957/head:pull/9957 PR: https://git.openjdk.org/jdk/pull/9957 From cjplummer at openjdk.org Mon Sep 19 20:46:10 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 19 Sep 2022 20:46:10 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 19:18:57 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fixed typo in VirtualThread.c src/hotspot/share/prims/jvmtiEnvBase.cpp line 713: > 711: if (!jt->is_in_tmp_VTMS_transition()) { > 712: jvf = check_and_skip_hidden_frames(jt, jvf); > 713: } I think this comment needs some help. It's hard to match it up with what the code is doing. I think you are saying you want to avoid skipping hidden frames when in transition, although if that's the case, it's not clear to me why not skipping is ok. Also is skipping (or not skipping) ok regardless of the JvmtiEnvBase::is_cthread_with_continuation() result? src/hotspot/share/prims/jvmtiExport.cpp line 1055: > 1053: if (JavaThread::current()->is_in_tmp_VTMS_transition()) { > 1054: return false; > 1055: } You mentioned this in the PR description. However, it's not clear to me why this is ok. Also, it should be commented. Same thing for changes in JvmtiExport::post_class_load() and JvmtiExport::post_class_prepare(). src/hotspot/share/runtime/javaThread.cpp line 1174: > 1172: #if INCLUDE_JVMTI > 1173: // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks. > 1174: assert(!is_in_non_tmp_VTMS_transition(), "no suspend allowed in VTMS transition"); IMHO, a non tmp VTMS transition should be considered a type of VTMS transition, so the assert check here does not really match the assert text. Also see my related comments below on naming and use of these flags and APIs. src/hotspot/share/runtime/javaThread.hpp line 650: > 648: void set_is_in_VTMS_transition(bool val); > 649: bool is_in_tmp_VTMS_transition() const { return _is_in_tmp_VTMS_transition; } > 650: void toggle_is_in_tmp_VTMS_transition() { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; }; The naming of the flags does not match up with the naming of the APIs, which is confusing. An API named is_in_VTMS_transition() should return _is_in_VTMS_transition. I think part of problem is that _is_in_VTMS_transition is not a superset of _is_in_tmp_VTMS_transition. The flags are never both set true, although both can be false. Maybe this should be changed to make it an invariant that if _is_in_tmp_VTMS_transit is true, then _is_in_tmp_VTMS_transition is true. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From jwaters at openjdk.org Mon Sep 19 20:49:49 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 19 Sep 2022 20:49:49 GMT Subject: RFR: 8293595: tstrings::any() is missing an overload In-Reply-To: References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com> <-LTFLRniQjzc1wQ9k3NHN2ZTVM07DV6PEf9IY9Ed6vM=.cdcdcc64-52ef-4363-b087-3efcca94c840@github.com> Message-ID: On Mon, 19 Sep 2022 19:17:06 GMT, Alexey Semenyuk wrote: >> I deliberately left those 2 out since the comments accompanying them seem to suggest that they're Windows specific overloads that are there for different reasons (As opposed to the one this PR is aimed at, which takes in a regular std::wstring), moreover not providing overloads for them don't seem to be causing issues either. I'm unsure if adding them too would be correct, I'll wait for more reviews before doing so > > I'm the author of these comments and basically the entire source file. > > You are right, it will work without the additional overloads. However the null pointers will be ignored (tested with G++ 7.4.0), but this is minor, probably implementation-specific and can be ignored. Strange, on my end gcc doesn't mind NULL being passed (though this may be due to a different gcc version being used), guess it's probably implementation specific like you mentioned ------------- PR: https://git.openjdk.org/jdk/pull/10231 From almatvee at openjdk.org Mon Sep 19 21:29:44 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 19 Sep 2022 21:29:44 GMT Subject: RFR: 8293595: tstrings::any() is missing an overload In-Reply-To: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com> References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com> Message-ID: On Fri, 9 Sep 2022 13:38:14 GMT, Julian Waters wrote: > tstrings::any() has an overload for std::wstring (if required) but is missing the corresponding operator overload for std::string, leaving only the templated one as a fallback, which will expand into a std::wostringstream << std::string operation. This isn't particularly safe on Windows, considering that JDK-8292008 and JDK-8247283 have been recently merged, and can sporadically cause build failures. This change simply adds the missing overload with the appropriate format handling that jpackage expects from std::string. Also contains minor name changes to fit the rest of the parameter names in the other overloads. Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10231 From dholmes at openjdk.org Mon Sep 19 22:09:45 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Sep 2022 22:09:45 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 12:33:44 GMT, Stefan Karlsson wrote: > We have this code code in our signal handler: > > > #ifndef AMD64 > // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs > // This can happen in any running code (currently more frequently in > // interpreter code but has been seen in compiled code) > if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { > fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " > "to unstable signal handling in this distribution."); > } > #endif // AMD64 > > > This bug added that change: > https://bugs.openjdk.java.net/browse/JDK-8004124 > > In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: > > "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" > > That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. > > As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. > > I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. > > We've been running with this patch in the Generational ZGC repository for over a year, without any problems. This seems quite reasonable. We've had a few SI_KERNEL crash reports since the original 32-bit Linux issue was reported. Short-circuiting the processing makes complete sense. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10340 From dlong at openjdk.org Mon Sep 19 22:29:48 2022 From: dlong at openjdk.org (Dean Long) Date: Mon, 19 Sep 2022 22:29:48 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 12:33:44 GMT, Stefan Karlsson wrote: > We have this code code in our signal handler: > > > #ifndef AMD64 > // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs > // This can happen in any running code (currently more frequently in > // interpreter code but has been seen in compiled code) > if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { > fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " > "to unstable signal handling in this distribution."); > } > #endif // AMD64 > > > This bug added that change: > https://bugs.openjdk.java.net/browse/JDK-8004124 > > In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: > > "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" > > That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. > > As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. > > I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. > > We've been running with this patch in the Generational ZGC repository for over a year, without any problems. Is there a way to detect this on Windows too? https://bugs.openjdk.org/browse/JDK-8293832 looks like it could be because of high bits with ZGC. ------------- PR: https://git.openjdk.org/jdk/pull/10340 From lmesnik at openjdk.org Tue Sep 20 00:28:16 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 20 Sep 2022 00:28:16 GMT Subject: RFR: 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume Message-ID: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume ------------- Commit messages: - 8289608: Change com/sun/jdi tests to not use Thread.suspend/resume Changes: https://git.openjdk.org/jdk/pull/10351/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10351&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289607 Stats: 319 lines in 16 files changed: 90 ins; 166 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/10351.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10351/head:pull/10351 PR: https://git.openjdk.org/jdk/pull/10351 From lmesnik at openjdk.org Tue Sep 20 00:36:38 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 20 Sep 2022 00:36:38 GMT Subject: RFR: 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume [v2] In-Reply-To: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: > The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. > Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. > > Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: revert changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10351/files - new: https://git.openjdk.org/jdk/pull/10351/files/8f660693..356ee078 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10351&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10351&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10351.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10351/head:pull/10351 PR: https://git.openjdk.org/jdk/pull/10351 From dholmes at openjdk.org Tue Sep 20 01:04:25 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Sep 2022 01:04:25 GMT Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications Message-ID: This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref: JDK-8290196 12.8: Clarify the definition of program exit https://bugs.openjdk.org/browse/JDK-8290196 JDK-8290388 5.7: Clarify the definition of JVM termination https://bugs.openjdk.org/browse/JDK-8290388 JDK-8290036 Define and specify Runtime shutdown sequence https://bugs.openjdk.org/browse/JDK-8290036 Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes: 1. The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this) 2. We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot. Issue 2 covers the code change, and regression test, in this PR. In addition the specification changes can be seen here: - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment. Thank you. ------------- Commit messages: - Fix code format - Fix code format - Fix @bug number - Merge branch 'master' into 8290482-destroyjvm - Added testcase - 8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications Changes: https://git.openjdk.org/jdk/pull/10352/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10352&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290482 Stats: 110 lines in 4 files changed: 108 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10352.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10352/head:pull/10352 PR: https://git.openjdk.org/jdk/pull/10352 From dholmes at openjdk.org Tue Sep 20 01:11:47 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Sep 2022 01:11:47 GMT Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications [v2] In-Reply-To: References: Message-ID: > This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref: > > JDK-8290196 12.8: Clarify the definition of program exit > https://bugs.openjdk.org/browse/JDK-8290196 > > JDK-8290388 5.7: Clarify the definition of JVM termination > https://bugs.openjdk.org/browse/JDK-8290388 > > JDK-8290036 Define and specify Runtime shutdown sequence > https://bugs.openjdk.org/browse/JDK-8290036 > > Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes: > > 1. The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this) > > 2. We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot. > > Issue 2 covers the code change, and regression test, in this PR. > > In addition the specification changes can be seen here: > > - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html > - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html > - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html > > The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment. > > Thank you. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Fix code format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10352/files - new: https://git.openjdk.org/jdk/pull/10352/files/3106d6a3..e6c36702 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10352&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10352&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10352.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10352/head:pull/10352 PR: https://git.openjdk.org/jdk/pull/10352 From david.holmes at oracle.com Tue Sep 20 02:42:12 2022 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Sep 2022 12:42:12 +1000 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_HotSpot_Group_Member=3a_Roberto_Casta?= =?UTF-8?Q?=c3=b1eda_Lozano?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: Vote: yes David On 15/09/2022 3:54 am, Vladimir Kozlov wrote: > I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the > HotSpot Group. > > Roberto is member of HotSpot compiler group at Oracle. Since 2020, he > contributed > a lot of changes to OpenJDK. He made very important updates and > improvements to > C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 10h50 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] https://openjdk.org/census#rcastanedalo > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From david.holmes at oracle.com Tue Sep 20 02:42:34 2022 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Sep 2022 12:42:34 +1000 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: References: Message-ID: <5d8058fd-b289-b423-f8ab-8f810dd2777d@oracle.com> Vote: yes David On 15/09/2022 4:25 am, Vladimir Kozlov wrote: > I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot Group. > > Tobias is member of HotSpot compiler group at Oracle. Since 2021, he > contributed > 26 changes to HotSpot. Recently he is working on IR graph visualizer (IGV) > improvements which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 11h25 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > PS: He is second Tobias in our group (Tobias Hartmann is first). > > [1] https://openjdk.org/census#tholenstein > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From david.holmes at oracle.com Tue Sep 20 02:51:53 2022 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Sep 2022 12:51:53 +1000 Subject: Hall of shame: Header compilation times In-Reply-To: <8f64fe8a-ea39-75db-91db-9a2f23a701e8@oracle.com> References: <8f64fe8a-ea39-75db-91db-9a2f23a701e8@oracle.com> Message-ID: FYI Ioi (cc'd) has already been doing a lot of work with reorganising include files and their contents. David ----- On 6/09/2022 8:31 pm, Magnus Ihse Bursie wrote: > I recently discovered the clang -ftime-trace flag, combined with the > nifty tool ClangBuildAnalyzer[1] which analyses the output files from > -ftime-trace, and presents the "top offenders" for a whole project. > Naturally, I ran this on hotspot. :-) > > I think the most important information gathered was how costly different > header files are. It is hard to understand which files are included many > times, and if that is a problem or if they are trivial. But now we can > get this in black and white. So, without further ado, here is the top > list of costly header files in Hotspot: > > src/hotspot/share/asm/assembler.hpp (total 30284 ms, included 541 times, > avg 55 ms) > src/hotspot/share/runtime/frame.inline.hpp (total 29234 ms, included 344 > times, avg 84 ms) > src/hotspot/share/runtime/javaThread.inline.hpp (total 22297 ms, > included 226 times, avg 98 ms) > src/hotspot/share/oops/access.inline.hpp (total 19675 ms, included 514 > times, avg 38 ms) > src/hotspot/share/ci/ciEnv.hpp (total 18703 ms, included 231 times, avg > 80 ms) > src/hotspot/share/runtime/continuationEntry.inline.hpp (total 17318 ms, > included 230 times, avg 75 ms) > src/hotspot/share/oops/access.hpp (total 17123 ms, included 594 times, > avg 28 ms) > src/hotspot/share/code/nativeInst.hpp (total 14769 ms, included 389 > times, avg 37 ms) > src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp (total 14757 ms, included > 393 times, avg 37 ms) > src/hotspot/share/code/debugInfoRec.hpp (total 13809 ms, included 257 > times, avg 53 ms) > src/hotspot/share/oops/stackChunkOop.inline.hpp (total 13549 ms, > included 347 times, avg 39 ms) > src/hotspot/share/code/debugInfo.hpp (total 13411 ms, included 503 > times, avg 26 ms) > src/hotspot/share/gc/g1/g1BarrierSet.inline.hpp (total 13393 ms, > included 512 times, avg 26 ms) > src/hotspot/share/code/compiledMethod.inline.hpp (total 13337 ms, > included 330 times, avg 40 ms) > src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp (total 13295 ms, > included 60 times, avg 221 ms) > src/hotspot/share/code/location.hpp (total 12095 ms, included 316 times, > avg 38 ms) > gensrc/adfiles/ad_aarch64.hpp (total 11987 ms, included 44 times, avg > 272 ms) > src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp (total 11588 ms, > included 60 times, avg 193 ms) > src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp (total 11406 ms, included 97 times, avg 117 ms) > gensrc/jfrfiles/jfrEventClasses.hpp (total 11147 ms, included 72 times, > avg 154 ms) > src/hotspot/share/oops/oop.inline.hpp (total 11128 ms, included 510 > times, avg 21 ms) > src/hotspot/share/jfr/jfrEvents.hpp (total 10968 ms, included 71 times, > avg 154 ms) > src/hotspot/share/memory/iterator.inline.hpp (total 10512 ms, included > 83 times, avg 126 ms) > src/hotspot/share/opto/compile.hpp (total 10107 ms, included 117 times, > avg 86 ms) > src/hotspot/share/gc/g1/g1OopClosures.inline.hpp (total 10018 ms, > included 60 times, avg 166 ms) > src/hotspot/share/opto/node.hpp (total 8731 ms, included 93 times, avg > 93 ms) > src/hotspot/share/code/codeCache.hpp (total 8574 ms, included 587 times, > avg 14 ms) > src/hotspot/share/gc/z/zBarrier.inline.hpp (total 8446 ms, included 509 > times, avg 16 ms) > src/hotspot/share/asm/macroAssembler.hpp (total 8419 ms, included 433 > times, avg 19 ms) > src/hotspot/share/jfr/recorder/service/jfrEvent.hpp (total 8390 ms, > included 73 times, avg 114 ms) > src/hotspot/share/classfile/vmSymbols.hpp (total 8346 ms, included 297 > times, avg 28 ms) > src/hotspot/share/opto/ad.hpp (total 8258 ms, included 34 times, avg 242 > ms) > src/hotspot/share/classfile/javaClasses.inline.hpp (total 8174 ms, > included 185 times, avg 44 ms) > src/hotspot/share/runtime/interfaceSupport.inline.hpp (total 8053 ms, > included 135 times, avg 59 ms) > src/hotspot/share/asm/codeBuffer.hpp (total 7117 ms, included 692 times, > avg 10 ms) > src/hotspot/share/interpreter/interpreter.hpp (total 6891 ms, included > 380 times, avg 18 ms) > src/hotspot/share/ci/ciUtilities.hpp (total 6759 ms, included 196 times, > avg 34 ms) > src/hotspot/share/memory/allocation.inline.hpp (total 6557 ms, included > 266 times, avg 24 ms) > src/hotspot/share/oops/instanceKlass.inline.hpp (total 6395 ms, included > 193 times, avg 33 ms) > src/hotspot/share/code/codeBlob.hpp (total 6108 ms, included 685 times, > avg 8 ms) > > So, given this list, it seems like it would have a huge potential payoff > to start looking more closely on assembler.hpp. Is it strictly needed > everywhere it is included? Can it be split into multiple parts, so most > users only need to include some smaller subsets? Etc. And then > continuing doing the same with ciEnv.hpp and the top inline.hpp files... > > Caveats: This is from compiling with clang on a mac. There is probably > variations due to OS/compiler, etc. But I think this is a very good > approximation on what is problematic even for gcc and msvc. > > /Magnus > > [1] https://github.com/aras-p/ClangBuildAnalyzer > From yzhu at openjdk.org Tue Sep 20 02:55:40 2022 From: yzhu at openjdk.org (Yanhong Zhu) Date: Tue, 20 Sep 2022 02:55:40 GMT Subject: RFR: 8293781: RISC-V: Clarify types of calls [v5] In-Reply-To: References: Message-ID: > RISCV64 OpenJDK uses different types of calls in generated calls. It should be clarified what they are. And the PR also cleans up some out-of-date comments. > > HotSpot tier1 tests passed. Yanhong Zhu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293781 - add relocInfo comments for far_call/far_jump - modify comments - fix a typo - Clarify types of calls ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10311/files - new: https://git.openjdk.org/jdk/pull/10311/files/49355876..ee810dbd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10311&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10311&range=03-04 Stats: 2297 lines in 175 files changed: 1320 ins; 472 del; 505 mod Patch: https://git.openjdk.org/jdk/pull/10311.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10311/head:pull/10311 PR: https://git.openjdk.org/jdk/pull/10311 From fyang at openjdk.org Tue Sep 20 03:04:43 2022 From: fyang at openjdk.org (Fei Yang) Date: Tue, 20 Sep 2022 03:04:43 GMT Subject: RFR: 8293781: RISC-V: Clarify types of calls [v5] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 02:55:40 GMT, Yanhong Zhu wrote: >> RISCV64 OpenJDK uses different types of calls in generated calls. It should be clarified what they are. And the PR also cleans up some out-of-date comments. >> >> HotSpot tier1 tests passed. > > Yanhong Zhu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293781 > - add relocInfo comments for far_call/far_jump > - modify comments > - fix a typo > - Clarify types of calls Looks good. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10311 From fjiang at openjdk.org Tue Sep 20 03:04:44 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 20 Sep 2022 03:04:44 GMT Subject: RFR: 8293781: RISC-V: Clarify types of calls [v5] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 02:55:40 GMT, Yanhong Zhu wrote: >> RISCV64 OpenJDK uses different types of calls in generated calls. It should be clarified what they are. And the PR also cleans up some out-of-date comments. >> >> HotSpot tier1 tests passed. > > Yanhong Zhu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293781 > - add relocInfo comments for far_call/far_jump > - modify comments > - fix a typo > - Clarify types of calls New change looks good. ------------- Marked as reviewed by fjiang (Author). PR: https://git.openjdk.org/jdk/pull/10311 From igor.veresov at oracle.com Tue Sep 20 03:08:03 2022 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 20 Sep 2022 03:08:03 +0000 Subject: =?utf-8?B?UmU6IENGVjogTmV3IEhvdFNwb3QgR3JvdXAgTWVtYmVyOiBSb2JlcnRvIENh?= =?utf-8?B?c3Rhw7FlZGEgTG96YW5v?= In-Reply-To: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: <080A1C79-4F44-465E-8379-961517C2C82E@oracle.com> Vote: Yes igor > On Sep 14, 2022, at 10:54 AM, Vladimir Kozlov wrote: > > ?I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the HotSpot Group. > > Roberto is member of HotSpot compiler group at Oracle. Since 2020, he contributed > a lot of changes to OpenJDK. He made very important updates and improvements to > C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. > > Votes are due by Wednesday, September 28, 2022 at 10h50 PST. > > Only current Members of the HotSpot Group [2] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Vladimir Kozlov > > [1] https://openjdk.org/census#rcastanedalo > [2] https://openjdk.java.net/census#hotspot > [3] https://openjdk.org/bylaws#member-vote From ioi.lam at oracle.com Tue Sep 20 03:59:06 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 19 Sep 2022 20:59:06 -0700 Subject: Hall of shame: Header compilation times In-Reply-To: References: <8f64fe8a-ea39-75db-91db-9a2f23a701e8@oracle.com> Message-ID: I mainly look at non-PCH compilation time. I want to optimize the build time to HotSpot developers. Here are some recent fixes https://bugs.openjdk.org/issues/?jql=labels%20%3D%20include%20AND%20Status%20in%20(Resolved)%20ORDER%20BY%20resolved%20DESC I usually avoid doing large changes. A lot of times you can remove superfluous dependencies by making small tweaks, like moving inline function definitions from .hpp to .cpp files. Thanks - Ioi On 9/19/2022 7:51 PM, David Holmes wrote: > FYI Ioi (cc'd) has already been doing a lot of work with reorganising > include files and their contents. > > David > ----- > > On 6/09/2022 8:31 pm, Magnus Ihse Bursie wrote: >> I recently discovered the clang -ftime-trace flag, combined with the >> nifty tool ClangBuildAnalyzer[1] which analyses the output files from >> -ftime-trace, and presents the "top offenders" for a whole project. >> Naturally, I ran this on hotspot. :-) >> >> I think the most important information gathered was how costly >> different header files are. It is hard to understand which files are >> included many times, and if that is a problem or if they are trivial. >> But now we can get this in black and white. So, without further ado, >> here is the top list of costly header files in Hotspot: >> >> src/hotspot/share/asm/assembler.hpp (total 30284 ms, included 541 >> times, avg 55 ms) >> src/hotspot/share/runtime/frame.inline.hpp (total 29234 ms, included >> 344 times, avg 84 ms) >> src/hotspot/share/runtime/javaThread.inline.hpp (total 22297 ms, >> included 226 times, avg 98 ms) >> src/hotspot/share/oops/access.inline.hpp (total 19675 ms, included >> 514 times, avg 38 ms) >> src/hotspot/share/ci/ciEnv.hpp (total 18703 ms, included 231 times, >> avg 80 ms) >> src/hotspot/share/runtime/continuationEntry.inline.hpp (total 17318 >> ms, included 230 times, avg 75 ms) >> src/hotspot/share/oops/access.hpp (total 17123 ms, included 594 >> times, avg 28 ms) >> src/hotspot/share/code/nativeInst.hpp (total 14769 ms, included 389 >> times, avg 37 ms) >> src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp (total 14757 ms, >> included 393 times, avg 37 ms) >> src/hotspot/share/code/debugInfoRec.hpp (total 13809 ms, included 257 >> times, avg 53 ms) >> src/hotspot/share/oops/stackChunkOop.inline.hpp (total 13549 ms, >> included 347 times, avg 39 ms) >> src/hotspot/share/code/debugInfo.hpp (total 13411 ms, included 503 >> times, avg 26 ms) >> src/hotspot/share/gc/g1/g1BarrierSet.inline.hpp (total 13393 ms, >> included 512 times, avg 26 ms) >> src/hotspot/share/code/compiledMethod.inline.hpp (total 13337 ms, >> included 330 times, avg 40 ms) >> src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp (total 13295 ms, >> included 60 times, avg 221 ms) >> src/hotspot/share/code/location.hpp (total 12095 ms, included 316 >> times, avg 38 ms) >> gensrc/adfiles/ad_aarch64.hpp (total 11987 ms, included 44 times, avg >> 272 ms) >> src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp (total 11588 ms, >> included 60 times, avg 193 ms) >> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp >> (total 11406 ms, included 97 times, avg 117 ms) >> gensrc/jfrfiles/jfrEventClasses.hpp (total 11147 ms, included 72 >> times, avg 154 ms) >> src/hotspot/share/oops/oop.inline.hpp (total 11128 ms, included 510 >> times, avg 21 ms) >> src/hotspot/share/jfr/jfrEvents.hpp (total 10968 ms, included 71 >> times, avg 154 ms) >> src/hotspot/share/memory/iterator.inline.hpp (total 10512 ms, >> included 83 times, avg 126 ms) >> src/hotspot/share/opto/compile.hpp (total 10107 ms, included 117 >> times, avg 86 ms) >> src/hotspot/share/gc/g1/g1OopClosures.inline.hpp (total 10018 ms, >> included 60 times, avg 166 ms) >> src/hotspot/share/opto/node.hpp (total 8731 ms, included 93 times, >> avg 93 ms) >> src/hotspot/share/code/codeCache.hpp (total 8574 ms, included 587 >> times, avg 14 ms) >> src/hotspot/share/gc/z/zBarrier.inline.hpp (total 8446 ms, included >> 509 times, avg 16 ms) >> src/hotspot/share/asm/macroAssembler.hpp (total 8419 ms, included 433 >> times, avg 19 ms) >> src/hotspot/share/jfr/recorder/service/jfrEvent.hpp (total 8390 ms, >> included 73 times, avg 114 ms) >> src/hotspot/share/classfile/vmSymbols.hpp (total 8346 ms, included >> 297 times, avg 28 ms) >> src/hotspot/share/opto/ad.hpp (total 8258 ms, included 34 times, avg >> 242 ms) >> src/hotspot/share/classfile/javaClasses.inline.hpp (total 8174 ms, >> included 185 times, avg 44 ms) >> src/hotspot/share/runtime/interfaceSupport.inline.hpp (total 8053 ms, >> included 135 times, avg 59 ms) >> src/hotspot/share/asm/codeBuffer.hpp (total 7117 ms, included 692 >> times, avg 10 ms) >> src/hotspot/share/interpreter/interpreter.hpp (total 6891 ms, >> included 380 times, avg 18 ms) >> src/hotspot/share/ci/ciUtilities.hpp (total 6759 ms, included 196 >> times, avg 34 ms) >> src/hotspot/share/memory/allocation.inline.hpp (total 6557 ms, >> included 266 times, avg 24 ms) >> src/hotspot/share/oops/instanceKlass.inline.hpp (total 6395 ms, >> included 193 times, avg 33 ms) >> src/hotspot/share/code/codeBlob.hpp (total 6108 ms, included 685 >> times, avg 8 ms) >> >> So, given this list, it seems like it would have a huge potential >> payoff to start looking more closely on assembler.hpp. Is it strictly >> needed everywhere it is included? Can it be split into multiple >> parts, so most users only need to include some smaller subsets? Etc. >> And then continuing doing the same with ciEnv.hpp and the top >> inline.hpp files... >> >> Caveats: This is from compiling with clang on a mac. There is >> probably variations due to OS/compiler, etc. But I think this is a >> very good approximation on what is problematic even for gcc and msvc. >> >> /Magnus >> >> [1] https://github.com/aras-p/ClangBuildAnalyzer >> From dholmes at openjdk.org Tue Sep 20 06:14:45 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Sep 2022 06:14:45 GMT Subject: RFR: 8291714: Implement a Multi-Reader Single-Writer mutex for Hotspot [v5] In-Reply-To: References: <0szqSdnIumlLUEIrEGYqPO8sUCAxLmu1XcDd_YntKS8=.5d1d9d96-de9d-4ac6-8e4d-5e577f087fa7@github.com> Message-ID: On Thu, 8 Sep 2022 16:13:17 GMT, Thomas Stuefe wrote: >>>To be clear, you will only ever get a null if someone passes it in explicitly as Thread::current_or_null() should never be able to return null in the contexts you would use this RWL. >> >> Context: UL uses static initialization for LogTagSets, these use the RWLock and as such our thread system isn't initialized yet. It's not strictly necessary, as we can re-write things to not require this. >> >> Edit: Perhaps the right decision is to simply delay the initialization of LogTagSets. > >> >To be clear, you will only ever get a null if someone passes it in explicitly as Thread::current_or_null() should never be able to return null in the contexts you would use this RWL. >> >> >> >> Context: UL uses static initialization for LogTagSets, these use the RWLock and as such our thread system isn't initialized yet. It's not strictly necessary, as we can re-write things to not require this. >> >> >> >> Edit: Perhaps the right decision is to simply delay the initialization of LogTagSets. > > The early initialization of UL at lib load time is certainly a pain. > > But there are other things too, other code running before initialisation, and then there is the case of non-attached threads and signal handling, etc. > > I would be happy if this primitive was usable with Thread.current == Null. Otherwise you limit the future usefulness, and whatever code people use this lock in will also not be usable in these corner cases. > > If it does not cost too much complexity. Any use by non-attached threads is potentially problematic as they can prevent safepoints etc. I don't think we should be using a RWL in any code that might be executed by a non-attached thread. None of our locking code is async-signal-safe so using it from signal handlers should also be avoided. Early initialization of UL should be examined more closely. Anything initialized before we have threads doesn't need locking by definition, so if we structure the code/api correctly we won't encounter locks. That may mean clearly separating initialization code from similar modification code e.g. a growable data structure will need a lock in the grow method, but we don't then use the grow method from the constructor. But lets see what @jdksjolen comes up with here. ------------- PR: https://git.openjdk.org/jdk/pull/9838 From stefank at openjdk.org Tue Sep 20 07:08:52 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 20 Sep 2022 07:08:52 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 22:27:47 GMT, Dean Long wrote: > Is there a way to detect this on Windows too? https://bugs.openjdk.org/browse/JDK-8293832 looks like it could be because of high bits with ZGC. I don't know. Single-generational ZGC places most bits in "dereferenceable" memory. We only use one bit outside of that, and that bit is specifically for dealing with finalizers. I took a look at the linked Bug. So, on Windows we get 0xffffffff reported as the failing address. Note, that even with my patch, we still get the incorrect address reported on Linux. I don't know if that's fixable. My patch only makes sure that we don't try to continue running, and then hit one of those very misleading secondary failures. ------------- PR: https://git.openjdk.org/jdk/pull/10340 From svkamath at openjdk.org Tue Sep 20 07:09:42 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Tue, 20 Sep 2022 07:09:42 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 03:12:10 GMT, AJ Ferguson wrote: > Fix cipher state corruption when encrypting/decrypting less than 16 bytes at a time. Hi AJ-Ferguson, I have modified the changes you recommended and added a suggestion. Please have a look at the diff file and let me know what you think. Thanks. [diff.txt](https://github.com/openjdk/jdk/files/9604614/diff.txt) ------------- PR: https://git.openjdk.org/jdk/pull/9635 From stuefe at openjdk.org Tue Sep 20 07:12:40 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 20 Sep 2022 07:12:40 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 12:33:44 GMT, Stefan Karlsson wrote: > We have this code code in our signal handler: > > > #ifndef AMD64 > // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs > // This can happen in any running code (currently more frequently in > // interpreter code but has been seen in compiled code) > if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { > fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " > "to unstable signal handling in this distribution."); > } > #endif // AMD64 > > > This bug added that change: > https://bugs.openjdk.java.net/browse/JDK-8004124 > > In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: > > "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" > > That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. > > As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. > > I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. > > We've been running with this patch in the Generational ZGC repository for over a year, without any problems. Only question is, does distinguishing between 32-bit and 64-bit still make sense then? Both crash, only with different error texts. In the range of possible explanations (malformed address, XEN bug, ...) there is nothing that would explain a different behavior for 32-bit. ------------- PR: https://git.openjdk.org/jdk/pull/10340 From stefank at openjdk.org Tue Sep 20 07:19:28 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 20 Sep 2022 07:19:28 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 12:33:44 GMT, Stefan Karlsson wrote: > We have this code code in our signal handler: > > > #ifndef AMD64 > // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs > // This can happen in any running code (currently more frequently in > // interpreter code but has been seen in compiled code) > if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { > fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " > "to unstable signal handling in this distribution."); > } > #endif // AMD64 > > > This bug added that change: > https://bugs.openjdk.java.net/browse/JDK-8004124 > > In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: > > "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" > > That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. > > As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. > > I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. > > We've been running with this patch in the Generational ZGC repository for over a year, without any problems. Oracle doesn't build and test 32-bit versions anymore, so I can't effectively try to verify if this is needed or not. I wouldn't mind if someone else takes ownership of investigating if this is still needed for 32-bits. ------------- PR: https://git.openjdk.org/jdk/pull/10340 From dholmes at openjdk.org Tue Sep 20 08:27:49 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Sep 2022 08:27:49 GMT Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications [v3] In-Reply-To: References: Message-ID: > This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref: > > JDK-8290196 12.8: Clarify the definition of program exit > https://bugs.openjdk.org/browse/JDK-8290196 > > JDK-8290388 5.7: Clarify the definition of JVM termination > https://bugs.openjdk.org/browse/JDK-8290388 > > JDK-8290036 Define and specify Runtime shutdown sequence > https://bugs.openjdk.org/browse/JDK-8290036 > > Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes: > > 1. The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this) > > 2. We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot. > > Issue 2 covers the code change, and regression test, in this PR. > > In addition the specification changes can be seen here: > > - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html > - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html > - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html > > The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment. > > Thank you. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Missed update to Threads::is_supported_jni_version ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10352/files - new: https://git.openjdk.org/jdk/pull/10352/files/e6c36702..e56fd09d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10352&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10352&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10352.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10352/head:pull/10352 PR: https://git.openjdk.org/jdk/pull/10352 From kim.barrett at oracle.com Tue Sep 20 10:32:47 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 20 Sep 2022 10:32:47 +0000 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: <246e397f-2f10-84fa-19d7-65b1472606e9@littlepinkcloud.com> References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> <416c7338-2dff-7997-c95f-c9e1c74de180@littlepinkcloud.com> <0958C022-824B-4492-9D82-393F64965D5E@oracle.com> <246e397f-2f10-84fa-19d7-65b1472606e9@littlepinkcloud.com> Message-ID: > On Sep 15, 2022, at 4:01 AM, Andrew Haley wrote: > > On 9/15/22 01:16, Kim Barrett wrote: >> I*think* it can be done as a sequence of commits to revert prior commits, >> followed by a couple of newly developed commits to reinstate features like >> support for relaxed atomics. > > I expect so. The reversions are indeed relatively straightforward. There is one set of conflicts for one of the commits, due to unrelated nearby changes in one file, but that's relatively easy to deal with. But... Digging into this deeper, I've run across some problems. Of course, it's about memory_order_conservative. I know about the discussion here: https://mail.openjdk.org/pipermail/hotspot-dev/2019-November/039912.html (long discussion about implementing memory_order_conservative) which refers to this: https://patchwork.kernel.org/patch/3575821/ This is the reference leading to the pre-JDK-8261027 implementation. To summarize, for memory_order_conservative with ll/sc-style atomics - For cmpxchg, use - For other ops, use That's what we were requesting before JDK-8261027, via __atomic intrinsics. But -moutline-atomics changed things so we were potentially using the corresponding LSE atomic instead of the ll/sc-style. For now I'm only going to discuss the other ops, not cmpxchg. (cmpxchg is it's own ball of ugliness, but I think I know how to deal with it.) 8261027 introduced support for using LSE atomics. There are some surprises: (A) The default (ll/sc) implementations (atomic_linux_aarch64.S) are all "acq-rel" rather than "release". (B) The generated LSE stubs for "add" variants are "acq-rel" rather than "release". Meanwhile, the generated stubs for "xchg" variants are "release". (A) seems like a mistake. The inconsistency in (B) also seems like a mistake. The question of which one is correct takes us to the next change. 8261649 is intended to optimize the use of LSE atomics, though the bug only talks about cmpxchg. (It also fixes a problem with the timing of stub generation vs possible use, but that doesn't matter for this discussion.) There is a big comment in front of the new stub generation code, talking about how a acq-rel operation doesn't need a preceeding fence when using LSE atomics. I can see how that's very useful for cmpxchg. (And the comment mostly discusses cmpxchg.) But I'm not certain of it's relevance for other operations. Can non-cmpxchg operations still be implemented as when (potentially) using LSE instructions? It seems like an argument similar to the one for ll/sc could be made. If so, then we can use __atomic (and -moutline-atomics) to easily implement them. If not, that's a somewhat unpleasant semantic change going from ll/sc to LSE. (And probably breaks the current bsd_aarch64 implementation.) It also gives us a couple of choices for implementation: (C) Use with the op generated using __atomic (and using -moutline-atomics), in case we end up using LSE. This accepts the unneeded acquire if using ll/sc as a necessary evil for simplicity of implementation. (It also matches the current code, though generated differently.) (D) Avoid -moutline-atomics, doing our own use-LSE dispatch to either ll/sc or LSE implementations. There are several ways to do this, including the approach taken by the current code. So do we really need when using LSE istructions? Or can we continue to use ? I think there are also some problems with the big block comment for the stub generation. For example, I can't make sense of the model-based test description. For one thing, it talks about the resulting X3 and X4, but those don't appear in the test code. (I'm also not getting the point about a lack of barrier-ordered-after, but maybe I'm just confused.) From dholmes at openjdk.org Tue Sep 20 10:37:41 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Sep 2022 10:37:41 GMT Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications [v4] In-Reply-To: References: Message-ID: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com> > This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref: > > JDK-8290196 12.8: Clarify the definition of program exit > https://bugs.openjdk.org/browse/JDK-8290196 > > JDK-8290388 5.7: Clarify the definition of JVM termination > https://bugs.openjdk.org/browse/JDK-8290388 > > JDK-8290036 Define and specify Runtime shutdown sequence > https://bugs.openjdk.org/browse/JDK-8290036 > > Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes: > > 1. The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this) > > 2. We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot. > > Issue 2 covers the code change, and regression test, in this PR. > > In addition the specification changes can be seen here: > > - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html > - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html > - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html > > The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment. > > Thank you. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Fix JniVersion test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10352/files - new: https://git.openjdk.org/jdk/pull/10352/files/e56fd09d..9639dcf5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10352&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10352&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10352.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10352/head:pull/10352 PR: https://git.openjdk.org/jdk/pull/10352 From dholmes at openjdk.org Tue Sep 20 10:44:42 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Sep 2022 10:44:42 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs In-Reply-To: References: Message-ID: <9VgbjebYEEY_jtssZ864TYse-j67HCJLwPEP4-EGU6o=.144df90a-f723-4a6f-80ef-27ce5a7d95a9@github.com> On Mon, 19 Sep 2022 12:33:44 GMT, Stefan Karlsson wrote: > We have this code code in our signal handler: > > > #ifndef AMD64 > // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs > // This can happen in any running code (currently more frequently in > // interpreter code but has been seen in compiled code) > if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { > fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " > "to unstable signal handling in this distribution."); > } > #endif // AMD64 > > > This bug added that change: > https://bugs.openjdk.java.net/browse/JDK-8004124 > > In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: > > "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" > > That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. > > As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. > > I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. > > We've been running with this patch in the Generational ZGC repository for over a year, without any problems. The original issue we targeted on 32-bit was a kernel problem. Is it even possible to have an address past TASK_SIZE on 32-bit? ------------- PR: https://git.openjdk.org/jdk/pull/10340 From aph-open at littlepinkcloud.com Tue Sep 20 11:15:27 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 20 Sep 2022 12:15:27 +0100 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> <416c7338-2dff-7997-c95f-c9e1c74de180@littlepinkcloud.com> <0958C022-824B-4492-9D82-393F64965D5E@oracle.com> <246e397f-2f10-84fa-19d7-65b1472606e9@littlepinkcloud.com> Message-ID: <4a767b25-1539-183a-e4cd-4852f633e77d@littlepinkcloud.com> On 9/20/22 11:32, Kim Barrett wrote: >> On Sep 15, 2022, at 4:01 AM, Andrew Haley wrote: >> >> On 9/15/22 01:16, Kim Barrett wrote: >>> I*think* it can be done as a sequence of commits to revert prior commits, >>> followed by a couple of newly developed commits to reinstate features like >>> support for relaxed atomics. >> >> I expect so. > > The reversions are indeed relatively straightforward. There is one set of > conflicts for one of the commits, due to unrelated nearby changes in one file, > but that's relatively easy to deal with. > > But... > > Digging into this deeper, I've run across some problems. Of course, it's > about memory_order_conservative. No surprise. Let's start with what we know with a high degree of confidence: the assembly code in atomic_linux_aarch64.S is correct. > I know about the discussion here: > https://mail.openjdk.org/pipermail/hotspot-dev/2019-November/039912.html > (long discussion about implementing memory_order_conservative) > > which refers to this: > https://patchwork.kernel.org/patch/3575821/ > This is the reference leading to the pre-JDK-8261027 implementation. > > To summarize, for memory_order_conservative with ll/sc-style atomics > - For cmpxchg, use I think you found a bug in the pre-LSE code. aarch64_atomic_cmpxchg_8_default_impl: #ifdef __ARM_FEATURE_ATOMICS mov x3, x1 casal x3, x2, [x0] #else dmb ish prfm pstl1strm, [x0] 0: ldxr x3, [x0] cmp x3, x1 b.ne 1f stxr w8, x2, [x0] cbnz w8, 0b #endif 1: dmb ish mov x0, x3 ret This should be LDAXR;STLXR. CASAL is correct. > - For other ops, use > That's what we were requesting before JDK-8261027, via __atomic intrinsics. > But -moutline-atomics changed things so we were potentially using the > corresponding LSE atomic instead of the ll/sc-style. > > For now I'm only going to discuss the other ops, not cmpxchg. (cmpxchg is > it's own ball of ugliness, but I think I know how to deal with it.) > > 8261027 introduced support for using LSE atomics. There are some surprises: > > (A) The default (ll/sc) implementations (atomic_linux_aarch64.S) are all > "acq-rel" rather than "release". Good. > (B) The generated LSE stubs for "add" variants are "acq-rel" rather than > "release". Good. > Meanwhile, the generated stubs for "xchg" variants are "release". Really? I see void gen_swpal_entry(Assembler::operand_size size) { Register prev = r2, addr = c_rarg0, incr = c_rarg1; __ swpal(size, incr, prev, addr); __ membar(Assembler::StoreStore|Assembler::StoreLoad); That's acquire/release. What are you looking at? > (A) seems like a mistake. The inconsistency in (B) also seems like a > mistake. The question of which one is correct takes us to the next change. > > 8261649 is intended to optimize the use of LSE atomics, though the bug only > talks about cmpxchg. (It also fixes a problem with the timing of stub > generation vs possible use, but that doesn't matter for this discussion.) > > There is a big comment in front of the new stub generation code, talking about > how a acq-rel operation doesn't need a preceeding fence when using LSE > atomics. I can see how that's very useful for cmpxchg. (And the comment > mostly discusses cmpxchg.) But I'm not certain of it's relevance for other > operations. It's the same for all ops. None of them need a preceding fence. > Can non-cmpxchg operations still be implemented as when > (potentially) using LSE instructions? It seems like an argument similar to > the one for ll/sc could be made. If so, then we can use __atomic (and > -moutline-atomics) to easily implement them. If not, that's a somewhat > unpleasant semantic change going from ll/sc to LSE. (And probably breaks the > current bsd_aarch64 implementation.) It also gives us a couple of choices for > implementation: > > (C) Use with the op generated using __atomic (and using > -moutline-atomics), in case we end up using LSE. Yes, for conservative, whether we're using LSE or not. > This accepts the unneeded > acquire if using ll/sc as a necessary evil for simplicity of implementation. > (It also matches the current code, though generated differently.) > > (D) Avoid -moutline-atomics, doing our own use-LSE dispatch to either ll/sc or > LSE implementations. No, please use GCC -moutline-atomics. > There are several ways to do this, including the approach taken by > the current code. > > So do we really need when using LSE istructions? For conservative, yes. Just use the C++ sequentially-consistent op, followed by a full fence. > Or can we continue to use ? No. > I think there are also some problems with the big block comment for > the stub generation. For example, I can't make sense of the > model-based test description. For one thing, it talks about the > resulting X3 and X4, but those don't appear in the test code. They do: W3 is the bottom half of X3. > (I'm also not getting the point about a lack of > barrier-ordered-after, but maybe I'm just confused.) The lack of barrier-ordered-after is why we need a fence after all ops for conservative. (In fact we don't: all Arm hardware in existence works without the trailing fence. And probably always will. But the Arm spec allows reordering, even though available hardware doesn't. This is annoying, but that's life.) ------------------------------------------------------------------------ In summary, this is what you should do: Use GCC's sequentially-consistent atomics, plus a trailing full fence, for conservative. This includes add, cmpxchg, etc. Use GCC atomics without a trailing fence for relaxed, etc. Everything except conservative. ------------------------------------------------------------------------ That should be all. Thanks, -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph-open at littlepinkcloud.com Tue Sep 20 11:18:03 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 20 Sep 2022 12:18:03 +0100 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: <4a767b25-1539-183a-e4cd-4852f633e77d@littlepinkcloud.com> References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> <416c7338-2dff-7997-c95f-c9e1c74de180@littlepinkcloud.com> <0958C022-824B-4492-9D82-393F64965D5E@oracle.com> <246e397f-2f10-84fa-19d7-65b1472606e9@littlepinkcloud.com> <4a767b25-1539-183a-e4cd-4852f633e77d@littlepinkcloud.com> Message-ID: On 9/20/22 12:15, Andrew Haley wrote: > Let's start with what we know with a high degree of confidence: the > assembly code in atomic_linux_aarch64.S is correct. Err, not. :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuefe at openjdk.org Tue Sep 20 12:01:40 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 20 Sep 2022 12:01:40 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs In-Reply-To: <9VgbjebYEEY_jtssZ864TYse-j67HCJLwPEP4-EGU6o=.144df90a-f723-4a6f-80ef-27ce5a7d95a9@github.com> References: <9VgbjebYEEY_jtssZ864TYse-j67HCJLwPEP4-EGU6o=.144df90a-f723-4a6f-80ef-27ce5a7d95a9@github.com> Message-ID: On Tue, 20 Sep 2022 10:40:48 GMT, David Holmes wrote: > The original issue we targeted on 32-bit was a kernel problem. Is it even possible to have an address past TASK_SIZE on 32-bit? I think yes. TASK_SIZE seems to ultimately be PAGE_OFFSET, which on 32-bit is a high address like 0xB0000000 or so. ------------- PR: https://git.openjdk.org/jdk/pull/10340 From yadongwang at openjdk.org Tue Sep 20 12:06:41 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Tue, 20 Sep 2022 12:06:41 GMT Subject: RFR: 8293781: RISC-V: Clarify types of calls [v5] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 02:55:40 GMT, Yanhong Zhu wrote: >> RISCV64 OpenJDK uses different types of calls in generated calls. It should be clarified what they are. And the PR also cleans up some out-of-date comments. >> >> HotSpot tier1 tests passed. > > Yanhong Zhu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8293781 > - add relocInfo comments for far_call/far_jump > - modify comments > - fix a typo > - Clarify types of calls lgtm(not a reviewer) ------------- Marked as reviewed by yadongwang (Author). PR: https://git.openjdk.org/jdk/pull/10311 From yzhu at openjdk.org Tue Sep 20 12:16:47 2022 From: yzhu at openjdk.org (Yanhong Zhu) Date: Tue, 20 Sep 2022 12:16:47 GMT Subject: Integrated: 8293781: RISC-V: Clarify types of calls In-Reply-To: References: Message-ID: On Fri, 16 Sep 2022 13:52:58 GMT, Yanhong Zhu wrote: > RISCV64 OpenJDK uses different types of calls in generated calls. It should be clarified what they are. And the PR also cleans up some out-of-date comments. > > HotSpot tier1 tests passed. This pull request has now been integrated. Changeset: 84ee1a29 Author: Yanhong Zhu Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/84ee1a291cb38e1500dc1529c2aa79e7a195502c Stats: 93 lines in 4 files changed: 81 ins; 8 del; 4 mod 8293781: RISC-V: Clarify types of calls Reviewed-by: fjiang, fyang, yadongwang ------------- PR: https://git.openjdk.org/jdk/pull/10311 From asemenyuk at openjdk.org Tue Sep 20 13:05:18 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 20 Sep 2022 13:05:18 GMT Subject: RFR: 8293595: tstrings::any() is missing an overload In-Reply-To: References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com> <-LTFLRniQjzc1wQ9k3NHN2ZTVM07DV6PEf9IY9Ed6vM=.cdcdcc64-52ef-4363-b087-3efcca94c840@github.com> Message-ID: On Mon, 19 Sep 2022 20:46:12 GMT, Julian Waters wrote: >> I'm the author of these comments and basically the entire source file. >> >> You are right, it will work without the additional overloads. However the null pointers will be ignored (tested with G++ 7.4.0), but this is minor, probably implementation-specific and can be ignored. > > Strange, on my end gcc doesn't mind NULL being passed (though this may be due to a different gcc version being used), guess it's probably implementation specific like you mentioned Correct, it allows NULL to be passed. G++ 7.4.0 ignores it and doesn't append anything to the buffer, while msvc back when this code was created appended a "null" string to the buffer. ------------- PR: https://git.openjdk.org/jdk/pull/10231 From jwaters at openjdk.org Tue Sep 20 13:08:15 2022 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 20 Sep 2022 13:08:15 GMT Subject: Integrated: 8293595: tstrings::any() is missing an overload In-Reply-To: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com> References: <0tqqa1avFzs-MV0Veo0QnpBG1-0b1djoKap5D_vF62U=.4fed5b83-dfc2-4661-a031-f3d1b64eeca9@github.com> Message-ID: On Fri, 9 Sep 2022 13:38:14 GMT, Julian Waters wrote: > tstrings::any() has an overload for std::wstring (if required) but is missing the corresponding operator overload for std::string, leaving only the templated one as a fallback, which will expand into a std::wostringstream << std::string operation. This isn't particularly safe on Windows, considering that JDK-8292008 and JDK-8247283 have been recently merged, and can sporadically cause build failures. This change simply adds the missing overload with the appropriate format handling that jpackage expects from std::string. Also contains minor name changes to fit the rest of the parameter names in the other overloads. This pull request has now been integrated. Changeset: bb422f5c Author: Julian Waters Committer: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/bb422f5c14745bf29bc2cb741f819a17c8400543 Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod 8293595: tstrings::any() is missing an overload Reviewed-by: asemenyuk, almatvee ------------- PR: https://git.openjdk.org/jdk/pull/10231 From ChrisPhi at LGonQn.Org Tue Sep 20 14:27:53 2022 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Tue, 20 Sep 2022 10:27:53 -0400 Subject: =?UTF-8?Q?Re=3a_CFV=3a_New_HotSpot_Group_Member=3a_Roberto_Casta?= =?UTF-8?Q?=c3=b1eda_Lozano?= In-Reply-To: References: <6bfdd79d-0308-fee4-83fe-ed95f8d7b4a8@oracle.com> Message-ID: <72111d2c-b486-362b-844f-f4dfe67031aa@LGonQn.Org> Hi Vote: yes Cheers! Chris On 15/09/2022 3:54 am, Vladimir Kozlov wrote: >> I hereby nominate Roberto Casta?eda Lozano [1] to Membership in the >> HotSpot Group. >> >> Roberto is member of HotSpot compiler group at Oracle. Since 2020, he >> contributed >> a lot of changes to OpenJDK. He made very important updates and >> improvements to >> C2 JIT compiler IR graph visualizer (IGV) which helps C2 support a lot. >> >> Votes are due by Wednesday, September 28, 2022 at 10h50 PST. >> >> Only current Members of the HotSpot Group [2] are eligible >> to vote on this nomination.? Votes must be cast in the open by >> replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [3]. >> >> Thanks, >> Vladimir Kozlov >> >> [1] https://openjdk.org/census#rcastanedalo >> [2] https://openjdk.java.net/census#hotspot >> [3] https://openjdk.org/bylaws#member-vote From ChrisPhi at LGonQn.Org Tue Sep 20 14:28:59 2022 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Tue, 20 Sep 2022 10:28:59 -0400 Subject: CFV: New HotSpot Group Member: Tobias Holenstein In-Reply-To: <5d8058fd-b289-b423-f8ab-8f810dd2777d@oracle.com> References: <5d8058fd-b289-b423-f8ab-8f810dd2777d@oracle.com> Message-ID: <144fd50a-84e5-3a8b-eec9-2b1ab07884c5@LGonQn.Org> Hi Vote: yes Cheers! Chris On 15/09/2022 4:25 am, Vladimir Kozlov wrote: >> I hereby nominate Tobias Holenstein [1] to Membership in the HotSpot >> Group. >> >> Tobias is member of HotSpot compiler group at Oracle. Since 2021, he >> contributed >> 26 changes to HotSpot. Recently he is working on IR graph visualizer >> (IGV) >> improvements which helps C2 support a lot. >> >> Votes are due by Wednesday, September 28, 2022 at 11h25 PST. >> >> Only current Members of the HotSpot Group [2] are eligible >> to vote on this nomination.? Votes must be cast in the open by >> replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [3]. >> >> Thanks, >> Vladimir Kozlov >> >> PS: He is second Tobias in our group (Tobias Hartmann is first). >> >> [1] https://openjdk.org/census#tholenstein >> [2] https://openjdk.java.net/census#hotspot >> [3] https://openjdk.org/bylaws#member-vote From jsjolen at openjdk.org Tue Sep 20 14:45:43 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 20 Sep 2022 14:45:43 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 15:19:34 GMT, Thomas Stuefe wrote: > Arguments.cpp has several size parsing functions which would be useful in other areas of the hotspot, e.g. in NMT. > > It would be nice to have them factored out into utilities, to reuse the code and to unify memory size handling. Gtests would be good too. > > To simplify reviews, I split the patch into two commits. > > The first commit (https://github.com/openjdk/jdk/pull/10252/commits/700e77e8d1469a2fc3d6611072c4b07aa34ab8e6) contains the unchanged code move without functional changes. > > The second commit (https://github.com/openjdk/jdk/pull/10252/commits/76b4f6f30cc316fd966da60ff6601f54eeb394bf) contains the functional changes I did, as well as the new gtest. Seems like you can remove `#include "metaprogramming/enableIf.hpp"` from arguments.cpp test/hotspot/gtest/utilities/test_parse_memory_size.cpp line 41: > 39: > 40: #define LOG(s, ...) LOG_HERE(s, __VA_ARGS__) > 41: //#define LOG(s, ...) Forgot to remove this? ------------- PR: https://git.openjdk.org/jdk/pull/10252 From stuefe at openjdk.org Tue Sep 20 15:13:44 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 20 Sep 2022 15:13:44 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 14:33:45 GMT, Johan Sj?len wrote: >> Arguments.cpp has several size parsing functions which would be useful in other areas of the hotspot, e.g. in NMT. >> >> It would be nice to have them factored out into utilities, to reuse the code and to unify memory size handling. Gtests would be good too. >> >> To simplify reviews, I split the patch into two commits. >> >> The first commit (https://github.com/openjdk/jdk/pull/10252/commits/700e77e8d1469a2fc3d6611072c4b07aa34ab8e6) contains the unchanged code move without functional changes. >> >> The second commit (https://github.com/openjdk/jdk/pull/10252/commits/76b4f6f30cc316fd966da60ff6601f54eeb394bf) contains the functional changes I did, as well as the new gtest. > > test/hotspot/gtest/utilities/test_parse_memory_size.cpp line 41: > >> 39: >> 40: #define LOG(s, ...) LOG_HERE(s, __VA_ARGS__) >> 41: //#define LOG(s, ...) > > Forgot to remove this? :-) Yes, you are right. ------------- PR: https://git.openjdk.org/jdk/pull/10252 From stuefe at openjdk.org Tue Sep 20 15:23:58 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 20 Sep 2022 15:23:58 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: References: Message-ID: > Arguments.cpp has several size parsing functions which would be useful in other areas of the hotspot, e.g. in NMT. > > It would be nice to have them factored out into utilities, to reuse the code and to unify memory size handling. Gtests would be good too. > > To simplify reviews, I split the patch into two commits. > > The first commit (https://github.com/openjdk/jdk/pull/10252/commits/700e77e8d1469a2fc3d6611072c4b07aa34ab8e6) contains the unchanged code move without functional changes. > > The second commit (https://github.com/openjdk/jdk/pull/10252/commits/76b4f6f30cc316fd966da60ff6601f54eeb394bf) contains the functional changes I did, as well as the new gtest. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: feedback johan ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10252/files - new: https://git.openjdk.org/jdk/pull/10252/files/2fe22e1e..a5e6b6f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10252&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10252&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10252.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10252/head:pull/10252 PR: https://git.openjdk.org/jdk/pull/10252 From iklam at openjdk.org Tue Sep 20 17:46:00 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 20 Sep 2022 17:46:00 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v10] In-Reply-To: References: Message-ID: > Current in gdb, you can print information about a class or method with something like > > > call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) > call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) > > > However, it's difficult to find a class or method by its name and print out its contents. > > This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. > > - `findclass()`: class name only > - `findmethod()`: class name and method name > - `findmethod2()`: class name and method name/signature > > I also cleaned up `BytecodeTracer` to remove unnecessary complexity. > > Here are some examples: > > > (gdb) call findclass("java/lang/Object", 0) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > > (gdb) call findclass("java/lang/Object", 1) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000658 : ()V > 0x00007fffb40010f0 finalize : ()V > 0x00007fffb4000f00 wait0 : (J)V > 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z > 0x00007fffb4000aa0 toString : ()Ljava/lang/String; > 0x00007fffb40007f0 hashCode : ()I > 0x00007fffb4000720 getClass : ()Ljava/lang/Class; > 0x00007fffb40009a0 clone : ()Ljava/lang/Object; > 0x00007fffb4000b50 notify : ()V > 0x00007fffb4000c20 notifyAll : ()V > 0x00007fffb4000e50 wait : (J)V > 0x00007fffb4001028 wait : (JI)V > 0x00007fffb4000d08 wait : ()V > > (gdb) call findclass("*ClassLoader", 0) > [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [....] > > (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000d08 wait : ()V > 0x00007fffb4000ce8 0 fast_aload_0 > 0x00007fffb4000ce9 1 lconst_0 > 0x00007fffb4000cea 2 invokevirtual 38 > 0x00007fffb4000ced 5 return Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Allow ClassPrinter to also print to streams other than tty ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9957/files - new: https://git.openjdk.org/jdk/pull/9957/files/adb390e3..5b90b7d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=08-09 Stats: 21 lines in 3 files changed: 1 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/9957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9957/head:pull/9957 PR: https://git.openjdk.org/jdk/pull/9957 From duke at openjdk.org Tue Sep 20 18:07:17 2022 From: duke at openjdk.org (Ashutosh Mehra) Date: Tue, 20 Sep 2022 18:07:17 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> Message-ID: On Mon, 19 Sep 2022 17:11:15 GMT, Roman Kennke wrote: >> Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode. >> >> Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier. >> The Access API is same as in ZGC [1], [2] >> >> [1] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/oops/oop.inline.hpp#L215 >> [2] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/classfile/javaClasses.inline.hpp#L286 >> >> Test with fastdebug build: >> >> - [x] hotspot_loom >> - [x] jdk_loom >> - [x] hotspot_loom in Shenandoah IU mode >> - [x] jdk_loom in Shenandoah IU mode >> - [x] hotspot_loom in Shenandoah IU + aggressive >> - [x] jdk_loom in Shenandoah IU + aggressive >> >> Signed-off-by: Ashutosh Mehra > > Oh sorry, I've been deep in some other stuff. Thanks for reminding me. > The change looks good. > Does this mean we can now remove some of the GC specific paths in stack-chunk handling code? @rkennke @fisk thank you for reviewing the pr. ------------- PR: https://git.openjdk.org/jdk/pull/10089 From vladimir.x.ivanov at oracle.com Tue Sep 20 18:14:19 2022 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 20 Sep 2022 11:14:19 -0700 Subject: Massive slowdown in regex processing while GC log fills with ICBufferFull messages In-Reply-To: <330121A3-56DE-4C2E-9178-244150A71DA4@kungfoocoder.org> References: <48755CD4-2A8B-471B-865F-FACE080213A9@kungfoocoder.org> <0a11a64d-2449-0eb4-fee4-a1e24b1b944c@oracle.com> <2640b7df-d4d3-979c-9c96-2a02fd7fe98a@oracle.com> <330121A3-56DE-4C2E-9178-244150A71DA4@kungfoocoder.org> Message-ID: <43792df7-2859-f737-d062-4313546be036@oracle.com> Hi Paul, What you are seeing may be related to unwanted nmethod sweeper activity. When space in code cache becomes tight, sweeper may switch into aggressive mode and start invalidating nmethods triggering massive code recompilation. It will trigger repeated inline cache invalidations and eventually lead to ICBufferFull-related GCs. How to diagnose: - -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:-DisplayVMOutput -XX:LogFile=hotspot.log -XX:+PrintCompilation Things to watch for in the output: (1) continuous and repeated massive "made not entrant"/"made zombie" events coming from the sweeper thread; (2) multiple "made not compilable" events caused by continuous recompilation: made not compilable on level 4 ... decompile_count > PerMethodRecompilationCutoff Also, sample code cache utilization using jcmd before and after the problem occurs: $ jcmd Compiler.codecache : CodeHeap 'non-profiled nmethods': size=120028Kb used=9159Kb max_used=9159Kb free=110868Kb bounds [0x0000000018215000, 0x0000000018b15000, 0x000000001f74c000] CodeHeap 'profiled nmethods': size=120028Kb used=23937Kb max_used=23937Kb free=96090Kb bounds [0x0000000010cde000, 0x000000001244e000, 0x0000000018215000] CodeHeap 'non-nmethods': size=5704Kb used=1473Kb max_used=1514Kb free=4231Kb bounds [0x000000001074c000, 0x00000000109bc000, 0x0000000010cde000] total_blobs=10880 nmethods=10045 adapters=746 compilation: enabled stopped_count=0, restarted_count=0 full_count=0 I see you specify -XX:ReservedCodeCacheSize=150M. Try to increate it to reduce sweeper activity. Best regards, Vladimir Ivanov On 7/31/22 23:28, Paul Wagland wrote: > Hi David, > > Thanks for creating that issue! > > As to when we first saw it, we first saw this in 17.0.1, however that was also the first version that we widely deployed, prior to that we were using OpenJ9 Java 11. However, when moving to Java 17, we also moved back to hotspot as well. > > Cheers, > Paul > >> On 1 Aug 2022, at 03:16, David Holmes wrote: >> >> https://bugs.openjdk.org/browse/JDK-8291596 >> >> David >> >> On 1/08/2022 10:58 am, David Holmes wrote: >>> Hi Paul, >>> Redirecting to hotspot-dev as this issue is not likely to get much visibility on jdk-updates-dev. >>> Probably worth filing an issue in bugs.openjdk.org if you can. >>> Cheers, >>> David >>> On 1/08/2022 10:37 am, Paul Wagland wrote: >>>> Hi all, >>>> >>>> We have been running into a problem with Java 17.0.1, 17.0.2, and now 17.0.3. >>>> >>>> # java --version >>>> openjdk 17.0.3 2022-04-19 >>>> OpenJDK Runtime Environment Temurin-17.0.3+7 (build 17.0.3+7) >>>> OpenJDK 64-Bit Server VM Temurin-17.0.3+7 (build 17.0.3+7, mixed mode, sharing) >>>> >>>> >>>> The issue that we are seeing is very similar in behaviour to https://bugs.openjdk.org/browse/JDK-8277212 , with a couple of notable exceptions: >>>> 1. We are seeing this issue in 17.0.3, whereas JDK-8277212 was resolved in either 17.0.2 or 17.0.3-oracle. >>>> 2. We are using G1GC, not ZGC >>>> >>>> Unfortunately, we don?t know how to reproduce this issue, we are seeing it happen about once a week across our fleet. We have about 300 instances of Java running various different workloads. >>>> >>>> What happens is that on a machine where this occurs, after a period of time we see CPU usage suddenly spike, and the gc logs suddenly start getting flooded with ICBufferFull messages, at the rate of about 430 a second. When doing thread dumps to see what is happening at that time, we find most threads end up very deep in a regex processing stack, unfortunately we have one of these fairly central to the product, so this ends up affecting most threads. It seems that almost everything that isn?t thread parsing operates at, or near to, full speed. This is one of the reasons that this feels similar to JDK-8277212, since that was mashing the VTABLES, and because of the way that regexes work, they would appear to use a lot of VTABLE lookups, so any slowdown in that area, is likely to affect them greatly. Note that this is pure supposition, and I would love to know if there is any way if we can prove, or disprove this, either via testing, or additional logging. >>>> >>>> Unfortunately, as mentioned above, we are not able to reproduce this in our test environments, and we are only seeing this in customer environments, and then not with any clearly identifiable cause. We have seen the issue about a dozen times, over 17.0.1, 17.0.2, and recently, 17.0.3. >>>> >>>> We have done some performance testing, and during the slow-down we get, for our regex processing test: >>>> >>>> 10 iterations of testString 1 took 10700ms (1070004460ns/match) (matched=false) >>>> 10 iterations of testString 2 took 8965ms (896560879ns/match) (matched=true) >>>> >>>> Normal timings looks like: >>>> 18503 iterations of testString 1 took 1000ms (54047ns/match) (matched=false) >>>> 40954 iterations of testString 2 took 1000ms (24417ns/match) (matched=true) >>>> >>>> So that represents a slowdown of roughly 20,000 times! >>>> >>>> We have another test that is mostly map lookup heavy, and during the high CPU it has: >>>> doMapOperations:2:31076ns >>>> doMapOperations:3:16951ns >>>> doMapOperations:4:14192ns >>>> >>>> While normally it has: >>>> doMapOperations:2:27392ns >>>> doMapOperations:3:7987ns >>>> doMapOperations:4:6079ns >>>> >>>> So a slowdown of maybe a factor of 2, which is perfectly explainable by the very high CPU/system load. >>>> >>>> Our startup arguments are: >>>> >>>> JVM startup arguments: >>>> -javaagent:/opt/jmx-exporter/jmx-exporter.jar=9404:/opt/jmx-exporter/config.yaml >>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>> --add-opens=java.base/java.io =ALL-UNNAMED >>>> --add-opens=java.base/java.util=ALL-UNNAMED >>>> --add-opens=java.base/java.util.concurrent=ALL-UNNAMED >>>> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED >>>> -Dnop >>>> -Djava.security.egd=file:/dev/./urandom >>>> -XX:+HeapDumpOnOutOfMemoryError >>>> -XX:HeapDumpPath=/opt/?/logs >>>> -Djava.awt.headless=true >>>> -XX:+PrintFlagsFinal >>>> -DRP_CONTEXTPATH= >>>> -DRP_UNPACKWAR=true >>>> -XX:FlightRecorderOptions=stackdepth=256 >>>> -XX:+UnlockDiagnosticVMOptions >>>> -XX:+DebugNonSafepoints >>>> -Xlog:gc*,safepoint=info:file=/opt/?/logs/verbosegc.log:time,uptimemillis:filecount=10,filesize=50M >>>> -Xlog:class*=info:file=/opt/?/logs/classload.log:time,uptimemillis,level,tags:filecount=10,filesize=50M >>>> -XX:+UseG1GC >>>> -XX:G1PeriodicGCInterval=10000 >>>> -XX:+ParallelRefProcEnabled >>>> -XX:MaxDirectMemorySize=25M >>>> -XX:MaxMetaspaceSize=300M >>>> -XX:MetaspaceSize=100M >>>> -Xss1024K >>>> -XX:ReservedCodeCacheSize=150M >>>> -XX:+SegmentedCodeCache >>>> -Xmx862m >>>> -XX:MaxMetaspaceFreeRatio=20 >>>> -XX:MinMetaspaceFreeRatio=5 >>>> -XX:MaxHeapFreeRatio=40 >>>> -XX:MinHeapFreeRatio=5 >>>> -Djdk.nio.maxCachedBufferSize=8192 >>>> -XX:SoftMaxHeapSize=646m >>>> -Dlog4j2.disableJmx=true >>>> -Djdk.tls.ephemeralDHKeySize=2048 >>>> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources >>>> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 >>>> -Dignore.endorsed.dirs= >>>> -Dcatalina.base=/opt/?/server1 >>>> -Dcatalina.home=/opt/?/tomcat >>>> -Djava.io.tmpdir=/opt/?/temp >>>> >>>> Can anyone think of anything that we can do to ameliorate this problem, apart from not using regexes, which we are moving towards, but I think that they are the victim here, not the cause of the problem, since in normal use, they are ?fast enough?. >>>> >>>> If there is any information that I can add, please let me know! >>>> >>>> Cheers, >>>> Paul > From duke at openjdk.org Tue Sep 20 18:33:43 2022 From: duke at openjdk.org (Ashutosh Mehra) Date: Tue, 20 Sep 2022 18:33:43 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> Message-ID: On Mon, 19 Sep 2022 17:11:15 GMT, Roman Kennke wrote: > Does this mean we can now remove some of the GC specific paths in stack-chunk handling code? I guess you are referring to the checks for `UseShenandoahGC` in the continuations code. I am not sure we can get rid of it. I will need to dig deeper for that. ------------- PR: https://git.openjdk.org/jdk/pull/10089 From kvn at openjdk.org Tue Sep 20 19:48:46 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 20 Sep 2022 19:48:46 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v7] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 17:31:46 GMT, Quan Anh Mai wrote: >> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: >> >> vptest xmm0, xmm1 >> jb if_true >> if_false: >> >> instead of: >> >> vptest xmm0, xmm1 >> setb r10 >> movzbl r10 >> testl r10 >> jne if_true >> if_false: >> >> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: >> >> Before After >> Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% >> >> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > fix merge problems Looks reasonable. Please, merge with latest JDK sources and I will test it. ------------- PR: https://git.openjdk.org/jdk/pull/9855 From jonathanjoo at google.com Tue Sep 20 20:26:54 2022 From: jonathanjoo at google.com (Jonathan Joo) Date: Tue, 20 Sep 2022 13:26:54 -0700 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: <8a41712c80b8925fa5d3c4ba33a72c50bb5fb8f5.camel@redhat.com> References: <8a41712c80b8925fa5d3c4ba33a72c50bb5fb8f5.camel@redhat.com> Message-ID: Yes, Severin's summary sounds correct to me. The only additional thing is that X is tuned for reduced waste and/or preventing the entire container from going OOM. I also realized I had missed the discussion of this topic from hotspot-gc-dev - I am working through the questions there and hope to send out an update email by EOD. Thank you! ~ Jonathan On Mon, Sep 19, 2022 at 2:37 AM Severin Gehwolf wrote: > On Fri, 2022-09-16 at 12:41 -0400, Ashutosh Mehra wrote: > > Hi Severin, > > > > > So in that context the container limit would be detected from the > > > cgroups filesystem. > > > > That's correct. My question was actually targeting the mechanism used > > to achieve A, not from within the JVM, but when deploying the > > containers. > > OK, thanks. That aspect should be a non-goal of this proposal, IMO. > > Thanks, > Severin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sspitsyn at openjdk.org Tue Sep 20 21:09:41 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Sep 2022 21:09:41 GMT Subject: RFR: 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume [v2] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Tue, 20 Sep 2022 00:36:38 GMT, Leonid Mesnik wrote: >> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. >> Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. >> >> Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > revert changes src/hotspot/share/prims/jvmtiEnvBase.cpp line 1669: > 1667: if (java_thread->is_suspended()) { > 1668: if (!JvmtiSuspendControl::resume(java_thread)) { > 1669: return JVMTI_ERROR_THREAD_NOT_SUSPENDED; This is right. ------------- PR: https://git.openjdk.org/jdk/pull/10351 From sspitsyn at openjdk.org Tue Sep 20 21:15:07 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Sep 2022 21:15:07 GMT Subject: RFR: 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume [v2] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Tue, 20 Sep 2022 00:36:38 GMT, Leonid Mesnik wrote: >> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. >> Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. >> >> Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > revert changes test/hotspot/jtreg/testlibrary/jvmti/libJvmtiUtils.cpp line 84: > 82: } > 83: check_jvmti_status(jni, err, "Error during ResumeThread"); > 84: } Would it better to return the jvmtiError status as an int, so it can be checked at the java level? In fact, it is not good that the `JVMTI_ERROR_THREAD_NOT_ALIVE`, `JVMTI_ERROR_THREAD_SUSPENDED` and `JVMTI_ERROR_THREAD_NOT_SUSPENDED` are always ignored. test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java line 136: > 134: static final String EQUALS_NOT_INTERRUPTED = "Statuses of threads are equal: not interrupted"; > 135: > 136: static final int MAX_CASE = 1; This constant is not used anymore. Should it be deleted? ------------- PR: https://git.openjdk.org/jdk/pull/10351 From sspitsyn at openjdk.org Tue Sep 20 21:26:47 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Sep 2022 21:26:47 GMT Subject: RFR: 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume [v2] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Tue, 20 Sep 2022 00:36:38 GMT, Leonid Mesnik wrote: >> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. >> Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. >> >> Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > revert changes Hi Leonid, This looks good in general. I've added a couple of comments though. The PR title does not match the bug title: com/sun/jdi vs hotspot/jtreg. Thanks, Serguei ------------- PR: https://git.openjdk.org/jdk/pull/10351 From cjplummer at openjdk.org Tue Sep 20 21:43:34 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Sep 2022 21:43:34 GMT Subject: RFR: 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume [v2] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Tue, 20 Sep 2022 00:36:38 GMT, Leonid Mesnik wrote: >> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. >> Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. >> >> Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > revert changes > Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. As far as I know, this is the only test we have for ThreadReference.interrupt(). Also see [JDK-8282384](https://bugs.openjdk.org/browse/JDK-8282384), which points out that we have no test for ThreadReference.interrupt() of a virtual thread, and suggests modifying this test to support virtual threads. I actually attempted to do this, but ran into an issue with ThreadReference.resume() support for virtual threads, although I'm not sure what that issue was, and it may be fixed now. ------------- PR: https://git.openjdk.org/jdk/pull/10351 From cjplummer at openjdk.org Tue Sep 20 22:05:50 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Sep 2022 22:05:50 GMT Subject: RFR: 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume [v2] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Tue, 20 Sep 2022 21:11:30 GMT, Serguei Spitsyn wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> revert changes > > test/hotspot/jtreg/testlibrary/jvmti/libJvmtiUtils.cpp line 84: > >> 82: } >> 83: check_jvmti_status(jni, err, "Error during ResumeThread"); >> 84: } > > Would it better to return the jvmtiError status as an int, so it can be checked at the java level? > In fact, it is not good that the `JVMTI_ERROR_THREAD_NOT_ALIVE`, `JVMTI_ERROR_THREAD_SUSPENDED` and `JVMTI_ERROR_THREAD_NOT_SUSPENDED` are always ignored. I was going to ask something similar. Should the tests ever see these errors? If not, probably an exception should be thrown here. If they are ok in some situations, then the tests should be checking for them. ------------- PR: https://git.openjdk.org/jdk/pull/10351 From sspitsyn at openjdk.org Tue Sep 20 22:19:55 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Sep 2022 22:19:55 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 20:19:10 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed typo in VirtualThread.c > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 713: > >> 711: if (!jt->is_in_tmp_VTMS_transition()) { >> 712: jvf = check_and_skip_hidden_frames(jt, jvf); >> 713: } > > I think this comment needs some help. It's hard to match it up with what the code is doing. I think you are saying you want to avoid skipping hidden frames when in transition, although if that's the case, it's not clear to me why not skipping is ok. > > Also is skipping (or not skipping) ok regardless of the JvmtiEnvBase::is_cthread_with_continuation() result? Thank you for reviewing and the comment, Chris. I agree, this part and related comment is kind of obscure. I'll think how to make the comment better. In fact, all temporary VTMS transitions do temporary switch the `JavaThread` identity from virtual thread to carrier. There is no need to skip frames because there are no real carrier thread frames at the top. Moreover, any attempt to skip frames which are in transition works incorrectly and gives an empty stack. The check `JvmtiEnvBase::is_cthread_with_continuation()` is needed to make sure we have a deal with a continuation. There is no need to skip frames otherwise. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Tue Sep 20 22:38:47 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Sep 2022 22:38:47 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 20:22:54 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed typo in VirtualThread.c > > src/hotspot/share/prims/jvmtiExport.cpp line 1055: > >> 1053: if (JavaThread::current()->is_in_tmp_VTMS_transition()) { >> 1054: return false; >> 1055: } > > You mentioned this in the PR description. However, it's not clear to me why this is ok. Also, it should be commented. > > Same thing for changes in JvmtiExport::post_class_load() and JvmtiExport::post_class_prepare(). I initially wanted to consult on this with Alan. It feels like it'd be better if I did it before posting this PR. We have just two possible approaches here. The best approach is to move any class loading out of the temporary transition code path. Then we already have the relevant asserts in place. However, this is not that easy to solve. Alan already suggested a couple of patches which I've tested but new places with class loads were discovered. Another approach is to skip all ClassLoad, ClassPrepare and CFLH events in context of temporary transitions. It is hard to estimate how acceptable it is. At least, I've not found any failing tests because of it which means it most likely does not impact the debugger. My current suggestion is to file a bug and try to address it later as Alan may need more time for analysis. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Tue Sep 20 22:45:04 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Sep 2022 22:45:04 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 20:41:50 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed typo in VirtualThread.c > > src/hotspot/share/runtime/javaThread.cpp line 1174: > >> 1172: #if INCLUDE_JVMTI >> 1173: // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks. >> 1174: assert(!is_in_non_tmp_VTMS_transition(), "no suspend allowed in VTMS transition"); > > IMHO, a non tmp VTMS transition should be considered a type of VTMS transition, so the assert check here does not really match the assert text. Also see my related comments below on naming and use of these flags and APIs. Thanks. Accepted. > src/hotspot/share/runtime/javaThread.hpp line 650: > >> 648: void set_is_in_VTMS_transition(bool val); >> 649: bool is_in_tmp_VTMS_transition() const { return _is_in_tmp_VTMS_transition; } >> 650: void toggle_is_in_tmp_VTMS_transition() { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; }; > > The naming of the flags does not match up with the naming of the APIs, which is confusing. An API named is_in_VTMS_transition() should return _is_in_VTMS_transition. I think part of problem is that _is_in_VTMS_transition is not a superset of _is_in_tmp_VTMS_transition. The flags are never both set true, although both can be false. Maybe this should be changed to make it an invariant that if _is_in_tmp_VTMS_transit is true, then _is_in_tmp_VTMS_transition is true. I agree, this naming is not good. However, I was reluctant to do required renaming because it can potentially impact many spots and make review harder. Let me think a little bit more on this. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From kvn at openjdk.org Tue Sep 20 23:20:42 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 20 Sep 2022 23:20:42 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments I still got failures in tier1. All JVMCI tests filed with runs on AMD you with: jdk.vm.ci.common.JVMCIError: Missing CPU feature constants: [F16C] at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIBackendFactory.convertFeatures(HotSpotJVMCIBackendFactory.java:79) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory.computeFeatures(AMD64HotSpotJVMCIBackendFactory.java:53) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory.createTarget(AMD64HotSpotJVMCIBackendFactory.java:74) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory.createJVMCIBackend(AMD64HotSpotJVMCIBackendFactory.java:109) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.(HotSpotJVMCIRuntime.java:587) at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.runtime(HotSpotJVMCIRuntime.java:179) at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.initializeRuntime(Native Method) at jdk.internal.vm.ci/jdk.vm.ci.runtime.JVMCI.getRuntime(JVMCI.java:65) And `jdk/test/whitebox/CPUInfoTest.java` test failed with: ----------System.err:(13/810)---------- java.lang.RuntimeException: not all features are known: expected true, was false at jdk.test.lib.Asserts.fail(Asserts.java:594) at jdk.test.lib.Asserts.assertTrue(Asserts.java:486) at CPUInfoTest.main(CPUInfoTest.java:92) ------------- PR: https://git.openjdk.org/jdk/pull/9781 From kvn at openjdk.org Tue Sep 20 23:36:35 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 20 Sep 2022 23:36:35 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Looking on `cpuinfo` on this machines I do see `f16c`. Here is additional output from `jdk/test/whitebox/CPUInfoTest.java`: WB.getCPUFeatures(): "(12 cores per cpu, 2 threads per core) family 25 model 1 stepping 1 microcode 0x1000065, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, hv, rdtscp, rdpid, f16c" CPUInfo.getAdditionalCPUInfo(): "(12 cores per cpu, 2 threads per core) family 25 model 1 stepping 1 microcode 0x1000065" CPUInfo.getFeatures(): [cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4a, sse4.1, sse4.2, popcnt, lzcnt, tsc, avx, avx2, aes, erms, clmul, bmi1, bmi2, adx, sha, fma, vzeroupper, clflush, clflushopt, hv, rdtscp, rdpid, f16c] Well-known CPU features: [avx512bw, avx512pf, avx512_vbmi, avx2, rdpid, clflush, avx512cd, avx512_vbmi2, aes, 3dnowpref, avx512_vpopcntdq, avx512f, sha, avx512_vnni, avx512_vpclmulqdq, avx, erms, fsrm, sse4a, mmx, gfni, lzcnt, clmul, sse, avx512_vaes, avx512dq, fma, rtm, vzeroupper, cx8, ht, tsc, tscinv, clwb, tscinvbit, cmov, clflushopt, rdtscp, hv, sse2, sse3, avx512er, avx512vl, sse4.1, sse4.2, bmi1, bmi2, adx, avx512_bitalg, popcnt, fxsr, ssse3] Here is test location: `test/lib-test/jdk/test/whitebox/CPUInfoTest.java` I think you need to add `f16c` to it. I am still not sure why JVMCI tests failed. May be JVMCI also have a list of CPU features you need to update. I also don't see GitHub Action testing on your branch. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From sviswanathan at openjdk.org Tue Sep 20 23:39:21 2022 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 20 Sep 2022 23:39:21 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Yes, jmvci also seems to have feature list in jdk/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From kvn at openjdk.org Tue Sep 20 23:45:47 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 20 Sep 2022 23:45:47 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Tue, 20 Sep 2022 23:36:23 GMT, Sandhya Viswanathan wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed review comments > > Yes, jmvci also seems to have feature list in jdk/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java. Thank you @sviswa7 I submitted tier1 testing again with fixed `CPUInfoTest.java` and `AMD64.java`. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From svkamath at openjdk.org Wed Sep 21 00:20:45 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Wed, 21 Sep 2022 00:20:45 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments > Hi @vnkozlov , Github actions seems to be disabled for my account. I am working with Github support to fix this issue. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From kvn at openjdk.org Wed Sep 21 00:25:46 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 21 Sep 2022 00:25:46 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Tier1 tests passed now. I am submitting higher tiers. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From dholmes at openjdk.org Wed Sep 21 00:27:45 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Sep 2022 00:27:45 GMT Subject: RFR: 8292921: Rewrite object field printer [v3] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 01:56:39 GMT, David Holmes wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix macOS sensitivity to format specifier for jlong > > I think this looks fine in principle. A couple of queries/suggestions below. > > Thanks > @dholmes-ora Are you OK with the latest version of this patch? FTR, yes this looks good - thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10028 From jonathanjoo at google.com Wed Sep 21 01:58:49 2022 From: jonathanjoo at google.com (Jonathan Joo) Date: Tue, 20 Sep 2022 18:58:49 -0700 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: References: Message-ID: Hi all, Apologies for the late response - I had missed the replies due to the way I had set up my inbox filtering ?. I may have also missed entire emails due to this, so please feel free to re-reply to this email if I have not addressed your questions. I'll try to address all the email comments in one go, so please bear with a long email ahead! ----- @ Thomas Schatzl Long time no talk :) Thanks for your detailed response. > Most of these suggestions seem to be fairly consistent with existing > RFEs (e.g. [1], [2], [3], ...) that have been discussed before with you > (e.g. in [4]) and been considered really nice to have iirc. > > Agreed that there is a lot of overlap between AHS and the currently open RFEs. Happy to converge on these now that I have a better understanding of this area from working on it! Notably, [1] and [2] are very similar to the two manageable flags that are part of AHS, so I agree that there is room for collaboration here. For [3], I think that is something that is somewhat orthogonal (in terms of implementation) to AHS, but would be very helpful for AHS, since the more frequently we can uncommit memory, the closer we can get the heap to our target heap size. I am not convinced that having a thread inside the JVM is really the > best solution. Constantly querying the _environment_ for changes seems > to be traditionally outside of the scope of the JVM. [...] Using some external process (however it is distributed) seems to be a much more flexible option (not only in customizability but also in terms > of the release cycle for it). I would suggest to at least separate this > effort from improving the JVM capabilities. Just to clarify - the AHS thread is not part of the JVM itself. It is a separate thread that is kicked off in our Java launcher at the same time as the JVM, but is a completely separate process. Thus the functionality that pulls from the environment and sets the manageable flags is not part of hotspot/the JVM. The actual amount of changes to the JVM are not actually that intrusive and actually follow somewhat similar logic to https://github.com/tschatzl/jdk/tree/8238687-investigate-memory-uncommit-during-young-gc2 . some applications that exhibit a very "phased" behavior > results show very bad behavior. This is helpful to know - as someone who has never heard of SPECjbb2015, would it be easy for me to try running it with my prototype? ----- @ Severin: 1. How is AHS enabled? Is it on by default or is it opt-in? > AHS is controlled by a flag in Google's version of the JDK launcher. Right now at Google it is opt-in, but we plan to enable it by default for certain subsets of jobs (namely those already enrolled in a service meant to make tuning more hands-off). If that rollout goes smoothly, we will broaden adoption (but probably still leave as opt-in). > 2. Is the prototype working for all GCs available in OpenJDK or > specific to G1? > This prototype currently only works for G1 GC, and we don't currently have the bandwidth to extend the prototype to other GCs :( > 3. Would this be a Linux only feature? > Currently yes - it is dependent on things like cgroups which I'm not sure is available in other platforms. That being said, If an equivalent feature exists in other platforms, I don't see why it wouldn't work! ----- @ Thomas St?fe Can you describe the adjustment logic in more detail or is there a public > prototypec? > There isn't currently a public prototype - I'll have to double check with legal about the level of detail I can include in a public forum and get back to you. (I imagine it should be fine, but a public-facing doc hasn't been written yet :P) ----- @ Fazil Any chance to be considered as a JEP in OpenJDK? > I'm not familiar with the process of turning an idea/prototype into a JEP - do you have any suggestions on how to go about doing this? Is there some approval process for creating a JEP, or is anyone open to making one? ----- @ Volker 1. Is there a public prototype available? > Not yet, unfortunately! > 2. For which GCs have you implemented it? > Just G1 GC - the implementation I would say is fairly GC-dependent, so it may be a bit of work to get it to work on other GCs. (That being said I'm not familiar with the other GCs so maybe it won't be as bad as I think?) > 3. On which platforms does it currently work? > Just Linux at the moment. > 4. Do you use information from procfs on Linux (or what else) to get > the memory state of the system? > I can provide more details once I get approval from legal to share more specifics publicly! > 5. How often do you query the system and JVM state and update the > settings? Is this (or can it be) correlated to the JVMs allocation > rate? > Right now it defaults to once every 5 seconds, but is configurable to run at whatever frequency is appropriate for the server. That's a good idea to make it correlated with the JVMs allocation rate, that should definitely be doable. > 6. Can you please explain your approach in some more detail (e.g. how > does heap shrinking work)? I suppose you have "Current target heap > size" <= "Current maximum heap expansion size" <= Xmx. I can > understand how your monitoring thread updates "Current maximum heap > expansion size" based on the systems memory usage. But it's harder to > understand how you set "Current target heap size" based GC CPU > overhead and when and how do you trigger heap resizing (both > increasing and shrinking) based on these values? And why do you need > two new variables? Wouldn't "Current target heap size" be enough" > (also see next question for more context)? > Will provide more details regarding these questions when legal approves! But on a high level, the target heap size is a soft target that we try to get the heap to, but if say we have a large amount of legitimate heap usage that cannot be cleaned up (but is still higher than the target heap size), we will allow the heap size to stay above the target heap size indefinitely. This heap size target is determined by having some GC CPU overhead target, and if we are spending more CPU time on GC than the GC CPU target, then we increase the heap size target, and vice versa. The second flag (Current maximum heap expansion size) is a hard limit that prevents allocations no matter what that would cause us to hit container OOM. > 7. What you propose is very similar to the CurrentMaxHeapSize proposed > by "JEP draft: Dynamic Max Memory Limit" [1] except that the latter > proposal misses the part about how to automatically set and update > this value. 8. We already have "JEP 346: Promptly Return Unused Committed Memory > from G1" [2] since JDK 12. Can you explain why this isn't enough? I.e. > if the GC already returns as much heap memory as possible back to the > system, what else can you do to further improve the situation? Agreed! When initially sketching out the proposal, I had looked into both of the JEPs you mentioned in 7. and 8. JEP 346 is not sufficient for our use case since it is not available for JDK11, and IIRC there was trouble backporting that to JDK11, hence it was not usable from our end at least for a while. Furthermore, while periodic GC would help to some extent, but that leaves us trying to determine the optimal periodicity of GC to achieve what we want per server. This seems to be a less informed decision than specifically forcing more GC at times of low container free space. We actually have experimented with similar features within Google and saw that it was not sufficient for preventing container OOMs. ----- @ Stefan It would probably be good to use the same name for the other GCs. > Acknowledged - will change before upstreaming. ----- @ Kirk >From your description here, you're using CPU (GC overheads) to help you > resize. Do you mind elaborating on how this works? > We haven't spent much time focusing on the distribution of heap size between young and old generations, but I agree that this is an area that needs more active investigation for our prototype. Currently our model is just doing the simplest way of reducing and expanding the heap when necessary and not modifying the ratio from young and old gen. But we plan to look more into this as we encounter more types of workloads. Might I suggest that a quicker way is to start large and then resize to > smaller. The reason for doing this is because small clips the signals you > need to look at to know how big things need to be. Starting big should give > you a cleaner, unclipped signal to work with. > Thank you for the suggestion -- noted! One issue we've run into is that G1 tends to use as much heap as it is given, so often times, starting large does not give us the right signals as to why we should reduce the container. But I think with AHS, this becomes a viable approach. ----- @ Ioi - In the simplest case, you have a single JVM process running inside the > container. How do you balance its Java heap vs non-Java heap usage? We don't bound non-Java heap usage -- we assume that there are no memory leaks and that non-Java heap usage is valid usage. Thus, with AHS enabled, the onus becomes on the JVM heap to adapt to increases in non-Java heap usage. > - If you have two JVM processes running inside the container, how do > they coordinate? We haven't yet really tried AHS on multiple JVM processes running inside the same container, but I imagine it should work really mostly the same. Assuming that there is indeed enough space in the container for both processes to work with the target GC CPU overhead, then heap usage for both should stay fairly constant, and both AHS threads should prevent each JVM from exceeding a heap usage that would result in container OOMs. > - If the fluctuation is caused by other processes, can the JVM react > quickly (run GC and free up caches) to respond to quick spikes? Do we > need to configure the container to allow temporarily over-budget > (something like "you can be 100MB over budget for less than 20ms") so > the JVM has time to shrink itself? - Conversely, how can a spiky process request the JVM to temporarily > give up some memory? The JVM can react pretty quickly - basically if free space decreases quickly, then the next time the JVM tries to expand the heap due to an allocation, it will fail to expand, and thus runs GC to free up some space. During this GC it will then do its best to shrink the heap to its target size. Rather than allowing the container to go over-budget, we have some buffer so that we don't allow expansions if it would cause container usage to exceed 95% of the container limit. > It seems to me that for the more complex scenarios, it's not enough for > each individual JVM to make decisions on its own. We may need some sort > of intra-process coordination. Agreed that this is not a one-size-fits-all solution for all possible scenarios, especially the more complex ones. ----- Again, apologies for the delay in responding to the questions, but I hope I answered everything here. Will be more diligent about monitoring this discussion thread. Appreciate all the thoughtful questions and discussions! ~ Jonathan On Fri, Sep 16, 2022 at 10:41 AM Kirk Pepperdine wrote: > Hi Jonathan, > > Very interesting experiment. This sizing issue is something that is > befuddling a significant portion of those responsible for > deploying containerized Java applications. Lio nicely points out that the > old goal of "play nice" when configuring memory is in conflict with the new > goal of "be greedy". Thus a re-visiting of memory sizing ergonomics is > something that I certainly welcome. The cloud providers have been > interested in better (for some weakly definition of better) memory resizing > dynamics for quite some time so also a hot button topic. > > I'm not sure how much I have to add over what others have commented on > but, I don't believe we need an inter-process communication, at least not > in the first instance nor do we need a watcher thread (again, at least not > in the first instance). The one thing that I see here, if I'm reading this > correctly, is that there is a focus on total heap size. For generational > collectors, like G1, young and tenured play two different roles and thus > require different tuning strategies. Tuning young is about controlling the > promotion of transients into tenured. The two big things that drive > transients into tenured are undersized survivor space and frequency > collections (accelerated aging). Thus young sizing should be heavily > influenced by allocation rates. This is considerably different than tenured > where the driving metric is live set size (LSS). Thus tenured should be > LSS + some working space. From this, it follows that max heap will be the > sum of the parts. From your description here, you're using CPU (GC > overheads) to help you resize. Do you mind elaborating on how this works? > > Another side note is that you mention sizing is trial and error where you > start small and then make bigger as needed. Might I suggest that a quicker > way is to start large and then resize to smaller. The reason for doing this > is because small clips the signals you need to look at to know how big > things need to be. Starting big should give you a cleaner, unclipped signal > to work with. > > Kind regards, > Kirk > > > On Tue, Sep 13, 2022 at 12:17 PM Jonathan Joo > wrote: > >> Hello hotspot-dev and hotspot-gc-dev, >> >> My name is Jonathan, and I'm working on the Java Platform Team at Google. >> Here, we are working on a project to address Java container memory issues, >> as we noticed that a significant number of Java servers hit container OOM >> issues due to people incorrectly tuning their heap size with respect to the >> container size. Because our containers have other RAM consumers which >> fluctuate over time, it is often difficult to determine a priori what is an >> appropriate Xmx to set for a particular server. >> >> We set about trying to solve this by dynamically adjusting the Java >> heap/gc behavior based on the container usage information that we pass into >> the JVM. We have seen promising results so far, reducing container OOMs by >> a significant amount, and oftentimes also reducing average heap usage (with >> the tradeoff of more CPU time spent doing GC). >> >> Below (under the dotted line) is a more detailed explanation of our >> initial approach. Does this sound like something that may be useful for the >> general OpenJDK community? If so, would some of you be open to further >> discussion? I would also like to better understand what container >> environments look like outside of Google, to see how we could modify our >> approach for the more general case. >> >> Thank you! >> >> >> Jonathan >> ------------------------------------------------------------------------ >> Introduction: >> >> Adaptable Heap Sizing (AHS) is a project internal to Google that is meant >> to simplify configuration and improve the stability of applications in >> container environments. The key is that in a containerized environment, we >> have access to container usage and limit information. This can be used as a >> signal to modify Java heap behavior, helping prevent container OOMs. >> Problem: >> >> - >> >> Containers at Google must be properly sized to not only the JVM heap, >> but other memory consumers as well. These consumers include non-heap Java >> (e.g. native code allocations), and simultaneously running non-Java >> processes. >> - >> >> Common antipattern we see here at Google: >> - >> >> We have an application running into container OOMs. >> - >> >> An engineer raises both container memory limit and Xmx by the same >> amount, since there appears to be insufficient memory. >> - >> >> The application has reduced container OOMs, but is still prone to >> them, since G1 continues to use most of Xmx. >> - >> >> This results in many jobs being configured with much more RAM than >> they need, but still running into container OOM issues. >> >> Hypothesis: >> >> - >> >> For preventing container OOM: Why can't heap expansions be bounded by >> the remaining free space in the container? >> - >> >> For preventing the `unnecessarily high Xmx` antipattern: Why can't >> target heap size be set based on GC CPU overhead? >> - >> >> From our work on Adaptable Heap Sizing, it appears they can! >> >> Design: >> >> - >> >> We add two manageable flags in the JVM >> - >> >> Current maximum heap expansion size >> - >> >> Current target heap size >> - >> >> A separate thread runs alongside the JVM, querying: >> - >> >> Container memory usage/limits >> - >> >> GC CPU overhead metrics from the JVM. >> - >> >> This thread then uses this information to calculate new values for >> the two new JVM flags, and continually updates them at runtime. >> - >> >> The `Current maximum heap expansion size` informs the JVM what is the >> maximum amount we can expand the heap by, while staying within container >> limits. This is a hard limit, and trying to expand more than this amount >> results in behavior equivalent to hitting the Xmx limit. >> - >> >> The `Current target heap size` is a soft target value, which is used to >> resize the heap (when possible) so as to bring GC CPU overhead toward its >> target value. >> >> >> Results: >> >> - >> >> At Google, we have found that this design works incredibly well in >> our initial rollout, even for large and complex workloads. >> - >> >> After deploying this to dozens of applications: >> - >> >> Significant memory savings for previously misconfigured jobs (many >> of which reduced their heap usage by 50% or more) >> - >> >> Significantly reduced occurrences of container OOM (100% reduction >> in vast majority of cases) >> - >> >> No correctness issues >> - >> >> No latency regressions* >> - >> >> We plan to deploy AHS across a much wider subset of applications >> by EOY '22. >> >> >> *Caveats: >> >> - Enabling this feature might require tuning of the newly introduced >> default GC CPU overhead target to avoid regressions. >> - >> >> Time spent doing GC for an application may increase significantly >> (though generally we've seen in practice that even if this is the case, >> end-to-end latency does not increase a noticeable amount) >> - >> >> Enabling AHS results in frequent heap resizings, but we have not seen >> evidence of any negative effects as a result of these more frequent heap >> resizings. >> - >> >> AHS is not necessarily a replacement for proper JVM tuning, but >> should generally work better than an untuned or improperly tuned >> configuration. >> - >> >> AHS is not intended for every possible workload, and there could be >> pathological cases where AHS results in worse behavior. >> >> > > -- > Kind regards, > Kirk Pepperdine > > http://www.kodewerk.com > http://www.javaperformancetuning.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dholmes at openjdk.org Wed Sep 21 02:54:38 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Sep 2022 02:54:38 GMT Subject: RFR: JDK-8293346: Add NoThreadCurrentMark to simulate non-attached threads In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 06:37:35 GMT, Thomas Stuefe wrote: > When working on [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344), I needed a way to verify that I had removed all offending usages of ResourceArea memory inside an extend. > > For that, a NoThreadCurrentMark was useful. It temporarily sets the current Thread* to NULL for the extend. Any use of Thread::current below that mark will now crash or assert. > > This can be used for two things: > - guard code that is supposed to be safe for non-attached threads (os::malloc, stack printing, UL etc) against accidental usage of Thread::current() (e.g. resource area allocation) > - in gtests, simulate a non-attached thread to cover code that behaves differently with Thread::current()==NULL. > > This patch: > > - Introduces the debug-only `NoThreadCurrentMark` > - Adds a gtest for it > - Adds it to guard dwarf-parsing-based stack printing, which had not been safe due to use of ResourceArea, fixed with [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344) > - Adds it to `os::malloc()`, `os::realloc()` and `os::free()`, since those can certainly be called without a current thread. > - Replaces the test-local mark in the SafeFetch gtests that did a similar thing > - I may add and fix up other users later > > I also had to change Library-based TLS initialization such that it runs at C++ dynamic initialization time. That is because the `NoThreadCurrentMark` needs to set both Library-based TLS and C++ TLS slots, and having library-based TLS not available before VM initialization made the code too complex. This also means we can remove the explicit TLS initialization from create_vm. > > Finally, while I was here, I also fixed the error printing in library based TLS (since the pthread_key_xxx functions don't modify errno). Sorry Thomas but this seems far too disruptive and complex just to support the usecase you outlined. ------------- PR: https://git.openjdk.org/jdk/pull/10178 From dholmes at openjdk.org Wed Sep 21 02:59:42 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Sep 2022 02:59:42 GMT Subject: RFR: JDK-8293346: Add NoThreadCurrentMark to simulate non-attached threads In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 06:37:35 GMT, Thomas Stuefe wrote: > When working on [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344), I needed a way to verify that I had removed all offending usages of ResourceArea memory inside an extend. > > For that, a NoThreadCurrentMark was useful. It temporarily sets the current Thread* to NULL for the extend. Any use of Thread::current below that mark will now crash or assert. > > This can be used for two things: > - guard code that is supposed to be safe for non-attached threads (os::malloc, stack printing, UL etc) against accidental usage of Thread::current() (e.g. resource area allocation) > - in gtests, simulate a non-attached thread to cover code that behaves differently with Thread::current()==NULL. > > This patch: > > - Introduces the debug-only `NoThreadCurrentMark` > - Adds a gtest for it > - Adds it to guard dwarf-parsing-based stack printing, which had not been safe due to use of ResourceArea, fixed with [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344) > - Adds it to `os::malloc()`, `os::realloc()` and `os::free()`, since those can certainly be called without a current thread. > - Replaces the test-local mark in the SafeFetch gtests that did a similar thing > - I may add and fix up other users later > > I also had to change Library-based TLS initialization such that it runs at C++ dynamic initialization time. That is because the `NoThreadCurrentMark` needs to set both Library-based TLS and C++ TLS slots, and having library-based TLS not available before VM initialization made the code too complex. This also means we can remove the explicit TLS initialization from create_vm. > > Finally, while I was here, I also fixed the error printing in library based TLS (since the pthread_key_xxx functions don't modify errno). As you are simulating non-attached thread by attached threads why can't use just have a debug-only field in Thread that is set/cleared by the NTCM, and have Thread::current examine that field? ------------- PR: https://git.openjdk.org/jdk/pull/10178 From fyang at openjdk.org Wed Sep 21 03:06:17 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 21 Sep 2022 03:06:17 GMT Subject: RFR: 8294083: RISC-V: Minimal build failed with --disable-precompiled-headers Message-ID: The build failed due to undeclared 'java_lang_ref_Reference'. Including the corresponding header (classfile/javaClasses.hpp) will fix it. I see a similar issue was once fixed for aarch64: https://bugs.openjdk.org/browse/JDK-8257743 Testing: Minimal builds with this fix ------------- Commit messages: - 8294083: RISC-V: Minimal build failed with --disable-precompiled-headers Changes: https://git.openjdk.org/jdk/pull/10368/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10368&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294083 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10368.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10368/head:pull/10368 PR: https://git.openjdk.org/jdk/pull/10368 From fjiang at openjdk.org Wed Sep 21 03:11:44 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 21 Sep 2022 03:11:44 GMT Subject: RFR: 8294083: RISC-V: Minimal build failed with --disable-precompiled-headers In-Reply-To: References: Message-ID: <25VmiX9oQrLNIn1rs953hJVQKQ6c9abiUpN0TQsRuNA=.404ad9ec-764f-41c3-bb17-1f5f9838d281@github.com> On Wed, 21 Sep 2022 03:01:00 GMT, Fei Yang wrote: > The build failed due to undeclared 'java_lang_ref_Reference'. > Including the corresponding header (classfile/javaClasses.hpp) will fix it. > I see a similar issue was once fixed for aarch64: https://bugs.openjdk.org/browse/JDK-8257743 > > Testing: Minimal builds with this fix Looks good. Thanks for fixing the minimal build! ------------- Marked as reviewed by fjiang (Author). PR: https://git.openjdk.org/jdk/pull/10368 From xlinzheng at openjdk.org Wed Sep 21 03:57:09 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 21 Sep 2022 03:57:09 GMT Subject: RFR: 8294086: RISC-V: Cleanup InstructionMarks in the backend Message-ID: <0vL9HTzSH6i7KOSLmhCGPASAQjDzjnuCz3I7SsRrReA=.7a12d4ad-9f35-41ad-b4b3-a974b1dd9b61@github.com> This is a trivial cleanup of dummy `InstructionMark` usages in the RISC-V backend. There are no more `InstructionMark` usages in the backend now. Tested hotspot tier1 and tier2 on Qemu. ------------- Commit messages: - RISC-V: Cleanup InstructionMarks in the backend Changes: https://git.openjdk.org/jdk/pull/10369/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10369&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294086 Stats: 21 lines in 3 files changed: 0 ins; 12 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/10369.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10369/head:pull/10369 PR: https://git.openjdk.org/jdk/pull/10369 From xlinzheng at openjdk.org Wed Sep 21 04:02:28 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 21 Sep 2022 04:02:28 GMT Subject: RFR: 8294087: RISC-V: Refactor instruction alignment assertions Message-ID: This is a trivial refactoring for some instruction alignment assertions. Due to the fact that the `assert (__ pc() % 4 == 0)` is getting used more, this small patch is extracted first to simplify code reviewing. This patch doesn't change the code behavior. Tested hotspot tier1 and tier2 together with other patches on QEMU. ------------- Commit messages: - RISC-V: Refactor instruction alignment assertions Changes: https://git.openjdk.org/jdk/pull/10370/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294087 Stats: 14 lines in 5 files changed: 10 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10370.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10370/head:pull/10370 PR: https://git.openjdk.org/jdk/pull/10370 From dholmes at openjdk.org Wed Sep 21 04:05:35 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Sep 2022 04:05:35 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 03:56:42 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback johan > > src/hotspot/share/runtime/arguments.cpp line 63: > >> 61: #include "utilities/defaultStream.hpp" >> 62: #include "utilities/macros.hpp" >> 63: #include "utilities/parse_memory_size.hpp" > > File names use camelCase naming. And why is this "memory_size"? It is just integer parsing. ------------- PR: https://git.openjdk.org/jdk/pull/10252 From dholmes at openjdk.org Wed Sep 21 04:05:34 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Sep 2022 04:05:34 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 15:23:58 GMT, Thomas Stuefe wrote: >> Arguments.cpp has several size parsing functions which would be useful in other areas of the hotspot, e.g. in NMT. >> >> It would be nice to have them factored out into utilities, to reuse the code and to unify memory size handling. Gtests would be good too. >> >> To simplify reviews, I split the patch into two commits. >> >> The first commit (https://github.com/openjdk/jdk/pull/10252/commits/700e77e8d1469a2fc3d6611072c4b07aa34ab8e6) contains the unchanged code move without functional changes. >> >> The second commit (https://github.com/openjdk/jdk/pull/10252/commits/76b4f6f30cc316fd966da60ff6601f54eeb394bf) contains the functional changes I did, as well as the new gtest. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > feedback johan Basic moving of the parsing functions to their own header file (modulo the naming of that file) seems okay. But I don't follow the "memory size" aspect of this refactoring. ?? src/hotspot/share/runtime/arguments.cpp line 63: > 61: #include "utilities/defaultStream.hpp" > 62: #include "utilities/macros.hpp" > 63: #include "utilities/parse_memory_size.hpp" File names use camelCase naming. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10252 From stefank at openjdk.org Wed Sep 21 05:23:31 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 21 Sep 2022 05:23:31 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 15:23:58 GMT, Thomas Stuefe wrote: >> Arguments.cpp has several size parsing functions which would be useful in other areas of the hotspot, e.g. in NMT. >> >> It would be nice to have them factored out into utilities, to reuse the code and to unify memory size handling. Gtests would be good too. >> >> To simplify reviews, I split the patch into two commits. >> >> The first commit (https://github.com/openjdk/jdk/pull/10252/commits/700e77e8d1469a2fc3d6611072c4b07aa34ab8e6) contains the unchanged code move without functional changes. >> >> The second commit (https://github.com/openjdk/jdk/pull/10252/commits/76b4f6f30cc316fd966da60ff6601f54eeb394bf) contains the functional changes I did, as well as the new gtest. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > feedback johan Changes requested by stefank (Reviewer). src/hotspot/share/utilities/globalDefinitions.hpp line 113: > 111: // Format 32-bit quantities. > 112: #define INT32_FORMAT "%" PRId32 > 113: #define INT32_FORMAT_X "0x%" PRIx32 Could you add corresponding test lines to test_globalDefintions.cpp? src/hotspot/share/utilities/parse_integer.hpp line 2: > 1: /* > 2: * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved. I think you should use the copyright dates from the file where this code got copied from. Same goes for the other new file. src/hotspot/share/utilities/parse_integer.hpp line 93: > 91: } > 92: > 93: #endif // SHARE_UTILITIES_COPY_HPP Wrong comment test/hotspot/gtest/testutils.hpp line 60: > 58: > 59: #define LOG_HERE(s, ...) { printf(s, __VA_ARGS__); printf("\n"); fflush(stdout); } > 60: In other reviews I've asked the reviewers to use unified logging with the `test` tag. Maybe do the same for this test? ------------- PR: https://git.openjdk.org/jdk/pull/10252 From stuefe at openjdk.org Wed Sep 21 06:13:39 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 06:13:39 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 04:02:00 GMT, David Holmes wrote: > Basic moving of the parsing functions to their own header file (modulo the naming of that file) seems okay. But I don't follow the "memory size" aspect of this refactoring. ?? I splitted the original function set into two. One parsing integers, one atop of that parsing memory sizes. These functions existed before, but I renamed the original one to parse_memory_size to make it clear what it actually does. Before we had: A) parse_integer() -> does not parse integer, but memory sizes, e.g. "1K", "1G", etc B) parse_integer_impl() -> helper functions to parse real integers Now we have: A) parse_memory_size() -> parses memory sizes B) parse_integer() -> parses integers ------------- PR: https://git.openjdk.org/jdk/pull/10252 From stuefe at openjdk.org Wed Sep 21 06:21:45 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 06:21:45 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: References: Message-ID: <0neA85yaA9GsH1OyYw_AKKr3u8phBG6kctjGqD7wyaU=.98846cf7-76df-4ff6-a387-ea70be152d40@github.com> On Wed, 21 Sep 2022 05:18:20 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback johan > > test/hotspot/gtest/testutils.hpp line 60: > >> 58: >> 59: #define LOG_HERE(s, ...) { printf(s, __VA_ARGS__); printf("\n"); fflush(stdout); } >> 60: > > In other reviews I've asked the reviewers to use unified logging with the `test` tag. Maybe do the same for this test? Unfortunately, UL is not an option here, since I use it in TEST tests (without _VM, so I may not have VM infrastructure available depending on the order of test execution). ------------- PR: https://git.openjdk.org/jdk/pull/10252 From stuefe at openjdk.org Wed Sep 21 06:31:22 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 06:31:22 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v3] In-Reply-To: References: Message-ID: > Arguments.cpp has several size parsing functions which would be useful in other areas of the hotspot, e.g. in NMT. > > It would be nice to have them factored out into utilities, to reuse the code and to unify memory size handling. Gtests would be good too. > > To simplify reviews, I split the patch into two commits. > > The first commit (https://github.com/openjdk/jdk/pull/10252/commits/700e77e8d1469a2fc3d6611072c4b07aa34ab8e6) contains the unchanged code move without functional changes. > > The second commit (https://github.com/openjdk/jdk/pull/10252/commits/76b4f6f30cc316fd966da60ff6601f54eeb394bf) contains the functional changes I did, as well as the new gtest. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback stefank+dholmes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10252/files - new: https://git.openjdk.org/jdk/pull/10252/files/a5e6b6f1..339fab1f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10252&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10252&range=01-02 Stats: 9 lines in 5 files changed: 3 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10252.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10252/head:pull/10252 PR: https://git.openjdk.org/jdk/pull/10252 From stuefe at openjdk.org Wed Sep 21 06:31:23 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 06:31:23 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 04:02:00 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback johan > > Basic moving of the parsing functions to their own header file (modulo the naming of that file) seems okay. But I don't follow the "memory size" aspect of this refactoring. ?? Hi @dholmes-ora, @stefank, thanks for looking at this. I worked in your feedback. @dholmes-ora: I hope my comment above made my intent a bit clearer. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/10252 From stuefe at openjdk.org Wed Sep 21 06:33:43 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 06:33:43 GMT Subject: RFR: JDK-8293346: Add NoThreadCurrentMark to simulate non-attached threads In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 02:51:22 GMT, David Holmes wrote: > Sorry Thomas but this seems far too disruptive and complex just to support the usecase you outlined. I was afraid you would dislike the changes to TLS initialization. > As you are simulating non-attached thread by attached threads why can't use just have a debug-only field in Thread that is set/cleared by the NTCM, and have Thread::current examine that field? I can try this. This would be simpler. Has to support nesting though. Lets see. ------------- PR: https://git.openjdk.org/jdk/pull/10178 From stuefe at openjdk.org Wed Sep 21 06:38:50 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 06:38:50 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v3] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 06:31:22 GMT, Thomas Stuefe wrote: >> Arguments.cpp has several size parsing functions which would be useful in other areas of the hotspot, e.g. in NMT. >> >> It would be nice to have them factored out into utilities, to reuse the code and to unify memory size handling. Gtests would be good too. >> >> To simplify reviews, I split the patch into two commits. >> >> The first commit (https://github.com/openjdk/jdk/pull/10252/commits/700e77e8d1469a2fc3d6611072c4b07aa34ab8e6) contains the unchanged code move without functional changes. >> >> The second commit (https://github.com/openjdk/jdk/pull/10252/commits/76b4f6f30cc316fd966da60ff6601f54eeb394bf) contains the functional changes I did, as well as the new gtest. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback stefank+dholmes BTW, this fix intends to simplify the solution for https://github.com/openjdk/jdk/pull/10144 which then will make it possible to remove -XX:MallocMaxTestWords and its supporting code, and use NMT malloc limits instead (e.g. in compiler tests). So, the end result would hopefully be a code reduction too. ------------- PR: https://git.openjdk.org/jdk/pull/10252 From dholmes at openjdk.org Wed Sep 21 06:50:39 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Sep 2022 06:50:39 GMT Subject: RFR: JDK-8293346: Add NoThreadCurrentMark to simulate non-attached threads In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 06:37:35 GMT, Thomas Stuefe wrote: > When working on [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344), I needed a way to verify that I had removed all offending usages of ResourceArea memory inside an extend. > > For that, a NoThreadCurrentMark was useful. It temporarily sets the current Thread* to NULL for the extend. Any use of Thread::current below that mark will now crash or assert. > > This can be used for two things: > - guard code that is supposed to be safe for non-attached threads (os::malloc, stack printing, UL etc) against accidental usage of Thread::current() (e.g. resource area allocation) > - in gtests, simulate a non-attached thread to cover code that behaves differently with Thread::current()==NULL. > > This patch: > > - Introduces the debug-only `NoThreadCurrentMark` > - Adds a gtest for it > - Adds it to guard dwarf-parsing-based stack printing, which had not been safe due to use of ResourceArea, fixed with [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344) > - Adds it to `os::malloc()`, `os::realloc()` and `os::free()`, since those can certainly be called without a current thread. > - Replaces the test-local mark in the SafeFetch gtests that did a similar thing > - I may add and fix up other users later > > I also had to change Library-based TLS initialization such that it runs at C++ dynamic initialization time. That is because the `NoThreadCurrentMark` needs to set both Library-based TLS and C++ TLS slots, and having library-based TLS not available before VM initialization made the code too complex. This also means we can remove the explicit TLS initialization from create_vm. > > Finally, while I was here, I also fixed the error printing in library based TLS (since the pthread_key_xxx functions don't modify errno). A counter rather than a bit allows nesting easily enough. As this is just a debugging/testing aid it really shouldn't disrupt product code IMO. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10178 From dholmes at openjdk.org Wed Sep 21 06:54:51 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Sep 2022 06:54:51 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 06:09:47 GMT, Thomas Stuefe wrote: > Before we had: > A) parse_integer() -> does not parse integer, but memory sizes, e.g. "1K", "1G", etc Hmmm, I don't consider those "memory sizes" even if often used for such they are just ways of expressing large integers in a simple way. They are used for file sizes and data-structure sizes as well. ------------- PR: https://git.openjdk.org/jdk/pull/10252 From fjiang at openjdk.org Wed Sep 21 07:00:46 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 21 Sep 2022 07:00:46 GMT Subject: RFR: 8294086: RISC-V: Cleanup InstructionMark usages in the backend In-Reply-To: <0vL9HTzSH6i7KOSLmhCGPASAQjDzjnuCz3I7SsRrReA=.7a12d4ad-9f35-41ad-b4b3-a974b1dd9b61@github.com> References: <0vL9HTzSH6i7KOSLmhCGPASAQjDzjnuCz3I7SsRrReA=.7a12d4ad-9f35-41ad-b4b3-a974b1dd9b61@github.com> Message-ID: On Wed, 21 Sep 2022 03:50:22 GMT, Xiaolin Zheng wrote: > This is a trivial cleanup of dummy `InstructionMark` usages in the RISC-V backend. There are no more `InstructionMark` usages in the backend now. > > Tested hotspot tier1 and tier2 on Qemu. Nice cleanup, thanks! ------------- Marked as reviewed by fjiang (Author). PR: https://git.openjdk.org/jdk/pull/10369 From stuefe at openjdk.org Wed Sep 21 07:08:47 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 07:08:47 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 06:52:47 GMT, David Holmes wrote: > > Before we had: > > A) parse_integer() -> does not parse integer, but memory sizes, e.g. "1K", "1G", etc > > Hmmm, I don't consider those "memory sizes" even if often used for such they are just ways of expressing large integers in a simple way. They are used for file sizes and data-structure sizes as well. I'm unemotional about the name as long as its clearly different from a simple integer parsing. How about "parse_size" ? "parse_si_size" ? (though we don't implement the full complement of si units). "parse_size_with_units" ? ------------- PR: https://git.openjdk.org/jdk/pull/10252 From chagedorn at openjdk.org Wed Sep 21 07:08:46 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 21 Sep 2022 07:08:46 GMT Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v2] In-Reply-To: References: Message-ID: > The DWARF debugging symbols emitted by Clang is different from what GCC is emitting. While GCC produces a complete `.debug_aranges` section (which is required in the DWARF parser), Clang does not. As a result, the DWARF parser cannot find the necessary information to proceed and create the line number information: > > The `.debug_aranges` section contains address range to compilation unit offset mappings. The parsing algorithm can just walk through all these entries to find the correct address range that contains the library offset of the current pc. This gives us the compilation unit offset into the `.debug_info` section from where we can proceed to parse the line number information. > > Without a complete `.debug_aranges` section, we fail with an assertion that we could not find the correct entry. Since [JDK-8293402](https://bugs.openjdk.org/browse/JDK-8293402), we will still get the complete stack trace at least. Nevertheless, we should still fix this assertion failure of course. But that would require a different parsing approach. We need to parse the entire `.debug_info` section instead to get to the correct compilation unit. This, however, would require a lot more work. > > I therefore suggest to disable DWARF parsing for Clang for now and file an RFE to support Clang in the future with a different parsing approach. I'm using the `__clang__` `ifdef` to bail out in `get_source_info()` and disable the `gtests`. I've noticed that we are currently running the `gtests` with `NOT PRODUCT` which I think is not necessary - the gtests should also work fine with product builds. I've corrected this as well but that could also be done separately. > > Thanks, > Christian Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: Change old bailout fix to only apply to Clang versions older than 5.0 and add new fix with -gdwarf-aranges + -gdwarf-4 for Clang 5.0+ ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10287/files - new: https://git.openjdk.org/jdk/pull/10287/files/058db652..3b1516a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10287&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10287&range=00-01 Stats: 31 lines in 5 files changed: 25 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10287.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10287/head:pull/10287 PR: https://git.openjdk.org/jdk/pull/10287 From chagedorn at openjdk.org Wed Sep 21 07:08:48 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 21 Sep 2022 07:08:48 GMT Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 11:59:08 GMT, Christian Hagedorn wrote: > The DWARF debugging symbols emitted by Clang is different from what GCC is emitting. While GCC produces a complete `.debug_aranges` section (which is required in the DWARF parser), Clang does not. As a result, the DWARF parser cannot find the necessary information to proceed and create the line number information: > > The `.debug_aranges` section contains address range to compilation unit offset mappings. The parsing algorithm can just walk through all these entries to find the correct address range that contains the library offset of the current pc. This gives us the compilation unit offset into the `.debug_info` section from where we can proceed to parse the line number information. > > Without a complete `.debug_aranges` section, we fail with an assertion that we could not find the correct entry. Since [JDK-8293402](https://bugs.openjdk.org/browse/JDK-8293402), we will still get the complete stack trace at least. Nevertheless, we should still fix this assertion failure of course. But that would require a different parsing approach. We need to parse the entire `.debug_info` section instead to get to the correct compilation unit. This, however, would require a lot more work. > > I therefore suggest to disable DWARF parsing for Clang for now and file an RFE to support Clang in the future with a different parsing approach. I'm using the `__clang__` `ifdef` to bail out in `get_source_info()` and disable the `gtests`. I've noticed that we are currently running the `gtests` with `NOT PRODUCT` which I think is not necessary - the gtests should also work fine with product builds. I've corrected this as well but that could also be done separately. > > Thanks, > Christian Thanks Thomas for that link. I was not aware of this `-gdwarf-aranges` flag. I've tried it out and it indeed seems to work. But I was not able to build with `-flto=thin` as it resulted in build failures. So, I'm not sure what would happen and if it's even possible to build with it in general. Nevertheless, I suggest to go with that `-gdwarf-aranges` flag solution for now and remove the previously suggested bailout fix for Clang. However, `-gdwarf-aranges` (and `-gdwarf-4` which I think we should also add to avoid getting the unsupported DWARF 5 format) was only added in Clang 5.0. But we must support down to 3.5 according to: https://github.com/openjdk/jdk/blob/cb72f80925965c73e32c44ce3196866272306d7f/doc/building.md?plain=1#L353-L354 I therefore changed the previous complete bailout fix to a bailout fix for Clang versions older than 5.0. I've noticed that Clang is emitting a full relative path for the filename in the form of `src/hotspot/share/compiler/compilerThread.cpp:58` with debug builds (it only emits the filename with release builds). I therefore added an additional method `strip_path_prefix()` to get rid of the path prefix. ------------- PR: https://git.openjdk.org/jdk/pull/10287 From yadongwang at openjdk.org Wed Sep 21 07:26:49 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Wed, 21 Sep 2022 07:26:49 GMT Subject: RFR: 8294083: RISC-V: Minimal build failed with --disable-precompiled-headers In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 03:01:00 GMT, Fei Yang wrote: > The build failed due to undeclared 'java_lang_ref_Reference'. > Including the corresponding header (classfile/javaClasses.hpp) will fix it. > I see a similar issue was once fixed for aarch64: https://bugs.openjdk.org/browse/JDK-8257743 > > Testing: Minimal builds with this fix lgtm ------------- Marked as reviewed by yadongwang (Author). PR: https://git.openjdk.org/jdk/pull/10368 From duke at openjdk.org Wed Sep 21 07:40:46 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Wed, 21 Sep 2022 07:40:46 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v8] In-Reply-To: References: Message-ID: > This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: > > vptest xmm0, xmm1 > jb if_true > if_false: > > instead of: > > vptest xmm0, xmm1 > setb r10 > movzbl r10 > testl r10 > jne if_true > if_false: > > The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: > > Before After > Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change > ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% > > I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge branch 'master' into improveVTest - fix merge problems - Merge branch 'master' into improveVTest - refactor x86 - revert renaming temp - style + use rscratch instead of tmp - fix - redo aarch - Merge branch 'master' into improveVTest - delete aarch64 vector files - ... and 14 more: https://git.openjdk.org/jdk/compare/1b496064...0894474a ------------- Changes: https://git.openjdk.org/jdk/pull/9855/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=07 Stats: 483 lines in 23 files changed: 214 ins; 145 del; 124 mod Patch: https://git.openjdk.org/jdk/pull/9855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9855/head:pull/9855 PR: https://git.openjdk.org/jdk/pull/9855 From shade at openjdk.org Wed Sep 21 07:48:55 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Sep 2022 07:48:55 GMT Subject: RFR: 8294083: RISC-V: Minimal build failed with --disable-precompiled-headers In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 03:01:00 GMT, Fei Yang wrote: > The build failed due to undeclared 'java_lang_ref_Reference'. > Including the corresponding header (classfile/javaClasses.hpp) will fix it. > I see a similar issue was once fixed for aarch64: https://bugs.openjdk.org/browse/JDK-8257743 > > Testing: Minimal builds with this fix Looks fine! ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10368 From dholmes at openjdk.org Wed Sep 21 08:11:48 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Sep 2022 08:11:48 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v3] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 06:31:22 GMT, Thomas Stuefe wrote: >> Arguments.cpp has several size parsing functions which would be useful in other areas of the hotspot, e.g. in NMT. >> >> It would be nice to have them factored out into utilities, to reuse the code and to unify memory size handling. Gtests would be good too. >> >> To simplify reviews, I split the patch into two commits. >> >> The first commit (https://github.com/openjdk/jdk/pull/10252/commits/700e77e8d1469a2fc3d6611072c4b07aa34ab8e6) contains the unchanged code move without functional changes. >> >> The second commit (https://github.com/openjdk/jdk/pull/10252/commits/76b4f6f30cc316fd966da60ff6601f54eeb394bf) contains the functional changes I did, as well as the new gtest. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback stefank+dholmes I'm not sure why you need to have two different parsing routines when one routine can parse everything. Things like 1K, 1M etc are defined by Unicode as "compact number formats", so you could incorporate that in the name if you had to, but I don't see why you want/need to. ------------- PR: https://git.openjdk.org/jdk/pull/10252 From fyang at openjdk.org Wed Sep 21 08:27:43 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 21 Sep 2022 08:27:43 GMT Subject: RFR: 8294086: RISC-V: Cleanup InstructionMark usages in the backend In-Reply-To: <0vL9HTzSH6i7KOSLmhCGPASAQjDzjnuCz3I7SsRrReA=.7a12d4ad-9f35-41ad-b4b3-a974b1dd9b61@github.com> References: <0vL9HTzSH6i7KOSLmhCGPASAQjDzjnuCz3I7SsRrReA=.7a12d4ad-9f35-41ad-b4b3-a974b1dd9b61@github.com> Message-ID: On Wed, 21 Sep 2022 03:50:22 GMT, Xiaolin Zheng wrote: > This is a trivial cleanup of dummy `InstructionMark` usages in the RISC-V backend. There are no more `InstructionMark` usages in the backend now. > > Tested hotspot tier1 and tier2 on Qemu. Looks OK. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10369 From stuefe at openjdk.org Wed Sep 21 08:39:56 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 08:39:56 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v3] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 08:08:03 GMT, David Holmes wrote: > I'm not sure why you need to have two different parsing routines when one routine can parse everything. Things like 1K, 1M etc are defined by Unicode as "compact number formats", so you could incorporate that in the name if you had to, but I don't see why you want/need to. Okay, so you want me to hide the parse_integer() variant, and possibly rename parse_memory back to parse_integer? ------------- PR: https://git.openjdk.org/jdk/pull/10252 From fyang at openjdk.org Wed Sep 21 08:42:54 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 21 Sep 2022 08:42:54 GMT Subject: RFR: 8294087: RISC-V: Refactor instruction alignment assertions In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 03:54:03 GMT, Xiaolin Zheng wrote: > This is a trivial refactoring for some instruction alignment assertions. Due to the fact that the `assert (__ offset() % 4 == 0)` is getting used more, this small patch is extracted first to simplify code reviewing. > This patch doesn't change the code behavior. > Tested hotspot tier1 and tier2 together with other patches on QEMU. Can you add in the code alignment assertions introduced by your new RVC proposal [1]? [1] https://github.com/zhengxiaolinX/jdk/commit/26874527d196cd6c31b1649c8c00ed4f5a6b154a ------------- PR: https://git.openjdk.org/jdk/pull/10370 From fjiang at openjdk.org Wed Sep 21 08:58:51 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 21 Sep 2022 08:58:51 GMT Subject: RFR: 8294087: RISC-V: Refactor instruction alignment assertions In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 03:54:03 GMT, Xiaolin Zheng wrote: > This is a trivial refactoring for some instruction alignment assertions. Due to the fact that the `assert (__ offset() % 4 == 0)` is getting used more, this small patch is extracted first to simplify code reviewing. > This patch doesn't change the code behavior. > Tested hotspot tier1 and tier2 together with other patches on QEMU. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 94: > 92: } > 93: > 94: void MacroAssembler::assert_alignment() { It's a bit weird that `assert_alignment` only checks the alignment of instruction size. Can you extend this method with a parameter like `align_size` to check any alignment? (instruction size can be the default size of the check) ------------- PR: https://git.openjdk.org/jdk/pull/10370 From dholmes at openjdk.org Wed Sep 21 09:25:49 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Sep 2022 09:25:49 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v3] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 06:31:22 GMT, Thomas Stuefe wrote: >> Arguments.cpp has several size parsing functions which would be useful in other areas of the hotspot, e.g. in NMT. >> >> It would be nice to have them factored out into utilities, to reuse the code and to unify memory size handling. Gtests would be good too. >> >> To simplify reviews, I split the patch into two commits. >> >> The first commit (https://github.com/openjdk/jdk/pull/10252/commits/700e77e8d1469a2fc3d6611072c4b07aa34ab8e6) contains the unchanged code move without functional changes. >> >> The second commit (https://github.com/openjdk/jdk/pull/10252/commits/76b4f6f30cc316fd966da60ff6601f54eeb394bf) contains the functional changes I did, as well as the new gtest. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback stefank+dholmes Okay so we currently have `parse_integer` that calls `parse_integer_impl` to do the raw numeric parsing, then applies the modifiers conversions itself. I don't see why that structure needs to change just because your are refactoring the code. ------------- PR: https://git.openjdk.org/jdk/pull/10252 From xlinzheng at openjdk.org Wed Sep 21 10:16:21 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 21 Sep 2022 10:16:21 GMT Subject: RFR: 8294087: RISC-V: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v2] In-Reply-To: References: Message-ID: <6-vMsRX1oHHfCtHrcFpFwMZx2bKhUixa6jtg1rtVUjc=.2bdaa8bc-0f09-41b0-b0d3-36a7c2171fab@github.com> > This is a trivial refactoring for some instruction alignment assertions. Due to the fact that the `assert (__ offset() % 4 == 0)` is getting used more, this small patch is extracted first to simplify code reviewing. > This patch doesn't change the code behavior. > Tested hotspot tier1 and tier2 together with other patches on QEMU. Xiaolin Zheng has updated the pull request incrementally with two additional commits since the last revision: - Modifications as to review comments - RISC-V: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10370/files - new: https://git.openjdk.org/jdk/pull/10370/files/16d601ba..88256ff1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=00-01 Stats: 25 lines in 6 files changed: 18 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10370.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10370/head:pull/10370 PR: https://git.openjdk.org/jdk/pull/10370 From xlinzheng at openjdk.org Wed Sep 21 10:31:39 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 21 Sep 2022 10:31:39 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v2] In-Reply-To: <6-vMsRX1oHHfCtHrcFpFwMZx2bKhUixa6jtg1rtVUjc=.2bdaa8bc-0f09-41b0-b0d3-36a7c2171fab@github.com> References: <6-vMsRX1oHHfCtHrcFpFwMZx2bKhUixa6jtg1rtVUjc=.2bdaa8bc-0f09-41b0-b0d3-36a7c2171fab@github.com> Message-ID: <2zouoS0AzcTgkEqM5uPe_KWTM83FaF9HQ5qwhFg_8v0=.49630088-88a2-489a-89d0-b6215b75ad4a@github.com> On Wed, 21 Sep 2022 10:16:21 GMT, Xiaolin Zheng wrote: >> With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) >> >> Tested hotspot tier1 and tier2 together with other patches on QEMU. > > Xiaolin Zheng has updated the pull request incrementally with two additional commits since the last revision: > > - Modifications as to review comments > - RISC-V: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops > Can you add in the code alignment assertions introduced by your new RVC proposal [1]? > > [1] [zhengxiaolinX at 2687452](https://github.com/zhengxiaolinX/jdk/commit/26874527d196cd6c31b1649c8c00ed4f5a6b154a) Of course, I have added that and modified the title and descriptions of this PR. ------------- PR: https://git.openjdk.org/jdk/pull/10370 From xlinzheng at openjdk.org Wed Sep 21 10:31:41 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 21 Sep 2022 10:31:41 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v2] In-Reply-To: References: Message-ID: <7D8wBxSu5pQany4IU8PCUsFMS9OegWzDRRlKKaps2Ec=.9885fa8e-d5c7-4873-b54a-46f453a5bcca@github.com> On Wed, 21 Sep 2022 08:53:48 GMT, Feilong Jiang wrote: >> Xiaolin Zheng has updated the pull request incrementally with two additional commits since the last revision: >> >> - Modifications as to review comments >> - RISC-V: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 94: > >> 92: } >> 93: >> 94: void MacroAssembler::assert_alignment() { > > It's a bit weird that `assert_alignment` only checks the alignment of instruction size. Can you extend this method with a parameter like `align_size` to check any alignment? (instruction size can be the default size of the check) Thank you, that is reasonable and I have modified it; but due to the introduction of `NativeInstruction::instruction_size` in the `macroassembler_riscv.hpp`, it seems we also need to introduce `nativeinst_riscv.hpp` in it. I was wondering is this okay, or other plans? ------------- PR: https://git.openjdk.org/jdk/pull/10370 From xlinzheng at openjdk.org Wed Sep 21 10:44:54 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 21 Sep 2022 10:44:54 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v3] In-Reply-To: References: Message-ID: > With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) > > Tested hotspot tier1 and tier2 together with other patches on QEMU. Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: (Revertible) Just to see which code style is better ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10370/files - new: https://git.openjdk.org/jdk/pull/10370/files/88256ff1..229d535e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=01-02 Stats: 13 lines in 8 files changed: 2 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/10370.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10370/head:pull/10370 PR: https://git.openjdk.org/jdk/pull/10370 From xlinzheng at openjdk.org Wed Sep 21 10:44:55 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 21 Sep 2022 10:44:55 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v3] In-Reply-To: <7D8wBxSu5pQany4IU8PCUsFMS9OegWzDRRlKKaps2Ec=.9885fa8e-d5c7-4873-b54a-46f453a5bcca@github.com> References: <7D8wBxSu5pQany4IU8PCUsFMS9OegWzDRRlKKaps2Ec=.9885fa8e-d5c7-4873-b54a-46f453a5bcca@github.com> Message-ID: <0eQ4qbTSZoykLN0kP7ZYKrpJGBd9sQHy9Mo7Wuxgaw0=.d03950c7-e1ab-4968-8259-4631849fba0b@github.com> On Wed, 21 Sep 2022 10:28:23 GMT, Xiaolin Zheng wrote: >> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 94: >> >>> 92: } >>> 93: >>> 94: void MacroAssembler::assert_alignment() { >> >> It's a bit weird that `assert_alignment` only checks the alignment of instruction size. Can you extend this method with a parameter like `align_size` to check any alignment? (instruction size can be the default size of the check) > > Thank you, that is reasonable and I have modified it; but due to the introduction of `NativeInstruction::instruction_size` in the `macroassembler_riscv.hpp`, it seems we also need to introduce `nativeinst_riscv.hpp` in it. I was wondering is this okay, or I can explicitly add `NativeInstruction::instruction_size` arguments to the call sites. I have updated a revertible patch to see which code style is better: adding `NativeInstruction::instruction_size` to the default argument would introduce `nativeInst_riscv.hpp` to one `hpp` file; adding it to every call site would introduce the `nativeInst_riscv.hpp` to two `cpp` files. ------------- PR: https://git.openjdk.org/jdk/pull/10370 From sjohanss at openjdk.org Wed Sep 21 10:45:47 2022 From: sjohanss at openjdk.org (Stefan Johansson) Date: Wed, 21 Sep 2022 10:45:47 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal In-Reply-To: References: Message-ID: <0dfe0HnqB-TnjKk6-CFF9ANIeyz8NSFIid-b_q1r5ZY=.0a5ad315-5dd3-4340-9ef2-0e9f508b24c1@github.com> On Wed, 14 Sep 2022 00:36:18 GMT, Kim Barrett wrote: > 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal > 8155996: Improve concurrent refinement green zone control > 8134303: Introduce -XX:-G1UseConcRefinement > > Please review this change to the control of concurrent refinement. > > This new controller takes a different approach to the problem, addressing a > number of issues. > > The old controller used a multiple of the target number of cards to determine > the range over which increasing numbers of refinement threads should be > activated, and finally activating mutator refinement. This has a variety of > problems. It doesn't account for the processing rate, the rate of new dirty > cards, or the time available to perform the processing. This often leads to > unnecessary spikes in the number of running refinement threads. It also tends > to drive the pending number to the target quickly and keep it there, removing > the benefit from having pending dirty cards filter out new cards for nearby > writes. It can't delay and leave excess cards in the queue because it could > be a long time before another buffer is enqueued. > > The old controller was triggered by mutator threads enqueing card buffers, > when the number of cards in the queue exceeded a threshold near the target. > This required a complex activation protocol between the mutators and the > refinement threads. > > With the new controller there is a primary refinement thread that periodically > estimates how many refinement threads need to be running to reach the target > in time for the next GC, along with whether to also activate mutator > refinement. If the primary thread stops running because it isn't currently > needed, it sleeps for a period and reevaluates on wakeup. This eliminates any > involvement in the activation of refinement threads by mutator threads. > > The estimate of how many refinement threads are needed uses a prediction of > time until the next GC, the number of buffered cards, the predicted rate of > new dirty cards, and the predicted refinement rate. The number of running > threads is adjusted based on these periodically performed estimates. > > This new approach allows more dirty cards to be left in the queue until late > in the mutator phase, typically reducing the rate of new dirty cards, which > reduces the amount of concurrent refinement work needed. > > It also smooths out the number of running refinement threads, eliminating the > unnecessarily large spikes that are common with the old method. One benefit > is that the number of refinement threads (lazily) allocated is often much > lower now. (This plus UseDynamicNumberOfGCThreads mitigates the problem > described in JDK-8153225.) > > This change also provides a new method for calculating for the number of dirty > cards that should be pending at the start of a GC. While this calculation is > conceptually distinct from the thread control, the two were significanly > intertwined in the old controller. Changing this calculation separately and > first would have changed the behavior of the old controller in ways that might > have introduced regressions. Changing it after the thread control was changed > would have made it more difficult to test and measure the thread control in a > desirable configuration. > > The old calculation had various problems that are described in JDK-8155996. > In particular, it can get more or less stuck at low values, and is slow to > respond to changes. > > The old controller provided a number of product options, none of which were > very useful for real applications, and none of which are very applicable to > the new controller. All of these are being obsoleted. > > -XX:-G1UseAdaptiveConcRefinement > -XX:G1ConcRefinementGreenZone= > -XX:G1ConcRefinementYellowZone= > -XX:G1ConcRefinementRedZone= > -XX:G1ConcRefinementThresholdStep= > > The new controller *could* use G1ConcRefinementGreenZone to provide a fixed > value for the target number of cards, though it is poorly named for that. > > A configuration that was useful for some kinds of debugging and testing was to > disable G1UseAdaptiveConcRefinement and set g1ConcRefinementGreenZone to a > very large value, effectively disabling concurrent refinement. To support > this use case with the new controller, the -XX:-G1UseConcRefinement diagnostic > option has been added (see JDK-8155996). > > The other options are meaningless for the new controller. > > Because of these option changes, a CSR and a release note need to accompany > this change. > > Testing: > mach5 tier1-6 > various performance tests. > local (linux-x64) tier1 with -XX:-G1UseConcRefinement > > Performance testing found no regressions, but also little or no improvement > with default options, which was expected. With default options most of our > performance tests do very little concurrent refinement. And even for those > that do, while the old controller had a number of problems, the impact of > those problems is small and hard to measure for most applications. > > When reducing G1RSetUpdatingPauseTimePercent the new controller seems to fare > better, particularly when also reducing MaxGCPauseMillis. specjbb2015 with > MaxGCPauseMillis=75 and G1RSetUpdatingPauseTimePercent=3 (and other options > held constant) showed a statistically significant improvement of about 4.5% > for critical-jOPS. Using the changed controller, the difference between this > configuration and the default is fairly small, while the baseline shows > significant degradation with the more restrictive options. > > For all tests and configurations the new controller often creates many fewer > refinement threads. Took a first pass over the code and I really like the new approach. Feels much simpler to reason about and understand. I have a few small suggestions/questions. src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 267: > 265: // If target is "unbounded" then wait forever (until explicitly > 266: // activated). This happens during startup, when we don't bother with > 267: // refinement. We use `SIZE_MAX` to signal that the target is "unbounded", like the comment says. We do this comparison a few times and I think it would make sense to define a constant with a more descriptive name for this. src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 174: > 172: if (!try_refinement_step(cr()->pending_cards_target())) { > 173: // Proceed with fewer threads if target reached. > 174: cr()->reduce_threads_wanted(); Not sure I see the reason to never try refinement when adjusted. I get that there is a case where we don't need to do refinement but that seems to be handled by an "early return" in `try_refinement_step(...)`. If we really want to skip refinement I would prefer an early return here as well. if (cr()->adjust_threads_periodically()) { // If adjustment done, don't do any refinement this round, since this thread // might no longer be wanted active. return; } ... src/hotspot/share/gc/g1/g1ConcurrentRefineThreadsNeeded.hpp line 40: > 38: G1Policy* _policy; > 39: double _update_period_ms; > 40: double _predicted_time_ms; I like to keep the names short but I wonder if it would make sense to include until gc here: `_predicted_time_until_gc_ms` src/hotspot/share/gc/g1/g1Policy.cpp line 1124: > 1122: uint remaining = target - MIN2(target, full); > 1123: size_t bytes = remaining * HeapRegion::GrainBytes; > 1124: return bytes - MIN2(bytes, allocator->used_in_alloc_regions()); >From what I can tell it's only this last line that require the `Heap_lock` to be held, so we could still do an estimate (slightly worse) even if we fail to take the lock. So my question is would it make sense to move the `Heap_lock->try_lock()` in here and just skip including `allocator->used_in_alloc_regions()` in the calculation when not getting the lock? ------------- Changes requested by sjohanss (Reviewer). PR: https://git.openjdk.org/jdk/pull/10256 From shade at openjdk.org Wed Sep 21 10:52:45 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Sep 2022 10:52:45 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v3] In-Reply-To: References: Message-ID: <3PFGSIGfFlkQT2J29Zi4XCClWgZrFgBoURpI8Xh_sWk=.cff39968-fd0f-48a7-9b03-4198c31a9282@github.com> On Wed, 21 Sep 2022 10:44:54 GMT, Xiaolin Zheng wrote: >> With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) >> >> Tested hotspot tier1 and tier2 together with other patches on QEMU. > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > (Revertible) Just to see which code style is better I think `static void assert_alignment(address pc, int alignment = NativeInstruction::instruction_size);` is cleaner, even though it requires a new include in `macroAssembler_riscv.hpp`. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2850: > 2848: > 2849: address call_pc = pc(); > 2850: assert(entry.rspec().type() == relocInfo::runtime_call_type || is_aligned(call_pc, 4), "bad alignment for patchable calls"); "4" is still here? ------------- PR: https://git.openjdk.org/jdk/pull/10370 From tschatzl at openjdk.org Wed Sep 21 10:52:49 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Sep 2022 10:52:49 GMT Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v2] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 07:08:46 GMT, Christian Hagedorn wrote: >> The DWARF debugging symbols emitted by Clang is different from what GCC is emitting. While GCC produces a complete `.debug_aranges` section (which is required in the DWARF parser), Clang does not. As a result, the DWARF parser cannot find the necessary information to proceed and create the line number information: >> >> The `.debug_aranges` section contains address range to compilation unit offset mappings. The parsing algorithm can just walk through all these entries to find the correct address range that contains the library offset of the current pc. This gives us the compilation unit offset into the `.debug_info` section from where we can proceed to parse the line number information. >> >> Without a complete `.debug_aranges` section, we fail with an assertion that we could not find the correct entry. Since [JDK-8293402](https://bugs.openjdk.org/browse/JDK-8293402), we will still get the complete stack trace at least. Nevertheless, we should still fix this assertion failure of course. But that would require a different parsing approach. We need to parse the entire `.debug_info` section instead to get to the correct compilation unit. This, however, would require a lot more work. >> >> I therefore suggest to disable DWARF parsing for Clang for now and file an RFE to support Clang in the future with a different parsing approach. I'm using the `__clang__` `ifdef` to bail out in `get_source_info()` and disable the `gtests`. I've noticed that we are currently running the `gtests` with `NOT PRODUCT` which I think is not necessary - the gtests should also work fine with product builds. I've corrected this as well but that could also be done separately. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Change old bailout fix to only apply to Clang versions older than 5.0 and add new fix with -gdwarf-aranges + -gdwarf-4 for Clang 5.0+ Minor suggestions src/hotspot/share/utilities/elfFile.cpp line 1632: > 1630: // example, for Clang debug builds which emit a relative path while GCC only emits the filename. > 1631: void DwarfFile::LineNumberProgram::strip_path_prefix(char* filename, const size_t filename_len) { > 1632: char* last_slash = strrchr(filename, '/'); Maybe use `os::file_separator()` instead of `/` here. src/hotspot/share/utilities/elfFile.cpp line 1639: > 1637: assert(bytes_written > 0, "could not strip path prefix"); > 1638: // Add null terminator. > 1639: jio_snprintf(filename + bytes_written, 1, "%s", '\0'); I think the correct format string is `%c` here. I also looked into other code that appends the `\0`, that one just pokes it in via direct assignment, but `snprintf` does not seem wrong. test/hotspot/gtest/runtime/test_os_linux.cpp line 462: > 460: // This gives us either "jni.cp" or "src/ho". In the latter case, we strip the path prefix to get to the actual > 461: // filename which, however, is useless in this case - we get "ho". > 462: ASSERT_TRUE(strcmp(buf, "jni.cp") == 0 || strcmp(buf, "ho") == 0); I did not try it out, but since we already stripped the prefix before printing the file name, why can we get "ho" here? ------------- Changes requested by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/10287 From tschatzl at openjdk.org Wed Sep 21 10:52:51 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 21 Sep 2022 10:52:51 GMT Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 07:04:12 GMT, Christian Hagedorn wrote: > Thanks Thomas for that link. I was not aware of this `-gdwarf-aranges` flag. I've tried it out and it indeed seems to work. But I was not able to build with `-flto=thin` as it resulted in build failures. I only thought that maybe we do compile with `-flto=thin` already, and so we could not use these flags. >So, I'm not sure what would happen and if it's even possible to build with it in general. Nevertheless, I suggest to go with that `-gdwarf-aranges` flag solution for now and remove the previously suggested bailout fix for Clang. I agree. > > However, `-gdwarf-aranges` (and `-gdwarf-4` which I think we should also add to avoid getting the unsupported DWARF 5 format) was only added in Clang 5.0. But we must support down to 3.5 according to: > > https://github.com/openjdk/jdk/blob/cb72f80925965c73e32c44ce3196866272306d7f/doc/building.md?plain=1#L353-L354 > > I therefore changed the previous complete bailout fix to a bailout fix for Clang versions older than 5.0. > > I've noticed that Clang is emitting a full relative path for the filename in the form of `src/hotspot/share/compiler/compilerThread.cpp:58` with debug builds (it only emits the filename with release builds). I therefore added an additional method `strip_path_prefix()` to get rid of the path prefix. Okay. ------------- PR: https://git.openjdk.org/jdk/pull/10287 From xlinzheng at openjdk.org Wed Sep 21 11:00:07 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 21 Sep 2022 11:00:07 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v4] In-Reply-To: References: Message-ID: > With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) > > Tested hotspot tier1 and tier2 together with other patches on QEMU. Xiaolin Zheng has updated the pull request incrementally with two additional commits since the last revision: - Modifications as review comments again - Revert "(Revertible) Just to see which code style is better" This reverts commit 229d535e93ceeff4f6ba32a2c882599e2999999b. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10370/files - new: https://git.openjdk.org/jdk/pull/10370/files/229d535e..8ab3377d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=02-03 Stats: 14 lines in 9 files changed: 1 ins; 2 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/10370.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10370/head:pull/10370 PR: https://git.openjdk.org/jdk/pull/10370 From xlinzheng at openjdk.org Wed Sep 21 11:00:07 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 21 Sep 2022 11:00:07 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v3] In-Reply-To: <3PFGSIGfFlkQT2J29Zi4XCClWgZrFgBoURpI8Xh_sWk=.cff39968-fd0f-48a7-9b03-4198c31a9282@github.com> References: <3PFGSIGfFlkQT2J29Zi4XCClWgZrFgBoURpI8Xh_sWk=.cff39968-fd0f-48a7-9b03-4198c31a9282@github.com> Message-ID: On Wed, 21 Sep 2022 10:48:32 GMT, Aleksey Shipilev wrote: > I think `static void assert_alignment(address pc, int alignment = NativeInstruction::instruction_size);` is cleaner, even though it requires a new include in `macroAssembler_riscv.hpp`. Thanks for the determination. I have reverted the revertible one. > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2850: > >> 2848: >> 2849: address call_pc = pc(); >> 2850: assert(entry.rspec().type() == relocInfo::runtime_call_type || is_aligned(call_pc, 4), "bad alignment for patchable calls"); > > "4" is still here? Nice catch, modified. ------------- PR: https://git.openjdk.org/jdk/pull/10370 From stuefe at openjdk.org Wed Sep 21 11:00:44 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 11:00:44 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v3] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 09:23:37 GMT, David Holmes wrote: > Okay so we currently have `parse_integer` that calls `parse_integer_impl` to do the raw numeric parsing, then applies the modifiers conversions itself. I don't see why that structure needs to change just because your are refactoring the code. My intention was to give the user two utility functions, one which parses integers (stroll with some benefits) and one which I can feed memory sizes. But since this is a point of contention, I just revert that part, its not really important. ------------- PR: https://git.openjdk.org/jdk/pull/10252 From fjiang at openjdk.org Wed Sep 21 11:45:14 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 21 Sep 2022 11:45:14 GMT Subject: RFR: 8294100: RISC-V: Move rt_call and xxx_move from SharedRuntime to MacroAssembler Message-ID: When we port Foreign Function & Memory API (Preview) for riscv backend [1], we find some methods in sharedRuntime_riscv.cpp that can be reused. Here is the list of methods that can be moved to MacroAssembler: - move32_64 - float_move - long_move - double_move - object_move - rt_call 1. https://github.com/feilongjiang/jdk/tree/riscv-foreign-api Testing: - Regular workloads like SPECjvm2008 (startup) and Dacapo on Unmatched board ------------- Commit messages: - move some methods into MacroAssembler Changes: https://git.openjdk.org/jdk/pull/10375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10375&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294100 Stats: 432 lines in 3 files changed: 220 ins; 202 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/10375.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10375/head:pull/10375 PR: https://git.openjdk.org/jdk/pull/10375 From shade at openjdk.org Wed Sep 21 11:55:18 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Sep 2022 11:55:18 GMT Subject: RFR: 8294100: RISC-V: Move rt_call and xxx_move from SharedRuntime to MacroAssembler In-Reply-To: References: Message-ID: <24g9haGNoxlpHkAolpOIAcQm76GpBuBpA3kn-eNoIUc=.064a90cf-d23d-4e5e-867d-1df799dae5d1@github.com> On Wed, 21 Sep 2022 11:40:14 GMT, Feilong Jiang wrote: > When we port Foreign Function & Memory API (Preview) for riscv backend [1], we find some methods in sharedRuntime_riscv.cpp that can be reused. > > Here is the list of methods that can be moved to MacroAssembler: > - move32_64 > - float_move > - long_move > - double_move > - object_move > - rt_call > > 1. https://github.com/feilongjiang/jdk/tree/riscv-foreign-api > > Testing: > - Regular workloads like SPECjvm2008 (startup) and Dacapo on Unmatched board Looks fine, assuming the actual moves were straight cut-and-paste. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10375 From fjiang at openjdk.org Wed Sep 21 11:57:51 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 21 Sep 2022 11:57:51 GMT Subject: RFR: 8294100: RISC-V: Move rt_call and xxx_move from SharedRuntime to MacroAssembler In-Reply-To: <24g9haGNoxlpHkAolpOIAcQm76GpBuBpA3kn-eNoIUc=.064a90cf-d23d-4e5e-867d-1df799dae5d1@github.com> References: <24g9haGNoxlpHkAolpOIAcQm76GpBuBpA3kn-eNoIUc=.064a90cf-d23d-4e5e-867d-1df799dae5d1@github.com> Message-ID: On Wed, 21 Sep 2022 11:51:53 GMT, Aleksey Shipilev wrote: > Looks fine, assuming the actual moves were straight cut-and-paste. @shipilev Thank you! Yes, it's almost straight cut-and-paste but also removes the `masm` in the methods. ------------- PR: https://git.openjdk.org/jdk/pull/10375 From shade at openjdk.org Wed Sep 21 12:03:01 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Sep 2022 12:03:01 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v4] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 11:00:07 GMT, Xiaolin Zheng wrote: >> With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) >> >> Tested hotspot tier1 and tier2 together with other patches on QEMU. > > Xiaolin Zheng has updated the pull request incrementally with two additional commits since the last revision: > > - Modifications as review comments again > - Revert "(Revertible) Just to see which code style is better" > > This reverts commit 229d535e93ceeff4f6ba32a2c882599e2999999b. src/hotspot/cpu/riscv/nativeInst_riscv.cpp line 274: > 272: > 273: // Must be 4 byte aligned > 274: MacroAssembler::assert_alignment(verified_entry); So, if the intent to pass explicit `NativeInsn::insn_size` everywhere we say "Must be 4 bytes aligned", then we should probably pass it here too. Or, drop the explicit `NativeInsn::insn_size` everywhere else? ------------- PR: https://git.openjdk.org/jdk/pull/10370 From fjiang at openjdk.org Wed Sep 21 12:03:00 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 21 Sep 2022 12:03:00 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v4] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 11:00:07 GMT, Xiaolin Zheng wrote: >> With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) >> >> Tested hotspot tier1 and tier2 together with other patches on QEMU. > > Xiaolin Zheng has updated the pull request incrementally with two additional commits since the last revision: > > - Modifications as review comments again > - Revert "(Revertible) Just to see which code style is better" > > This reverts commit 229d535e93ceeff4f6ba32a2c882599e2999999b. Marked as reviewed by fjiang (Author). ------------- PR: https://git.openjdk.org/jdk/pull/10370 From duke at openjdk.org Wed Sep 21 12:18:09 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Wed, 21 Sep 2022 12:18:09 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v9] In-Reply-To: References: Message-ID: > This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: > > vptest xmm0, xmm1 > jb if_true > if_false: > > instead of: > > vptest xmm0, xmm1 > setb r10 > movzbl r10 > testl r10 > jne if_true > if_false: > > The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: > > Before After > Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change > ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% > > I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge branch 'master' into improveVTest - Merge branch 'master' into improveVTest - fix merge problems - Merge branch 'master' into improveVTest - refactor x86 - revert renaming temp - style + use rscratch instead of tmp - fix - redo aarch - Merge branch 'master' into improveVTest - ... and 15 more: https://git.openjdk.org/jdk/compare/d14e96d9...4db8b6e5 ------------- Changes: https://git.openjdk.org/jdk/pull/9855/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=08 Stats: 483 lines in 23 files changed: 214 ins; 145 del; 124 mod Patch: https://git.openjdk.org/jdk/pull/9855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9855/head:pull/9855 PR: https://git.openjdk.org/jdk/pull/9855 From duke at openjdk.org Wed Sep 21 12:18:10 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Wed, 21 Sep 2022 12:18:10 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v7] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 19:46:39 GMT, Vladimir Kozlov wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> fix merge problems > > Looks reasonable. Please, merge with latest JDK sources and I will test it. @vnkozlov I have merged the patch with latest JDK sources. ------------- PR: https://git.openjdk.org/jdk/pull/9855 From xlinzheng at openjdk.org Wed Sep 21 12:28:40 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 21 Sep 2022 12:28:40 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v4] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 12:00:20 GMT, Aleksey Shipilev wrote: >> Xiaolin Zheng has updated the pull request incrementally with two additional commits since the last revision: >> >> - Modifications as review comments again >> - Revert "(Revertible) Just to see which code style is better" >> >> This reverts commit 229d535e93ceeff4f6ba32a2c882599e2999999b. > > src/hotspot/cpu/riscv/nativeInst_riscv.cpp line 274: > >> 272: >> 273: // Must be 4 byte aligned >> 274: MacroAssembler::assert_alignment(verified_entry); > > So, if the intent to pass explicit `NativeInsn::insn_size` everywhere we say "Must be 4 bytes aligned", then we should probably pass it here too. Or, drop the explicit `NativeInsn::insn_size` everywhere else? Well, if I understand correctly, as we want to make it clean, we won't explicitly pass `NativeInstruction::instruction_size` as an argument of `__ assert_alignment()`. And it seems currently all the call sites of `__ assert_alignment()` have already dropped the explicit argument, including this position. So... haven't we already succeeded in dropping them? The `__ align()` API needs an explicit argument as alignment, so when calling that one, the `NativeInstruction::instruction_size` is passed explicitly. ------------- PR: https://git.openjdk.org/jdk/pull/10370 From shade at openjdk.org Wed Sep 21 12:38:51 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Sep 2022 12:38:51 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v4] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 11:00:07 GMT, Xiaolin Zheng wrote: >> With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) >> >> Tested hotspot tier1 and tier2 together with other patches on QEMU. > > Xiaolin Zheng has updated the pull request incrementally with two additional commits since the last revision: > > - Modifications as review comments again > - Revert "(Revertible) Just to see which code style is better" > > This reverts commit 229d535e93ceeff4f6ba32a2c882599e2999999b. Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10370 From shade at openjdk.org Wed Sep 21 12:38:53 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Sep 2022 12:38:53 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v4] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 12:24:48 GMT, Xiaolin Zheng wrote: >> src/hotspot/cpu/riscv/nativeInst_riscv.cpp line 274: >> >>> 272: >>> 273: // Must be 4 byte aligned >>> 274: MacroAssembler::assert_alignment(verified_entry); >> >> So, if the intent to pass explicit `NativeInsn::insn_size` everywhere we say "Must be 4 bytes aligned", then we should probably pass it here too. Or, drop the explicit `NativeInsn::insn_size` everywhere else? > > Well, if I understand correctly, as we want to make it clean, we won't explicitly pass `NativeInstruction::instruction_size` as an argument of `__ assert_alignment()`. And it seems currently all the call sites of `__ assert_alignment()` have already dropped the explicit argument, including this position. So... haven't we already succeeded in dropping them? > > The `__ align()` API needs an explicit argument as alignment, so when calling that one, the `NativeInstruction::instruction_size` is passed explicitly. Sorry, I misread the patch, and confused `align` and `assert_alignment`. ------------- PR: https://git.openjdk.org/jdk/pull/10370 From xlinzheng at openjdk.org Wed Sep 21 12:38:53 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 21 Sep 2022 12:38:53 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v4] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 12:34:50 GMT, Aleksey Shipilev wrote: > Sorry, I misread the patch, and confused `align` and `assert_alignment`. That's nothing. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10370 From fyang at openjdk.org Wed Sep 21 12:41:53 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 21 Sep 2022 12:41:53 GMT Subject: RFR: 8294100: RISC-V: Move rt_call and xxx_move from SharedRuntime to MacroAssembler In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 11:40:14 GMT, Feilong Jiang wrote: > When we port Foreign Function & Memory API (Preview) for riscv backend [1], we find some methods in sharedRuntime_riscv.cpp that can be reused. > > Here is the list of methods that can be moved to MacroAssembler: > - move32_64 > - float_move > - long_move > - double_move > - object_move > - rt_call > > 1. https://github.com/feilongjiang/jdk/tree/riscv-foreign-api > > Testing: > - Regular workloads like SPECjvm2008 (startup) and Dacapo on Unmatched board Looks good. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10375 From stuefe at openjdk.org Wed Sep 21 12:47:20 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 12:47:20 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v4] In-Reply-To: References: Message-ID: <9De-oiQg9mWhLwq0l9CCMeh-j2-OvMGw3gq2fSwbxsQ=.9d5edae5-f0d0-4d27-9fde-3b0ad80bdce5@github.com> > Arguments.cpp has several size parsing functions which would be useful in other areas of the hotspot, e.g. in NMT. > > It would be nice to have them factored out into utilities, to reuse the code and to unify memory size handling. Gtests would be good too. > > To simplify reviews, I split the patch into two commits. > > The first commit (https://github.com/openjdk/jdk/pull/10252/commits/700e77e8d1469a2fc3d6611072c4b07aa34ab8e6) contains the unchanged code move without functional changes. > > The second commit (https://github.com/openjdk/jdk/pull/10252/commits/76b4f6f30cc316fd966da60ff6601f54eeb394bf) contains the functional changes I did, as well as the new gtest. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: feedback dholmes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10252/files - new: https://git.openjdk.org/jdk/pull/10252/files/339fab1f..30df4862 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10252&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10252&range=02-03 Stats: 229 lines in 4 files changed: 83 ins; 122 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/10252.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10252/head:pull/10252 PR: https://git.openjdk.org/jdk/pull/10252 From stuefe at openjdk.org Wed Sep 21 12:47:20 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 12:47:20 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v3] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 06:31:22 GMT, Thomas Stuefe wrote: >> Arguments.cpp has several size parsing functions which would be useful in other areas of the hotspot, e.g. in NMT. >> >> It would be nice to have them factored out into utilities, to reuse the code and to unify memory size handling. Gtests would be good too. >> >> To simplify reviews, I split the patch into two commits. >> >> The first commit (https://github.com/openjdk/jdk/pull/10252/commits/700e77e8d1469a2fc3d6611072c4b07aa34ab8e6) contains the unchanged code move without functional changes. >> >> The second commit (https://github.com/openjdk/jdk/pull/10252/commits/76b4f6f30cc316fd966da60ff6601f54eeb394bf) contains the functional changes I did, as well as the new gtest. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback stefank+dholmes parse_memory_size renamed back to parse_integer as David requested. ------------- PR: https://git.openjdk.org/jdk/pull/10252 From fyang at openjdk.org Wed Sep 21 12:57:44 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 21 Sep 2022 12:57:44 GMT Subject: RFR: 8294083: RISC-V: Minimal build failed with --disable-precompiled-headers In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 03:01:00 GMT, Fei Yang wrote: > The build failed due to undeclared 'java_lang_ref_Reference'. > Including the corresponding header (classfile/javaClasses.hpp) will fix it. > I see a similar issue was once fixed for aarch64: https://bugs.openjdk.org/browse/JDK-8257743 > > Testing: Minimal builds with this fix @all: Thanks for the quick review. I guess it's safe to integrate this trivial fix now. ------------- PR: https://git.openjdk.org/jdk/pull/10368 From fyang at openjdk.org Wed Sep 21 13:00:28 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 21 Sep 2022 13:00:28 GMT Subject: Integrated: 8294083: RISC-V: Minimal build failed with --disable-precompiled-headers In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 03:01:00 GMT, Fei Yang wrote: > The build failed due to undeclared 'java_lang_ref_Reference'. > Including the corresponding header (classfile/javaClasses.hpp) will fix it. > I see a similar issue was once fixed for aarch64: https://bugs.openjdk.org/browse/JDK-8257743 > > Testing: Minimal builds with this fix This pull request has now been integrated. Changeset: 0746bcb6 Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/0746bcb68fde1d59e71c573aaf448bc54a0897d3 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8294083: RISC-V: Minimal build failed with --disable-precompiled-headers Reviewed-by: fjiang, yadongwang, shade ------------- PR: https://git.openjdk.org/jdk/pull/10368 From chagedorn at openjdk.org Wed Sep 21 13:20:53 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 21 Sep 2022 13:20:53 GMT Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v3] In-Reply-To: References: Message-ID: > The DWARF debugging symbols emitted by Clang is different from what GCC is emitting. While GCC produces a complete `.debug_aranges` section (which is required in the DWARF parser), Clang does not. As a result, the DWARF parser cannot find the necessary information to proceed and create the line number information: > > The `.debug_aranges` section contains address range to compilation unit offset mappings. The parsing algorithm can just walk through all these entries to find the correct address range that contains the library offset of the current pc. This gives us the compilation unit offset into the `.debug_info` section from where we can proceed to parse the line number information. > > Without a complete `.debug_aranges` section, we fail with an assertion that we could not find the correct entry. Since [JDK-8293402](https://bugs.openjdk.org/browse/JDK-8293402), we will still get the complete stack trace at least. Nevertheless, we should still fix this assertion failure of course. But that would require a different parsing approach. We need to parse the entire `.debug_info` section instead to get to the correct compilation unit. This, however, would require a lot more work. > > I therefore suggest to disable DWARF parsing for Clang for now and file an RFE to support Clang in the future with a different parsing approach. I'm using the `__clang__` `ifdef` to bail out in `get_source_info()` and disable the `gtests`. I've noticed that we are currently running the `gtests` with `NOT PRODUCT` which I think is not necessary - the gtests should also work fine with product builds. I've corrected this as well but that could also be done separately. > > Thanks, > Christian Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: Review comments from Thomas ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10287/files - new: https://git.openjdk.org/jdk/pull/10287/files/3b1516a4..6fbeee23 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10287&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10287&range=01-02 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10287.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10287/head:pull/10287 PR: https://git.openjdk.org/jdk/pull/10287 From chagedorn at openjdk.org Wed Sep 21 13:20:56 2022 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 21 Sep 2022 13:20:56 GMT Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v2] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 10:34:07 GMT, Thomas Schatzl wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> Change old bailout fix to only apply to Clang versions older than 5.0 and add new fix with -gdwarf-aranges + -gdwarf-4 for Clang 5.0+ > > src/hotspot/share/utilities/elfFile.cpp line 1632: > >> 1630: // example, for Clang debug builds which emit a relative path while GCC only emits the filename. >> 1631: void DwarfFile::LineNumberProgram::strip_path_prefix(char* filename, const size_t filename_len) { >> 1632: char* last_slash = strrchr(filename, '/'); > > Maybe use `os::file_separator()` instead of `/` here. Also corrected a second usage of `/` in the DWARF parser code. > src/hotspot/share/utilities/elfFile.cpp line 1639: > >> 1637: assert(bytes_written > 0, "could not strip path prefix"); >> 1638: // Add null terminator. >> 1639: jio_snprintf(filename + bytes_written, 1, "%s", '\0'); > > I think the correct format string is `%c` here. I also looked into other code that appends the `\0`, that one just pokes it in via direct assignment, but `snprintf` does not seem wrong. Right, directly setting it is more straight forward. > test/hotspot/gtest/runtime/test_os_linux.cpp line 462: > >> 460: // This gives us either "jni.cp" or "src/ho". In the latter case, we strip the path prefix to get to the actual >> 461: // filename which, however, is useless in this case - we get "ho". >> 462: ASSERT_TRUE(strcmp(buf, "jni.cp") == 0 || strcmp(buf, "ho") == 0); > > I did not try it out, but since we already stripped the prefix before printing the file name, why can we get "ho" here? I updated the comment to make it more clear. Due to the small buffer, we only read "src/ho" instead of "src/hotspot/share...". And since we are also calling `strip_path_prefix`, we strip "src/" and we get "ho" as filename which is not actually a filename. ------------- PR: https://git.openjdk.org/jdk/pull/10287 From alanb at openjdk.org Wed Sep 21 13:47:47 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Sep 2022 13:47:47 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume Message-ID: Degrade Thread.suspend/resume to throw UOE unconditionally. Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). ------------- Commit messages: - Fix typo in test comment - Keep link to threadPrimitiveDeprecation.html - Merge - Tests - Initial commit Changes: https://git.openjdk.org/jdk/pull/10324/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10324&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8249627 Stats: 347 lines in 15 files changed: 148 ins; 139 del; 60 mod Patch: https://git.openjdk.org/jdk/pull/10324.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10324/head:pull/10324 PR: https://git.openjdk.org/jdk/pull/10324 From smarks at openjdk.org Wed Sep 21 13:47:48 2022 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 21 Sep 2022 13:47:48 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman wrote: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). Code changes look fine, though I didn't look too closely at the JDWP and JVMTI stuff. Nice use of JUnit. Not a big deal, but I could see leaving the links from `Thread::suspend` et. al. to the "Why deprecated?" doc, and then updating that doc to make it clear that the mechanisms have in fact been removed, but leaving the rationale that's there mostly in place. Might also be useful in the CSR to re-emphasize that this does not affect the ability to suspend and resume threads through the debugging interfaces. Of course the specs in those areas need to be updated so they no longer deal with the case of a thread that's been suspended through the API, but the debugging mechanisms' functions themselves are unchanged. ------------- PR: https://git.openjdk.org/jdk/pull/10324 From shade at openjdk.org Wed Sep 21 13:59:42 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Sep 2022 13:59:42 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 12:33:44 GMT, Stefan Karlsson wrote: > We have this code code in our signal handler: > > > #ifndef AMD64 > // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs > // This can happen in any running code (currently more frequently in > // interpreter code but has been seen in compiled code) > if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { > fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " > "to unstable signal handling in this distribution."); > } > #endif // AMD64 > > > This bug added that change: > https://bugs.openjdk.java.net/browse/JDK-8004124 > > In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: > > "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" > > That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. > > As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. > > I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. > > We've been running with this patch in the Generational ZGC repository for over a year, without any problems. I think x86_32 can/should do the same, because faulting on bona fide incorrect address currently produces a misleading error, see below. From the reading of JDK-8015837, JDK-8004124 and related issues, it looks like this code was added for x86_32 to better handle a kernel bug with exec-shield emulation on hardware without NX bit. But even then "better handle" seems to be only about crashing with more precise message. I think only the ancient hardware runs without NX, and most kernels where this bug appears otherwise are long dead. So, I think we should favor faulting with proper error instead of telling (potentially misleading) things about "unstable signal handling". $ lscpu Model name: Intel(R) Atom(TM) CPU Z530 @ 1.60GHz $ cat /etc/debian_version 11.5 $ jdk/bin/java -version openjdk version "20-testing" 2023-03-21 OpenJDK Runtime Environment (build 20-testing-builds.shipilev.net-openjdk-jdk-b210-20220919) OpenJDK Server VM (build 20-testing-builds.shipilev.net-openjdk-jdk-b210-20220919, mixed mode, sharing) $ cat Crash.java import java.lang.reflect.*; import sun.misc.Unsafe; public class Crash { public static void main(String... args) throws Exception { Field f = Unsafe.class.getDeclaredField("theUnsafe"); f.setAccessible(true); Unsafe u = (Unsafe) f.get(null); u.getInt(-1L); // 0xF....F } } $ jdk/bin/java Crash.java # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (os_linux_x86.cpp:227), pid=1033, tid=1034 # fatal error: An irrecoverable SI_KERNEL SIGSEGV has occurred due to unstable signal handling in this distribution. # ------------- PR: https://git.openjdk.org/jdk/pull/10340 From fyang at openjdk.org Wed Sep 21 14:20:38 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 21 Sep 2022 14:20:38 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v4] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 12:36:48 GMT, Xiaolin Zheng wrote: >> Sorry, I misread the patch, and confused `align` and `assert_alignment`. > >> Sorry, I misread the patch, and confused `align` and `assert_alignment`. > > That's nothing. Thanks! I think this comment should be: "// Must be 4 bytes aligned" ------------- PR: https://git.openjdk.org/jdk/pull/10370 From duke at openjdk.org Wed Sep 21 14:31:31 2022 From: duke at openjdk.org (Ashutosh Mehra) Date: Wed, 21 Sep 2022 14:31:31 GMT Subject: Integrated: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com> Message-ID: On Tue, 30 Aug 2022 23:40:32 GMT, Ashutosh Mehra wrote: > Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode. > > Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier. > The Access API is same as in ZGC [1], [2] > > [1] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/oops/oop.inline.hpp#L215 > [2] https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/classfile/javaClasses.inline.hpp#L286 > > Test with fastdebug build: > > - [x] hotspot_loom > - [x] jdk_loom > - [x] hotspot_loom in Shenandoah IU mode > - [x] jdk_loom in Shenandoah IU mode > - [x] hotspot_loom in Shenandoah IU + aggressive > - [x] jdk_loom in Shenandoah IU + aggressive > > Signed-off-by: Ashutosh Mehra This pull request has now been integrated. Changeset: 84d7ff64 Author: Ashutosh Mehra Committer: Andrew Dinn URL: https://git.openjdk.org/jdk/commit/84d7ff64d86388cc60cd8257b7b1fb5a6e8c6804 Stats: 36 lines in 9 files changed: 27 ins; 3 del; 6 mod 8288129: Shenandoah: Skynet test crashed with iu + aggressive Reviewed-by: eosterlund, rkennke ------------- PR: https://git.openjdk.org/jdk/pull/10089 From xlinzheng at openjdk.org Wed Sep 21 14:51:52 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 21 Sep 2022 14:51:52 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v5] In-Reply-To: References: Message-ID: > With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) > > Tested hotspot tier1 and tier2 together with other patches on QEMU. Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: Fix a plural form typo in one comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10370/files - new: https://git.openjdk.org/jdk/pull/10370/files/8ab3377d..a8cede0f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10370.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10370/head:pull/10370 PR: https://git.openjdk.org/jdk/pull/10370 From xlinzheng at openjdk.org Wed Sep 21 14:51:52 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 21 Sep 2022 14:51:52 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v4] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 14:16:47 GMT, Fei Yang wrote: > I think this comment should be: "// Must be 4 bytes aligned" Oh thanks for catching that. With hindsight, I found Aleksey had already hinted at it by indicating `...everywhere we say "Must be 4 bytes aligned"...`, but I failed to catch that :-) Thank you both! ------------- PR: https://git.openjdk.org/jdk/pull/10370 From shade at openjdk.org Wed Sep 21 15:30:13 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 Sep 2022 15:30:13 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 13:55:48 GMT, Aleksey Shipilev wrote: > I think x86_32 can/should do the same, because faulting on bona fide incorrect address currently produces a misleading error, see below. So I think we can just drop the entirety of `#ifndef` block: diff --git a/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp b/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp index 31afbe696a2..9cd0b9a8b58 100644 --- a/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp +++ b/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp @@ -220,17 +220,9 @@ bool PosixSignals::pd_hotspot_signal_handler(int sig, siginfo_t* info, pc = (address) os::Posix::ucontext_get_pc(uc); if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { -#ifndef AMD64 - // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs - // This can happen in any running code (currently more frequently in - // interpreter code but has been seen in compiled code) - fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " - "to unstable signal handling in this distribution."); -#else // An irrecoverable SI_KERNEL SIGSEGV has occurred. // It's likely caused by dereferencing an address larger than TASK_SIZE. return false; -#endif } // Handle ALL stack overflow variations here On the test above, x86_32 failure before: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (os_linux_x86.cpp:227), pid=1007, tid=1008 # fatal error: An irrecoverable SI_KERNEL SIGSEGV has occurred due to unstable signal handling in this distribution. # # JRE version: OpenJDK Runtime Environment (20.0) (build 20-testing-builds.shipilev.net-openjdk-jdk-b210-20220919) # Java VM: OpenJDK Server VM (20-testing-builds.shipilev.net-openjdk-jdk-b210-20220919, mixed mode, sharing, tiered, serial gc, linux-x86) # Problematic frame: # V [libjvm.so+0xa095be] PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x40e ... --------------- T H R E A D --------------- Current thread (0xb6a162d0): JavaThread "main" [_thread_in_vm, id=1008, stack(0xb6bda000,0xb6c2b000)] Stack: [0xb6bda000,0xb6c2b000], sp=0xb6c29810, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xa095be] PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x40e (os_linux_x86.cpp:227) V [libjvm.so+0xb477fa] JVM_handle_linux_signal+0x15a (signals_posix.cpp:655) V [libjvm.so+0xb47a23] javaSignalHandler(int, siginfo_t*, void*)+0x23 (signals_posix.cpp:683) C [linux-gate.so.1+0x570] __kernel_rt_sigreturn+0x0 J 860 jdk.internal.misc.Unsafe.getInt(Ljava/lang/Object;J)I java.base at 20-testing (0 bytes) @ 0xaf3706e3 [0xaf370620+0x000000c3] j jdk.internal.misc.Unsafe.getInt(J)I+3 java.base at 20-testing j sun.misc.Unsafe.getInt(J)I+4 jdk.unsupported at 20-testing j Crash.main([Ljava/lang/String;)V+26 x86_32 failure after: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xb78f5f53, pid=710, tid=711 # # JRE version: OpenJDK Runtime Environment (20.0) (build 20-internal-adhoc.buildbot.openjdk-jdk) # Java VM: OpenJDK Server VM (20-internal-adhoc.buildbot.openjdk-jdk, mixed mode, sharing, tiered, serial gc, linux-x86) # Problematic frame: # V [libjvm.so+0xc35f53] Unsafe_GetInt+0xa3 Current thread (0xb6a162c0): JavaThread "main" [_thread_in_vm, id=711, stack(0xb6b6b000,0xb6bbc000)] Stack: [0xb6b6b000,0xb6bbc000], sp=0xb6bbacf0, free space=319k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xc35f53] Unsafe_GetInt+0xa3 (unsafe.cpp:223) J 884 jdk.internal.misc.Unsafe.getInt(Ljava/lang/Object;J)I java.base at 20-internal (0 bytes) @ 0xaf372063 [0xaf371fa0+0x000000c3] j jdk.internal.misc.Unsafe.getInt(J)I+3 java.base at 20-internal j sun.misc.Unsafe.getInt(J)I+4 jdk.unsupported at 20-internal j Crash.main([Ljava/lang/String;)V+26 Current hs_err does not have siginfo printout, while the hs_err with the patch does the proper: siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x00000000 ------------- PR: https://git.openjdk.org/jdk/pull/10340 From kvn at openjdk.org Wed Sep 21 16:43:26 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 21 Sep 2022 16:43:26 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments tier2 and 3 passed. I will wait update with test and JVMCI fix before doing more testing. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From coleenp at openjdk.org Wed Sep 21 16:48:33 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 21 Sep 2022 16:48:33 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 15:24:59 GMT, Aleksey Shipilev wrote: >> I think x86_32 can/should do the same, because faulting on bona fide incorrect address currently produces a misleading error, see below. From the reading of JDK-8015837, JDK-8004124 and related issues, it looks like this code was added for x86_32 to better handle a kernel bug with exec-shield emulation on hardware without NX bit. But even then "better handle" seems to be only about crashing with more precise message. >> >> I think only the ancient hardware runs without NX, and most kernels where this bug appears otherwise are long dead. So, I think we should favor faulting with proper error instead of telling (potentially misleading) things about "unstable signal handling". >> >> >> $ lscpu >> Model name: Intel(R) Atom(TM) CPU Z530 @ 1.60GHz >> >> $ cat /etc/debian_version >> 11.5 >> >> $ jdk/bin/java -version >> openjdk version "20-testing" 2023-03-21 >> OpenJDK Runtime Environment (build 20-testing-builds.shipilev.net-openjdk-jdk-b210-20220919) >> OpenJDK Server VM (build 20-testing-builds.shipilev.net-openjdk-jdk-b210-20220919, mixed mode, sharing) >> >> $ cat Crash.java >> import java.lang.reflect.*; >> import sun.misc.Unsafe; >> >> public class Crash { >> public static void main(String... args) throws Exception { >> Field f = Unsafe.class.getDeclaredField("theUnsafe"); >> f.setAccessible(true); >> Unsafe u = (Unsafe) f.get(null); >> u.getInt(-1L); // 0xF....F >> } >> } >> >> $ jdk/bin/java Crash.java >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (os_linux_x86.cpp:227), pid=1033, tid=1034 >> # fatal error: An irrecoverable SI_KERNEL SIGSEGV has occurred due to unstable signal handling in this distribution. >> # > >> I think x86_32 can/should do the same, because faulting on bona fide incorrect address currently produces a misleading error, see below. > > So I think we can just drop the entirety of `#ifndef` block: > > > diff --git a/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp b/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp > index 31afbe696a2..9cd0b9a8b58 100644 > --- a/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp > +++ b/src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp > @@ -220,17 +220,9 @@ bool PosixSignals::pd_hotspot_signal_handler(int sig, siginfo_t* info, > pc = (address) os::Posix::ucontext_get_pc(uc); > > if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { > -#ifndef AMD64 > - // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs > - // This can happen in any running code (currently more frequently in > - // interpreter code but has been seen in compiled code) > - fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " > - "to unstable signal handling in this distribution."); > -#else > // An irrecoverable SI_KERNEL SIGSEGV has occurred. > // It's likely caused by dereferencing an address larger than TASK_SIZE. > return false; > -#endif > } > > // Handle ALL stack overflow variations here > > > On the test above, x86_32 failure before: > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (os_linux_x86.cpp:227), pid=1007, tid=1008 > # fatal error: An irrecoverable SI_KERNEL SIGSEGV has occurred due to unstable signal handling in this distribution. > # > # JRE version: OpenJDK Runtime Environment (20.0) (build 20-testing-builds.shipilev.net-openjdk-jdk-b210-20220919) > # Java VM: OpenJDK Server VM (20-testing-builds.shipilev.net-openjdk-jdk-b210-20220919, mixed mode, sharing, tiered, serial gc, linux-x86) > # Problematic frame: > # V [libjvm.so+0xa095be] PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x40e > ... > --------------- T H R E A D --------------- > > Current thread (0xb6a162d0): JavaThread "main" [_thread_in_vm, id=1008, stack(0xb6bda000,0xb6c2b000)] > > Stack: [0xb6bda000,0xb6c2b000], sp=0xb6c29810, free space=318k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xa095be] PosixSignals::pd_hotspot_signal_handler(int, siginfo_t*, ucontext_t*, JavaThread*)+0x40e (os_linux_x86.cpp:227) > V [libjvm.so+0xb477fa] JVM_handle_linux_signal+0x15a (signals_posix.cpp:655) > V [libjvm.so+0xb47a23] javaSignalHandler(int, siginfo_t*, void*)+0x23 (signals_posix.cpp:683) > C [linux-gate.so.1+0x570] __kernel_rt_sigreturn+0x0 > J 860 jdk.internal.misc.Unsafe.getInt(Ljava/lang/Object;J)I java.base at 20-testing (0 bytes) @ 0xaf3706e3 [0xaf370620+0x000000c3] > j jdk.internal.misc.Unsafe.getInt(J)I+3 java.base at 20-testing > j sun.misc.Unsafe.getInt(J)I+4 jdk.unsupported at 20-testing > j Crash.main([Ljava/lang/String;)V+26 > > > x86_32 failure after: > > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0xb78f5f53, pid=710, tid=711 > # > # JRE version: OpenJDK Runtime Environment (20.0) (build 20-internal-adhoc.buildbot.openjdk-jdk) > # Java VM: OpenJDK Server VM (20-internal-adhoc.buildbot.openjdk-jdk, mixed mode, sharing, tiered, serial gc, linux-x86) > # Problematic frame: > # V [libjvm.so+0xc35f53] Unsafe_GetInt+0xa3 > > Current thread (0xb6a162c0): JavaThread "main" [_thread_in_vm, id=711, stack(0xb6b6b000,0xb6bbc000)] > > Stack: [0xb6b6b000,0xb6bbc000], sp=0xb6bbacf0, free space=319k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xc35f53] Unsafe_GetInt+0xa3 (unsafe.cpp:223) > J 884 jdk.internal.misc.Unsafe.getInt(Ljava/lang/Object;J)I java.base at 20-internal (0 bytes) @ 0xaf372063 [0xaf371fa0+0x000000c3] > j jdk.internal.misc.Unsafe.getInt(J)I+3 java.base at 20-internal > j sun.misc.Unsafe.getInt(J)I+4 jdk.unsupported at 20-internal > j Crash.main([Ljava/lang/String;)V+26 > > > Current hs_err does not have siginfo printout, while the hs_err with the patch does the proper: > > > siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x00000000 Thanks @shipilev for the comment about the origin of this change. We used to see this error a LOT randomly and it was always painful to diagnose, but I agree that this hardware/config is likely long gone and we can remove this special message. ------------- PR: https://git.openjdk.org/jdk/pull/10340 From kvn at openjdk.org Wed Sep 21 17:14:19 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 21 Sep 2022 17:14:19 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v7] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 19:46:39 GMT, Vladimir Kozlov wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> fix merge problems > > Looks reasonable. Please, merge with latest JDK sources and I will test it. > @vnkozlov I have merged the patch with latest JDK sources. @merykitty I submitted testing. ------------- PR: https://git.openjdk.org/jdk/pull/9855 From cjplummer at openjdk.org Wed Sep 21 17:15:19 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 21 Sep 2022 17:15:19 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: <_bEledEsS53FuI7oLyVxlCrmpLwJFQitD0uB320-tR8=.7c04ba0b-963b-4bdd-8972-14c0950751dd@github.com> On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman wrote: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). Changes look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/10324 From cjplummer at openjdk.org Wed Sep 21 17:29:23 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 21 Sep 2022 17:29:23 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 22:15:49 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 713: >> >>> 711: if (!jt->is_in_tmp_VTMS_transition()) { >>> 712: jvf = check_and_skip_hidden_frames(jt, jvf); >>> 713: } >> >> I think this comment needs some help. It's hard to match it up with what the code is doing. I think you are saying you want to avoid skipping hidden frames when in transition, although if that's the case, it's not clear to me why not skipping is ok. >> >> Also is skipping (or not skipping) ok regardless of the JvmtiEnvBase::is_cthread_with_continuation() result? > > Thank you for reviewing and the comment, Chris. > I agree, this part and related comment is kind of obscure. > I'll think how to make the comment better. > In fact, all temporary VTMS transitions do temporary switch the `JavaThread` identity from virtual thread to carrier. There is no need to skip frames because there are no real carrier thread frames at the top. Moreover, any attempt to skip frames which are in transition works incorrectly and gives an empty stack. The check `JvmtiEnvBase::is_cthread_with_continuation()` is needed to make sure we have a deal with a continuation. There is no need to skip frames otherwise. It's still not clear to me if the result of `JvmtiEnvBase::is_cthread_with_continuation()` impacts if you have to possibly skip hidden frames. In other words, do you always have to do the `if` block that follows, no matter what `JvmtiEnvBase::is_cthread_with_continuation()` returns? If you don't, then maybe instead of a "? :" expression, an if/else would be better. I'm not sure if the following is correct, but something like: javaVFrame *jvf; if (JvmtiEnvBase::is_cthread_with_continuation(jt)) { jvf = jt->carrier_last_java_vframe(reg_map_p); } else { jvf - jt->last_java_vframe(reg_map_p); // Skipping hidden frames when jt->is_in_tmp_VTMS_transition()==true results // in returning jvf==NULL, and so, empty stack traces for carrier threads. if (!jt->is_in_tmp_VTMS_transition()) { jvf = check_and_skip_hidden_frames(jt, jvf); } } ------------- PR: https://git.openjdk.org/jdk/pull/10321 From cjplummer at openjdk.org Wed Sep 21 17:32:17 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 21 Sep 2022 17:32:17 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 22:41:50 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/runtime/javaThread.cpp line 1174: >> >>> 1172: #if INCLUDE_JVMTI >>> 1173: // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks. >>> 1174: assert(!is_in_non_tmp_VTMS_transition(), "no suspend allowed in VTMS transition"); >> >> IMHO, a non tmp VTMS transition should be considered a type of VTMS transition, so the assert check here does not really match the assert text. Also see my related comments below on naming and use of these flags and APIs. > > Thanks. Accepted. I thought I was pointing out a naming issue, but your change indicates that it was actually a bug, and it is ok to be in a tmp transition here. Is that correct? ------------- PR: https://git.openjdk.org/jdk/pull/10321 From jbhateja at openjdk.org Wed Sep 21 17:53:36 2022 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 21 Sep 2022 17:53:36 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Fri, 2 Sep 2022 00:52:49 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments Hi Smita, Adding some review comments. Best Regards src/hotspot/cpu/x86/assembler_x86.cpp line 1925: > 1923: > 1924: void Assembler::vcvtps2ph(XMMRegister dst, XMMRegister src, int imm8, int vector_len) { > 1925: assert(VM_Version::supports_evex() || VM_Version::supports_f16c(), ""); Since you are accepting vector_len so adding a AVX512VL check will be more appropriate here. src/hotspot/cpu/x86/assembler_x86.cpp line 1932: > 1930: > 1931: void Assembler::evcvtps2ph(Address dst, KRegister mask, XMMRegister src, int imm8, int vector_len) { > 1932: assert(VM_Version::supports_evex(), ""); Same as above. src/hotspot/cpu/x86/assembler_x86.cpp line 1946: > 1944: > 1945: void Assembler::vcvtph2ps(XMMRegister dst, XMMRegister src, int vector_len) { > 1946: assert(VM_Version::supports_evex() || VM_Version::supports_f16c(), ""); same as above. src/hotspot/cpu/x86/assembler_x86.cpp line 1949: > 1947: InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */false, /* no_mask_reg */ true, /* uses_vl */ true); > 1948: int encode = vex_prefix_and_encode(dst->encoding(), 0, src->encoding(), VEX_SIMD_66, VEX_OPCODE_0F_38, &attributes); > 1949: emit_int16((unsigned char)0x13, (0xC0 | encode)); Please rebase this patch, recently emit_int16 have starting accepting the unsigned char argument. src/hotspot/cpu/x86/x86.ad line 1686: > 1684: case Op_ConvHF2F: > 1685: if (!VM_Version::supports_f16c() && !(VM_Version::supports_evex() && > 1686: VM_Version::supports_avx512vl())) { Redundant evex check can be removed. src/hotspot/cpu/x86/x86_64.ad line 11309: > 11307: %} > 11308: > 11309: instruct convF2HF_reg_reg(rRegI dst, regF src, regF tmp) %{ You can move these patterns to common .ad file it will also handle 32 bit target. src/hotspot/cpu/x86/x86_64.ad line 11329: > 11327: ins_encode %{ > 11328: __ movl($rtmp$$Register, 0x1); > 11329: __ kmovdl($ktmp$$KRegister, $rtmp$$Register); kmovdl needs AVX512BW, so there should a check for it in the predicate. src/hotspot/share/opto/convertnode.cpp line 166: > 164: //============================================================================= > 165: //------------------------------Value------------------------------------------ > 166: const Type* ConvF2HFNode::Value(PhaseGVN* phase) const { IR framework based test will compliment newly introduced IR nodes. src/hotspot/share/opto/convertnode.hpp line 107: > 105: class ConvF2HFNode : public Node { > 106: public: > 107: ConvF2HFNode( Node *in1 ) : Node(0,in1) {} Additional space b/w , and in1 src/hotspot/share/opto/convertnode.hpp line 146: > 144: class ConvHF2FNode : public Node { > 145: public: > 146: ConvHF2FNode( Node *in1 ) : Node(0,in1) {} Space b/w , and in1 src/hotspot/share/runtime/sharedRuntime.cpp line 452: > 450: // Reference implementation at src/java.base/share/classes/java/lang/Float.java:floatToFloat16 > 451: JRT_LEAF(jshort, SharedRuntime::f2hf(jfloat x)) > 452: jint doppel = SharedRuntime::f2i(x); Newly added constant value computation runtime routines can be validated by a gtest. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From jwaters at openjdk.org Wed Sep 21 18:03:06 2022 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 21 Sep 2022 18:03:06 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v13] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: Rework JLI_ReportErrorMessageSys ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/ff398500..3303cbb8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=11-12 Stats: 145921 lines in 2250 files changed: 67760 ins; 63795 del; 14366 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From sspitsyn at openjdk.org Wed Sep 21 22:18:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Sep 2022 22:18:22 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman wrote: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10324 From fjiang at openjdk.org Thu Sep 22 00:58:32 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 22 Sep 2022 00:58:32 GMT Subject: RFR: 8294100: RISC-V: Move rt_call and xxx_move from SharedRuntime to MacroAssembler In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 12:39:29 GMT, Fei Yang wrote: >> When we port Foreign Function & Memory API (Preview) for riscv backend [1], we find some methods in sharedRuntime_riscv.cpp that can be reused. >> >> Here is the list of methods that can be moved to MacroAssembler: >> - move32_64 >> - float_move >> - long_move >> - double_move >> - object_move >> - rt_call >> >> 1. https://github.com/feilongjiang/jdk/tree/riscv-foreign-api >> >> Testing: >> - Regular workloads like SPECjvm2008 (startup) and Dacapo on Unmatched board > > Looks good. @RealFYang @shipilev -- Thanks for the review! ------------- PR: https://git.openjdk.org/jdk/pull/10375 From fjiang at openjdk.org Thu Sep 22 01:01:21 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 22 Sep 2022 01:01:21 GMT Subject: Integrated: 8294100: RISC-V: Move rt_call and xxx_move from SharedRuntime to MacroAssembler In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 11:40:14 GMT, Feilong Jiang wrote: > When we port Foreign Function & Memory API (Preview) for riscv backend [1], we find some methods in sharedRuntime_riscv.cpp that can be reused. > > Here is the list of methods that can be moved to MacroAssembler: > - move32_64 > - float_move > - long_move > - double_move > - object_move > - rt_call > > 1. https://github.com/feilongjiang/jdk/tree/riscv-foreign-api > > Testing: > - Regular workloads like SPECjvm2008 (startup) and Dacapo on Unmatched board This pull request has now been integrated. Changeset: 742bc041 Author: Feilong Jiang Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/742bc041eaba1ff9beb7f5b6d896e4f382b030ea Stats: 432 lines in 3 files changed: 220 ins; 202 del; 10 mod 8294100: RISC-V: Move rt_call and xxx_move from SharedRuntime to MacroAssembler Reviewed-by: shade, fyang ------------- PR: https://git.openjdk.org/jdk/pull/10375 From fyang at openjdk.org Thu Sep 22 02:08:18 2022 From: fyang at openjdk.org (Fei Yang) Date: Thu, 22 Sep 2022 02:08:18 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v5] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 14:51:52 GMT, Xiaolin Zheng wrote: >> With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) >> >> Tested hotspot tier1 and tier2 together with other patches on QEMU. > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Fix a plural form typo in one comment src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 101: > 99: assert(is_aligned(pc, alignment), "bad alignment"); > 100: } > 101: Would you mind a few more tweaks? I don't think we need two versions here. Maybe we can only keep the second one and remove the first one here? Then the call sites will look more consistent passing an explict 'pc' argument. Also we should move the function definition to macroAssembler_riscv.hpp. ------------- PR: https://git.openjdk.org/jdk/pull/10370 From lmesnik at openjdk.org Thu Sep 22 03:04:26 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 22 Sep 2022 03:04:26 GMT Subject: RFR: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume [v3] In-Reply-To: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: > The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. > Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. > > Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10351/files - new: https://git.openjdk.org/jdk/pull/10351/files/356ee078..c892fca0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10351&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10351&range=01-02 Stats: 112 lines in 5 files changed: 81 ins; 16 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/10351.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10351/head:pull/10351 PR: https://git.openjdk.org/jdk/pull/10351 From lmesnik at openjdk.org Thu Sep 22 03:06:17 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 22 Sep 2022 03:06:17 GMT Subject: RFR: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume [v2] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Tue, 20 Sep 2022 21:41:31 GMT, Chris Plummer wrote: > > Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. > > As far as I know, this is the only test we have for ThreadReference.interrupt(). Also see [JDK-8282384](https://bugs.openjdk.org/browse/JDK-8282384), which points out that we have no test for ThreadReference.interrupt() of a virtual thread, and suggests modifying this test to support virtual threads. I actually attempted to do this, but ran into an issue because Thread.resume() is not supported for virtual threads, but seems your changes get rid of resume() so it shouldn't be an issue anymore. > > I think losing this test case means we no longer test interrupt when suspended. Maybe we need to have the debugger side initiate the suspending. Let me file another bug for this. Just don't block Alan's fix https://github.com/openjdk/jdk/pull/10324 ------------- PR: https://git.openjdk.org/jdk/pull/10351 From xlinzheng at openjdk.org Thu Sep 22 03:20:50 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 22 Sep 2022 03:20:50 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v6] In-Reply-To: References: Message-ID: > With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) > > Tested hotspot tier1 and tier2 together with other patches on QEMU. Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: Revise as to comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10370/files - new: https://git.openjdk.org/jdk/pull/10370/files/a8cede0f..5e54d5dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=04-05 Stats: 17 lines in 7 files changed: 1 ins; 8 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/10370.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10370/head:pull/10370 PR: https://git.openjdk.org/jdk/pull/10370 From xlinzheng at openjdk.org Thu Sep 22 03:20:51 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 22 Sep 2022 03:20:51 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v5] In-Reply-To: References: Message-ID: <-nEtEIrf1mfUx_BEljQk6dZmVlRgCGrGVkhmHiMrkdc=.8ff45e5c-97b0-43c4-a97b-d12ad4123c62@github.com> On Thu, 22 Sep 2022 02:04:27 GMT, Fei Yang wrote: >> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix a plural form typo in one comment > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 101: > >> 99: assert(is_aligned(pc, alignment), "bad alignment"); >> 100: } >> 101: > > Would you mind a few more tweaks? > I don't think we need two versions here. Maybe we can only keep the second one and remove the first one here? > Then the call sites will look more consistent passing an explict 'pc' argument. > Also we should move the function definition to macroAssembler_riscv.hpp. Of course, revised and add `static inline void` for it in the hpp file. ------------- PR: https://git.openjdk.org/jdk/pull/10370 From xlinzheng at openjdk.org Thu Sep 22 03:23:14 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 22 Sep 2022 03:23:14 GMT Subject: RFR: 8294086: RISC-V: Cleanup InstructionMark usages in the backend In-Reply-To: <0vL9HTzSH6i7KOSLmhCGPASAQjDzjnuCz3I7SsRrReA=.7a12d4ad-9f35-41ad-b4b3-a974b1dd9b61@github.com> References: <0vL9HTzSH6i7KOSLmhCGPASAQjDzjnuCz3I7SsRrReA=.7a12d4ad-9f35-41ad-b4b3-a974b1dd9b61@github.com> Message-ID: On Wed, 21 Sep 2022 03:50:22 GMT, Xiaolin Zheng wrote: > This is a trivial cleanup of dummy `InstructionMark` usages in the RISC-V backend. There are no more `InstructionMark` usages in the backend now. > > Tested hotspot tier1 and tier2 on Qemu. Thank you for reviewing! Going to prepare another cleanup then. ------------- PR: https://git.openjdk.org/jdk/pull/10369 From xlinzheng at openjdk.org Thu Sep 22 03:50:37 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 22 Sep 2022 03:50:37 GMT Subject: Integrated: 8294086: RISC-V: Cleanup InstructionMark usages in the backend In-Reply-To: <0vL9HTzSH6i7KOSLmhCGPASAQjDzjnuCz3I7SsRrReA=.7a12d4ad-9f35-41ad-b4b3-a974b1dd9b61@github.com> References: <0vL9HTzSH6i7KOSLmhCGPASAQjDzjnuCz3I7SsRrReA=.7a12d4ad-9f35-41ad-b4b3-a974b1dd9b61@github.com> Message-ID: <1alkxcZWj3-W1OoACr_wrK_keP3kGBaXz5lSsM4XdUY=.aa40905d-b3fa-462c-89c3-097fd418666d@github.com> On Wed, 21 Sep 2022 03:50:22 GMT, Xiaolin Zheng wrote: > This is a trivial cleanup of dummy `InstructionMark` usages in the RISC-V backend. There are no more `InstructionMark` usages in the backend now. > > Tested hotspot tier1 and tier2 on Qemu. This pull request has now been integrated. Changeset: d5bee4a0 Author: Xiaolin Zheng Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/d5bee4a0dffebcf3037b83fa3f7bc635dd6b1303 Stats: 21 lines in 3 files changed: 0 ins; 12 del; 9 mod 8294086: RISC-V: Cleanup InstructionMark usages in the backend Reviewed-by: fjiang, fyang ------------- PR: https://git.openjdk.org/jdk/pull/10369 From cjplummer at openjdk.org Thu Sep 22 05:18:10 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 22 Sep 2022 05:18:10 GMT Subject: RFR: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume [v3] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Thu, 22 Sep 2022 03:04:26 GMT, Leonid Mesnik wrote: >> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. >> Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. >> >> Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fix serviceability changes look good ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/10351 From xlinzheng at openjdk.org Thu Sep 22 05:57:03 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 22 Sep 2022 05:57:03 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v7] In-Reply-To: References: Message-ID: > With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) > > Tested hotspot tier1 and tier2 together with other patches on QEMU. Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: Simply unify a remaining assertion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10370/files - new: https://git.openjdk.org/jdk/pull/10370/files/5e54d5dd..bb009697 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=05-06 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10370.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10370/head:pull/10370 PR: https://git.openjdk.org/jdk/pull/10370 From rehn at openjdk.org Thu Sep 22 06:13:21 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 22 Sep 2022 06:13:21 GMT Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications [v4] In-Reply-To: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com> References: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com> Message-ID: On Tue, 20 Sep 2022 10:37:41 GMT, David Holmes wrote: >> This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref: >> >> JDK-8290196 12.8: Clarify the definition of program exit >> https://bugs.openjdk.org/browse/JDK-8290196 >> >> JDK-8290388 5.7: Clarify the definition of JVM termination >> https://bugs.openjdk.org/browse/JDK-8290388 >> >> JDK-8290036 Define and specify Runtime shutdown sequence >> https://bugs.openjdk.org/browse/JDK-8290036 >> >> Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes: >> >> 1. The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this) >> >> 2. We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot. >> >> Issue 2 covers the code change, and regression test, in this PR. >> >> In addition the specification changes can be seen here: >> >> - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html >> - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html >> - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html >> >> The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment. >> >> Thank you. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix JniVersion test Looks good, thank you! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10352 From fjiang at openjdk.org Thu Sep 22 06:16:23 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 22 Sep 2022 06:16:23 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v7] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 05:57:03 GMT, Xiaolin Zheng wrote: >> With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) >> >> Tested hotspot tier1 and tier2 together with other patches on QEMU. > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Simply unify a remaining assertion src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp line 1375: > 1373: void LIR_Assembler::emit_static_call_stub() { > 1374: address call_pc = __ pc(); > 1375: __ assert_alignment(call_pc); As `assert_alignment` is defined as a static method, there is no need for `__`. `MacroAssembler::assert_alignment(call_pc)` would be better. src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 265: > 263: __ bind(local_guard); > 264: > 265: __ assert_alignment(__ pc()); ditto src/hotspot/cpu/riscv/riscv.ad line 1321: > 1319: // insert a nop at the start of the prolog so we can patch in a > 1320: // branch if we need to invalidate the method later > 1321: __ assert_alignment(__ pc()); ditto src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 1143: > 1141: > 1142: // First instruction must be a nop as it may need to be patched on deoptimisation > 1143: __ assert_alignment(__ pc()); ditto src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 1295: > 1293: // If we have to make this method not-entrant we'll overwrite its > 1294: // first instruction with a jump. > 1295: __ assert_alignment(__ pc()); ditto ------------- PR: https://git.openjdk.org/jdk/pull/10370 From shade at openjdk.org Thu Sep 22 06:39:21 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Sep 2022 06:39:21 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 12:33:44 GMT, Stefan Karlsson wrote: > We have this code code in our signal handler: > > > #ifndef AMD64 > // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs > // This can happen in any running code (currently more frequently in > // interpreter code but has been seen in compiled code) > if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { > fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " > "to unstable signal handling in this distribution."); > } > #endif // AMD64 > > > This bug added that change: > https://bugs.openjdk.java.net/browse/JDK-8004124 > > In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: > > "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" > > That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. > > As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. > > I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. > > We've been running with this patch in the Generational ZGC repository for over a year, without any problems. (Putting a formal review comment) We would be better off doing the same for x86_32, as per https://github.com/openjdk/jdk/pull/10340#issuecomment-1253868230 ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10340 From xlinzheng at openjdk.org Thu Sep 22 06:41:47 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 22 Sep 2022 06:41:47 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v8] In-Reply-To: References: Message-ID: > With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) > > Tested hotspot tier1 and tier2 together with other patches on QEMU. Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: Some code style modifications ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10370/files - new: https://git.openjdk.org/jdk/pull/10370/files/bb009697..83bdcd2c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10370&range=06-07 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10370.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10370/head:pull/10370 PR: https://git.openjdk.org/jdk/pull/10370 From xlinzheng at openjdk.org Thu Sep 22 06:41:48 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 22 Sep 2022 06:41:48 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v7] In-Reply-To: References: Message-ID: <_hgPH_zwBpbrZYhWOo0wYKlY-maKFMqZSUKJYliaLOs=.8a273361-edb1-4d6e-82f8-9ad50548118e@github.com> On Thu, 22 Sep 2022 06:06:32 GMT, Feilong Jiang wrote: >> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: >> >> Simply unify a remaining assertion > > src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp line 1375: > >> 1373: void LIR_Assembler::emit_static_call_stub() { >> 1374: address call_pc = __ pc(); >> 1375: __ assert_alignment(call_pc); > > As `assert_alignment` is defined as a static method, there is no need for `__`. `MacroAssembler::assert_alignment(call_pc)` would be better. Reasonable; all done. ------------- PR: https://git.openjdk.org/jdk/pull/10370 From stefank at openjdk.org Thu Sep 22 06:43:19 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 22 Sep 2022 06:43:19 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs In-Reply-To: References: Message-ID: <7KACXehZVXxaDmad_INi_QynXg9PTGN1OAvH_ZtUm0g=.fd45eecc-559b-4d5d-bdb3-5ff1d71af515@github.com> On Mon, 19 Sep 2022 12:33:44 GMT, Stefan Karlsson wrote: > We have this code code in our signal handler: > > > #ifndef AMD64 > // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs > // This can happen in any running code (currently more frequently in > // interpreter code but has been seen in compiled code) > if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { > fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " > "to unstable signal handling in this distribution."); > } > #endif // AMD64 > > > This bug added that change: > https://bugs.openjdk.java.net/browse/JDK-8004124 > > In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: > > "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" > > That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. > > As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. > > I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. > > We've been running with this patch in the Generational ZGC repository for over a year, without any problems. Thanks for the investigations, comments, and reviews! I'll remove the 32-bit ifdefs. ------------- PR: https://git.openjdk.org/jdk/pull/10340 From fjiang at openjdk.org Thu Sep 22 06:50:25 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 22 Sep 2022 06:50:25 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v8] In-Reply-To: References: Message-ID: <_89_cmDWHSwBq4945MDgtN1BkP3t1cKMkPBeMKyDgUQ=.c06d2b91-1588-4b2b-8675-e3e8c945cf7d@github.com> On Thu, 22 Sep 2022 06:41:47 GMT, Xiaolin Zheng wrote: >> With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) >> >> Tested hotspot tier1 and tier2 together with other patches on QEMU. > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Some code style modifications Marked as reviewed by fjiang (Author). ------------- PR: https://git.openjdk.org/jdk/pull/10370 From stefank at openjdk.org Thu Sep 22 06:51:05 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 22 Sep 2022 06:51:05 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs [v2] In-Reply-To: References: Message-ID: > We have this code code in our signal handler: > > > #ifndef AMD64 > // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs > // This can happen in any running code (currently more frequently in > // interpreter code but has been seen in compiled code) > if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { > fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " > "to unstable signal handling in this distribution."); > } > #endif // AMD64 > > > This bug added that change: > https://bugs.openjdk.java.net/browse/JDK-8004124 > > In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: > > "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" > > That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. > > As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. > > I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. > > We've been running with this patch in the Generational ZGC repository for over a year, without any problems. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Remove 32-bit error handling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10340/files - new: https://git.openjdk.org/jdk/pull/10340/files/f31550e4..d0d1bf73 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10340&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10340&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10340.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10340/head:pull/10340 PR: https://git.openjdk.org/jdk/pull/10340 From shade at openjdk.org Thu Sep 22 06:51:05 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Sep 2022 06:51:05 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs [v2] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 06:47:22 GMT, Stefan Karlsson wrote: >> We have this code code in our signal handler: >> >> >> #ifndef AMD64 >> // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs >> // This can happen in any running code (currently more frequently in >> // interpreter code but has been seen in compiled code) >> if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { >> fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " >> "to unstable signal handling in this distribution."); >> } >> #endif // AMD64 >> >> >> This bug added that change: >> https://bugs.openjdk.java.net/browse/JDK-8004124 >> >> In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: >> >> "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" >> >> That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. >> >> As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. >> >> I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. >> >> We've been running with this patch in the Generational ZGC repository for over a year, without any problems. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Remove 32-bit error handling Looks fine to me! ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10340 From dlong at openjdk.org Thu Sep 22 06:51:06 2022 From: dlong at openjdk.org (Dean Long) Date: Thu, 22 Sep 2022 06:51:06 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs [v2] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 06:47:22 GMT, Stefan Karlsson wrote: >> We have this code code in our signal handler: >> >> >> #ifndef AMD64 >> // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs >> // This can happen in any running code (currently more frequently in >> // interpreter code but has been seen in compiled code) >> if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { >> fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " >> "to unstable signal handling in this distribution."); >> } >> #endif // AMD64 >> >> >> This bug added that change: >> https://bugs.openjdk.java.net/browse/JDK-8004124 >> >> In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: >> >> "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" >> >> That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. >> >> As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. >> >> I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. >> >> We've been running with this patch in the Generational ZGC repository for over a year, without any problems. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Remove 32-bit error handling Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10340 From kbarrett at openjdk.org Thu Sep 22 07:01:30 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 22 Sep 2022 07:01:30 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v2] In-Reply-To: References: Message-ID: > 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal > 8155996: Improve concurrent refinement green zone control > 8134303: Introduce -XX:-G1UseConcRefinement > > Please review this change to the control of concurrent refinement. > > This new controller takes a different approach to the problem, addressing a > number of issues. > > The old controller used a multiple of the target number of cards to determine > the range over which increasing numbers of refinement threads should be > activated, and finally activating mutator refinement. This has a variety of > problems. It doesn't account for the processing rate, the rate of new dirty > cards, or the time available to perform the processing. This often leads to > unnecessary spikes in the number of running refinement threads. It also tends > to drive the pending number to the target quickly and keep it there, removing > the benefit from having pending dirty cards filter out new cards for nearby > writes. It can't delay and leave excess cards in the queue because it could > be a long time before another buffer is enqueued. > > The old controller was triggered by mutator threads enqueing card buffers, > when the number of cards in the queue exceeded a threshold near the target. > This required a complex activation protocol between the mutators and the > refinement threads. > > With the new controller there is a primary refinement thread that periodically > estimates how many refinement threads need to be running to reach the target > in time for the next GC, along with whether to also activate mutator > refinement. If the primary thread stops running because it isn't currently > needed, it sleeps for a period and reevaluates on wakeup. This eliminates any > involvement in the activation of refinement threads by mutator threads. > > The estimate of how many refinement threads are needed uses a prediction of > time until the next GC, the number of buffered cards, the predicted rate of > new dirty cards, and the predicted refinement rate. The number of running > threads is adjusted based on these periodically performed estimates. > > This new approach allows more dirty cards to be left in the queue until late > in the mutator phase, typically reducing the rate of new dirty cards, which > reduces the amount of concurrent refinement work needed. > > It also smooths out the number of running refinement threads, eliminating the > unnecessarily large spikes that are common with the old method. One benefit > is that the number of refinement threads (lazily) allocated is often much > lower now. (This plus UseDynamicNumberOfGCThreads mitigates the problem > described in JDK-8153225.) > > This change also provides a new method for calculating for the number of dirty > cards that should be pending at the start of a GC. While this calculation is > conceptually distinct from the thread control, the two were significanly > intertwined in the old controller. Changing this calculation separately and > first would have changed the behavior of the old controller in ways that might > have introduced regressions. Changing it after the thread control was changed > would have made it more difficult to test and measure the thread control in a > desirable configuration. > > The old calculation had various problems that are described in JDK-8155996. > In particular, it can get more or less stuck at low values, and is slow to > respond to changes. > > The old controller provided a number of product options, none of which were > very useful for real applications, and none of which are very applicable to > the new controller. All of these are being obsoleted. > > -XX:-G1UseAdaptiveConcRefinement > -XX:G1ConcRefinementGreenZone= > -XX:G1ConcRefinementYellowZone= > -XX:G1ConcRefinementRedZone= > -XX:G1ConcRefinementThresholdStep= > > The new controller *could* use G1ConcRefinementGreenZone to provide a fixed > value for the target number of cards, though it is poorly named for that. > > A configuration that was useful for some kinds of debugging and testing was to > disable G1UseAdaptiveConcRefinement and set g1ConcRefinementGreenZone to a > very large value, effectively disabling concurrent refinement. To support > this use case with the new controller, the -XX:-G1UseConcRefinement diagnostic > option has been added (see JDK-8155996). > > The other options are meaningless for the new controller. > > Because of these option changes, a CSR and a release note need to accompany > this change. > > Testing: > mach5 tier1-6 > various performance tests. > local (linux-x64) tier1 with -XX:-G1UseConcRefinement > > Performance testing found no regressions, but also little or no improvement > with default options, which was expected. With default options most of our > performance tests do very little concurrent refinement. And even for those > that do, while the old controller had a number of problems, the impact of > those problems is small and hard to measure for most applications. > > When reducing G1RSetUpdatingPauseTimePercent the new controller seems to fare > better, particularly when also reducing MaxGCPauseMillis. specjbb2015 with > MaxGCPauseMillis=75 and G1RSetUpdatingPauseTimePercent=3 (and other options > held constant) showed a statistically significant improvement of about 4.5% > for critical-jOPS. Using the changed controller, the difference between this > configuration and the default is fairly small, while the baseline shows > significant degradation with the more restrictive options. > > For all tests and configurations the new controller often creates many fewer > refinement threads. Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: - lengthen some names - improve comments for primary do_refinement_step - add is_pending_cards_target_initialized ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10256/files - new: https://git.openjdk.org/jdk/pull/10256/files/f4904691..ffdf6339 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10256&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10256&range=00-01 Stats: 54 lines in 5 files changed: 25 ins; 4 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/10256.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10256/head:pull/10256 PR: https://git.openjdk.org/jdk/pull/10256 From xlinzheng at openjdk.org Thu Sep 22 07:02:06 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 22 Sep 2022 07:02:06 GMT Subject: RFR: 8294187: RISC-V: Unify all relocations for the backend into MacroAssembler::relocate() Message-ID: Unify all relocations into MacroAssembler::relocate() as a simple cleanup, so that there are platform-related entrances for them. We will have needs to insert some code into the new MacroAssembler::relocate() afterward. Also, the (__ pc()) everywhere seems a little verbose here. Tested hotspot tier1 and tier2 on QEMU. ------------- Commit messages: - RISC-V: Unify all relocations for the backend to MacroAssembler::relocate() Changes: https://git.openjdk.org/jdk/pull/10384/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10384&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294187 Stats: 37 lines in 6 files changed: 18 ins; 6 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/10384.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10384/head:pull/10384 PR: https://git.openjdk.org/jdk/pull/10384 From thartmann at openjdk.org Thu Sep 22 07:07:16 2022 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 22 Sep 2022 07:07:16 GMT Subject: RFR: 8293618: x86: Wrong code generation in class Assembler In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 15:30:01 GMT, Quan Anh Mai wrote: > Hi, > > This patch fixes some issues in the code generation of x86 assembler: > > - `Assembler::testl` misses `prefix(dst)` > - `Assembler::addw` misses the 0x66 prefix > - `Assembler::emit_operand` needs the length of the instruction from the address operand, this is often forgotten, making this parameter explicit to prevent potential issues > - The assembler should not do optimisations that change the actual emitted instructions, these should be moved to `MacroAssembler` instead > > AFAICT there is no failure due to these mistakes. Please take a look and give reviews. > Thanks you very much. src/hotspot/cpu/x86/assembler_x86.cpp line 351: > 349: } > 350: > 351: void Assembler::emit_arith_operand_imm32(int op1, Register rm, Address adr, int32_t imm32) { Why is this needed? ------------- PR: https://git.openjdk.org/jdk/pull/10240 From kbarrett at openjdk.org Thu Sep 22 07:10:26 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 22 Sep 2022 07:10:26 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v2] In-Reply-To: <0dfe0HnqB-TnjKk6-CFF9ANIeyz8NSFIid-b_q1r5ZY=.0a5ad315-5dd3-4340-9ef2-0e9f508b24c1@github.com> References: <0dfe0HnqB-TnjKk6-CFF9ANIeyz8NSFIid-b_q1r5ZY=.0a5ad315-5dd3-4340-9ef2-0e9f508b24c1@github.com> Message-ID: On Wed, 21 Sep 2022 07:43:08 GMT, Stefan Johansson wrote: >> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: >> >> - lengthen some names >> - improve comments for primary do_refinement_step >> - add is_pending_cards_target_initialized > > src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 267: > >> 265: // If target is "unbounded" then wait forever (until explicitly >> 266: // activated). This happens during startup, when we don't bother with >> 267: // refinement. > > We use `SIZE_MAX` to signal that the target is "unbounded", like the comment says. We do this comparison a few times and I think it would make sense to define a constant with a more descriptive name for this. Added `is_pending_cards_target_initialize` and `PendingCardsTargetUninitialized`. > src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 174: > >> 172: if (!try_refinement_step(cr()->pending_cards_target())) { >> 173: // Proceed with fewer threads if target reached. >> 174: cr()->reduce_threads_wanted(); > > Not sure I see the reason to never try refinement when adjusted. I get that there is a case where we don't need to do refinement but that seems to be handled by an "early return" in `try_refinement_step(...)`. > > If we really want to skip refinement I would prefer an early return here as well. > > if (cr()->adjust_threads_periodically()) { > // If adjustment done, don't do any refinement this round, since this thread > // might no longer be wanted active. > return; > } > ... I expanded the comments here to give more explanation and justification. > src/hotspot/share/gc/g1/g1ConcurrentRefineThreadsNeeded.hpp line 40: > >> 38: G1Policy* _policy; >> 39: double _update_period_ms; >> 40: double _predicted_time_ms; > > I like to keep the names short but I wonder if it would make sense to include until gc here: `_predicted_time_until_gc_ms` That seems reasonable. `predicted_time_ms` => `predicted_time_until_next_gc_ms` `predicted_cards` => `predicted_cards_at_next_gc` > src/hotspot/share/gc/g1/g1Policy.cpp line 1124: > >> 1122: uint remaining = target - MIN2(target, full); >> 1123: size_t bytes = remaining * HeapRegion::GrainBytes; >> 1124: return bytes - MIN2(bytes, allocator->used_in_alloc_regions()); > > From what I can tell it's only this last line that require the `Heap_lock` to be held, so we could still do an estimate (slightly worse) even if we fail to take the lock. So my question is would it make sense to move the `Heap_lock->try_lock()` in here and just skip including `allocator->used_in_alloc_regions()` in the calculation when not getting the lock? `_g1h->young_list_count()` and `young_list_target_length()` can also be changed, protected by `Heap_lock`. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From jpai at openjdk.org Thu Sep 22 07:12:17 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 Sep 2022 07:12:17 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman wrote: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). Hello Alan, this PR deletes the `CountStackFrames.java` test case. Is that intentional? Looking at that test case it doesn't have any `suspend`/`resume` related testing and instead is just verifying that `Thread.countStackFrames()` throws the expected `UnsupportedOperationException`. Edit: Please ignore what I said - I now see that these tests have been moved to a new test file. ------------- PR: https://git.openjdk.org/jdk/pull/10324 From duke at openjdk.org Thu Sep 22 07:28:16 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Thu, 22 Sep 2022 07:28:16 GMT Subject: RFR: 8293618: x86: Wrong code generation in class Assembler In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 07:05:09 GMT, Tobias Hartmann wrote: >> Hi, >> >> This patch fixes some issues in the code generation of x86 assembler: >> >> - `Assembler::testl` misses `prefix(dst)` >> - `Assembler::addw` misses the 0x66 prefix >> - `Assembler::emit_operand` needs the length of the instruction from the address operand, this is often forgotten, making this parameter explicit to prevent potential issues >> - The assembler should not do optimisations that change the actual emitted instructions, these should be moved to `MacroAssembler` instead >> >> AFAICT there is no failure due to these mistakes. Please take a look and give reviews. >> Thanks you very much. > > src/hotspot/cpu/x86/assembler_x86.cpp line 351: > >> 349: } >> 350: >> 351: void Assembler::emit_arith_operand_imm32(int op1, Register rm, Address adr, int32_t imm32) { > > Why is this needed? @TobiHartmann Thanks for taking a look, method entry barrier needs a 4-byte immediate so it can be patched. This method is used in `Assembler::cmpl_imm32` ------------- PR: https://git.openjdk.org/jdk/pull/10240 From fyang at openjdk.org Thu Sep 22 07:34:25 2022 From: fyang at openjdk.org (Fei Yang) Date: Thu, 22 Sep 2022 07:34:25 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v8] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 06:41:47 GMT, Xiaolin Zheng wrote: >> With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) >> >> Tested hotspot tier1 and tier2 together with other patches on QEMU. > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Some code style modifications Marked as reviewed by fyang (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10370 From dholmes at openjdk.org Thu Sep 22 07:54:18 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Sep 2022 07:54:18 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs [v2] In-Reply-To: References: Message-ID: <_2Jwc04CMlpFUZh5ygK58DaJ-uXxV4Cm8K98Y2-N_IM=.d0643f2f-8ceb-450c-9c45-772373ba22cf@github.com> On Thu, 22 Sep 2022 06:51:05 GMT, Stefan Karlsson wrote: >> We have this code code in our signal handler: >> >> >> #ifndef AMD64 >> // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs >> // This can happen in any running code (currently more frequently in >> // interpreter code but has been seen in compiled code) >> if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { >> fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " >> "to unstable signal handling in this distribution."); >> } >> #endif // AMD64 >> >> >> This bug added that change: >> https://bugs.openjdk.java.net/browse/JDK-8004124 >> >> In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: >> >> "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" >> >> That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. >> >> As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. >> >> I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. >> >> We've been running with this patch in the Generational ZGC repository for over a year, without any problems. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Remove 32-bit error handling Ok ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10340 From dholmes at openjdk.org Thu Sep 22 08:06:30 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Sep 2022 08:06:30 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman wrote: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). One minor nit but otherwise looks good! Thanks. src/java.base/share/classes/java/lang/SecurityManager.java line 497: > 495: *

> 496: * This method is invoked for the current security manager by the > 497: * {@code stop}, {@code suspend}, {@code resume}, Why is stop being removed in this PR? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10324 From alanb at openjdk.org Thu Sep 22 08:25:22 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 Sep 2022 08:25:22 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 07:57:38 GMT, David Holmes wrote: > Why is stop being removed in this PR? It's just the sequencing of the two PRs and avoid merge conflicts. The Thread.stop should really edit this sentence, then this PR will edit it again. It was simpler to just do the SM edits in one PR. ------------- PR: https://git.openjdk.org/jdk/pull/10324 From jpai at openjdk.org Thu Sep 22 08:33:21 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 Sep 2022 08:33:21 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman wrote: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). The `java.base` changes look fine to me. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/10324 From sjohanss at openjdk.org Thu Sep 22 09:09:24 2022 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 22 Sep 2022 09:09:24 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v2] In-Reply-To: References: <0dfe0HnqB-TnjKk6-CFF9ANIeyz8NSFIid-b_q1r5ZY=.0a5ad315-5dd3-4340-9ef2-0e9f508b24c1@github.com> Message-ID: On Thu, 22 Sep 2022 07:07:59 GMT, Kim Barrett wrote: >> src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 267: >> >>> 265: // If target is "unbounded" then wait forever (until explicitly >>> 266: // activated). This happens during startup, when we don't bother with >>> 267: // refinement. >> >> We use `SIZE_MAX` to signal that the target is "unbounded", like the comment says. We do this comparison a few times and I think it would make sense to define a constant with a more descriptive name for this. > > Added `is_pending_cards_target_initialize` and `PendingCardsTargetUninitialized`. Good, was thinking about suggesting a predicate as well. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From sspitsyn at openjdk.org Thu Sep 22 09:13:19 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Sep 2022 09:13:19 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 17:25:42 GMT, Chris Plummer wrote: >> Thank you for reviewing and the comment, Chris. >> I agree, this part and related comment is kind of obscure. >> I'll think how to make the comment better. >> In fact, all temporary VTMS transitions do temporary switch the `JavaThread` identity from virtual thread to carrier. There is no need to skip frames because there are no real carrier thread frames at the top. Moreover, any attempt to skip frames which are in transition works incorrectly and gives an empty stack. The check `JvmtiEnvBase::is_cthread_with_continuation()` is needed to make sure we have a deal with a continuation. There is no need to skip frames otherwise. > > It's still not clear to me if the result of `JvmtiEnvBase::is_cthread_with_continuation()` impacts if you have to possibly skip hidden frames. In other words, do you always have to do the `if` block that follows, no matter what `JvmtiEnvBase::is_cthread_with_continuation()` returns? If you don't, then maybe instead of a "? :" expression, an if/else would be better. I'm not sure if the following is correct, but something like: > > javaVFrame *jvf; > if (JvmtiEnvBase::is_cthread_with_continuation(jt)) { > jvf = jt->carrier_last_java_vframe(reg_map_p); > } else { > jvf - jt->last_java_vframe(reg_map_p); > // Skipping hidden frames when jt->is_in_tmp_VTMS_transition()==true results > // in returning jvf==NULL, and so, empty stack traces for carrier threads. > if (!jt->is_in_tmp_VTMS_transition()) { > jvf = check_and_skip_hidden_frames(jt, jvf); > } > } I understand you question about `is_cthread_with_continuation(jt)` check. And I've incorrectly answered you initial question about it. It is much simpler to check if `jt->is_in_VTMS_transition()` but not tmp transition. I've already updated this part with renaming. Could you, please, look at it and check if it is more clear this way? I'll push my fix shortly. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Thu Sep 22 09:16:28 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Sep 2022 09:16:28 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: > There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. > > There are a couple of details of this fix to highlight: > - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. > - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. > - Suspending threads in temporary transition is allowed. > > The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: 1. addressed review comments from Chris; added VirtualThread.java update from Alan ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10321/files - new: https://git.openjdk.org/jdk/pull/10321/files/551d8d32..48f827fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=02-03 Stats: 99 lines in 8 files changed: 19 ins; 5 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/10321.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10321/head:pull/10321 PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Thu Sep 22 09:23:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Sep 2022 09:23:22 GMT Subject: RFR: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume [v3] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Thu, 22 Sep 2022 03:04:26 GMT, Leonid Mesnik wrote: >> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. >> Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. >> >> Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fix Leonid, I've posted a couple of comments but am not sure you see them. Do you see my comments? If so, are you going to address them? ------------- PR: https://git.openjdk.org/jdk/pull/10351 From sspitsyn at openjdk.org Thu Sep 22 09:43:18 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Sep 2022 09:43:18 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: <8lGsnac-zbc4jYW4ebQZxCVvYtEBYBcZNeQLBx4Hueg=.6cc8ec9c-0010-49ad-abc7-cd8bbec6a1a7@github.com> On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. addressed review comments from Chris; added VirtualThread.java update from Alan Alan is currently investigating and testing his approach to get rid of temporary transitions. If it comes to be successful then I'll close this PR. Getting rid of temporary transitions is preferable as it will simplify the code a lot. However, I've pushed an update to complete my current chunk of work for safety. It includes two items: - an update from Alan, to get rid of some lambda form classes loading in context of temporary VTMS transition - update which address comments from Chris: - renaming of Thread class functions - changes in the function: `JvmtiEnvBase::get_cthread_last_java_vframe()` ------------- PR: https://git.openjdk.org/jdk/pull/10321 From xlinzheng at openjdk.org Thu Sep 22 09:58:26 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 22 Sep 2022 09:58:26 GMT Subject: RFR: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops [v8] In-Reply-To: References: Message-ID: <3RKtpBk8twdaTCr4A8eFF28LivTHhZqpo_f3cESPQxc=.c83043f1-9ebb-464f-a32e-80b4d91d545e@github.com> On Thu, 22 Sep 2022 06:41:47 GMT, Xiaolin Zheng wrote: >> With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) >> >> Tested hotspot tier1 and tier2 together with other patches on QEMU. > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Some code style modifications Hotspot tier1 on QEMU has no new errors again after the changes. Thank you all for taking the time to review this! ------------- PR: https://git.openjdk.org/jdk/pull/10370 From dlong at openjdk.org Thu Sep 22 10:13:00 2022 From: dlong at openjdk.org (Dean Long) Date: Thu, 22 Sep 2022 10:13:00 GMT Subject: RFR: 8294160: misc crash dump improvements Message-ID: Try to recover and output meaningful information in more situations, such as: - when a pointer is in Method metadata memory range, but the memory is not committed - when we call a bad address When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information. ------------- Commit messages: - windows x86 - linux x86 print_instructions - revert - linux aarch64 support, simplify x86 - better crash dumps, linux x86 Changes: https://git.openjdk.org/jdk/pull/10387/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10387&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294160 Stats: 29 lines in 6 files changed: 20 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10387.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10387/head:pull/10387 PR: https://git.openjdk.org/jdk/pull/10387 From duke at openjdk.org Thu Sep 22 10:28:12 2022 From: duke at openjdk.org (AJ Ferguson) Date: Thu, 22 Sep 2022 10:28:12 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 [v2] In-Reply-To: References: Message-ID: > Fix cipher state corruption when encrypting/decrypting less than 16 bytes at a time. AJ Ferguson 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 remote-tracking branch 'upstream/master' into aesctr-avx3 - Add suggested changes Co-authored-by: smita-kamath - exit preloop if len_reg is 0 ------------- Changes: https://git.openjdk.org/jdk/pull/9635/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9635&range=01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9635.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9635/head:pull/9635 PR: https://git.openjdk.org/jdk/pull/9635 From kbarrett at openjdk.org Thu Sep 22 10:28:18 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 22 Sep 2022 10:28:18 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v2] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 07:01:30 GMT, Kim Barrett wrote: >> 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal >> 8155996: Improve concurrent refinement green zone control >> 8134303: Introduce -XX:-G1UseConcRefinement >> >> Please review this change to the control of concurrent refinement. >> >> This new controller takes a different approach to the problem, addressing a >> number of issues. >> >> The old controller used a multiple of the target number of cards to determine >> the range over which increasing numbers of refinement threads should be >> activated, and finally activating mutator refinement. This has a variety of >> problems. It doesn't account for the processing rate, the rate of new dirty >> cards, or the time available to perform the processing. This often leads to >> unnecessary spikes in the number of running refinement threads. It also tends >> to drive the pending number to the target quickly and keep it there, removing >> the benefit from having pending dirty cards filter out new cards for nearby >> writes. It can't delay and leave excess cards in the queue because it could >> be a long time before another buffer is enqueued. >> >> The old controller was triggered by mutator threads enqueing card buffers, >> when the number of cards in the queue exceeded a threshold near the target. >> This required a complex activation protocol between the mutators and the >> refinement threads. >> >> With the new controller there is a primary refinement thread that periodically >> estimates how many refinement threads need to be running to reach the target >> in time for the next GC, along with whether to also activate mutator >> refinement. If the primary thread stops running because it isn't currently >> needed, it sleeps for a period and reevaluates on wakeup. This eliminates any >> involvement in the activation of refinement threads by mutator threads. >> >> The estimate of how many refinement threads are needed uses a prediction of >> time until the next GC, the number of buffered cards, the predicted rate of >> new dirty cards, and the predicted refinement rate. The number of running >> threads is adjusted based on these periodically performed estimates. >> >> This new approach allows more dirty cards to be left in the queue until late >> in the mutator phase, typically reducing the rate of new dirty cards, which >> reduces the amount of concurrent refinement work needed. >> >> It also smooths out the number of running refinement threads, eliminating the >> unnecessarily large spikes that are common with the old method. One benefit >> is that the number of refinement threads (lazily) allocated is often much >> lower now. (This plus UseDynamicNumberOfGCThreads mitigates the problem >> described in JDK-8153225.) >> >> This change also provides a new method for calculating for the number of dirty >> cards that should be pending at the start of a GC. While this calculation is >> conceptually distinct from the thread control, the two were significanly >> intertwined in the old controller. Changing this calculation separately and >> first would have changed the behavior of the old controller in ways that might >> have introduced regressions. Changing it after the thread control was changed >> would have made it more difficult to test and measure the thread control in a >> desirable configuration. >> >> The old calculation had various problems that are described in JDK-8155996. >> In particular, it can get more or less stuck at low values, and is slow to >> respond to changes. >> >> The old controller provided a number of product options, none of which were >> very useful for real applications, and none of which are very applicable to >> the new controller. All of these are being obsoleted. >> >> -XX:-G1UseAdaptiveConcRefinement >> -XX:G1ConcRefinementGreenZone= >> -XX:G1ConcRefinementYellowZone= >> -XX:G1ConcRefinementRedZone= >> -XX:G1ConcRefinementThresholdStep= >> >> The new controller *could* use G1ConcRefinementGreenZone to provide a fixed >> value for the target number of cards, though it is poorly named for that. >> >> A configuration that was useful for some kinds of debugging and testing was to >> disable G1UseAdaptiveConcRefinement and set g1ConcRefinementGreenZone to a >> very large value, effectively disabling concurrent refinement. To support >> this use case with the new controller, the -XX:-G1UseConcRefinement diagnostic >> option has been added (see JDK-8155996). >> >> The other options are meaningless for the new controller. >> >> Because of these option changes, a CSR and a release note need to accompany >> this change. >> >> Testing: >> mach5 tier1-6 >> various performance tests. >> local (linux-x64) tier1 with -XX:-G1UseConcRefinement >> >> Performance testing found no regressions, but also little or no improvement >> with default options, which was expected. With default options most of our >> performance tests do very little concurrent refinement. And even for those >> that do, while the old controller had a number of problems, the impact of >> those problems is small and hard to measure for most applications. >> >> When reducing G1RSetUpdatingPauseTimePercent the new controller seems to fare >> better, particularly when also reducing MaxGCPauseMillis. specjbb2015 with >> MaxGCPauseMillis=75 and G1RSetUpdatingPauseTimePercent=3 (and other options >> held constant) showed a statistically significant improvement of about 4.5% >> for critical-jOPS. Using the changed controller, the difference between this >> configuration and the default is fairly small, while the baseline shows >> significant degradation with the more restrictive options. >> >> For all tests and configurations the new controller often creates many fewer >> refinement threads. > > Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: > > - lengthen some names > - improve comments for primary do_refinement_step > - add is_pending_cards_target_initialized There is now an associated draft CSR for folks to review: https://bugs.openjdk.org/browse/JDK-8294206 ------------- PR: https://git.openjdk.org/jdk/pull/10256 From duke at openjdk.org Thu Sep 22 10:30:15 2022 From: duke at openjdk.org (AJ Ferguson) Date: Thu, 22 Sep 2022 10:30:15 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 07:07:36 GMT, Smita Kamath wrote: >> Fix cipher state corruption when encrypting/decrypting less than 16 bytes at a time. > > Hi @AJ-Ferguson, I have modified the changes you recommended and added a suggestion. Please have a look at the diff file and let me know what you think. Thanks. > [diff.txt](https://github.com/openjdk/jdk/files/9604614/diff.txt) Hello @smita-kamath, thank you for taking the time to look at this PR. The changes you posted look good to me. I have added your improvements and updated the branch. ------------- PR: https://git.openjdk.org/jdk/pull/9635 From kbarrett at openjdk.org Thu Sep 22 10:32:27 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 22 Sep 2022 10:32:27 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v2] In-Reply-To: References: <0dfe0HnqB-TnjKk6-CFF9ANIeyz8NSFIid-b_q1r5ZY=.0a5ad315-5dd3-4340-9ef2-0e9f508b24c1@github.com> Message-ID: <0ltcb3Kb94TQTtXYa1deBWr96XTzku64CfY8YXE8kW8=.313079f7-11c4-4717-b6c8-5425a6f9f549@github.com> On Thu, 22 Sep 2022 07:08:08 GMT, Kim Barrett wrote: >> src/hotspot/share/gc/g1/g1Policy.cpp line 1124: >> >>> 1122: uint remaining = target - MIN2(target, full); >>> 1123: size_t bytes = remaining * HeapRegion::GrainBytes; >>> 1124: return bytes - MIN2(bytes, allocator->used_in_alloc_regions()); >> >> From what I can tell it's only this last line that require the `Heap_lock` to be held, so we could still do an estimate (slightly worse) even if we fail to take the lock. So my question is would it make sense to move the `Heap_lock->try_lock()` in here and just skip including `allocator->used_in_alloc_regions()` in the calculation when not getting the lock? > > `_g1h->young_list_count()` and `young_list_target_length()` can also be > changed, protected by `Heap_lock`. Also, I originally didn't include the used_in_alloc_regions information in the calculation, and the resulting predictions were pretty bad, esp. with larger region sizes. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From xlinzheng at openjdk.org Thu Sep 22 11:46:26 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 22 Sep 2022 11:46:26 GMT Subject: Integrated: 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 03:54:03 GMT, Xiaolin Zheng wrote: > With RVC turning on, we must carefully keep all runtime-patchable instructions aligned. Code is running at full speed, when patching unaligned instructions spanning cache lines, concurrency issues may occur. This patch fixes a potential alignment issue of the patchable nop after MachUEPNode, with adding some strong alignment assertions as well. (In fact, currently the `nop` in the Verified Entry Point is fortunately aligned to 4 under RVC even without this patch, so this patch doesn't change program behaviors.) > > Tested hotspot tier1 and tier2 together with other patches on QEMU. This pull request has now been integrated. Changeset: a216960d Author: Xiaolin Zheng Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/a216960d71bdf111a9c232a0228cc43256a01b29 Stats: 30 lines in 9 files changed: 25 ins; 0 del; 5 mod 8294087: RISC-V: RVC: Fix a potential alignment issue and add more alignment assertions for the patchable calls/nops Reviewed-by: shade, fjiang, fyang ------------- PR: https://git.openjdk.org/jdk/pull/10370 From tschatzl at openjdk.org Thu Sep 22 11:59:47 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 22 Sep 2022 11:59:47 GMT Subject: RFR: 8293422: DWARF emitted by Clang cannot be parsed [v3] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 13:20:53 GMT, Christian Hagedorn wrote: >> The DWARF debugging symbols emitted by Clang is different from what GCC is emitting. While GCC produces a complete `.debug_aranges` section (which is required in the DWARF parser), Clang does not. As a result, the DWARF parser cannot find the necessary information to proceed and create the line number information: >> >> The `.debug_aranges` section contains address range to compilation unit offset mappings. The parsing algorithm can just walk through all these entries to find the correct address range that contains the library offset of the current pc. This gives us the compilation unit offset into the `.debug_info` section from where we can proceed to parse the line number information. >> >> Without a complete `.debug_aranges` section, we fail with an assertion that we could not find the correct entry. Since [JDK-8293402](https://bugs.openjdk.org/browse/JDK-8293402), we will still get the complete stack trace at least. Nevertheless, we should still fix this assertion failure of course. But that would require a different parsing approach. We need to parse the entire `.debug_info` section instead to get to the correct compilation unit. This, however, would require a lot more work. >> >> I therefore suggest to disable DWARF parsing for Clang for now and file an RFE to support Clang in the future with a different parsing approach. I'm using the `__clang__` `ifdef` to bail out in `get_source_info()` and disable the `gtests`. I've noticed that we are currently running the `gtests` with `NOT PRODUCT` which I think is not necessary - the gtests should also work fine with product builds. I've corrected this as well but that could also be done separately. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Review comments from Thomas I'll leave it up to you what to do about the path stripping problem mentioned in the comment for `DwarfFile::LineNumberProgram::get_filename_from_header`. src/hotspot/share/utilities/elfFile.cpp line 1613: > 1611: if (current_index == file_index) { > 1612: // Found correct file. > 1613: strip_path_prefix(filename, filename_len); After some digging I believe this is the wrong place to strip the path prefix, and causes the strange workaround in the `decoder_get_source_info_valid_truncated` gtest. The call to `_reader.read_string()` above should do the stripping as it is read; if like in the gtest, the given `filename_len` is too small to contain the original string, the `strip_path_prefix` tries to strip the too small buffer, but what has actually been intended was probably stripping the entire path and then limiting the return value. I.e. a more useful implementation of this would be reading the string into a temporary buffer, stripping the path prefix and then copying the result to the output buffer. I can see the reasoning for why the current implementation is as is, it is nowhere specified what the contents of the filename string in `debug_aranges` should be, and what should be actually printed. Looking at callers of this method, it might actually a problem when using clang: `VMError::print_native_stack` uses a 128 byte buffer, `NativeCallStack::print_on` uses a 1024 byte buffer. I can see that at least 128 bytes would be just a bit small, but then we (Oracle) do not use clang. It's up to you to fix this imo. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/10287 From stefank at openjdk.org Thu Sep 22 12:39:26 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 22 Sep 2022 12:39:26 GMT Subject: Integrated: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 12:33:44 GMT, Stefan Karlsson wrote: > We have this code code in our signal handler: > > > #ifndef AMD64 > // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs > // This can happen in any running code (currently more frequently in > // interpreter code but has been seen in compiled code) > if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { > fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " > "to unstable signal handling in this distribution."); > } > #endif // AMD64 > > > This bug added that change: > https://bugs.openjdk.java.net/browse/JDK-8004124 > > In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: > > "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" > > That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. > > As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. > > I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. > > We've been running with this patch in the Generational ZGC repository for over a year, without any problems. This pull request has now been integrated. Changeset: d781ab09 Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/d781ab09f745fb8b1406609da4a799eab767847a Stats: 8 lines in 1 file changed: 1 ins; 5 del; 2 mod 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs Reviewed-by: dholmes, shade, dlong ------------- PR: https://git.openjdk.org/jdk/pull/10340 From sjohanss at openjdk.org Thu Sep 22 12:53:20 2022 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 22 Sep 2022 12:53:20 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v2] In-Reply-To: <0ltcb3Kb94TQTtXYa1deBWr96XTzku64CfY8YXE8kW8=.313079f7-11c4-4717-b6c8-5425a6f9f549@github.com> References: <0dfe0HnqB-TnjKk6-CFF9ANIeyz8NSFIid-b_q1r5ZY=.0a5ad315-5dd3-4340-9ef2-0e9f508b24c1@github.com> <0ltcb3Kb94TQTtXYa1deBWr96XTzku64CfY8YXE8kW8=.313079f7-11c4-4717-b6c8-5425a6f9f549@github.com> Message-ID: On Thu, 22 Sep 2022 10:28:39 GMT, Kim Barrett wrote: >> `_g1h->young_list_count()` and `young_list_target_length()` can also be >> changed, protected by `Heap_lock`. > > Also, I originally didn't include the used_in_alloc_regions information in the calculation, and the resulting predictions were pretty bad, esp. with larger region sizes. I see, yeah, I was mostly thinking if there was a way to make it even less likely that we would get no estimate. But if the estimate would be really bad a missing estimate might be better. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From avoitylov at openjdk.org Thu Sep 22 13:05:00 2022 From: avoitylov at openjdk.org (Aleksei Voitylov) Date: Thu, 22 Sep 2022 13:05:00 GMT Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V Message-ID: Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR. benchmark results: before: Benchmark Mode Cnt Score Error Units DoubleClassCheck.testIsFiniteBranch avgt 15 52.824 ? 1.744 ns/op DoubleClassCheck.testIsFiniteCMov avgt 15 16.104 ? 0.358 ns/op DoubleClassCheck.testIsFiniteStore avgt 15 14.366 ? 2.174 ns/op FloatClassCheck.testIsFiniteBranch avgt 15 49.821 ? 0.330 ns/op FloatClassCheck.testIsFiniteCMov avgt 15 14.702 ? 0.335 ns/op FloatClassCheck.testIsFiniteStore avgt 15 14.749 ? 0.496 ns/op after: DoubleClassCheck.testIsFiniteBranch avgt 15 48.921 ? 0.557 ns/op DoubleClassCheck.testIsFiniteCMov avgt 15 13.716 ? 0.304 ns/op DoubleClassCheck.testIsFiniteStore avgt 15 9.152 ? 0.158 ns/op FloatClassCheck.testIsFiniteBranch avgt 15 47.740 ? 2.028 ns/op FloatClassCheck.testIsFiniteCMov avgt 15 13.299 ? 0.282 ns/op FloatClassCheck.testIsFiniteStore avgt 15 9.185 ? 0.396 ns/op Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way. Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues. ------------- Commit messages: - JDK-8294198 implementation Changes: https://git.openjdk.org/jdk/pull/10391/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10391&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294198 Stats: 363 lines in 17 files changed: 315 ins; 47 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10391.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10391/head:pull/10391 PR: https://git.openjdk.org/jdk/pull/10391 From stuefe at openjdk.org Thu Sep 22 13:06:30 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 22 Sep 2022 13:06:30 GMT Subject: RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs [v2] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 06:51:05 GMT, Stefan Karlsson wrote: >> We have this code code in our signal handler: >> >> >> #ifndef AMD64 >> // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs >> // This can happen in any running code (currently more frequently in >> // interpreter code but has been seen in compiled code) >> if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) { >> fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due " >> "to unstable signal handling in this distribution."); >> } >> #endif // AMD64 >> >> >> This bug added that change: >> https://bugs.openjdk.java.net/browse/JDK-8004124 >> >> In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above: >> >> "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL" >> >> That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs. >> >> As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code. >> >> I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die. >> >> We've been running with this patch in the Generational ZGC repository for over a year, without any problems. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Remove 32-bit error handling A small nit remains: why do we even need this section at all? We get a SIGSEGV with si_addr=0. VM assumes this to be an implicit null check if signal==SIGSEGV and the PC makes sense (interpreter or code blob or vtable stub). Would it not be cleaner to add a check at that point for info->si_code != SI_KERNEL? E.g. before calling SharedRuntime::continuation_for_implicit_exception? ------------- PR: https://git.openjdk.org/jdk/pull/10340 From jwaters at openjdk.org Thu Sep 22 13:25:35 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 22 Sep 2022 13:25:35 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v14] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Use format specifier for differentiating Windows API errors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/3303cbb8..b169fba9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=12-13 Stats: 32 lines in 2 files changed: 11 ins; 9 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Thu Sep 22 13:29:40 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 22 Sep 2022 13:29:40 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v15] In-Reply-To: References: Message-ID: <6HmPsNZip67Ipu7i1egXPJOTc16Est66en_Fsy_fZaY=.655485e8-31cb-4ec3-8a4d-0390cef05899@github.com> > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters 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 remote-tracking branch 'upstream/master' into rework - Use format specifier for differentiating Windows API errors - Rework JLI_ReportErrorMessageSys ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/b169fba9..04223d42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=13-14 Stats: 4371 lines in 148 files changed: 2527 ins; 1357 del; 487 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Thu Sep 22 13:32:35 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 22 Sep 2022 13:32:35 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v16] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Don't forget the null terminator! ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/04223d42..39ba8c2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Thu Sep 22 13:35:05 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 22 Sep 2022 13:35:05 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v17] In-Reply-To: References: Message-ID: <9UILvQvJKaoq_jTCPbzvzJXVyC_W1xRVqj52V-tYTHU=.7f7f86a3-250c-4807-aff5-8fb099040a6f@github.com> > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Fix whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/39ba8c2d..681a92e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=15-16 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Thu Sep 22 13:46:40 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 22 Sep 2022 13:46:40 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v18] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Proper WINAPI for getErrorString and getLastErrorString too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/681a92e1..8a6f7f08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=16-17 Stats: 81 lines in 3 files changed: 34 ins; 39 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Thu Sep 22 13:49:10 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 22 Sep 2022 13:49:10 GMT Subject: RFR: 8292016: Rework JLI_ReportErrorMessageSys [v19] In-Reply-To: References: Message-ID: <114IePkCV0wTJaVyJo0C2_wX6_ZyjPgiWItdcgwdF44=.63175b59-ef69-4494-864c-355d5c6c62e7@github.com> > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: getLastWinErrorString calls wrong handler ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/8a6f7f08..6c6290e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=17-18 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Thu Sep 22 13:54:55 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 22 Sep 2022 13:54:55 GMT Subject: RFR: 8292016: Better handle intermingling WINAPI and C Runtime errors in the JDK [v20] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Fix whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/6c6290e9..3fb2fcc9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=18-19 Stats: 20 lines in 1 file changed: 0 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From fjiang at openjdk.org Thu Sep 22 14:06:50 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 22 Sep 2022 14:06:50 GMT Subject: RFR: 8294187: RISC-V: Unify all relocations for the backend into MacroAssembler::relocate() In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 06:56:05 GMT, Xiaolin Zheng wrote: > Unify all relocations into MacroAssembler::relocate() as a simple cleanup, so that there are platform-related entrances for them. We will have needs to insert some code into the new MacroAssembler::relocate() afterward. Also, the (__ pc()) everywhere seems a little verbose here. > > Tested hotspot tier1 and tier2 on QEMU. LGTM ------------- Marked as reviewed by fjiang (Author). PR: https://git.openjdk.org/jdk/pull/10384 From lmesnik at openjdk.org Thu Sep 22 15:05:37 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 22 Sep 2022 15:05:37 GMT Subject: RFR: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume [v3] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Thu, 22 Sep 2022 09:21:00 GMT, Serguei Spitsyn wrote: > Leonid, I've posted a couple of comments but am not sure you see them. Do you see my comments? If so, are you going to address them? Yes, I updated JvmtiUtils and removed unused variable. The PR title is correct now. ------------- PR: https://git.openjdk.org/jdk/pull/10351 From lmesnik at openjdk.org Thu Sep 22 15:05:37 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 22 Sep 2022 15:05:37 GMT Subject: RFR: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume [v4] In-Reply-To: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: <8JLdprikc0ub2-fJpBfZdvPetHalkAwMnWuTEDWUJWo=.288de2f6-24de-4f2b-bcf6-94dfd56e5f00@github.com> > The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. > Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. > > Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10351/files - new: https://git.openjdk.org/jdk/pull/10351/files/c892fca0..5ad84a91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10351&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10351&range=02-03 Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10351.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10351/head:pull/10351 PR: https://git.openjdk.org/jdk/pull/10351 From kvn at openjdk.org Thu Sep 22 15:31:24 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 22 Sep 2022 15:31:24 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v9] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 12:18:09 GMT, Quan Anh Mai wrote: >> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: >> >> vptest xmm0, xmm1 >> jb if_true >> if_false: >> >> instead of: >> >> vptest xmm0, xmm1 >> setb r10 >> movzbl r10 >> testl r10 >> jne if_true >> if_false: >> >> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: >> >> Before After >> Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% >> >> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. > > Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into improveVTest > - Merge branch 'master' into improveVTest > - fix merge problems > - Merge branch 'master' into improveVTest > - refactor x86 > - revert renaming temp > - style + use rscratch instead of tmp > - fix > - redo aarch > - Merge branch 'master' into improveVTest > - ... and 15 more: https://git.openjdk.org/jdk/compare/d14e96d9...4db8b6e5 My testing passed. You need second review. May be @jatin-bhateja can look. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9855 From iwalulya at openjdk.org Thu Sep 22 15:51:21 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 22 Sep 2022 15:51:21 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v2] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 07:01:30 GMT, Kim Barrett wrote: >> 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal >> 8155996: Improve concurrent refinement green zone control >> 8134303: Introduce -XX:-G1UseConcRefinement >> >> Please review this change to the control of concurrent refinement. >> >> This new controller takes a different approach to the problem, addressing a >> number of issues. >> >> The old controller used a multiple of the target number of cards to determine >> the range over which increasing numbers of refinement threads should be >> activated, and finally activating mutator refinement. This has a variety of >> problems. It doesn't account for the processing rate, the rate of new dirty >> cards, or the time available to perform the processing. This often leads to >> unnecessary spikes in the number of running refinement threads. It also tends >> to drive the pending number to the target quickly and keep it there, removing >> the benefit from having pending dirty cards filter out new cards for nearby >> writes. It can't delay and leave excess cards in the queue because it could >> be a long time before another buffer is enqueued. >> >> The old controller was triggered by mutator threads enqueing card buffers, >> when the number of cards in the queue exceeded a threshold near the target. >> This required a complex activation protocol between the mutators and the >> refinement threads. >> >> With the new controller there is a primary refinement thread that periodically >> estimates how many refinement threads need to be running to reach the target >> in time for the next GC, along with whether to also activate mutator >> refinement. If the primary thread stops running because it isn't currently >> needed, it sleeps for a period and reevaluates on wakeup. This eliminates any >> involvement in the activation of refinement threads by mutator threads. >> >> The estimate of how many refinement threads are needed uses a prediction of >> time until the next GC, the number of buffered cards, the predicted rate of >> new dirty cards, and the predicted refinement rate. The number of running >> threads is adjusted based on these periodically performed estimates. >> >> This new approach allows more dirty cards to be left in the queue until late >> in the mutator phase, typically reducing the rate of new dirty cards, which >> reduces the amount of concurrent refinement work needed. >> >> It also smooths out the number of running refinement threads, eliminating the >> unnecessarily large spikes that are common with the old method. One benefit >> is that the number of refinement threads (lazily) allocated is often much >> lower now. (This plus UseDynamicNumberOfGCThreads mitigates the problem >> described in JDK-8153225.) >> >> This change also provides a new method for calculating for the number of dirty >> cards that should be pending at the start of a GC. While this calculation is >> conceptually distinct from the thread control, the two were significanly >> intertwined in the old controller. Changing this calculation separately and >> first would have changed the behavior of the old controller in ways that might >> have introduced regressions. Changing it after the thread control was changed >> would have made it more difficult to test and measure the thread control in a >> desirable configuration. >> >> The old calculation had various problems that are described in JDK-8155996. >> In particular, it can get more or less stuck at low values, and is slow to >> respond to changes. >> >> The old controller provided a number of product options, none of which were >> very useful for real applications, and none of which are very applicable to >> the new controller. All of these are being obsoleted. >> >> -XX:-G1UseAdaptiveConcRefinement >> -XX:G1ConcRefinementGreenZone= >> -XX:G1ConcRefinementYellowZone= >> -XX:G1ConcRefinementRedZone= >> -XX:G1ConcRefinementThresholdStep= >> >> The new controller *could* use G1ConcRefinementGreenZone to provide a fixed >> value for the target number of cards, though it is poorly named for that. >> >> A configuration that was useful for some kinds of debugging and testing was to >> disable G1UseAdaptiveConcRefinement and set g1ConcRefinementGreenZone to a >> very large value, effectively disabling concurrent refinement. To support >> this use case with the new controller, the -XX:-G1UseConcRefinement diagnostic >> option has been added (see JDK-8155996). >> >> The other options are meaningless for the new controller. >> >> Because of these option changes, a CSR and a release note need to accompany >> this change. >> >> Testing: >> mach5 tier1-6 >> various performance tests. >> local (linux-x64) tier1 with -XX:-G1UseConcRefinement >> >> Performance testing found no regressions, but also little or no improvement >> with default options, which was expected. With default options most of our >> performance tests do very little concurrent refinement. And even for those >> that do, while the old controller had a number of problems, the impact of >> those problems is small and hard to measure for most applications. >> >> When reducing G1RSetUpdatingPauseTimePercent the new controller seems to fare >> better, particularly when also reducing MaxGCPauseMillis. specjbb2015 with >> MaxGCPauseMillis=75 and G1RSetUpdatingPauseTimePercent=3 (and other options >> held constant) showed a statistically significant improvement of about 4.5% >> for critical-jOPS. Using the changed controller, the difference between this >> configuration and the default is fairly small, while the baseline shows >> significant degradation with the more restrictive options. >> >> For all tests and configurations the new controller often creates many fewer >> refinement threads. > > Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: > > - lengthen some names > - improve comments for primary do_refinement_step > - add is_pending_cards_target_initialized src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 203: > 201: } > 202: > 203: void G1ConcurrentRefine::update_pending_cards_target(double logged_cards_scan_time_ms, `logged_cards_scan_time_ms` includes time for merging card (i think it should include time for concatenation), probably better to name it as `logged_cards_processing_time_ms` as in the caller. Additionally, we use `processed_logged_cards` and not `scanned_logged_cards` src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 246: > 244: // drastically, record that adjustment is needed and kick the primary > 245: // thread, in case it is waiting. > 246: _dcqs.set_max_cards(SIZE_MAX); Don't we already set `_dcqs.set_max_cards(SIZE_MAX)` in `G1DirtyCardQueueSet::concatenate_logs()` src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 258: > 256: // This reduces the number of primary thread wakeups that just immediately > 257: // go back to waiting, while still being responsive to behavior changes. > 258: static uint64_t compute_adjust_delay(double available_ms) { `delay` and `wait` used interchangeably, maybe better to choose one src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 116: > 114: Ticks _last_deactivate; > 115: bool _needs_adjust; > 116: G1ConcurrentRefineThreadsNeeded _threads_needed; `_threads_wanted` vs. `_threads_needed` makes for difficult reading in many places ------------- PR: https://git.openjdk.org/jdk/pull/10256 From stuefe at openjdk.org Thu Sep 22 17:07:25 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 22 Sep 2022 17:07:25 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: References: Message-ID: <3AIWW1prhISoIn6Bnw6f_JkcSQqBJeMQMwisfOnI8vU=.ff7dae90-7da6-471e-9fdf-49ac3f6429ee@github.com> On Wed, 21 Sep 2022 05:20:01 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback johan > > Changes requested by stefank (Reviewer). @stefank @dholmes-ora @jdksjolen is the new version acceptable? ------------- PR: https://git.openjdk.org/jdk/pull/10252 From stuefe at openjdk.org Thu Sep 22 17:08:02 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 22 Sep 2022 17:08:02 GMT Subject: RFR: JDK-8293346: Add NoThreadCurrentMark to simulate non-attached threads [v2] In-Reply-To: References: Message-ID: > When working on [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344), I needed a way to verify that I had removed all offending usages of ResourceArea memory inside an extend. > > For that, a NoThreadCurrentMark was useful. It temporarily sets the current Thread* to NULL for the extend. Any use of Thread::current below that mark will now crash or assert. > > This can be used for two things: > - guard code that is supposed to be safe for non-attached threads (os::malloc, stack printing, UL etc) against accidental usage of Thread::current() (e.g. resource area allocation) > - in gtests, simulate a non-attached thread to cover code that behaves differently with Thread::current()==NULL. > > This patch: > > - Introduces the debug-only `NoThreadCurrentMark` > - Adds a gtest for it > - Adds it to guard dwarf-parsing-based stack printing, which had not been safe due to use of ResourceArea, fixed with [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344) > - Adds it to `os::malloc()`, `os::realloc()` and `os::free()`, since those can certainly be called without a current thread. > - Replaces the test-local mark in the SafeFetch gtests that did a similar thing > - I may add and fix up other users later > > I also had to change Library-based TLS initialization such that it runs at C++ dynamic initialization time. That is because the `NoThreadCurrentMark` needs to set both Library-based TLS and C++ TLS slots, and having library-based TLS not available before VM initialization made the code too complex. This also means we can remove the explicit TLS initialization from create_vm. > > Finally, while I was here, I also fixed the error printing in library based TLS (since the pthread_key_xxx functions don't modify errno). Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: - New solution - Revert changes to TLS initialization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10178/files - new: https://git.openjdk.org/jdk/pull/10178/files/c91655aa..74984d13 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10178&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10178&range=00-01 Stats: 106 lines in 7 files changed: 29 ins; 48 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/10178.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10178/head:pull/10178 PR: https://git.openjdk.org/jdk/pull/10178 From stuefe at openjdk.org Thu Sep 22 17:08:05 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 22 Sep 2022 17:08:05 GMT Subject: RFR: JDK-8293346: Add NoThreadCurrentMark to simulate non-attached threads In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 06:37:35 GMT, Thomas Stuefe wrote: > When working on [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344), I needed a way to verify that I had removed all offending usages of ResourceArea memory inside an extend. > > For that, a NoThreadCurrentMark was useful. It temporarily sets the current Thread* to NULL for the extend. Any use of Thread::current below that mark will now crash or assert. > > This can be used for two things: > - guard code that is supposed to be safe for non-attached threads (os::malloc, stack printing, UL etc) against accidental usage of Thread::current() (e.g. resource area allocation) > - in gtests, simulate a non-attached thread to cover code that behaves differently with Thread::current()==NULL. > > This patch: > > - Introduces the debug-only `NoThreadCurrentMark` > - Adds a gtest for it > - Adds it to guard dwarf-parsing-based stack printing, which had not been safe due to use of ResourceArea, fixed with [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344) > - Adds it to `os::malloc()`, `os::realloc()` and `os::free()`, since those can certainly be called without a current thread. > - Replaces the test-local mark in the SafeFetch gtests that did a similar thing > - I may add and fix up other users later > > I also had to change Library-based TLS initialization such that it runs at C++ dynamic initialization time. That is because the `NoThreadCurrentMark` needs to set both Library-based TLS and C++ TLS slots, and having library-based TLS not available before VM initialization made the code too complex. This also means we can remove the explicit TLS initialization from create_vm. > > Finally, while I was here, I also fixed the error printing in library based TLS (since the pthread_key_xxx functions don't modify errno). New solution, based on a "hide thread current" flag inside Thread. I'm not a big fan tbh. I liked my first approach, switching thread current to NULL, better. Modulo the TLS initialization changes, those I admit were too complex. ------------- PR: https://git.openjdk.org/jdk/pull/10178 From darcy at openjdk.org Thu Sep 22 17:22:17 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 22 Sep 2022 17:22:17 GMT Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov wrote: > Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR. > > benchmark results: > > before: > > Benchmark Mode Cnt Score Error Units > DoubleClassCheck.testIsFiniteBranch avgt 15 52.824 ? 1.744 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 16.104 ? 0.358 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 14.366 ? 2.174 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 49.821 ? 0.330 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 14.702 ? 0.335 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 14.749 ? 0.496 ns/op > > after: > > DoubleClassCheck.testIsFiniteBranch avgt 15 48.921 ? 0.557 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 13.716 ? 0.304 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 9.152 ? 0.158 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 47.740 ? 2.028 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 13.299 ? 0.282 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 9.185 ? 0.396 ns/op > > Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way. > > Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues. The java.lang.* changes look fine if the rest of the work proceeds. ------------- PR: https://git.openjdk.org/jdk/pull/10391 From iklam at openjdk.org Thu Sep 22 18:03:44 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 22 Sep 2022 18:03:44 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v11] In-Reply-To: References: Message-ID: <867TdKmJce7HpB-gIDtPbGAnZlEloOjgLjRfFIwGZgk=.2d7b3a8d-a54a-4363-81ef-a175a34aeebe@github.com> > Current in gdb, you can print information about a class or method with something like > > > call ((InstanceKlass*)0x00000008000411b8)->print_on(tty) > call ((Method*)0x00007fffb4000d08)->print_codes_on(tty) > > > However, it's difficult to find a class or method by its name and print out its contents. > > This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity. > > - `findclass()`: class name only > - `findmethod()`: class name and method name > - `findmethod2()`: class name and method name/signature > > I also cleaned up `BytecodeTracer` to remove unnecessary complexity. > > Here are some examples: > > > (gdb) call findclass("java/lang/Object", 0) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > > (gdb) call findclass("java/lang/Object", 1) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000658 : ()V > 0x00007fffb40010f0 finalize : ()V > 0x00007fffb4000f00 wait0 : (J)V > 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z > 0x00007fffb4000aa0 toString : ()Ljava/lang/String; > 0x00007fffb40007f0 hashCode : ()I > 0x00007fffb4000720 getClass : ()Ljava/lang/Class; > 0x00007fffb40009a0 clone : ()Ljava/lang/Object; > 0x00007fffb4000b50 notify : ()V > 0x00007fffb4000c20 notifyAll : ()V > 0x00007fffb4000e50 wait : (J)V > 0x00007fffb4001028 wait : (JI)V > 0x00007fffb4000d08 wait : ()V > > (gdb) call findclass("*ClassLoader", 0) > [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap' > [....] > > (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7) > [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap' > 0x00007fffb4000d08 wait : ()V > 0x00007fffb4000ce8 0 fast_aload_0 > 0x00007fffb4000ce9 1 lconst_0 > 0x00007fffb4000cea 2 invokevirtual 38 > 0x00007fffb4000ced 5 return Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @coleenp comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9957/files - new: https://git.openjdk.org/jdk/pull/9957/files/5b90b7d1..e4afb9fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9957&range=09-10 Stats: 45 lines in 3 files changed: 18 ins; 17 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/9957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9957/head:pull/9957 PR: https://git.openjdk.org/jdk/pull/9957 From iklam at openjdk.org Thu Sep 22 18:17:16 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 22 Sep 2022 18:17:16 GMT Subject: RFR: 8292699: Improve printing of classes in native debugger [v7] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 19:24:33 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Use proper locking > > src/hotspot/share/interpreter/bytecodeTracer.cpp line 434: > >> 432: // TODO: print info for tag.is_dynamic_constant() >> 433: } >> 434: } > > This should be a function in ConstantPool::print() This block of code works on an `indy_index`, which is stored only inside the bytecode stream (it's the rewritten index of the [invokedynamic bytecode](https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-6.html#jvms-6.5.invokedynamic). `indy_index` is not store anywhere inside the `ConstantPool`, so I can't find a good place to print this info in the printing functions of `ConstantPool`. Note that you can have multiple `invokedynamic` bytecodes that use the same `JVM_CONSTANT_InvokeDynamic` entry in a `ConstantPool`, resulting in a different `indy_index` for each call site. Therefore, this per-callsite information cannot be printed as part of the `JVM_CONSTANT_InvokeDynamic` entry > src/hotspot/share/interpreter/bytecodeTracer.cpp line 462: > >> 460: } >> 461: } >> 462: } > > Line 444-461 should call a function in cpCache like: > void ConstantPoolCacheEntry::print(outputStream* st, int index) const { > > If this doesn't have the format you want, you can enhance this function. I moved this code to `ConstantPoolCacheEntry::print` in version [e4afb9f](https://github.com/openjdk/jdk/pull/9957/commits/e4afb9fa235551ef98ccca408aeba4c18bf9904c) ------------- PR: https://git.openjdk.org/jdk/pull/9957 From shade at openjdk.org Thu Sep 22 18:28:51 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Sep 2022 18:28:51 GMT Subject: RFR: 8294211: Zero: Decode arch-specific error context if possible Message-ID: <68x5tTa2dHOc-tAj6OfoLSK2MNK2GN2io8qj1POUT2I=.b4ef9779-3b2a-4af4-aa1b-166375420547@github.com> After POSIX signal refactorings, Zero error handling had "regressed" a bit: Zero always gets `NULL` as `pc` in error handling code, and thus it fails with SEGV at pc=0x0. We can do better by implementing context decoding where possible. Unfortunately, this introduces some arch-specific code in Zero code. The arch-specific code is copy-pasted (with inline definitions, if needed) from the relevant `os_linux_*.cpp` files. The unimplemented arches would still report the same confusing `hs_err`-s. We can emulate (and thus test) the generic behavior using new diagnostic VM option. This reverts parts of [JDK-8259392](https://bugs.openjdk.org/browse/JDK-8259392). Sample test: import java.lang.reflect.*; import sun.misc.Unsafe; public class Crash { public static void main(String... args) throws Exception { Field f = Unsafe.class.getDeclaredField("theUnsafe"); f.setAccessible(true); Unsafe u = (Unsafe) f.get(null); u.getInt(42); // accesing via broken ptr } } Linux x86_64 Zero fastdebug crash currently: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000000000000, pid=538793, tid=538794 # ... # (no native frame info) ... siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a Linux x86_64 Zero fastdebug crash with this patch: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fbbbf08b584, pid=520119, tid=520120 # ... # Problematic frame: # V [libjvm.so+0xcbe584] Unsafe_GetInt+0xe4 .... siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a Linux x86_64 Zero fastdebug crash with this patch and `-XX:-DecodeErrorContext`: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000000000000000, pid=520268, tid=520269 # ... # Problematic frame: # C 0x0000000000000000 ... siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a Additional testing: - [x] Linux x86_64 Zero fastdebug eyeballing crash logs - [ ] Linux x86_64 Zero fastdebug, `tier1` - [x] Linux {x86_64, x86_32, aarch64, arm, riscv64, s390x, ppc64le, ppc64be} Zero fastdebug builds ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/10397/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10397&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294211 Stats: 150 lines in 4 files changed: 124 ins; 11 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/10397.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10397/head:pull/10397 PR: https://git.openjdk.org/jdk/pull/10397 From stuefe at openjdk.org Thu Sep 22 18:44:37 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 22 Sep 2022 18:44:37 GMT Subject: RFR: 8294211: Zero: Decode arch-specific error context if possible In-Reply-To: <68x5tTa2dHOc-tAj6OfoLSK2MNK2GN2io8qj1POUT2I=.b4ef9779-3b2a-4af4-aa1b-166375420547@github.com> References: <68x5tTa2dHOc-tAj6OfoLSK2MNK2GN2io8qj1POUT2I=.b4ef9779-3b2a-4af4-aa1b-166375420547@github.com> Message-ID: On Thu, 22 Sep 2022 18:20:28 GMT, Aleksey Shipilev wrote: > After POSIX signal refactorings, Zero error handling had "regressed" a bit: Zero always gets `NULL` as `pc` in error handling code, and thus it fails with SEGV at pc=0x0. We can do better by implementing context decoding where possible. > > Unfortunately, this introduces some arch-specific code in Zero code. The arch-specific code is copy-pasted (with inline definitions, if needed) from the relevant `os_linux_*.cpp` files. The unimplemented arches would still report the same confusing `hs_err`-s. We can emulate (and thus test) the generic behavior using new diagnostic VM option. > > This reverts parts of [JDK-8259392](https://bugs.openjdk.org/browse/JDK-8259392). > > Sample test: > > > import java.lang.reflect.*; > import sun.misc.Unsafe; > > public class Crash { > public static void main(String... args) throws Exception { > Field f = Unsafe.class.getDeclaredField("theUnsafe"); > f.setAccessible(true); > Unsafe u = (Unsafe) f.get(null); > u.getInt(42); // accesing via broken ptr > } > } > > > Linux x86_64 Zero fastdebug crash currently: > > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000000000000, pid=538793, tid=538794 > # > ... > # (no native frame info) > ... > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a > > > Linux x86_64 Zero fastdebug crash with this patch: > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007fbbbf08b584, pid=520119, tid=520120 > # > ... > # Problematic frame: > # V [libjvm.so+0xcbe584] Unsafe_GetInt+0xe4 > .... > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a > > > Linux x86_64 Zero fastdebug crash with this patch and `-XX:-DecodeErrorContext`: > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000000000000, pid=520268, tid=520269 > # > ... > # Problematic frame: > # C 0x0000000000000000 > ... > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a > > > Additional testing: > - [x] Linux x86_64 Zero fastdebug eyeballing crash logs > - [ ] Linux x86_64 Zero fastdebug, `tier1` > - [x] Linux {x86_64, x86_32, aarch64, arm, riscv64, s390x, ppc64le, ppc64be} Zero fastdebug builds Good! But why make this conditional with a switch? Who would not want to have better error information? src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp line 183: > 181: epc = os::Posix::ucontext_get_pc(uc); > 182: if (ret_sp) *ret_sp = (intptr_t *)os::Linux::ucontext_get_sp(uc); > 183: if (ret_fp) *ret_fp = (intptr_t *)os::Linux::ucontext_get_fp(uc); style nits: curly brackets? Remove space in `intptr_t *`? src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp line 390: > 388: > 389: void os::print_context(outputStream* st, const void* ucVoid) { > 390: st->print_cr("No context information."); Regrettable, maybe something for a future RFE? src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp line 404: > 402: // this at the end, and hope for the best. > 403: address pc = os::Posix::ucontext_get_pc(uc); > 404: print_instructions(st, pc, sizeof(char)); Does print_instructions not use safefetch like os::print_hex_dump does? If yes, remove comment? If no, should it? ------------- PR: https://git.openjdk.org/jdk/pull/10397 From shade at openjdk.org Thu Sep 22 19:06:35 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Sep 2022 19:06:35 GMT Subject: RFR: 8294211: Zero: Decode arch-specific error context if possible [v2] In-Reply-To: <68x5tTa2dHOc-tAj6OfoLSK2MNK2GN2io8qj1POUT2I=.b4ef9779-3b2a-4af4-aa1b-166375420547@github.com> References: <68x5tTa2dHOc-tAj6OfoLSK2MNK2GN2io8qj1POUT2I=.b4ef9779-3b2a-4af4-aa1b-166375420547@github.com> Message-ID: > After POSIX signal refactorings, Zero error handling had "regressed" a bit: Zero always gets `NULL` as `pc` in error handling code, and thus it fails with SEGV at pc=0x0. We can do better by implementing context decoding where possible. > > Unfortunately, this introduces some arch-specific code in Zero code. The arch-specific code is copy-pasted (with inline definitions, if needed) from the relevant `os_linux_*.cpp` files. The unimplemented arches would still report the same confusing `hs_err`-s. We can emulate (and thus test) the generic behavior using new diagnostic VM option. > > This reverts parts of [JDK-8259392](https://bugs.openjdk.org/browse/JDK-8259392). > > Sample test: > > > import java.lang.reflect.*; > import sun.misc.Unsafe; > > public class Crash { > public static void main(String... args) throws Exception { > Field f = Unsafe.class.getDeclaredField("theUnsafe"); > f.setAccessible(true); > Unsafe u = (Unsafe) f.get(null); > u.getInt(42); // accesing via broken ptr > } > } > > > Linux x86_64 Zero fastdebug crash currently: > > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000000000000, pid=538793, tid=538794 > # > ... > # (no native frame info) > ... > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a > > > Linux x86_64 Zero fastdebug crash with this patch: > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007fbbbf08b584, pid=520119, tid=520120 > # > ... > # Problematic frame: > # V [libjvm.so+0xcbe584] Unsafe_GetInt+0xe4 > .... > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a > > > Linux x86_64 Zero fastdebug crash with this patch and `-XX:-DecodeErrorContext`: > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000000000000, pid=520268, tid=520269 > # > ... > # Problematic frame: > # C 0x0000000000000000 > ... > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a > > > Additional testing: > - [x] Linux x86_64 Zero fastdebug eyeballing crash logs > - [ ] Linux x86_64 Zero fastdebug, `tier1` > - [x] Linux {x86_64, x86_32, aarch64, arm, riscv64, s390x, ppc64le, ppc64be} Zero fastdebug builds Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Style nits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10397/files - new: https://git.openjdk.org/jdk/pull/10397/files/917d8c0c..26c768e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10397&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10397&range=00-01 Stats: 12 lines in 1 file changed: 8 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10397.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10397/head:pull/10397 PR: https://git.openjdk.org/jdk/pull/10397 From shade at openjdk.org Thu Sep 22 19:06:36 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Sep 2022 19:06:36 GMT Subject: RFR: 8294211: Zero: Decode arch-specific error context if possible [v2] In-Reply-To: References: <68x5tTa2dHOc-tAj6OfoLSK2MNK2GN2io8qj1POUT2I=.b4ef9779-3b2a-4af4-aa1b-166375420547@github.com> Message-ID: On Thu, 22 Sep 2022 18:42:24 GMT, Thomas Stuefe wrote: > Good! But why make this conditional with a switch? Who would not want to have better error information? Because I want to be able to test the generic error handling paths that would run on "generic" arch, without leaving the comfort of my x86_64 machine :) > src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp line 183: > >> 181: epc = os::Posix::ucontext_get_pc(uc); >> 182: if (ret_sp) *ret_sp = (intptr_t *)os::Linux::ucontext_get_sp(uc); >> 183: if (ret_fp) *ret_fp = (intptr_t *)os::Linux::ucontext_get_fp(uc); > > style nits: curly brackets? Remove space in `intptr_t *`? Right, modified. > src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp line 390: > >> 388: >> 389: void os::print_context(outputStream* st, const void* ucVoid) { >> 390: st->print_cr("No context information."); > > Regrettable, maybe something for a future RFE? Yes. I don't want to copy-paste the whole arch-specific code into this file. The bare minimum to have reasonable `hs_err`-s should do :) > src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp line 404: > >> 402: // this at the end, and hope for the best. >> 403: address pc = os::Posix::ucontext_get_pc(uc); >> 404: print_instructions(st, pc, sizeof(char)); > > Does print_instructions not use safefetch like os::print_hex_dump does? If yes, remove comment? If no, should it? It does use safe fetch after some change in the past. But all other arches also have this comment, so I prefer to be consistent with them. I think this comment is the left-over from the switch to safefetch on this path. That deserves a separate RFR, I think. ------------- PR: https://git.openjdk.org/jdk/pull/10397 From shade at openjdk.org Thu Sep 22 19:06:36 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 Sep 2022 19:06:36 GMT Subject: RFR: 8294211: Zero: Decode arch-specific error context if possible [v2] In-Reply-To: References: <68x5tTa2dHOc-tAj6OfoLSK2MNK2GN2io8qj1POUT2I=.b4ef9779-3b2a-4af4-aa1b-166375420547@github.com> Message-ID: On Thu, 22 Sep 2022 18:59:12 GMT, Aleksey Shipilev wrote: >> src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp line 390: >> >>> 388: >>> 389: void os::print_context(outputStream* st, const void* ucVoid) { >>> 390: st->print_cr("No context information."); >> >> Regrettable, maybe something for a future RFE? > > Yes. I don't want to copy-paste the whole arch-specific code into this file. The bare minimum to have reasonable `hs_err`-s should do :) I forgot to mention why I do this. If we leave `ShouldNotCallThis()` here, then error handler does a secondary fault in these methods, and `hs_err` prints errors in these sections. So the deal here is removing the risky secondary fault -- I see no reason for it -- rather than printing out more info. When we can do that easily, like in the TOS and PC sections, we do. ------------- PR: https://git.openjdk.org/jdk/pull/10397 From stuefe at openjdk.org Thu Sep 22 19:16:17 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 22 Sep 2022 19:16:17 GMT Subject: RFR: 8294211: Zero: Decode arch-specific error context if possible [v2] In-Reply-To: References: <68x5tTa2dHOc-tAj6OfoLSK2MNK2GN2io8qj1POUT2I=.b4ef9779-3b2a-4af4-aa1b-166375420547@github.com> Message-ID: On Thu, 22 Sep 2022 19:06:35 GMT, Aleksey Shipilev wrote: >> After POSIX signal refactorings, Zero error handling had "regressed" a bit: Zero always gets `NULL` as `pc` in error handling code, and thus it fails with SEGV at pc=0x0. We can do better by implementing context decoding where possible. >> >> Unfortunately, this introduces some arch-specific code in Zero code. The arch-specific code is copy-pasted (with inline definitions, if needed) from the relevant `os_linux_*.cpp` files. The unimplemented arches would still report the same confusing `hs_err`-s. We can emulate (and thus test) the generic behavior using new diagnostic VM option. >> >> This reverts parts of [JDK-8259392](https://bugs.openjdk.org/browse/JDK-8259392). >> >> Sample test: >> >> >> import java.lang.reflect.*; >> import sun.misc.Unsafe; >> >> public class Crash { >> public static void main(String... args) throws Exception { >> Field f = Unsafe.class.getDeclaredField("theUnsafe"); >> f.setAccessible(true); >> Unsafe u = (Unsafe) f.get(null); >> u.getInt(42); // accesing via broken ptr >> } >> } >> >> >> Linux x86_64 Zero fastdebug crash currently: >> >> >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=538793, tid=538794 >> # >> ... >> # (no native frame info) >> ... >> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a >> >> >> Linux x86_64 Zero fastdebug crash with this patch: >> >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00007fbbbf08b584, pid=520119, tid=520120 >> # >> ... >> # Problematic frame: >> # V [libjvm.so+0xcbe584] Unsafe_GetInt+0xe4 >> .... >> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a >> >> >> Linux x86_64 Zero fastdebug crash with this patch and `-XX:-DecodeErrorContext`: >> >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=520268, tid=520269 >> # >> ... >> # Problematic frame: >> # C 0x0000000000000000 >> ... >> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a >> >> >> Additional testing: >> - [x] Linux x86_64 Zero fastdebug eyeballing crash logs >> - [ ] Linux x86_64 Zero fastdebug, `tier1` >> - [x] Linux {x86_64, x86_32, aarch64, arm, riscv64, s390x, ppc64le, ppc64be} Zero fastdebug builds > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Style nits LGTM. BTW, if you want to test error handling, you don't have to use Unsafe put, you can just use -XX:ErrorHandlerTest=number, e.g. 15 should give you a Segfault I believe. Only works in debug VMs though. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/10397 From stuefe at openjdk.org Thu Sep 22 19:16:19 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 22 Sep 2022 19:16:19 GMT Subject: RFR: 8294211: Zero: Decode arch-specific error context if possible [v2] In-Reply-To: References: <68x5tTa2dHOc-tAj6OfoLSK2MNK2GN2io8qj1POUT2I=.b4ef9779-3b2a-4af4-aa1b-166375420547@github.com> Message-ID: On Thu, 22 Sep 2022 19:03:28 GMT, Aleksey Shipilev wrote: >> Yes. I don't want to copy-paste the whole arch-specific code into this file. The bare minimum to have reasonable `hs_err`-s should do :) > > I forgot to mention why I do this. If we leave `ShouldNotCallThis()` here, then error handler does a secondary fault in these methods, and `hs_err` prints errors in these sections. So the deal here is removing the risky secondary fault -- I see no reason for it -- rather than printing out more info. When we can do that easily, like in the TOS and PC sections, we do. Sure, makes sense to avoid them. Secondary crashes also build up stack, therefore they are limited to only a few before error handling just stops. ------------- PR: https://git.openjdk.org/jdk/pull/10397 From stuefe at openjdk.org Thu Sep 22 19:16:18 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 22 Sep 2022 19:16:18 GMT Subject: RFR: 8294211: Zero: Decode arch-specific error context if possible [v2] In-Reply-To: References: <68x5tTa2dHOc-tAj6OfoLSK2MNK2GN2io8qj1POUT2I=.b4ef9779-3b2a-4af4-aa1b-166375420547@github.com> Message-ID: On Thu, 22 Sep 2022 18:57:25 GMT, Aleksey Shipilev wrote: > > Good! But why make this conditional with a switch? Who would not want to have better error information? > > Because I want to be able to test the generic error handling paths that would run on "generic" arch, without leaving the comfort of my x86_64 machine :) :-) Okay. Like zero-in-zero. >> src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp line 404: >> >>> 402: // this at the end, and hope for the best. >>> 403: address pc = os::Posix::ucontext_get_pc(uc); >>> 404: print_instructions(st, pc, sizeof(char)); >> >> Does print_instructions not use safefetch like os::print_hex_dump does? If yes, remove comment? If no, should it? > > It does use safe fetch after some change in the past. But all other arches also have this comment, so I prefer to be consistent with them. I think this comment is the left-over from the switch to safefetch on this path. That deserves a separate RFR, I think. Okay ------------- PR: https://git.openjdk.org/jdk/pull/10397 From duke at openjdk.org Thu Sep 22 19:26:38 2022 From: duke at openjdk.org (Kirill Prazdnikov) Date: Thu, 22 Sep 2022 19:26:38 GMT Subject: [jdk19] RFR: 8289302: Restore CriticalJNINatives In-Reply-To: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com> References: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com> Message-ID: On Wed, 29 Jun 2022 12:10:35 GMT, Coleen Phillimore wrote: > This change restores the code in the JVM that implemented the internal JavaCritical or CriticalJNINatives functionality. Customers are using this feature and there's no replacement yet for it. > This change is a backout and merge of jDK-8258192: Obsolete the CriticalJNINatives flag. > This change also adds the deprecation message that was missed, which I checked is okay with the customer. > > Tested with tiers1-4. I can confirm very significant performance drop. We have been using JavaCritical for OpenGL calls, for FreeType & HarfBuzz calls, for libPNG interop, for TurboJPEG interop. Basically for everything and it makes a very significant performance gain ------------- PR: https://git.openjdk.org/jdk19/pull/90 From cjplummer at openjdk.org Thu Sep 22 20:15:29 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 22 Sep 2022 20:15:29 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. addressed review comments from Chris; added VirtualThread.java update from Alan src/hotspot/share/runtime/javaThread.hpp line 652: > 650: void set_is_in_VTMS_transition(bool val); > 651: void toggle_is_in_tmp_VTMS_transition() { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; }; > 652: My suggestion was to have the term "in VTMS transition" be inclusive of temp transitions. So based on your current names I would suggest: - is_in_VTMS_transition -> is_in_non_tmp_VTMS_transition - is_in_any_VTMS_transition -> is_in_VTMS_transition But that becomes a problem for `set_is_in_VTMS_transition`, which would need to be renamed `set_is_in_non_tmp_VTMS_transition`, which I'm guessing you don't want to do. So let's instead just hope this all goes away before thinking about it any more. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From coleenp at openjdk.org Thu Sep 22 20:53:40 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 22 Sep 2022 20:53:40 GMT Subject: [jdk19] RFR: 8289302: Restore CriticalJNINatives In-Reply-To: References: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com> Message-ID: On Thu, 22 Sep 2022 19:24:33 GMT, Kirill Prazdnikov wrote: >> This change restores the code in the JVM that implemented the internal JavaCritical or CriticalJNINatives functionality. Customers are using this feature and there's no replacement yet for it. >> This change is a backout and merge of jDK-8258192: Obsolete the CriticalJNINatives flag. >> This change also adds the deprecation message that was missed, which I checked is okay with the customer. >> >> Tested with tiers1-4. > > I can confirm very significant performance drop. We have been using JavaCritical for OpenGL calls, for FreeType & HarfBuzz calls, > for libPNG interop, for TurboJPEG interop. Basically for everything and it makes a very significant performance gain > > Performance numbers were investigated during GraalVM evaluations here: https://github.com/oracle/graal/issues/2873 > You can find all source code there > And the result is JavaCritical is about 6x-7x faster: > > This is my results, numbers is time spent, lower better: > Jvm > min critical: 84200 > min non critical: 558200 @kirillp Can you try your measurements with the current JDK 20 build with and without the option: -XX:+UseSystemMemoryBarrier ------------- PR: https://git.openjdk.org/jdk19/pull/90 From dholmes at openjdk.org Thu Sep 22 21:55:17 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Sep 2022 21:55:17 GMT Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications [v4] In-Reply-To: References: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com> Message-ID: On Thu, 22 Sep 2022 06:09:46 GMT, Robbin Ehn wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix JniVersion test > > Looks good, thank you! Thanks @robehn ! ------------- PR: https://git.openjdk.org/jdk/pull/10352 From svkamath at openjdk.org Thu Sep 22 23:06:22 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Thu, 22 Sep 2022 23:06:22 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 [v2] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 10:28:12 GMT, AJ Ferguson wrote: >> Fix cipher state corruption when encrypting/decrypting less than 16 bytes at a time. > > AJ Ferguson 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 remote-tracking branch 'upstream/master' into aesctr-avx3 > - Add suggested changes > > Co-authored-by: smita-kamath > - exit preloop if len_reg is 0 Marked as reviewed by svkamath (Author). ------------- PR: https://git.openjdk.org/jdk/pull/9635 From dholmes at openjdk.org Thu Sep 22 23:32:20 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Sep 2022 23:32:20 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v4] In-Reply-To: <9De-oiQg9mWhLwq0l9CCMeh-j2-OvMGw3gq2fSwbxsQ=.9d5edae5-f0d0-4d27-9fde-3b0ad80bdce5@github.com> References: <9De-oiQg9mWhLwq0l9CCMeh-j2-OvMGw3gq2fSwbxsQ=.9d5edae5-f0d0-4d27-9fde-3b0ad80bdce5@github.com> Message-ID: On Wed, 21 Sep 2022 12:47:20 GMT, Thomas Stuefe wrote: >> Arguments.cpp has several size parsing functions which would be useful in other areas of the hotspot, e.g. in NMT. >> >> It would be nice to have them factored out into utilities, to reuse the code and to unify memory size handling. Gtests would be good too. >> >> To simplify reviews, I split the patch into two commits. >> >> The first commit (https://github.com/openjdk/jdk/pull/10252/commits/700e77e8d1469a2fc3d6611072c4b07aa34ab8e6) contains the unchanged code move without functional changes. >> >> The second commit (https://github.com/openjdk/jdk/pull/10252/commits/76b4f6f30cc316fd966da60ff6601f54eeb394bf) contains the functional changes I did, as well as the new gtest. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > feedback dholmes This simple refactoring looks fine. Thanks. src/hotspot/share/utilities/parseInteger.hpp line 26: > 24: */ > 25: > 26: #ifndef SHARE_UTILITIES_PARSE_INTEGER_HPP Nit: that should be `PARSEINTEGER_HPP` ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10252 From dean.long at oracle.com Thu Sep 22 23:40:42 2022 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 22 Sep 2022 16:40:42 -0700 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: <4a767b25-1539-183a-e4cd-4852f633e77d@littlepinkcloud.com> References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> <416c7338-2dff-7997-c95f-c9e1c74de180@littlepinkcloud.com> <0958C022-824B-4492-9D82-393F64965D5E@oracle.com> <246e397f-2f10-84fa-19d7-65b1472606e9@littlepinkcloud.com> <4a767b25-1539-183a-e4cd-4852f633e77d@littlepinkcloud.com> Message-ID: <66cb1e28-0d38-2008-753e-431aaa9c9791@oracle.com> On 9/20/22 4:15 AM, Andrew Haley wrote: > > (I'm also not getting the point about a lack of > > barrier-ordered-after, but maybe I'm just confused.) > > The lack of barrier-ordered-after is why we need a fence after all ops > for conservative. > > (In fact we don't: all Arm hardware in existence works without the > trailing fence. And probably always will. But the Arm spec allows > reordering, even though available hardware doesn't. This is annoying, > but that's life.) I'm probably missing something too, because I don't understand this either. If the atomic op has acquire-release semantics, then this part of the spec seems like it means no fence after is required: (older spec) "At least one of RW1 and RW2 is generated by an atomic instruction with both Acquire and Release semantics." (newer spec) "RW1 is a memory write effect W1 and is generated by an atomic instruction with both Acquire and Release semantics." (if the cas succeeded) "RW1 is a memory read effect R1, except a Tag-Check-read, and is generated by an instruction with Acquire or AcquirePC semantics." (if the cas failed) Also, since "Barrier-ordered-before" describes when RW1 "happened before" RW2 (or RW2 "happened after" RW1, right?), I don't understand why an additional "barrier-ordered-after" would be desired. dl From sviswanathan at openjdk.org Thu Sep 22 23:55:18 2022 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 22 Sep 2022 23:55:18 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 10:28:00 GMT, AJ Ferguson wrote: >> Hi @AJ-Ferguson, I have modified the changes you recommended and added a suggestion. Please have a look at the diff file and let me know what you think. Thanks. >> [diff.txt](https://github.com/openjdk/jdk/files/9604614/diff.txt) > > Hello @smita-kamath, thank you for taking the time to look at this PR. The changes you posted look good to me. I have added your improvements and updated the branch. @AJ-Ferguson Please do add a test for this case. ------------- PR: https://git.openjdk.org/jdk/pull/9635 From svkamath at openjdk.org Fri Sep 23 00:16:38 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Fri, 23 Sep 2022 00:16:38 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v9] In-Reply-To: References: Message-ID: > 8289552: Make intrinsic conversions between bit representations of half precision values and floats Smita Kamath 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' of https://git.openjdk.java.net/jdk into JDK-8289552 - Addressed review comments - Added missing parantheses - Addressed review comments, updated microbenchmark - Updated copyright comment - Updated test cases as per review comments - Addressed review comments, updated test cases and microbenchmark - Added a jmh microbenchmark - Intrinsic conversions between halffloat and floats ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9781/files - new: https://git.openjdk.org/jdk/pull/9781/files/6b828e60..bd55803a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=07-08 Stats: 162166 lines in 2652 files changed: 77056 ins; 68233 del; 16877 mod Patch: https://git.openjdk.org/jdk/pull/9781.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781 PR: https://git.openjdk.org/jdk/pull/9781 From yadongwang at openjdk.org Fri Sep 23 01:05:20 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Fri, 23 Sep 2022 01:05:20 GMT Subject: RFR: 8294187: RISC-V: Unify all relocations for the backend into MacroAssembler::relocate() In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 06:56:05 GMT, Xiaolin Zheng wrote: > Unify all relocations into MacroAssembler::relocate() as a simple cleanup, so that there are platform-related entrances for them. We will have needs to insert some code into the new MacroAssembler::relocate() afterward. Also, the (__ pc()) everywhere seems a little verbose here. > > Tested hotspot tier1 and tier2 on QEMU. Looks fine. But it's best to point out that it's bridging to the compressed-instruction-related relocation. ------------- Marked as reviewed by yadongwang (Author). PR: https://git.openjdk.org/jdk/pull/10384 From fyang at openjdk.org Fri Sep 23 03:00:34 2022 From: fyang at openjdk.org (Fei Yang) Date: Fri, 23 Sep 2022 03:00:34 GMT Subject: RFR: 8294187: RISC-V: Unify all relocations for the backend into MacroAssembler::relocate() In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 06:56:05 GMT, Xiaolin Zheng wrote: > Unify all relocations into MacroAssembler::relocate() as a simple cleanup, so that there are platform-related entrances for them. We will have needs to insert some code into the new MacroAssembler::relocate() afterward. Also, the (__ pc()) everywhere seems a little verbose here. > > Tested hotspot tier1 and tier2 on QEMU. Changes requested by fyang (Reviewer). src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp line 2147: > 2145: } > 2146: > 2147: void LIR_Assembler::add_debug_info_for_branch(address adr, CodeEmitInfo* info) { I see this function is never used: void LIR_Assembler::add_debug_info_for_branch(address adr, CodeEmitInfo* info) So I would suggest remove this function. Then following two functions introduced by this PR would become unnecessary: void relocate(address at, RelocationHolder const& rspec, int format = 0) { code_section()->relocate(at, rspec, format); } void relocate(address at, relocInfo::relocType rtype, int format = 0, jint method_index = 0) { code_section()->relocate(at, rtype, format, method_index); } ------------- PR: https://git.openjdk.org/jdk/pull/10384 From rehn at openjdk.org Fri Sep 23 06:21:25 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 23 Sep 2022 06:21:25 GMT Subject: [jdk19] RFR: 8289302: Restore CriticalJNINatives In-Reply-To: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com> References: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com> Message-ID: On Wed, 29 Jun 2022 12:10:35 GMT, Coleen Phillimore wrote: > This change restores the code in the JVM that implemented the internal JavaCritical or CriticalJNINatives functionality. Customers are using this feature and there's no replacement yet for it. > This change is a backout and merge of jDK-8258192: Obsolete the CriticalJNINatives flag. > This change also adds the deprecation message that was missed, which I checked is okay with the customer. > > Tested with tiers1-4. Note that if there is a safepoint or handshake without JavaCritical the JavaThread may be stopped for such on the back edge of the call. Which means if you measure the time from Java you also including time spend in safepoint/handshake in such case. We measure using https://github.com/openjdk/jmh, which can control for such events. Here are some example of our numbers: ########### BASELINE JDK17 ########## Benchmark - Iterations: 100000000 total time:3446158970 ns ; Per op:34.4615897 Benchmark - Iterations: 100000000 total time:3481146574 ns ; Per op:34.81146574 Benchmark - Iterations: 100000000 total time:3432662217 ns ; Per op:34.32662217 ########### CRITICAL JDK17 ########## Benchmark - Iterations: 100000000 total time:2695102198 ns ; Per op:26.95102198 Benchmark - Iterations: 100000000 total time:2707413238 ns ; Per op:27.07413238 Benchmark - Iterations: 100000000 total time:2604335910 ns ; Per op:26.0433591 ########### UseSystemMemoryBarrier JDK17 ########## Benchmark - Iterations: 100000000 total time:2930762287 ns ; Per op:29.30762287 Benchmark - Iterations: 100000000 total time:2874010646 ns ; Per op:28.74010646 Benchmark - Iterations: 100000000 total time:2817695430 ns ; Per op:28.1769543 Note that we accidentally optimized JavaCritical in JDK 17, so UseSystemMemoryBarrier should be on par with pre-JDK-17. ------------- PR: https://git.openjdk.org/jdk19/pull/90 From kbarrett at openjdk.org Fri Sep 23 06:39:33 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 23 Sep 2022 06:39:33 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: > 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal > 8155996: Improve concurrent refinement green zone control > 8134303: Introduce -XX:-G1UseConcRefinement > > Please review this change to the control of concurrent refinement. > > This new controller takes a different approach to the problem, addressing a > number of issues. > > The old controller used a multiple of the target number of cards to determine > the range over which increasing numbers of refinement threads should be > activated, and finally activating mutator refinement. This has a variety of > problems. It doesn't account for the processing rate, the rate of new dirty > cards, or the time available to perform the processing. This often leads to > unnecessary spikes in the number of running refinement threads. It also tends > to drive the pending number to the target quickly and keep it there, removing > the benefit from having pending dirty cards filter out new cards for nearby > writes. It can't delay and leave excess cards in the queue because it could > be a long time before another buffer is enqueued. > > The old controller was triggered by mutator threads enqueing card buffers, > when the number of cards in the queue exceeded a threshold near the target. > This required a complex activation protocol between the mutators and the > refinement threads. > > With the new controller there is a primary refinement thread that periodically > estimates how many refinement threads need to be running to reach the target > in time for the next GC, along with whether to also activate mutator > refinement. If the primary thread stops running because it isn't currently > needed, it sleeps for a period and reevaluates on wakeup. This eliminates any > involvement in the activation of refinement threads by mutator threads. > > The estimate of how many refinement threads are needed uses a prediction of > time until the next GC, the number of buffered cards, the predicted rate of > new dirty cards, and the predicted refinement rate. The number of running > threads is adjusted based on these periodically performed estimates. > > This new approach allows more dirty cards to be left in the queue until late > in the mutator phase, typically reducing the rate of new dirty cards, which > reduces the amount of concurrent refinement work needed. > > It also smooths out the number of running refinement threads, eliminating the > unnecessarily large spikes that are common with the old method. One benefit > is that the number of refinement threads (lazily) allocated is often much > lower now. (This plus UseDynamicNumberOfGCThreads mitigates the problem > described in JDK-8153225.) > > This change also provides a new method for calculating for the number of dirty > cards that should be pending at the start of a GC. While this calculation is > conceptually distinct from the thread control, the two were significanly > intertwined in the old controller. Changing this calculation separately and > first would have changed the behavior of the old controller in ways that might > have introduced regressions. Changing it after the thread control was changed > would have made it more difficult to test and measure the thread control in a > desirable configuration. > > The old calculation had various problems that are described in JDK-8155996. > In particular, it can get more or less stuck at low values, and is slow to > respond to changes. > > The old controller provided a number of product options, none of which were > very useful for real applications, and none of which are very applicable to > the new controller. All of these are being obsoleted. > > -XX:-G1UseAdaptiveConcRefinement > -XX:G1ConcRefinementGreenZone= > -XX:G1ConcRefinementYellowZone= > -XX:G1ConcRefinementRedZone= > -XX:G1ConcRefinementThresholdStep= > > The new controller *could* use G1ConcRefinementGreenZone to provide a fixed > value for the target number of cards, though it is poorly named for that. > > A configuration that was useful for some kinds of debugging and testing was to > disable G1UseAdaptiveConcRefinement and set g1ConcRefinementGreenZone to a > very large value, effectively disabling concurrent refinement. To support > this use case with the new controller, the -XX:-G1UseConcRefinement diagnostic > option has been added (see JDK-8155996). > > The other options are meaningless for the new controller. > > Because of these option changes, a CSR and a release note need to accompany > this change. > > Testing: > mach5 tier1-6 > various performance tests. > local (linux-x64) tier1 with -XX:-G1UseConcRefinement > > Performance testing found no regressions, but also little or no improvement > with default options, which was expected. With default options most of our > performance tests do very little concurrent refinement. And even for those > that do, while the old controller had a number of problems, the impact of > those problems is small and hard to measure for most applications. > > When reducing G1RSetUpdatingPauseTimePercent the new controller seems to fare > better, particularly when also reducing MaxGCPauseMillis. specjbb2015 with > MaxGCPauseMillis=75 and G1RSetUpdatingPauseTimePercent=3 (and other options > held constant) showed a statistically significant improvement of about 4.5% > for critical-jOPS. Using the changed controller, the difference between this > configuration and the default is fairly small, while the baseline shows > significant degradation with the more restrictive options. > > For all tests and configurations the new controller often creates many fewer > refinement threads. Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: - wanted vs needed nomenclature - remove several spurious "scan" - delay => wait_time_ms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10256/files - new: https://git.openjdk.org/jdk/pull/10256/files/ffdf6339..9a735bc0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10256&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10256&range=01-02 Stats: 28 lines in 4 files changed: 1 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/10256.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10256/head:pull/10256 PR: https://git.openjdk.org/jdk/pull/10256 From kbarrett at openjdk.org Fri Sep 23 06:41:55 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 23 Sep 2022 06:41:55 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v2] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 15:07:04 GMT, Ivan Walulya wrote: >> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: >> >> - lengthen some names >> - improve comments for primary do_refinement_step >> - add is_pending_cards_target_initialized > > src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 203: > >> 201: } >> 202: >> 203: void G1ConcurrentRefine::update_pending_cards_target(double logged_cards_scan_time_ms, > > `logged_cards_scan_time_ms` includes time for merging card (i think it should include time for concatenation), probably better to name it as `logged_cards_processing_time_ms` as in the caller. Additionally, we use `processed_logged_cards` and not `scanned_logged_cards` Agreed that "scan" isn't right. I dropped that word in several places. Just dropped rather than replacing with "processing" because of excessive length and I didn't think it added anything. > src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 246: > >> 244: // drastically, record that adjustment is needed and kick the primary >> 245: // thread, in case it is waiting. >> 246: _dcqs.set_max_cards(SIZE_MAX); > > Don't we already set `_dcqs.set_max_cards(SIZE_MAX)` in `G1DirtyCardQueueSet::concatenate_logs()` We do, but I don't want to rely on that far away and done for other reasons code. The reason for setting in concatenate_logs is to cut off any refinement by handle_completed_buffer (via flushing buffers). It isn't entirely necessary for that either, as there are other reasons why that function won't do any refinement. I waffled about whether to keep or remove it. > src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 258: > >> 256: // This reduces the number of primary thread wakeups that just immediately >> 257: // go back to waiting, while still being responsive to behavior changes. >> 258: static uint64_t compute_adjust_delay(double available_ms) { > > `delay` and `wait` used interchangeably, maybe better to choose one s/delay/wait_time_ms/ > src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 116: > >> 114: Ticks _last_deactivate; >> 115: bool _needs_adjust; >> 116: G1ConcurrentRefineThreadsNeeded _threads_needed; > > `_threads_wanted` vs. `_threads_needed` makes for difficult reading in many places The intent is that "needed" refers to the number required to reach the goal, while "wanted" is the number the controller wants active. "wanted" may be less than "needed" for a variety of reasons. There were a couple of places where that intended nomenclature wasn't followed, which I've fixed. There is still G1ConcurrentRefine::_threads_wanted (the number of active threads wanted by the controller) and G1ConcurrentRefine::_threads_needed (the object that provides the calculation of the needed threads). From usage I hope there isn't confusion, but I'm open to suggestions for better names. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From thartmann at openjdk.org Fri Sep 23 06:48:09 2022 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 23 Sep 2022 06:48:09 GMT Subject: RFR: 8293618: x86: Wrong code generation in class Assembler In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 07:26:03 GMT, Quan Anh Mai wrote: >> src/hotspot/cpu/x86/assembler_x86.cpp line 351: >> >>> 349: } >>> 350: >>> 351: void Assembler::emit_arith_operand_imm32(int op1, Register rm, Address adr, int32_t imm32) { >> >> Why is this needed? > > @TobiHartmann Thanks for taking a look, method entry barrier needs a 4-byte immediate so it can be patched. This method is used in `Assembler::cmpl_imm32` Okay, so code before emitted an 8-bit immediate. Why didn't that cause any issues when patching? ------------- PR: https://git.openjdk.org/jdk/pull/10240 From jsjolen at openjdk.org Fri Sep 23 07:23:36 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 23 Sep 2022 07:23:36 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v4] In-Reply-To: <9De-oiQg9mWhLwq0l9CCMeh-j2-OvMGw3gq2fSwbxsQ=.9d5edae5-f0d0-4d27-9fde-3b0ad80bdce5@github.com> References: <9De-oiQg9mWhLwq0l9CCMeh-j2-OvMGw3gq2fSwbxsQ=.9d5edae5-f0d0-4d27-9fde-3b0ad80bdce5@github.com> Message-ID: On Wed, 21 Sep 2022 12:47:20 GMT, Thomas Stuefe wrote: >> Arguments.cpp has several size parsing functions which would be useful in other areas of the hotspot, e.g. in NMT. >> >> It would be nice to have them factored out into utilities, to reuse the code and to unify memory size handling. Gtests would be good too. >> >> To simplify reviews, I split the patch into two commits. >> >> The first commit (https://github.com/openjdk/jdk/pull/10252/commits/700e77e8d1469a2fc3d6611072c4b07aa34ab8e6) contains the unchanged code move without functional changes. >> >> The second commit (https://github.com/openjdk/jdk/pull/10252/commits/76b4f6f30cc316fd966da60ff6601f54eeb394bf) contains the functional changes I did, as well as the new gtest. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > feedback dholmes Looks good to me. Thanks. ------------- Marked as reviewed by jsjolen (Author). PR: https://git.openjdk.org/jdk/pull/10252 From duke at openjdk.org Fri Sep 23 07:33:24 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Fri, 23 Sep 2022 07:33:24 GMT Subject: RFR: 8293618: x86: Wrong code generation in class Assembler In-Reply-To: References: Message-ID: <06gdL9a_rlqEHgMAKUMiY69LbFGaaoD3M05U9QPmHKA=.e5dc017b-7f68-4b00-820a-e53f35d31224@github.com> On Fri, 23 Sep 2022 06:44:18 GMT, Tobias Hartmann wrote: >> @TobiHartmann Thanks for taking a look, method entry barrier needs a 4-byte immediate so it can be patched. This method is used in `Assembler::cmpl_imm32` > > Okay, so code before emitted an 8-bit immediate. Why didn't that cause any issues when patching? `cmpl(Address, int)` unconditionally emits a 32-bit immediate before, I make it emit 8-bit immediate where possible and create `cmpl_imm32` to strictly emit a 32-bit immediate, similar to how we have `subl_imm32` and `subq_imm32`. ------------- PR: https://git.openjdk.org/jdk/pull/10240 From stefank at openjdk.org Fri Sep 23 07:38:06 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 23 Sep 2022 07:38:06 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: <3AIWW1prhISoIn6Bnw6f_JkcSQqBJeMQMwisfOnI8vU=.ff7dae90-7da6-471e-9fdf-49ac3f6429ee@github.com> References: <3AIWW1prhISoIn6Bnw6f_JkcSQqBJeMQMwisfOnI8vU=.ff7dae90-7da6-471e-9fdf-49ac3f6429ee@github.com> Message-ID: On Thu, 22 Sep 2022 17:05:14 GMT, Thomas Stuefe wrote: > is the new version acceptable? I would have preferred if the parsing code were not placed in a .hpp file, and would have placed it in a .inline.hpp file, to comply with our guidelines. Other than that, I'm OK with this patch. ------------- PR: https://git.openjdk.org/jdk/pull/10252 From thartmann at openjdk.org Fri Sep 23 07:41:19 2022 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 23 Sep 2022 07:41:19 GMT Subject: RFR: 8293618: x86: Wrong code generation in class Assembler In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 15:30:01 GMT, Quan Anh Mai wrote: > Hi, > > This patch fixes some issues in the code generation of x86 assembler: > > - `Assembler::testl` misses `prefix(dst)` > - `Assembler::addw` misses the 0x66 prefix > - `Assembler::emit_operand` needs the length of the instruction from the address operand, this is often forgotten, making this parameter explicit to prevent potential issues > - The assembler should not do optimisations that change the actual emitted instructions, these should be moved to `MacroAssembler` instead > > AFAICT there is no failure due to these mistakes. Please take a look and give reviews. > Thanks you very much. Looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.org/jdk/pull/10240 From thartmann at openjdk.org Fri Sep 23 07:41:22 2022 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 23 Sep 2022 07:41:22 GMT Subject: RFR: 8293618: x86: Wrong code generation in class Assembler In-Reply-To: <06gdL9a_rlqEHgMAKUMiY69LbFGaaoD3M05U9QPmHKA=.e5dc017b-7f68-4b00-820a-e53f35d31224@github.com> References: <06gdL9a_rlqEHgMAKUMiY69LbFGaaoD3M05U9QPmHKA=.e5dc017b-7f68-4b00-820a-e53f35d31224@github.com> Message-ID: On Fri, 23 Sep 2022 07:29:04 GMT, Quan Anh Mai wrote: >> Okay, so code before emitted an 8-bit immediate. Why didn't that cause any issues when patching? > > `cmpl(Address, int)` unconditionally emits a 32-bit immediate before, I make it emit 8-bit immediate where possible and create `cmpl_imm32` to strictly emit a 32-bit immediate, similar to how we have `subl_imm32` and `subq_imm32`. Ah! Now I got it. Thanks for the explanation. ------------- PR: https://git.openjdk.org/jdk/pull/10240 From stuefe at openjdk.org Fri Sep 23 07:48:16 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 23 Sep 2022 07:48:16 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: References: <3AIWW1prhISoIn6Bnw6f_JkcSQqBJeMQMwisfOnI8vU=.ff7dae90-7da6-471e-9fdf-49ac3f6429ee@github.com> Message-ID: <7sBkuBNEssOrbvqJ7RtGNvjwz2u03YFhShncwo-sCSs=.f434addb-8f5e-43ef-8fae-d3144f8bdb57@github.com> On Fri, 23 Sep 2022 07:34:09 GMT, Stefan Karlsson wrote: >> @stefank @dholmes-ora @jdksjolen is the new version acceptable? > >> is the new version acceptable? > > I would have preferred if the parsing code were not placed in a .hpp file, and would have placed it in a .inline.hpp file, to comply with our guidelines. Other than that, I'm OK with this patch. Thanks Johan. I'll wait for @stefank a bit more, but will commit later today since I'm having vacation coming up. ------------- PR: https://git.openjdk.org/jdk/pull/10252 From aph-open at littlepinkcloud.com Fri Sep 23 08:51:11 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 23 Sep 2022 09:51:11 +0100 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: <66cb1e28-0d38-2008-753e-431aaa9c9791@oracle.com> References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> <416c7338-2dff-7997-c95f-c9e1c74de180@littlepinkcloud.com> <0958C022-824B-4492-9D82-393F64965D5E@oracle.com> <246e397f-2f10-84fa-19d7-65b1472606e9@littlepinkcloud.com> <4a767b25-1539-183a-e4cd-4852f633e77d@littlepinkcloud.com> <66cb1e28-0d38-2008-753e-431aaa9c9791@oracle.com> Message-ID: <5e7b6939-093e-87c3-146c-b6e7965aaf34@littlepinkcloud.com> On 9/23/22 00:40, dean.long at oracle.com wrote: > Also, since "Barrier-ordered-before" describes when RW1 "happened > before" RW2 (or RW2 "happened after" RW1, right?), I don't understand > why an additional "barrier-ordered-after" would be desired. This was explained by the comment: // This was checked by using the herd7 consistency model simulator // (http://diy.inria.fr/) with this test case: // // AArch64 LseCas // { 0:X1=x; 0:X2=y; 1:X1=x; 1:X2=y; } // P0 | P1; // LDR W4, [X2] | MOV W3, #0; // DMB LD | MOV W4, #1; // LDR W3, [X1] | CASAL W3, W4, [X1]; // | DMB ISH; // | STR W4, [X2]; // exists // (0:X3=0 /\ 0:X4=1) Here, if you remove the trailing DMB the store to [x2] has become visible before the store to [x1]. This happens because the CASAL followed by the STR has the memory effect of load [x1]; acquire; release; store [x1]; store [x2] And it's obvious that there is no ordering between the two stores. The fact that the operation on [x1] is atomic has no bearing on when the stores to [x1] and [x2] become visible. In order to prevent this reordering, we need StoreStore|StoreLoad after the CASAL. It's very instructive to run this test on the consistency model simulator. This interpretation was confirmed by the author of the Arm memory model. HOWEVER, the spec has been changed again, and it may well be that we no longer need the trailing barrier, because of the section you quoted: A memory read or write effect RW1 is Barrier-ordered-before a memory read or write effect RW2 from the same Observer if and only if RW1 appears in program order before RW2 and any of the following cases apply: ? RW1 is a memory write effect W1 and is generated by an atomic instruction with both Acquire and Release semantics. ... which looks like the spec has been tightened enough that we do not need the trailing barrier. Having said that, I think we still may need it for non-LSE, at least in theory. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From duke at openjdk.org Fri Sep 23 08:56:31 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Fri, 23 Sep 2022 08:56:31 GMT Subject: RFR: 8293618: x86: Wrong code generation in class Assembler In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 02:17:17 GMT, Vladimir Kozlov wrote: >> Hi, >> >> This patch fixes some issues in the code generation of x86 assembler: >> >> - `Assembler::testl` misses `prefix(dst)` >> - `Assembler::addw` misses the 0x66 prefix >> - `Assembler::emit_operand` needs the length of the instruction from the address operand, this is often forgotten, making this parameter explicit to prevent potential issues >> - The assembler should not do optimisations that change the actual emitted instructions, these should be moved to `MacroAssembler` instead >> >> AFAICT there is no failure due to these mistakes. Please take a look and give reviews. >> Thanks you very much. > > Testing passed. @vnkozlov @TobiHartmann Thanks a lot for your reviews. ------------- PR: https://git.openjdk.org/jdk/pull/10240 From dholmes at openjdk.org Fri Sep 23 08:58:42 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Sep 2022 08:58:42 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup Message-ID: Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). Testing: tiers 1-3 ------------- Commit messages: - Removal all special handling of ThreadDeath. - Remove all references to the stillborn field - Initial commit: remove JVM_StopThread - Merge - Updates to Java Thread Primitive Deprecation page - Repalce "it" with "victim thread" - Merge - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop - become -> became in javadoc - Merge - ... and 5 more: https://git.openjdk.org/jdk/compare/01e7b881...58bfb313 Changes: https://git.openjdk.org/jdk/pull/10400/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10400&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293592 Stats: 549 lines in 43 files changed: 134 ins; 308 del; 107 mod Patch: https://git.openjdk.org/jdk/pull/10400.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10400/head:pull/10400 PR: https://git.openjdk.org/jdk/pull/10400 From sspitsyn at openjdk.org Fri Sep 23 09:13:15 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Sep 2022 09:13:15 GMT Subject: RFR: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume [v4] In-Reply-To: <8JLdprikc0ub2-fJpBfZdvPetHalkAwMnWuTEDWUJWo=.288de2f6-24de-4f2b-bcf6-94dfd56e5f00@github.com> References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> <8JLdprikc0ub2-fJpBfZdvPetHalkAwMnWuTEDWUJWo=.288de2f6-24de-4f2b-bcf6-94dfd56e5f00@github.com> Message-ID: On Thu, 22 Sep 2022 15:05:37 GMT, Leonid Mesnik wrote: >> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. >> Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. >> >> Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fix Looks good. Thank you for the update. Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10351 From sspitsyn at openjdk.org Fri Sep 23 09:37:18 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Sep 2022 09:37:18 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 22:41:50 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/runtime/javaThread.cpp line 1174: >> >>> 1172: #if INCLUDE_JVMTI >>> 1173: // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks. >>> 1174: assert(!is_in_non_tmp_VTMS_transition(), "no suspend allowed in VTMS transition"); >> >> IMHO, a non tmp VTMS transition should be considered a type of VTMS transition, so the assert check here does not really match the assert text. Also see my related comments below on naming and use of these flags and APIs. > > Thanks. Accepted. Chris, I believe, this comment is resolved. Please, let me know if you disagree. >> src/hotspot/share/runtime/javaThread.hpp line 650: >> >>> 648: void set_is_in_VTMS_transition(bool val); >>> 649: bool is_in_tmp_VTMS_transition() const { return _is_in_tmp_VTMS_transition; } >>> 650: void toggle_is_in_tmp_VTMS_transition() { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; }; >> >> The naming of the flags does not match up with the naming of the APIs, which is confusing. An API named is_in_VTMS_transition() should return _is_in_VTMS_transition. I think part of problem is that _is_in_VTMS_transition is not a superset of _is_in_tmp_VTMS_transition. The flags are never both set true, although both can be false. Maybe this should be changed to make it an invariant that if _is_in_tmp_VTMS_transit is true, then _is_in_tmp_VTMS_transition is true. > > I agree, this naming is not good. However, I was reluctant to do required renaming because it can potentially impact many spots and make review harder. Let me think a little bit more on this. I've simplified this naming but, probably, not in a way your were expecting. Please, see my comment below. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Fri Sep 23 09:37:21 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Sep 2022 09:37:21 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 20:09:21 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. addressed review comments from Chris; added VirtualThread.java update from Alan > > src/hotspot/share/runtime/javaThread.hpp line 652: > >> 650: void set_is_in_VTMS_transition(bool val); >> 651: void toggle_is_in_tmp_VTMS_transition() { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; }; >> 652: > > My suggestion was to have the term "in VTMS transition" be inclusive of temp transitions. So based on your current names I would suggest: > > - is_in_VTMS_transition -> is_in_non_tmp_VTMS_transition > - is_in_any_VTMS_transition -> is_in_VTMS_transition > > But that becomes a problem for `set_is_in_VTMS_transition`, which would need to be renamed `set_is_in_non_tmp_VTMS_transition`, which I'm guessing you don't want to do. So let's instead just hope this all goes away before thinking about it any more. Thank you for sharing your suggestion. To be honest, I'm inclined to keep the two as simple as possible, independent end mutually exclusive. Temporary transitions have big difference comparing to normal transitions. They are allowed to be suspended and do not clash with VTMS disablers. Please, let me know if are okay with this. Unfortunately, it seems, Alan got some difficulties in getting rid of temporary transitions. I'll double check on it just to be sure I understand it correctly. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Fri Sep 23 09:42:15 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Sep 2022 09:42:15 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 22:34:59 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiExport.cpp line 1055: >> >>> 1053: if (JavaThread::current()->is_in_tmp_VTMS_transition()) { >>> 1054: return false; >>> 1055: } >> >> You mentioned this in the PR description. However, it's not clear to me why this is ok. Also, it should be commented. >> >> Same thing for changes in JvmtiExport::post_class_load() and JvmtiExport::post_class_prepare(). > > I initially wanted to consult on this with Alan. It feels like it'd be better if I did it before posting this PR. > We have just two possible approaches here. The best approach is to move any class loading out of the temporary transition code path. Then we already have the relevant asserts in place. However, this is not that easy to solve. Alan already suggested a couple of patches which I've tested but new places with class loads were discovered. Another approach is to skip all ClassLoad, ClassPrepare and CFLH events in context of temporary transitions. It is hard to estimate how acceptable it is. At least, I've not found any failing tests because of it which means it most likely does not impact the debugger. My current suggestion is to file a bug and try to address it later as Alan may need more time for analysis. We touched this issue with Alan and made a couple of updates. However, it occurred much harder to get rid of all class loading in context of temporary transitions. My current suggestion is still on the table. It is to file a separate bug and attempt to fix it later. NO test failures were discovered because of the skipped ClassLoad, ClassPrepare and CFLH events. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From fyang at openjdk.org Fri Sep 23 09:42:22 2022 From: fyang at openjdk.org (Fei Yang) Date: Fri, 23 Sep 2022 09:42:22 GMT Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov wrote: > Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR. > > benchmark results: > > before: > > Benchmark Mode Cnt Score Error Units > DoubleClassCheck.testIsFiniteBranch avgt 15 52.824 ? 1.744 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 16.104 ? 0.358 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 14.366 ? 2.174 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 49.821 ? 0.330 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 14.702 ? 0.335 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 14.749 ? 0.496 ns/op > > after: > > DoubleClassCheck.testIsFiniteBranch avgt 15 48.921 ? 0.557 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 13.716 ? 0.304 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 9.152 ? 0.158 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 47.740 ? 2.028 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 13.299 ? 0.282 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 9.185 ? 0.396 ns/op > > Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way. > > Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues. May I ask on which platform was the JMH test performed? I see some fluctuations for 'testIsFiniteBranch' on SiFive Unmatched board: Before: Benchmark Mode Cnt Score Error Units DoubleClassCheck.testIsFiniteBranch avgt 15 32.114 ? 3.514 ns/op DoubleClassCheck.testIsFiniteCMov avgt 15 8.656 ? 0.023 ns/op DoubleClassCheck.testIsFiniteStore avgt 15 7.757 ? 1.691 ns/op FloatClassCheck.testIsFiniteBranch avgt 15 32.446 ? 3.130 ns/op FloatClassCheck.testIsFiniteCMov avgt 15 7.801 ? 0.011 ns/op FloatClassCheck.testIsFiniteStore avgt 15 7.279 ? 1.483 ns/op Benchmark Mode Cnt Score Error Units DoubleClassCheck.testIsFiniteBranch avgt 15 33.724 ? 5.157 ns/op DoubleClassCheck.testIsFiniteCMov avgt 15 8.642 ? 0.012 ns/op DoubleClassCheck.testIsFiniteStore avgt 15 7.765 ? 1.711 ns/op FloatClassCheck.testIsFiniteBranch avgt 15 31.401 ? 4.104 ns/op FloatClassCheck.testIsFiniteCMov avgt 15 7.799 ? 0.014 ns/op FloatClassCheck.testIsFiniteStore avgt 15 8.234 ? 0.023 ns/op Benchmark Mode Cnt Score Error Units DoubleClassCheck.testIsFiniteBranch avgt 15 32.461 ? 3.688 ns/op DoubleClassCheck.testIsFiniteCMov avgt 15 8.643 ? 0.007 ns/op DoubleClassCheck.testIsFiniteStore avgt 15 7.772 ? 1.701 ns/op FloatClassCheck.testIsFiniteBranch avgt 15 33.258 ? 3.131 ns/op FloatClassCheck.testIsFiniteCMov avgt 15 7.815 ? 0.014 ns/op FloatClassCheck.testIsFiniteStore avgt 15 6.343 ? 1.475 ns/op After: Benchmark Mode Cnt Score Error Units DoubleClassCheck.testIsFiniteBranch avgt 15 33.915 ? 4.193 ns/op DoubleClassCheck.testIsFiniteCMov avgt 15 7.736 ? 0.012 ns/op DoubleClassCheck.testIsFiniteStore avgt 15 5.931 ? 0.007 ns/op FloatClassCheck.testIsFiniteBranch avgt 15 33.845 ? 3.449 ns/op FloatClassCheck.testIsFiniteCMov avgt 15 7.543 ? 0.013 ns/op FloatClassCheck.testIsFiniteStore avgt 15 6.035 ? 0.006 ns/op Benchmark Mode Cnt Score Error Units DoubleClassCheck.testIsFiniteBranch avgt 15 33.421 ? 4.262 ns/op DoubleClassCheck.testIsFiniteCMov avgt 15 7.734 ? 0.012 ns/op DoubleClassCheck.testIsFiniteStore avgt 15 5.940 ? 0.010 ns/op FloatClassCheck.testIsFiniteBranch avgt 15 33.348 ? 2.656 ns/op FloatClassCheck.testIsFiniteCMov avgt 15 7.542 ? 0.013 ns/op FloatClassCheck.testIsFiniteStore avgt 15 6.040 ? 0.004 ns/op Benchmark Mode Cnt Score Error Units DoubleClassCheck.testIsFiniteBranch avgt 15 31.669 ? 2.517 ns/op DoubleClassCheck.testIsFiniteCMov avgt 15 7.761 ? 0.092 ns/op DoubleClassCheck.testIsFiniteStore avgt 15 5.940 ? 0.007 ns/op FloatClassCheck.testIsFiniteBranch avgt 15 33.508 ? 3.680 ns/op FloatClassCheck.testIsFiniteCMov avgt 15 7.534 ? 0.009 ns/op FloatClassCheck.testIsFiniteStore avgt 15 6.031 ? 0.007 ns/op ------------- PR: https://git.openjdk.org/jdk/pull/10391 From mdoerr at openjdk.org Fri Sep 23 10:57:33 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 23 Sep 2022 10:57:33 GMT Subject: [jdk19] RFR: 8289302: Restore CriticalJNINatives In-Reply-To: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com> References: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com> Message-ID: On Wed, 29 Jun 2022 12:10:35 GMT, Coleen Phillimore wrote: > This change restores the code in the JVM that implemented the internal JavaCritical or CriticalJNINatives functionality. Customers are using this feature and there's no replacement yet for it. > This change is a backout and merge of jDK-8258192: Obsolete the CriticalJNINatives flag. > This change also adds the deprecation message that was missed, which I checked is okay with the customer. > > Tested with tiers1-4. `UseSystemMemoryBarrier` reduces the overhead of Java thread state transitions significantly (when returning from native and when calling JNI functions). But there's one additional thing which should be checked regarding handling of primitive arrays. Critical JNI functions provide direct access to the arrays in the Java heap while the regular JNI functions need to use Get/SetArrayRegion (which is fast for small arrays or when copying is required anyway) or GetArrayElements&ReleaseArrayElements (slower) or GetPrimitiveArrayCritical&ReleasePrimitiveArrayCritical (which can avoid copying costs, but require expensive interaction with GC). It's probably worth checking the JNI code for good selection of array access functions. ------------- PR: https://git.openjdk.org/jdk19/pull/90 From alanb at openjdk.org Fri Sep 23 11:12:24 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 23 Sep 2022 11:12:24 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes wrote: > Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). > > Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. > > Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). > > Testing: tiers 1-3 (JDK-8289610 is integrated now so once you sync up it should remove the changes from the dependent PR once the list of changed files. You should be able to trim down the labels too.) I did a pass over the src/hotspot change and didn't spot any issues. It's good that stillborn can go away. The removal of the special-casing of ThreadDeath is consistent with the libs side of the change, including the change to ExceptionDescribe. ------------- PR: https://git.openjdk.org/jdk/pull/10400 From bkilambi at openjdk.org Fri Sep 23 11:26:05 2022 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Fri, 23 Sep 2022 11:26:05 GMT Subject: RFR: 8293488: Add EOR3 backend rule for aarch64 SHA3 extension Message-ID: Arm ISA v8.2A and v9.0A include SHA3 feature extensions and one of those SHA3 instructions - "eor3" performs an exclusive OR of three vectors. This is helpful in applications that have multiple, consecutive "eor" operations which can be reduced by clubbing them into fewer operations using the "eor3" instruction. For example - eor a, a, b eor a, a, c can be optimized to single instruction - `eor3 a, b, c` This patch adds backend rules for Neon and SVE2 "eor3" instructions and a micro benchmark to assess the performance gains with this patch. Following are the results of the included micro benchmark on a 128-bit aarch64 machine that supports Neon, SVE2 and SHA3 features - Benchmark gain TestEor3.test1Int 10.87% TestEor3.test1Long 8.84% TestEor3.test2Int 21.68% TestEor3.test2Long 21.04% The numbers shown are performance gains with using Neon eor3 instruction over the master branch that uses multiple "eor" instructions instead. Similar gains can be observed with the SVE2 "eor3" version as well since the "eor3" instruction is unpredicated and the machine under test uses a maximum vector width of 128 bits which makes the SVE2 code generation very similar to the one with Neon. ------------- Commit messages: - 8293488: Add EOR3 backend rule for aarch64 SHA3 extension Changes: https://git.openjdk.org/jdk/pull/10407/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10407&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293488 Stats: 345 lines in 10 files changed: 310 ins; 0 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/10407.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10407/head:pull/10407 PR: https://git.openjdk.org/jdk/pull/10407 From dean.long at oracle.com Fri Sep 23 11:40:03 2022 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 23 Sep 2022 04:40:03 -0700 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: <5e7b6939-093e-87c3-146c-b6e7965aaf34@littlepinkcloud.com> References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> <416c7338-2dff-7997-c95f-c9e1c74de180@littlepinkcloud.com> <0958C022-824B-4492-9D82-393F64965D5E@oracle.com> <246e397f-2f10-84fa-19d7-65b1472606e9@littlepinkcloud.com> <4a767b25-1539-183a-e4cd-4852f633e77d@littlepinkcloud.com> <66cb1e28-0d38-2008-753e-431aaa9c9791@oracle.com> <5e7b6939-093e-87c3-146c-b6e7965aaf34@littlepinkcloud.com> Message-ID: <7fe72a8b-803e-39ae-c569-020b985c397d@oracle.com> I have to admit it is a bit surprising and counter-intuitive to me to not treat the CASAL as atomic. If the memory model allows the 2nd store to be moved "inside" the CASAL, then that means it might be impossible to provide a total order of the AArch64 instructions that reproduces the observed memory effects, and that makes me wonder if it would break tools like "rr". dl On 9/23/22 1:51 AM, Andrew Haley wrote: > On 9/23/22 00:40, dean.long at oracle.com wrote: > > Also, since "Barrier-ordered-before" describes when RW1 "happened > > before" RW2 (or RW2 "happened after" RW1, right?), I don't understand > > why an additional "barrier-ordered-after" would be desired. > > This was explained by the comment: > > ? // This was checked by using the herd7 consistency model simulator > ? // (http://diy.inria.fr/) with this test case: > ? // > ? // AArch64 LseCas > ? // { 0:X1=x; 0:X2=y; 1:X1=x; 1:X2=y; } > ? // P0 | P1; > ? // LDR W4, [X2] | MOV W3, #0; > ? // DMB LD?????? | MOV W4, #1; > ? // LDR W3, [X1] | CASAL W3, W4, [X1]; > ? //????????????? | DMB ISH; > ? //????????????? | STR W4, [X2]; > ? // exists > ? // (0:X3=0 /\ 0:X4=1) > > Here, if you remove the trailing DMB the store to [x2] has become visible > before the store to [x1]. > > This happens because the CASAL followed by the STR has the memory effect of > > ? load [x1]; acquire; release; store [x1]; store [x2] > > And it's obvious that there is no ordering between the two stores. The > fact that the operation on [x1] is atomic has no bearing on when the > stores to [x1] and [x2] become visible. > > In order to prevent this reordering, we need StoreStore|StoreLoad after > the CASAL. > > It's very instructive to run this test on the consistency model simulator. > This interpretation was confirmed by the author of the Arm memory model. > > HOWEVER, the spec has been changed again, and it may well be that we no > longer need the trailing barrier, because of the section you quoted: > > ? A memory read or write effect RW1 is Barrier-ordered-before a memory > ? read or write effect RW2 from the same Observer if and only if RW1 > ? appears in program order before RW2 and any of the following cases > ? apply: > > ?? ? RW1 is a memory write effect W1 and is generated by an atomic > ???? instruction with both Acquire and Release semantics. > > ... which looks like the spec has been tightened enough that we do not > need the trailing barrier. Having said that, I think we still may need > it for non-LSE, at least in theory. > From xlinzheng at openjdk.org Fri Sep 23 11:56:27 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Fri, 23 Sep 2022 11:56:27 GMT Subject: RFR: 8294187: RISC-V: Unify all relocations for the backend into AbstractAssembler::relocate() [v2] In-Reply-To: References: Message-ID: > Unify all relocations into AbstractAssembler::relocate() as a simple cleanup. > > Tested hotspot tier1 and tier2 on QEMU. Xiaolin Zheng has updated the pull request incrementally with two additional commits since the last revision: - Migrate them to the next patch for AbstractAssembler has their counterparts - Remove useless add_debug_info_for_branch(adr, CodeEmitInfo*) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10384/files - new: https://git.openjdk.org/jdk/pull/10384/files/21ba6a61..a33331e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10384&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10384&range=00-01 Stats: 27 lines in 3 files changed: 0 ins; 27 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10384.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10384/head:pull/10384 PR: https://git.openjdk.org/jdk/pull/10384 From xlinzheng at openjdk.org Fri Sep 23 11:56:29 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Fri, 23 Sep 2022 11:56:29 GMT Subject: RFR: 8294187: RISC-V: Unify all relocations for the backend into AbstractAssembler::relocate() [v2] In-Reply-To: References: Message-ID: <7aMc753dt0PZ9fNF1vMlczlLuoBLY6-hSs-71j56VjU=.737fac4c-231b-49c3-b24f-da8607ea3745@github.com> On Fri, 23 Sep 2022 01:01:20 GMT, Yadong Wang wrote: > Looks fine. But it's best to point out that it's bridging to the compressed-instruction-related relocation. Thanks. I've removed the relocate() definitions and will add them to other patches so this patch could be a simple cleanup. The title and description get updated. ------------- PR: https://git.openjdk.org/jdk/pull/10384 From xlinzheng at openjdk.org Fri Sep 23 11:56:30 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Fri, 23 Sep 2022 11:56:30 GMT Subject: RFR: 8294187: RISC-V: Unify all relocations for the backend into AbstractAssembler::relocate() [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 02:55:35 GMT, Fei Yang wrote: >> Xiaolin Zheng has updated the pull request incrementally with two additional commits since the last revision: >> >> - Migrate them to the next patch for AbstractAssembler has their counterparts >> - Remove useless add_debug_info_for_branch(adr, CodeEmitInfo*) > > src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp line 2147: > >> 2145: } >> 2146: >> 2147: void LIR_Assembler::add_debug_info_for_branch(address adr, CodeEmitInfo* info) { > > I see this function is never used: void LIR_Assembler::add_debug_info_for_branch(address adr, CodeEmitInfo* info) > So I would suggest remove this function. Then following two functions introduced by this PR would become unnecessary: > void relocate(address at, RelocationHolder const& rspec, int format = 0) { > code_section()->relocate(at, rspec, format); > } > void relocate(address at, relocInfo::relocType rtype, int format = 0, jint method_index = 0) { > code_section()->relocate(at, rtype, format, method_index); > } Thanks for pointing this out. All done. ------------- PR: https://git.openjdk.org/jdk/pull/10384 From fyang at openjdk.org Fri Sep 23 12:02:22 2022 From: fyang at openjdk.org (Fei Yang) Date: Fri, 23 Sep 2022 12:02:22 GMT Subject: RFR: 8294187: RISC-V: Unify all relocations for the backend into AbstractAssembler::relocate() [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 11:56:27 GMT, Xiaolin Zheng wrote: >> Unify all relocations into AbstractAssembler::relocate() as a simple cleanup. >> >> Tested hotspot tier1 and tier2 on QEMU. > > Xiaolin Zheng has updated the pull request incrementally with two additional commits since the last revision: > > - Migrate them to the next patch for AbstractAssembler has their counterparts > - Remove useless add_debug_info_for_branch(adr, CodeEmitInfo*) Updated changes look good. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10384 From coleenp at openjdk.org Fri Sep 23 12:43:15 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 23 Sep 2022 12:43:15 GMT Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications [v4] In-Reply-To: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com> References: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com> Message-ID: <7uEEjcCVoEfGK2L99QCHvzy9OWzl2I-4P_AelvyhvTc=.04adb658-216b-4811-a7a8-173a6786a44b@github.com> On Tue, 20 Sep 2022 10:37:41 GMT, David Holmes wrote: >> This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref: >> >> JDK-8290196 12.8: Clarify the definition of program exit >> https://bugs.openjdk.org/browse/JDK-8290196 >> >> JDK-8290388 5.7: Clarify the definition of JVM termination >> https://bugs.openjdk.org/browse/JDK-8290388 >> >> JDK-8290036 Define and specify Runtime shutdown sequence >> https://bugs.openjdk.org/browse/JDK-8290036 >> >> Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes: >> >> 1. The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this) >> >> 2. We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot. >> >> Issue 2 covers the code change, and regression test, in this PR. >> >> In addition the specification changes can be seen here: >> >> - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html >> - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html >> - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html >> >> The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment. >> >> Thank you. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix JniVersion test This seems good. I looked at the specification changes and they looked okay also. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/10352 From xlinzheng at openjdk.org Fri Sep 23 12:54:04 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Fri, 23 Sep 2022 12:54:04 GMT Subject: RFR: 8294187: RISC-V: Unify all relocations for the backend into AbstractAssembler::relocate() [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 11:56:27 GMT, Xiaolin Zheng wrote: >> Unify all relocations into AbstractAssembler::relocate() as a simple cleanup. >> >> Tested hotspot tier1 and tier2 on QEMU. > > Xiaolin Zheng has updated the pull request incrementally with two additional commits since the last revision: > > - Migrate them to the next patch for AbstractAssembler has their counterparts > - Remove useless add_debug_info_for_branch(adr, CodeEmitInfo*) Thank you all for the review! ------------- PR: https://git.openjdk.org/jdk/pull/10384 From aph-open at littlepinkcloud.com Fri Sep 23 12:58:48 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 23 Sep 2022 13:58:48 +0100 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: <7fe72a8b-803e-39ae-c569-020b985c397d@oracle.com> References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> <416c7338-2dff-7997-c95f-c9e1c74de180@littlepinkcloud.com> <0958C022-824B-4492-9D82-393F64965D5E@oracle.com> <246e397f-2f10-84fa-19d7-65b1472606e9@littlepinkcloud.com> <4a767b25-1539-183a-e4cd-4852f633e77d@littlepinkcloud.com> <66cb1e28-0d38-2008-753e-431aaa9c9791@oracle.com> <5e7b6939-093e-87c3-146c-b6e7965aaf34@littlepinkcloud.com> <7fe72a8b-803e-39ae-c569-020b985c397d@oracle.com> Message-ID: On 9/23/22 12:40, dean.long at oracle.com wrote: > I have to admit it is a bit surprising and counter-intuitive to me to > not treat the CASAL as atomic. If the memory model allows the 2nd store > to be moved "inside" the CASAL, then that means it might be impossible > to provide a total order of the AArch64 instructions that reproduces the > observed memory effects, and that makes me wonder if it would break > tools like "rr". Is that an "all the world's an x86" kind of intuition, though? We're all influenced more than we know by our history. Even Aleksey was surprised by https://twitter.com/shipilev/status/1400154160918581248 in which AArch64 produces "Interesting Whoa". -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From xlinzheng at openjdk.org Fri Sep 23 13:20:22 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Fri, 23 Sep 2022 13:20:22 GMT Subject: Integrated: 8294187: RISC-V: Unify all relocations for the backend into AbstractAssembler::relocate() In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 06:56:05 GMT, Xiaolin Zheng wrote: > Unify all relocations into AbstractAssembler::relocate() as a simple cleanup. > > Tested hotspot tier1 and tier2 on QEMU. This pull request has now been integrated. Changeset: 664e5b1d Author: Xiaolin Zheng Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/664e5b1d2e91107a3bae5b4b95d5724cf241a55f Stats: 33 lines in 7 files changed: 3 ins; 18 del; 12 mod 8294187: RISC-V: Unify all relocations for the backend into AbstractAssembler::relocate() Reviewed-by: fjiang, yadongwang, fyang ------------- PR: https://git.openjdk.org/jdk/pull/10384 From mdoerr at openjdk.org Fri Sep 23 13:21:31 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 23 Sep 2022 13:21:31 GMT Subject: [jdk19] RFR: 8289302: Restore CriticalJNINatives In-Reply-To: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com> References: <7gR6Mn55A3UZok9QRC_RvzPyqhzUbGMyD2ZiBuTaLDo=.12c212e8-0f69-4b90-bc2d-a52a208fe208@github.com> Message-ID: On Wed, 29 Jun 2022 12:10:35 GMT, Coleen Phillimore wrote: > This change restores the code in the JVM that implemented the internal JavaCritical or CriticalJNINatives functionality. Customers are using this feature and there's no replacement yet for it. > This change is a backout and merge of jDK-8258192: Obsolete the CriticalJNINatives flag. > This change also adds the deprecation message that was missed, which I checked is okay with the customer. > > Tested with tiers1-4. Btw. performance of GetPrimitiveArrayCritical&ReleasePrimitiveArrayCritical could get improved for weak memory model platforms by relaxing memory ordering semantics of `Atomic::inc/dec` in object pinning and `GCLocker` handling code. ------------- PR: https://git.openjdk.org/jdk19/pull/90 From avoitylov at openjdk.org Fri Sep 23 13:29:21 2022 From: avoitylov at openjdk.org (Aleksei Voitylov) Date: Fri, 23 Sep 2022 13:29:21 GMT Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V In-Reply-To: References: Message-ID: <1pLzhhwS9UM_pIlsDwEUAhgYhgoM-bEmEVhiU52-SgQ=.765d106a-f996-4953-8e2e-5dd6219db87e@github.com> On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov wrote: > Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR. > > benchmark results: > > before: > > Benchmark Mode Cnt Score Error Units > DoubleClassCheck.testIsFiniteBranch avgt 15 52.824 ? 1.744 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 16.104 ? 0.358 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 14.366 ? 2.174 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 49.821 ? 0.330 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 14.702 ? 0.335 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 14.749 ? 0.496 ns/op > > after: > > DoubleClassCheck.testIsFiniteBranch avgt 15 48.921 ? 0.557 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 13.716 ? 0.304 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 9.152 ? 0.158 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 47.740 ? 2.028 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 13.299 ? 0.282 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 9.185 ? 0.396 ns/op > > Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way. > > Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues. Good you checked on SiFive HW, as I could only check their cookbook for instruction costs. I was using C906. You're not observing any statistically significant difference in the first benchmark from this change due to higher latency of fclass instruction on SiFive CPU (4 cycles, while C906 has 3 cycles latency for fclass). However, it is still profitable in general as we replace 2 relatively expensive FP instructions with 1 FP + 2 cheap GPR instructions. That's what the rest of the cases demonstrate on both SiFive and C906. Overall, as the platform matures the instructions costs tend to decrease, so I'd assume fclass will take less cycles in most future implementations. ------------- PR: https://git.openjdk.org/jdk/pull/10391 From alanb at openjdk.org Fri Sep 23 13:57:56 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 23 Sep 2022 13:57:56 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v2] In-Reply-To: References: Message-ID: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Update DegradedMethodsThrowUOE to test Thread.stop - Merge - Update modifyThread and modifyThreadGroup targets - Merge - Fix typo in test comment - Keep link to threadPrimitiveDeprecation.html - Merge - Tests - Initial commit ------------- Changes: https://git.openjdk.org/jdk/pull/10324/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10324&range=01 Stats: 466 lines in 17 files changed: 148 ins; 255 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/10324.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10324/head:pull/10324 PR: https://git.openjdk.org/jdk/pull/10324 From stuefe at openjdk.org Fri Sep 23 14:08:25 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 23 Sep 2022 14:08:25 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: References: <3AIWW1prhISoIn6Bnw6f_JkcSQqBJeMQMwisfOnI8vU=.ff7dae90-7da6-471e-9fdf-49ac3f6429ee@github.com> Message-ID: <7JN3D-ftzKvAvCRgNACnwQMEAPIOk7NnJl_BWbdnGB0=.00393e3c-6613-4605-b1a9-279d0c09ca6e@github.com> On Fri, 23 Sep 2022 07:34:09 GMT, Stefan Karlsson wrote: > > is the new version acceptable? > > I would have preferred if the parsing code were not placed in a .hpp file, and would have placed it in a .inline.hpp file, to comply with our guidelines. Other than that, I'm OK with this patch. Almost missed your comment :-) I'll split it up as you suggested, then push. ------------- PR: https://git.openjdk.org/jdk/pull/10252 From stuefe at openjdk.org Fri Sep 23 14:10:55 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 23 Sep 2022 14:10:55 GMT Subject: RFR: JDK-8294266: Add a way to pre-touch java thread stacks Message-ID: When doing performance- and memory analysis, `AlwaysPreTouch` option is very handy for reducing noise. It would be good to have a similar option for pre-touching thread stacks. In addition to reducing noise, it can serve as worst-case test for thread costs, as well as a test for NMT regressions. Patch adds a new diagnostic switch, `AlwaysPreTouchStacks`, as a companion switch to `AlwaysPreTouch`. Touching is super-simple using `alloca()`. Also, regression test. Examples: NMT, thread stacks, 10000 Threads, default: - Thread (reserved=10332400KB, committed=331828KB) (thread #10021) (stack: reserved=10301560KB, committed=300988KB) (malloc=19101KB #60755) (arena=11739KB #20037) NMT, thread stacks, 10000 Threads, +AlwaysPreTouchStacks: - Thread (reserved=10332400KB, committed=10284360KB) (thread #10021) (stack: reserved=10301560KB, committed=10253520KB) (malloc=19101KB #60755) (arena=11739KB #20037) ------------- Commit messages: - Use os::pretouch_memory - AlwaysPreTouchStacks Changes: https://git.openjdk.org/jdk/pull/10403/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10403&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294266 Stats: 119 lines in 4 files changed: 119 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10403.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10403/head:pull/10403 PR: https://git.openjdk.org/jdk/pull/10403 From shade at openjdk.org Fri Sep 23 14:10:57 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 23 Sep 2022 14:10:57 GMT Subject: RFR: JDK-8294266: Add a way to pre-touch java thread stacks In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 09:39:41 GMT, Thomas Stuefe wrote: > When doing performance- and memory analysis, `AlwaysPreTouch` option is very handy for reducing noise. It would be good to have a similar option for pre-touching thread stacks. In addition to reducing noise, it can serve as worst-case test for thread costs, as well as a test for NMT regressions. > > Patch adds a new diagnostic switch, `AlwaysPreTouchStacks`, as a companion switch to `AlwaysPreTouch`. Touching is super-simple using `alloca()`. Also, regression test. > > Examples: > > NMT, thread stacks, 10000 Threads, default: > > > - Thread (reserved=10332400KB, committed=331828KB) > (thread #10021) > (stack: reserved=10301560KB, committed=300988KB) > (malloc=19101KB #60755) > (arena=11739KB #20037) > > > NMT, thread stacks, 10000 Threads, +AlwaysPreTouchStacks: > > > - Thread (reserved=10332400KB, committed=10284360KB) > (thread #10021) > (stack: reserved=10301560KB, committed=10253520KB) > (malloc=19101KB #60755) > (arena=11739KB #20037) Drive-by comment: there is `os::pretouch_memory(void* start, void* end, size_t page_size)` ;) ------------- PR: https://git.openjdk.org/jdk/pull/10403 From stuefe at openjdk.org Fri Sep 23 14:10:58 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 23 Sep 2022 14:10:58 GMT Subject: RFR: JDK-8294266: Add a way to pre-touch java thread stacks In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 11:52:15 GMT, Aleksey Shipilev wrote: > Drive-by comment: there is `os::pretouch_memory(void* start, void* end, size_t page_size)` ;) Good point. Had to cast the volatile away though. ------------- PR: https://git.openjdk.org/jdk/pull/10403 From stuefe at openjdk.org Fri Sep 23 14:12:26 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 23 Sep 2022 14:12:26 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: <7JN3D-ftzKvAvCRgNACnwQMEAPIOk7NnJl_BWbdnGB0=.00393e3c-6613-4605-b1a9-279d0c09ca6e@github.com> References: <3AIWW1prhISoIn6Bnw6f_JkcSQqBJeMQMwisfOnI8vU=.ff7dae90-7da6-471e-9fdf-49ac3f6429ee@github.com> <7JN3D-ftzKvAvCRgNACnwQMEAPIOk7NnJl_BWbdnGB0=.00393e3c-6613-4605-b1a9-279d0c09ca6e@github.com> Message-ID: <2txQ-RFzFybqprusuQbnZWexNi9GNV0cZ4Y1FC4PM4I=.2922afc3-6bad-493e-8342-8e2872d760ea@github.com> On Fri, 23 Sep 2022 14:04:54 GMT, Thomas Stuefe wrote: > > > is the new version acceptable? > > > > > > I would have preferred if the parsing code were not placed in a .hpp file, and would have placed it in a .inline.hpp file, to comply with our guidelines. Other than that, I'm OK with this patch. > > Almost missed your comment :-) > > I'll split it up as you suggested, then push. Wait, since the whole thing is all parsing, would that not mean we have just a parseInteger.inline.hpp, without a parseInteger.hpp? Since I'm unsure what would be left to put into parseInteger.hpp. And a parseInteger.inline.hpp without a parseInteger.hpp makes not much sense, or? We have some other one-trick-pony-headers that are not .inline and contain their whole functionality: powerOfTwo.hpp, population_count.hpp (probably should rename that), pair.hpp... ------------- PR: https://git.openjdk.org/jdk/pull/10252 From jsjolen at openjdk.org Fri Sep 23 16:20:16 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 23 Sep 2022 16:20:16 GMT Subject: RFR: 8294293: Remove unused _width and _newlines field in outputStream Message-ID: 1. `_width` is unused so I deleted it 2. `_newlines` was used in one place, and only to check if any new lines had been seen. I removed `_newlines` and instead used `update_position`'s unused return value to indicate whether any newlines has been seen. This required expanding the call of `xmlTextStream::write` in `defaultStream`. This removes some cruft from `outputStream` and saves us 8 bytes on the size of `outputStream`. I also noted that `_position` isn't number of chars into a line, but rather a "visual position". It's a bit surprising, which is why I added this comment. This can be seen in the `\t` case in `update_position`. ------------- Commit messages: - Reduce size and API scope of outputStream Changes: https://git.openjdk.org/jdk/pull/10411/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10411&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294293 Stats: 26 lines in 2 files changed: 4 ins; 8 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/10411.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10411/head:pull/10411 PR: https://git.openjdk.org/jdk/pull/10411 From duke at openjdk.org Fri Sep 23 17:17:00 2022 From: duke at openjdk.org (Quan Anh Mai) Date: Fri, 23 Sep 2022 17:17:00 GMT Subject: Integrated: 8293618: x86: Wrong code generation in class Assembler In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 15:30:01 GMT, Quan Anh Mai wrote: > Hi, > > This patch fixes some issues in the code generation of x86 assembler: > > - `Assembler::testl` misses `prefix(dst)` > - `Assembler::addw` misses the 0x66 prefix > - `Assembler::emit_operand` needs the length of the instruction from the address operand, this is often forgotten, making this parameter explicit to prevent potential issues > - The assembler should not do optimisations that change the actual emitted instructions, these should be moved to `MacroAssembler` instead > > AFAICT there is no failure due to these mistakes. Please take a look and give reviews. > Thanks you very much. This pull request has now been integrated. Changeset: e2f82514 Author: Quan Anh Mai Committer: Vladimir Kozlov URL: https://git.openjdk.org/jdk/commit/e2f82514906d483b6e46ff06d8673b77c9f89f08 Stats: 540 lines in 5 files changed: 62 ins; 25 del; 453 mod 8293618: x86: Wrong code generation in class Assembler Reviewed-by: kvn, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/10240 From jsjolen at openjdk.org Fri Sep 23 17:25:44 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 23 Sep 2022 17:25:44 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj Message-ID: Here's a suggested solution for the ticket mentioned and a use case for outputStream. I'm not attached to the name. This saves space for all allocated outputStreams, which is nice. It also makes the purpose of ResourceObj more clear ("please handle the life cycle for me"), reducing the need for it. Thank you for considering it. ------------- Commit messages: - DynCHeapObj Changes: https://git.openjdk.org/jdk/pull/10412/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10412&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294308 Stats: 64 lines in 13 files changed: 44 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/10412.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10412/head:pull/10412 PR: https://git.openjdk.org/jdk/pull/10412 From lmesnik at openjdk.org Fri Sep 23 17:48:42 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 23 Sep 2022 17:48:42 GMT Subject: Integrated: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume In-Reply-To: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Mon, 19 Sep 2022 23:02:42 GMT, Leonid Mesnik wrote: > The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. > Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. > > Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. This pull request has now been integrated. Changeset: 543851db Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/543851db926469df57a8f4a2bd3458349012145f Stats: 393 lines in 16 files changed: 163 ins; 168 del; 62 mod 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/10351 From cjplummer at openjdk.org Fri Sep 23 18:31:23 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Sep 2022 18:31:23 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes wrote: > Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). > > Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. > > Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). > > Testing: tiers 1-3 src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 102: > 100: try { > 101: connector = connectors.next(); > 102: } catch (Exception | Error x) { Maybe this should just catch `Throwable`, although it is unclear to me why we would want to catch any exception here. src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126: > 124: try { > 125: transportService = transportServices.next(); > 126: } catch (Exception | Error x) { Another that could be just catch `Throwable` ------------- PR: https://git.openjdk.org/jdk/pull/10400 From cjplummer at openjdk.org Fri Sep 23 18:39:19 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Sep 2022 18:39:19 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. addressed review comments from Chris; added VirtualThread.java update from Alan src/hotspot/share/prims/jvmtiThreadState.cpp line 273: > 271: > 272: assert(!thread->is_in_tmp_VTMS_transition(), "sanity check"); > 273: assert(!thread->is_in_VTMS_transition(), "VTMS_transition sanity check"); Why not cover both of these with `!thread->is_in_any_VTMS_transition()`? ------------- PR: https://git.openjdk.org/jdk/pull/10321 From cjplummer at openjdk.org Fri Sep 23 18:39:22 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Sep 2022 18:39:22 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 09:30:32 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/runtime/javaThread.hpp line 652: >> >>> 650: void set_is_in_VTMS_transition(bool val); >>> 651: void toggle_is_in_tmp_VTMS_transition() { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; }; >>> 652: >> >> My suggestion was to have the term "in VTMS transition" be inclusive of temp transitions. So based on your current names I would suggest: >> >> - is_in_VTMS_transition -> is_in_non_tmp_VTMS_transition >> - is_in_any_VTMS_transition -> is_in_VTMS_transition >> >> But that becomes a problem for `set_is_in_VTMS_transition`, which would need to be renamed `set_is_in_non_tmp_VTMS_transition`, which I'm guessing you don't want to do. So let's instead just hope this all goes away before thinking about it any more. > > Thank you for sharing your suggestion. > To be honest, I'm inclined to keep the two as simple as possible, independent end mutually exclusive. > Temporary transitions have big difference comparing to normal transitions. > They are allowed to be suspended and do not clash with VTMS disablers. > Please, let me know if are okay with this. > > Unfortunately, it seems, Alan got some difficulties in getting rid of temporary transitions. > I'll double check on it just to be sure I understand it correctly. ok ------------- PR: https://git.openjdk.org/jdk/pull/10321 From dean.long at oracle.com Fri Sep 23 18:52:44 2022 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 23 Sep 2022 11:52:44 -0700 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> <416c7338-2dff-7997-c95f-c9e1c74de180@littlepinkcloud.com> <0958C022-824B-4492-9D82-393F64965D5E@oracle.com> <246e397f-2f10-84fa-19d7-65b1472606e9@littlepinkcloud.com> <4a767b25-1539-183a-e4cd-4852f633e77d@littlepinkcloud.com> <66cb1e28-0d38-2008-753e-431aaa9c9791@oracle.com> <5e7b6939-093e-87c3-146c-b6e7965aaf34@littlepinkcloud.com> <7fe72a8b-803e-39ae-c569-020b985c397d@oracle.com> Message-ID: <7f54075d-777b-e33c-19a2-d0ff69e9d77d@oracle.com> On 9/23/22 5:58 AM, Andrew Haley wrote: > On 9/23/22 12:40, dean.long at oracle.com wrote: >> I have to admit it is a bit surprising and counter-intuitive to me to >> not treat the CASAL as atomic.? If the memory model allows the 2nd store >> to be moved "inside" the CASAL, then that means it might be impossible >> to provide a total order of the AArch64 instructions that reproduces the >> observed memory effects, and that makes me wonder if it would break >> tools like "rr". > > Is that an "all the world's an x86" kind of intuition, though? We're > all influenced more than we know by our history. Even Aleksey was > surprised by > https://twitter.com/shipilev/status/1400154160918581248 > in which AArch64 produces "Interesting? Whoa". > For me it's more getting stuck thinking in terms of machine instructions. If I can conceptually make the switch to "operations" and memory effects, then everything is fine. dl PS - I didn't mean to derail this thread! From coleenp at openjdk.org Fri Sep 23 19:58:22 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 23 Sep 2022 19:58:22 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 17:08:46 GMT, Johan Sj?len wrote: > Here's a suggested solution for the ticket mentioned and a use case for outputStream. I'm not attached to the name. > > This saves space for all allocated outputStreams, which is nice. It also makes the purpose of ResourceObj more clear ("please handle the life cycle for me"), reducing the need for it. > > Thank you for considering it. src/hotspot/share/memory/allocation.hpp line 219: > 217: }; > 218: > 219: class DynCHeapObj { I tried this and it seems to work: If you make CHeapObj new operators take MEMFLAGS f = F, where F is the default value, you could not have this class and make outputStream inherit from CHeapObj and the new calls will override mtInternal. I guess the risk is that you get mtInternal if you forget the parameter to new. src/hotspot/share/opto/compile.cpp line 4413: > 4411: // print_inlining_init is actually called several times. > 4412: print_inlining_stream_free(); > 4413: _print_inlining_stream = new (mtCompiler) stringStream(); These now need a delete (which is good because it doesn't need an explicit destructor call). ------------- PR: https://git.openjdk.org/jdk/pull/10412 From sspitsyn at openjdk.org Fri Sep 23 20:42:03 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Sep 2022 20:42:03 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: <8XO95Zy9ZwaIiWxspJhRLwP9JdLM8sVpTyIoF3JKYOY=.a0320f59-6e1e-4c9d-ad2c-5b2b8b792529@github.com> On Fri, 23 Sep 2022 18:32:57 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. addressed review comments from Chris; added VirtualThread.java update from Alan > > src/hotspot/share/prims/jvmtiThreadState.cpp line 273: > >> 271: >> 272: assert(!thread->is_in_tmp_VTMS_transition(), "sanity check"); >> 273: assert(!thread->is_in_VTMS_transition(), "VTMS_transition sanity check"); > > Why not cover both of these with `!thread->is_in_any_VTMS_transition()`? It is to be clear what condition caused the assert as they are different beasts. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Fri Sep 23 20:48:02 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Sep 2022 20:48:02 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 13:57:56 GMT, Alan Bateman wrote: >> Degrade Thread.suspend/resume to throw UOE unconditionally. >> >> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. >> >> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. >> >> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Update DegradedMethodsThrowUOE to test Thread.stop > - Merge > - Update modifyThread and modifyThreadGroup targets > - Merge > - Fix typo in test comment > - Keep link to threadPrimitiveDeprecation.html > - Merge > - Tests > - Initial commit Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10324 From cjplummer at openjdk.org Fri Sep 23 21:00:47 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Sep 2022 21:00:47 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. addressed review comments from Chris; added VirtualThread.java update from Alan Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10321 From cjplummer at openjdk.org Fri Sep 23 21:00:47 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Sep 2022 21:00:47 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: <8XO95Zy9ZwaIiWxspJhRLwP9JdLM8sVpTyIoF3JKYOY=.a0320f59-6e1e-4c9d-ad2c-5b2b8b792529@github.com> References: <8XO95Zy9ZwaIiWxspJhRLwP9JdLM8sVpTyIoF3JKYOY=.a0320f59-6e1e-4c9d-ad2c-5b2b8b792529@github.com> Message-ID: On Fri, 23 Sep 2022 20:38:17 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiThreadState.cpp line 273: >> >>> 271: >>> 272: assert(!thread->is_in_tmp_VTMS_transition(), "sanity check"); >>> 273: assert(!thread->is_in_VTMS_transition(), "VTMS_transition sanity check"); >> >> Why not cover both of these with `!thread->is_in_any_VTMS_transition()`? > > It is to be clear what condition caused the assert as they are different beasts. ok ------------- PR: https://git.openjdk.org/jdk/pull/10321 From kim.barrett at oracle.com Fri Sep 23 21:22:43 2022 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 23 Sep 2022 21:22:43 +0000 Subject: RFC: linux-aarch64 and LSE support In-Reply-To: <7f54075d-777b-e33c-19a2-d0ff69e9d77d@oracle.com> References: <7BD2A887-C204-4A36-8F2E-FA7386C17E2D@oracle.com> <28764c2d-6963-98ca-1212-b296d649e513@littlepinkcloud.com> <268A90AB-A4F1-44CB-A027-C07A12F9209B@oracle.com> <416c7338-2dff-7997-c95f-c9e1c74de180@littlepinkcloud.com> <0958C022-824B-4492-9D82-393F64965D5E@oracle.com> <246e397f-2f10-84fa-19d7-65b1472606e9@littlepinkcloud.com> <4a767b25-1539-183a-e4cd-4852f633e77d@littlepinkcloud.com> <66cb1e28-0d38-2008-753e-431aaa9c9791@oracle.com> <5e7b6939-093e-87c3-146c-b6e7965aaf34@littlepinkcloud.com> <7fe72a8b-803e-39ae-c569-020b985c397d@oracle.com> <7f54075d-777b-e33c-19a2-d0ff69e9d77d@oracle.com> Message-ID: > On Sep 23, 2022, at 2:52 PM, dean.long at oracle.com wrote: > > On 9/23/22 5:58 AM, Andrew Haley wrote: >> On 9/23/22 12:40, dean.long at oracle.com wrote: >>> I have to admit it is a bit surprising and counter-intuitive to me to >>> not treat the CASAL as atomic. If the memory model allows the 2nd store >>> to be moved "inside" the CASAL, then that means it might be impossible >>> to provide a total order of the AArch64 instructions that reproduces the >>> observed memory effects, and that makes me wonder if it would break >>> tools like "rr". >> Is that an "all the world's an x86" kind of intuition, though? We're >> all influenced more than we know by our history. Even Aleksey was >> surprised by >> https://twitter.com/shipilev/status/1400154160918581248 >> in which AArch64 produces "Interesting Whoa". > > For me it's more getting stuck thinking in terms of machine instructions. If I can conceptually make the switch to "operations" and memory effects, then everything is fine. > > dl > > PS - I didn't mean to derail this thread! You haven?t derailed anything. I?m having similar thoughts and trying to figure out the story might be. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From dholmes at openjdk.org Fri Sep 23 21:47:06 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Sep 2022 21:47:06 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: > Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). > > Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. > > Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). > > Testing: tiers 1-3 David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' into 8293592-JVM_StopThread - Removal all special handling of ThreadDeath. - Remove all references to the stillborn field - Initial commit: remove JVM_StopThread - Merge - Updates to Java Thread Primitive Deprecation page - Repalce "it" with "victim thread" - Merge - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop - become -> became in javadoc - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 ------------- Changes: https://git.openjdk.org/jdk/pull/10400/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10400&range=01 Stats: 208 lines in 18 files changed: 19 ins; 146 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/10400.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10400/head:pull/10400 PR: https://git.openjdk.org/jdk/pull/10400 From dholmes at openjdk.org Fri Sep 23 21:47:08 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Sep 2022 21:47:08 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes wrote: > Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). > > Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. > > Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). > > Testing: tiers 1-3 This PR is now back to its proper form after merging the upstream changes. I can't say I like the "dependent PR" feature. ------------- PR: https://git.openjdk.org/jdk/pull/10400 From dholmes at openjdk.org Fri Sep 23 21:47:10 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Sep 2022 21:47:10 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 18:21:30 GMT, Chris Plummer wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into 8293592-JVM_StopThread >> - Removal all special handling of ThreadDeath. >> - Remove all references to the stillborn field >> - Initial commit: remove JVM_StopThread >> - Merge >> - Updates to Java Thread Primitive Deprecation page >> - Repalce "it" with "victim thread" >> - Merge >> - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop >> - become -> became in javadoc >> - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 > > src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 102: > >> 100: try { >> 101: connector = connectors.next(); >> 102: } catch (Exception | Error x) { > > Maybe this should just catch `Throwable`, although it is unclear to me why we would want to catch any exception here. @plummercj these changes are not actually part of this PR but came from the upstream PR this was dependent on. > src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126: > >> 124: try { >> 125: transportService = transportServices.next(); >> 126: } catch (Exception | Error x) { > > Another that could be just catch `Throwable` @plummercj these changes are not actually part of this PR but came from the upstream PR this was dependent on. ------------- PR: https://git.openjdk.org/jdk/pull/10400 From ihse at openjdk.org Fri Sep 23 21:49:55 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 Sep 2022 21:49:55 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v2] In-Reply-To: References: Message-ID: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - ppc64 triggers shift-negative-value on gcc :-( - s390 triggers shift-negative-value on gcc :-( ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/209822db..ac15b0b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Fri Sep 23 21:49:56 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 Sep 2022 21:49:56 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 20:22:37 GMT, Magnus Ihse Bursie wrote: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. It turned out GHA had problems, with the cross-compiled platforms. I'll fix those. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From kbarrett at openjdk.org Sat Sep 24 03:36:54 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 24 Sep 2022 03:36:54 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v2] In-Reply-To: References: Message-ID: <90OTsoZSmHOgDEDHsqPbsuodVH8U-pLO4bfRXszp6bU=.1f06f500-3f4c-42b7-8f9c-e428d272da92@github.com> On Fri, 23 Sep 2022 21:49:55 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. >> >> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. >> >> Some warnings didn't trigger in any file anymore, and could just be removed. >> >> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. >> >> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. >> >> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. >> >> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). >> >> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - ppc64 triggers shift-negative-value on gcc :-( > - s390 triggers shift-negative-value on gcc :-( I like the general idea. In particular, the file-specific disables provide a nice list of bite-sized potential cleanup RFEs. However, shift-negative-value should remain globally disabled for gcc/clang; see https://bugs.openjdk.org/browse/JDK-8240259. There might be other warnings that should remain globally disabled; I've not gone through the list carefully yet. There used to be more comments around the warning disables. The Windows ones had comments that gave titles to the numeric codes. And I think there were some comments that discussed why a warning was disabled rather than fixing code. I don't know when that all disappeared, but it was quite a while ago, and I still miss that commentary. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/10414 From alanb at openjdk.org Sat Sep 24 06:43:17 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 Sep 2022 06:43:17 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 21:47:06 GMT, David Holmes wrote: >> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). >> >> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. >> >> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). >> >> Testing: tiers 1-3 > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into 8293592-JVM_StopThread > - Removal all special handling of ThreadDeath. > - Remove all references to the stillborn field > - Initial commit: remove JVM_StopThread > - Merge > - Updates to Java Thread Primitive Deprecation page > - Repalce "it" with "victim thread" > - Merge > - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop > - become -> became in javadoc > - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10400 From alanb at openjdk.org Sat Sep 24 06:43:18 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 Sep 2022 06:43:18 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: <-8imvtLKzzu_1t6YJsZYkxNbQ5JD1PaXXzK2O0nWc-s=.7c3843ad-c959-4a14-86c8-7b9722c3eb05@github.com> On Fri, 23 Sep 2022 21:42:08 GMT, David Holmes wrote: >> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126: >> >>> 124: try { >>> 125: transportService = transportServices.next(); >>> 126: } catch (Exception | Error x) { >> >> Another that could be just catch `Throwable` > > @plummercj these changes are not actually part of this PR but came from the upstream PR this was dependent on. I think this dates from JDK 5 when pluggable JDI connectors and transports were aded. VirtualMachineManager does specify that it tolerates configuration and deployment issues with: "At start-up time the VirtualMachineManager attempts to load and instantiate (using the no-arg constructor) each class listed in the provider configuration file. Exceptions thrown when loading or creating the Connector are caught and ignored. In other words, the start-up process continues despite of errors." Looking at it now, I think it should be catching ServiceConfigurationError as that is what the SL's iterator hasNext/next will throw if locating, loading or instantiating a Connector fails. This seems something for an another issue of course, just strange that the Skara bots included it. ------------- PR: https://git.openjdk.org/jdk/pull/10400 From alanb at openjdk.org Sat Sep 24 06:50:45 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 Sep 2022 06:50:45 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v3] In-Reply-To: References: Message-ID: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Remove tests from exclude list - Merge - Update DegradedMethodsThrowUOE to test Thread.stop - Merge - Update modifyThread and modifyThreadGroup targets - Merge - Fix typo in test comment - Keep link to threadPrimitiveDeprecation.html - Merge - Tests - ... and 1 more: https://git.openjdk.org/jdk/compare/543851db...6aa38889 ------------- Changes: https://git.openjdk.org/jdk/pull/10324/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10324&range=02 Stats: 454 lines in 16 files changed: 136 ins; 255 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/10324.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10324/head:pull/10324 PR: https://git.openjdk.org/jdk/pull/10324 From alanb at openjdk.org Sat Sep 24 06:50:46 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 Sep 2022 06:50:46 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 13:57:56 GMT, Alan Bateman wrote: >> Degrade Thread.suspend/resume to throw UOE unconditionally. >> >> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. >> >> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. >> >> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Update DegradedMethodsThrowUOE to test Thread.stop > - Merge > - Update modifyThread and modifyThreadGroup targets > - Merge > - Fix typo in test comment > - Keep link to threadPrimitiveDeprecation.html > - Merge > - Tests > - Initial commit Leonid has integrated JDK-8289607 to remove the last usages of Thread.suspend/resume from the hotspot tests so I've refreshed this PR to drop the temporary excluding of these tests. ------------- PR: https://git.openjdk.org/jdk/pull/10324 From sspitsyn at openjdk.org Sat Sep 24 08:45:17 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 24 Sep 2022 08:45:17 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. addressed review comments from Chris; added VirtualThread.java update from Alan Thank you for review, Chris! ------------- PR: https://git.openjdk.org/jdk/pull/10321 From jsjolen at openjdk.org Sat Sep 24 09:53:23 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sat, 24 Sep 2022 09:53:23 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v2] In-Reply-To: References: Message-ID: <7EOFhJV-QAk2dB7FM5LHurR5R0lypcWPvdO_nSSMRgk=.8752a923-0b25-4ad3-832e-511037267449@github.com> > Here's a suggested solution for the ticket mentioned and a use case for outputStream. I'm not attached to the name. > > This saves space for all allocated outputStreams, which is nice. It also makes the purpose of ResourceObj more clear ("please handle the life cycle for me"), reducing the need for it. > > Thank you for considering it. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Try out Coleen's suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10412/files - new: https://git.openjdk.org/jdk/pull/10412/files/eb0174f6..11e88122 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10412&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10412&range=00-01 Stats: 61 lines in 2 files changed: 1 ins; 42 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/10412.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10412/head:pull/10412 PR: https://git.openjdk.org/jdk/pull/10412 From jsjolen at openjdk.org Sat Sep 24 09:53:25 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sat, 24 Sep 2022 09:53:25 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 19:53:56 GMT, Coleen Phillimore wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Try out Coleen's suggestion > > src/hotspot/share/memory/allocation.hpp line 219: > >> 217: }; >> 218: >> 219: class DynCHeapObj { > > I tried this and it seems to work: If you make CHeapObj new operators take MEMFLAGS f = F, where F is the default value, you could not have this class and make outputStream inherit from CHeapObj and the new calls will override mtInternal. I guess the risk is that you get mtInternal if you forget the parameter to new. Good idea! I implemented this instead. > src/hotspot/share/opto/compile.cpp line 4413: > >> 4411: // print_inlining_init is actually called several times. >> 4412: print_inlining_stream_free(); >> 4413: _print_inlining_stream = new (mtCompiler) stringStream(); > > These now need a delete (which is good because it doesn't need an explicit destructor call). We'll wait and see how https://github.com/openjdk/jdk/pull/10396 turns out before merging this :-). ------------- PR: https://git.openjdk.org/jdk/pull/10412 From ihse at openjdk.org Sun Sep 25 00:28:47 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Sun, 25 Sep 2022 00:28:47 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v2] In-Reply-To: <90OTsoZSmHOgDEDHsqPbsuodVH8U-pLO4bfRXszp6bU=.1f06f500-3f4c-42b7-8f9c-e428d272da92@github.com> References: <90OTsoZSmHOgDEDHsqPbsuodVH8U-pLO4bfRXszp6bU=.1f06f500-3f4c-42b7-8f9c-e428d272da92@github.com> Message-ID: On Sat, 24 Sep 2022 03:33:34 GMT, Kim Barrett wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - ppc64 triggers shift-negative-value on gcc :-( >> - s390 triggers shift-negative-value on gcc :-( > > There used to be more comments around the warning disables. The Windows ones > had comments that gave titles to the numeric codes. And I think there were > some comments that discussed why a warning was disabled rather than fixing > code. I don't know when that all disappeared, but it was quite a while ago, > and I still miss that commentary. @kimbarrett That must have been in the old hotspot build system then. We are now nearing a point were we have so few disabled warnings that it makes sense to write down some rationale for those we have left, at least those which are globally (I assume you mean "for hotspot" with "globally" :-)) disabled. There is also a list of truly globally disabled warnings (for all native code in the JDK, not only hotspot). These should need some reviewing as well, and if we agree to keep them globally disabled, a rationale can be provided. If the documentation tends to be to long and rambling, we might need to put it elsewhere than as comments in the makefiles though, perhaps as a separate document. I can make a summary of the warnings that are no longer globally disabled with this fix, so you can check if some of them should be (even if they are not triggering anything right now). Also note that I ran into a lot of trouble with the cross-compilation on GHA, so I'll have to either replicate those locally, or fight a bit with GHA to get progress more than one file at a time. In any case, it will take a while for me to sort out. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From jwaters at openjdk.org Sun Sep 25 00:36:26 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 25 Sep 2022 00:36:26 GMT Subject: RFR: 8291917: Windows - Improve error messages when the C Runtime Libraries or jvm.dll cannot be loaded [v5] In-Reply-To: References: Message-ID: > Please review a small patch for dumping the failure reason when the MSVCRT libraries or the Java Virtual Machine fails to load on Windows, which can provide invaluable insight when debugging related launcher issues. Julian Waters 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 'openjdk:master' into patch-4 - Back out change to DLL_ERROR4 for separate RFE - Missing spacing between errors - Introduce warning when system error cannot be determined - LoadLibrary checks should explicitly use NULL - Dump error (if any) when libraries fail to load - Prettify DLL_ERROR4 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9749/files - new: https://git.openjdk.org/jdk/pull/9749/files/990ee4fd..284ac2f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9749&range=03-04 Stats: 164674 lines in 2718 files changed: 78252 ins; 68762 del; 17660 mod Patch: https://git.openjdk.org/jdk/pull/9749.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9749/head:pull/9749 PR: https://git.openjdk.org/jdk/pull/9749 From mernst at openjdk.org Sun Sep 25 17:04:38 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Message-ID: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni ------------- Commit messages: - Remove file that was removed upstream - Fix inconsistency in capitalization - Undo change in zlip - Fix typos Changes: https://git.openjdk.org/jdk/pull/10029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294321 Stats: 317 lines in 108 files changed: 0 ins; 195 del; 122 mod Patch: https://git.openjdk.org/jdk/pull/10029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029 PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:38 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue. Done: https://bugs.openjdk.org/browse/SKARA-1566 ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jpai at openjdk.org Sun Sep 25 17:04:38 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> References: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> Message-ID: On Thu, 25 Aug 2022 19:55:47 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > >> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue. > > Done: https://bugs.openjdk.org/browse/SKARA-1566 Hello Michael @mernst, these changes are mostly fine. However, they are spread across files which reside in different areas of the JDK. For changes like these, we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs. Would you be willing to split this PR into separate ones. I would recommend starting with one PR which includes changes that are part of `test/jdk/java`, `test/jdk/jdk` and `test/jdk/jni`. If you can come up with that PR, then I'll go ahead and create a JBS issue for it and you can then link the PR against that issue. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:38 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> Message-ID: On Mon, 5 Sep 2022 06:32:44 GMT, Jaikiran Pai wrote: > these changes are mostly fine. Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? It doesn't seem useful to make a pull request with known deficiencies. > we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs. Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Sun Sep 25 17:04:39 2022 From: duke at openjdk.org (SWinxy) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> Message-ID: On Mon, 5 Sep 2022 14:54:50 GMT, Michael Ernst wrote: > Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? These changes are fine. I don't see an instance where the duplicated words would mean a change in the specification. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jpai at openjdk.org Sun Sep 25 17:04:39 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Hello Michael, > > these changes are mostly fine. > > Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? It doesn't seem useful to make a pull request with known deficiencies. I wasn't implying this PR had deficiencies. What I meant was, to be able to have this reviewed, in addition to code changes this will also need a issue to be created and linked to this PR (and the PR title changed to the form `: `). I have now created https://bugs.openjdk.org/browse/JDK-8294321. Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:39 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Sat, 24 Sep 2022 10:41:05 GMT, Jaikiran Pai wrote: > Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers. OK. I'll repeat my comment from before: > Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Sun Sep 25 17:04:39 2022 From: duke at openjdk.org (SWinxy) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Oh no what happened ![image](https://user-images.githubusercontent.com/8303399/192155378-4bb439fa-d27a-417d-8a3c-cf7f7329458f.png) src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053: > 1051: * fetch will take place at index 1. > 1052: * > 1053: * @return The current position index. Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:39 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Sun, 25 Sep 2022 16:51:27 GMT, SWinxy wrote: > Oh no what happened Oops! Thanks for pointing out the goof. It seems to be fixed now. It has now been a month since I opened the pull request, and I have responded to each substantive comment promptly. It would be great to merge this pull request to avoid the need for more merges. > src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053: > >> 1051: * fetch will take place at index 1. >> 1052: * >> 1053: * @return The current position index. > > Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here. Thanks for pointing out the inconsistency. I have fixed it. (I noticed many violations of the official Javadoc style, but this is not the right pull request to fix them.) ------------- PR: https://git.openjdk.org/jdk/pull/10029 From alanb at openjdk.org Sun Sep 25 17:04:40 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 25 Sep 2022 17:04:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni src/java.base/share/native/libzip/zlib/zlib.h line 756: > 754: If this is done, the old level and strategy will be applied to the data > 755: compressed before deflateParams(), and the new level and strategy will be > 756: applied to the data compressed after deflateParams(). This is an issue for the upstream zlib project, we probably don't want to change it here. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From lancea at openjdk.org Sun Sep 25 17:04:40 2022 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 25 Sep 2022 17:04:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 09:31:07 GMT, Alan Bateman wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > src/java.base/share/native/libzip/zlib/zlib.h line 756: > >> 754: If this is done, the old level and strategy will be applied to the data >> 755: compressed before deflateParams(), and the new level and strategy will be >> 756: applied to the data compressed after deflateParams(). > > This is an issue for the upstream zlib project, we probably don't want to change it here. Agree. See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:40 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 09:55:18 GMT, Lance Andersen wrote: >> src/java.base/share/native/libzip/zlib/zlib.h line 756: >> >>> 754: If this is done, the old level and strategy will be applied to the data >>> 755: compressed before deflateParams(), and the new level and strategy will be >>> 756: applied to the data compressed after deflateParams(). >> >> This is an issue for the upstream zlib project, we probably don't want to change it here. > > Agree. See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos. OK. I backed out the change to zlib. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Sun Sep 25 17:23:28 2022 From: duke at openjdk.org (SWinxy) Date: Sun, 25 Sep 2022 17:23:28 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni I'm not a committer (yet) so I can't [sponsor](https://openjdk.org/sponsor/) this PR, even though I would. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From rehn at openjdk.org Mon Sep 26 07:06:00 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 26 Sep 2022 07:06:00 GMT Subject: RFR: 8294293: Remove unused _width and _newlines field in outputStream In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 15:59:39 GMT, Johan Sj?len wrote: > 1. `_width` is unused so I deleted it > 2. `_newlines` was used in one place, and only to check if any new lines had been seen. I removed `_newlines` and instead used `update_position`'s unused return value to indicate whether any newlines has been seen. This required expanding the call of `xmlTextStream::write` in `defaultStream`. > > This removes some cruft from `outputStream` and saves us 8 bytes on the size of `outputStream`. > > I also noted that `_position` isn't number of chars into a line, but rather a "visual position". It's a bit surprising, which is why I added this comment. This can be seen in the `\t` case in `update_position`. Looks good, thanks! src/hotspot/share/utilities/ostream.hpp line 91: > 89: int position() const { return _position; } > 90: julong count() const { return _precount + _position; } > 91: void set_count(julong count) { _precount = count - _position; } These julong should probably be uint64_t. But it may cause some more changes, e.g. _file_end in CompileLog should then also probably also be uint64_t. We can look at that in another RFE. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10411 From dholmes at openjdk.org Mon Sep 26 07:15:25 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Sep 2022 07:15:25 GMT Subject: RFR: JDK-8293346: Add NoThreadCurrentMark to simulate non-attached threads [v2] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 17:08:02 GMT, Thomas Stuefe wrote: >> When working on [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344), I needed a way to verify that I had removed all offending usages of ResourceArea memory inside an extend. >> >> For that, a NoThreadCurrentMark was useful. It temporarily sets the current Thread* to NULL for the extend. Any use of Thread::current below that mark will now crash or assert. >> >> This can be used for two things: >> - guard code that is supposed to be safe for non-attached threads (os::malloc, stack printing, UL etc) against accidental usage of Thread::current() (e.g. resource area allocation) >> - in gtests, simulate a non-attached thread to cover code that behaves differently with Thread::current()==NULL. >> >> This patch: >> >> - Introduces the debug-only `NoThreadCurrentMark` >> - Adds a gtest for it >> - Adds it to guard dwarf-parsing-based stack printing, which had not been safe due to use of ResourceArea, fixed with [JDK-8293344](https://bugs.openjdk.org/browse/JDK-8293344) >> - Adds it to `os::malloc()`, `os::realloc()` and `os::free()`, since those can certainly be called without a current thread. >> - Replaces the test-local mark in the SafeFetch gtests that did a similar thing >> - I may add and fix up other users later >> >> I also had to change Library-based TLS initialization such that it runs at C++ dynamic initialization time. That is because the `NoThreadCurrentMark` needs to set both Library-based TLS and C++ TLS slots, and having library-based TLS not available before VM initialization made the code too complex. This also means we can remove the explicit TLS initialization from create_vm. >> >> Finally, while I was here, I also fixed the error printing in library based TLS (since the pthread_key_xxx functions don't modify errno). > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - New solution > - Revert changes to TLS initialization This version of the code seems fine in terms of basic functionality. I'm less convinced about the actual usefulness of this, but as it is debug only code ... My main query here is why some of this code should ever be being executed by non-attached threads? Conditional pre-VM-init usage? (If it unconditional then we don't need to simulate anything as we will have a NULL current thread.) src/hotspot/share/runtime/thread.hpp line 668: > 666: if (t != nullptr && t->_thread_current_disabled) { > 667: t = nullptr; > 668: } This needs to be in `ifdef ASSERT` src/hotspot/share/runtime/thread.hpp line 679: > 677: if (t != nullptr && t->_thread_current_disabled) { > 678: t = nullptr; > 679: } This needs to be in `ifdef ASSERT` src/hotspot/share/runtime/thread.inline.hpp line 96: > 94: > 95: #ifdef ASSERT > 96: // Mark disables Thread::current by setting it to NULL for the extend. Can be s/extend/extent/ src/hotspot/share/runtime/thread.inline.hpp line 98: > 96: // Mark disables Thread::current by setting it to NULL for the extend. Can be > 97: // used to simulate running code in non-attached threads, or to guard code > 98: // against accidental usage of features that depend on Thread::current() (e.g. So the "guard" aspect of this is that we expect to crash if the code tries to use the result of `Thread::current()`? ------------- PR: https://git.openjdk.org/jdk/pull/10178 From dholmes at openjdk.org Mon Sep 26 07:19:27 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Sep 2022 07:19:27 GMT Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications [v4] In-Reply-To: <7uEEjcCVoEfGK2L99QCHvzy9OWzl2I-4P_AelvyhvTc=.04adb658-216b-4811-a7a8-173a6786a44b@github.com> References: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com> <7uEEjcCVoEfGK2L99QCHvzy9OWzl2I-4P_AelvyhvTc=.04adb658-216b-4811-a7a8-173a6786a44b@github.com> Message-ID: On Fri, 23 Sep 2022 12:41:05 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix JniVersion test > > This seems good. I looked at the specification changes and they looked okay also. Thanks @coleenp ! ------------- PR: https://git.openjdk.org/jdk/pull/10352 From stefank at openjdk.org Mon Sep 26 07:21:36 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 26 Sep 2022 07:21:36 GMT Subject: RFR: JDK-8293711: Factor out size parsing functions from arguments.cpp [v2] In-Reply-To: <2txQ-RFzFybqprusuQbnZWexNi9GNV0cZ4Y1FC4PM4I=.2922afc3-6bad-493e-8342-8e2872d760ea@github.com> References: <3AIWW1prhISoIn6Bnw6f_JkcSQqBJeMQMwisfOnI8vU=.ff7dae90-7da6-471e-9fdf-49ac3f6429ee@github.com> <7JN3D-ftzKvAvCRgNACnwQMEAPIOk7NnJl_BWbdnGB0=.00393e3c-6613-4605-b1a9-279d0c09ca6e@github.com> <2txQ-RFzFybqprusuQbnZWexNi9GNV0cZ4Y1FC4PM4I=.2922afc3-6bad-493e-8342-8e2872d760ea@github.com> Message-ID: On Fri, 23 Sep 2022 14:10:10 GMT, Thomas Stuefe wrote: > > > > is the new version acceptable? > > > > > > > > > I would have preferred if the parsing code were not placed in a .hpp file, and would have placed it in a .inline.hpp file, to comply with our guidelines. Other than that, I'm OK with this patch. > > > > > > Almost missed your comment :-) > > I'll split it up as you suggested, then push. > > Wait, since the whole thing is all parsing, would that not mean we have just a parseInteger.inline.hpp, without a parseInteger.hpp? Since I'm unsure what would be left to put into parseInteger.hpp. And a parseInteger.inline.hpp without a parseInteger.hpp makes not much sense, or? > > We have some other one-trick-pony-headers that are not .inline and contain their whole functionality: powerOfTwo.hpp, population_count.hpp (probably should rename that), pair.hpp... Right. There's a pragmatic side to the rules w.r.t .hpp vs .inline.hpp files. If the file doesn't have dependencies to "non-trivial" header files, then we typically let it slide and put the code in the .hpp, as you have seen in the files you list. Another notable example is atomic.inline.hpp, which was renamed to atomic.hpp. I think we did that, since were too many header files that used Atomic, and it would have been a lot of work to clean that up. The questions for me now are: 1) Is this header small enough that it doesn't pull in large amounts of other headers? 2) Is it likely to be changed in the future to include "non-trivial" headers? 3) Is it likely to be used in other .hpp files? I think this it is small enough (1), will only be used in .cpp/.inline.hpp files (3), but I'm unsure about (2). I'll leave it to your judgement to decide if this is fine to leave in the .hpp file. ------------- PR: https://git.openjdk.org/jdk/pull/10252 From dholmes at openjdk.org Mon Sep 26 07:21:37 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Sep 2022 07:21:37 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 11:10:19 GMT, Alan Bateman wrote: >> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). >> >> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. >> >> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). >> >> Testing: tiers 1-3 > > (JDK-8289610 is integrated now so once you sync up it should remove the changes from the dependent PR and reduce the list of changed files. You should be able to trim down the labels too.) > > I did a pass over the src/hotspot change and didn't spot any issues. It's good that stillborn can go away. The removal of the special-casing of ThreadDeath is consistent with the libs side of the change, including the change to ExceptionDescribe. Thanks @AlanBateman ! ------------- PR: https://git.openjdk.org/jdk/pull/10400 From dholmes at openjdk.org Mon Sep 26 08:14:45 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Sep 2022 08:14:45 GMT Subject: RFR: 8294293: Remove unused _width and _newlines field in outputStream In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 15:59:39 GMT, Johan Sj?len wrote: > 1. `_width` is unused so I deleted it > 2. `_newlines` was used in one place, and only to check if any new lines had been seen. I removed `_newlines` and instead used `update_position`'s unused return value to indicate whether any newlines has been seen. This required expanding the call of `xmlTextStream::write` in `defaultStream`. > > This removes some cruft from `outputStream` and saves us 8 bytes on the size of `outputStream`. > > I also noted that `_position` isn't number of chars into a line, but rather a "visual position". It's a bit surprising, which is why I added this comment. This can be seen in the `\t` case in `update_position`. Generally seems okay but a couple of queries. Thanks. src/hotspot/share/utilities/ostream.cpp line 904: > 902: if (has_log_file()) { > 903: int nl0 = _newlines; > 904: xmlTextStream::write(s, len); xmlTextStream::write seems to be unused after this change. src/hotspot/share/utilities/ostream.hpp line 32: > 30: #include "utilities/globalDefinitions.hpp" > 31: #include "utilities/macros.hpp" > 32: #include This std header doesn't seem to be used anywhere else in hotspot code - why do we need it here? ------------- PR: https://git.openjdk.org/jdk/pull/10411 From jsjolen at openjdk.org Mon Sep 26 08:44:44 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 26 Sep 2022 08:44:44 GMT Subject: RFR: 8294293: Remove unused _width and _newlines field in outputStream [v2] In-Reply-To: References: Message-ID: > 1. `_width` is unused so I deleted it > 2. `_newlines` was used in one place, and only to check if any new lines had been seen. I removed `_newlines` and instead used `update_position`'s unused return value to indicate whether any newlines has been seen. This required expanding the call of `xmlTextStream::write` in `defaultStream`. > > This removes some cruft from `outputStream` and saves us 8 bytes on the size of `outputStream`. > > I also noted that `_position` isn't number of chars into a line, but rather a "visual position". It's a bit surprising, which is why I added this comment. This can be seen in the `\t` case in `update_position`. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Remove include ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10411/files - new: https://git.openjdk.org/jdk/pull/10411/files/18847c61..11977a50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10411&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10411&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10411.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10411/head:pull/10411 PR: https://git.openjdk.org/jdk/pull/10411 From jsjolen at openjdk.org Mon Sep 26 08:44:45 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 26 Sep 2022 08:44:45 GMT Subject: RFR: 8294293: Remove unused _width and _newlines field in outputStream [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 08:11:53 GMT, David Holmes wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove include > > src/hotspot/share/utilities/ostream.cpp line 904: > >> 902: if (has_log_file()) { >> 903: int nl0 = _newlines; >> 904: xmlTextStream::write(s, len); > > xmlTextStream::write seems to be unused after this change. It does seem that way. The `outputStream::write` method is the function which all subclasses of `outputStream` implements, so we shouldn't remove this function without removing `xmlTextStream`. That's probably a separate RFE, and perhaps not desirable as it'd require merging the class into `defaultStream`. > src/hotspot/share/utilities/ostream.hpp line 32: > >> 30: #include "utilities/globalDefinitions.hpp" >> 31: #include "utilities/macros.hpp" >> 32: #include > > This std header doesn't seem to be used anywhere else in hotspot code - why do we need it here? Good catch, it's been removed. ------------- PR: https://git.openjdk.org/jdk/pull/10411 From kbarrett at openjdk.org Mon Sep 26 10:15:23 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 26 Sep 2022 10:15:23 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v2] In-Reply-To: References: Message-ID: On Sat, 24 Sep 2022 09:47:38 GMT, Johan Sj?len wrote: >> src/hotspot/share/memory/allocation.hpp line 219: >> >>> 217: }; >>> 218: >>> 219: class DynCHeapObj { >> >> I tried this and it seems to work: If you make CHeapObj new operators take MEMFLAGS f = F, where F is the default value, you could not have this class and make outputStream inherit from CHeapObj and the new calls will override mtInternal. I guess the risk is that you get mtInternal if you forget the parameter to new. > > Good idea! I implemented this instead. We can eliminate this problem: "I guess the risk is that you get mtInternal if you forget the parameter to new." We can instead have CHeapObj that *only* allocates with mtFoo, and CHeapObj<> that *requires* specifying the flag when allocating the memory. (I did something like this for the CHeapAllocator in my prototype for Standard Library usage.) As part of that, we can also have the MEMFLAGS argument (when needed) always be the first argument in the placement list. Very(!) lightly tested: https://github.com/kimbarrett/openjdk-jdk/tree/dynamic-memflags ------------- PR: https://git.openjdk.org/jdk/pull/10412 From dholmes at openjdk.org Mon Sep 26 10:32:40 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Sep 2022 10:32:40 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v3] In-Reply-To: References: Message-ID: <5FVc4-m-MyON0EHxtzwvuBFlwypdnhukQPk8lzYaA9Y=.85232874-19eb-4c1b-be85-9c6f37f7a20e@github.com> On Sat, 24 Sep 2022 06:50:45 GMT, Alan Bateman wrote: >> Degrade Thread.suspend/resume to throw UOE unconditionally. >> >> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. >> >> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. >> >> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Remove tests from exclude list > - Merge > - Update DegradedMethodsThrowUOE to test Thread.stop > - Merge > - Update modifyThread and modifyThreadGroup targets > - Merge > - Fix typo in test comment > - Keep link to threadPrimitiveDeprecation.html > - Merge > - Tests > - ... and 1 more: https://git.openjdk.org/jdk/compare/543851db...6aa38889 Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10324 From shade at openjdk.org Mon Sep 26 10:53:23 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 Sep 2022 10:53:23 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v2] In-Reply-To: References: Message-ID: <8RYDHApihXiKZLPVjmoMBRR5sTE9cgrGWLGaHu7SNp0=.0467e114-94bf-4b63-b26c-9658878f1490@github.com> On Fri, 23 Sep 2022 21:49:55 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. >> >> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. >> >> Some warnings didn't trigger in any file anymore, and could just be removed. >> >> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. >> >> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. >> >> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. >> >> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). >> >> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - ppc64 triggers shift-negative-value on gcc :-( > - s390 triggers shift-negative-value on gcc :-( > (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) I see the failure due to `-Werror=misleading-indentation`: ------------- PR: https://git.openjdk.org/jdk/pull/10414 From ayang at openjdk.org Mon Sep 26 11:59:25 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 26 Sep 2022 11:59:25 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 06:39:33 GMT, Kim Barrett wrote: >> 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal >> 8155996: Improve concurrent refinement green zone control >> 8134303: Introduce -XX:-G1UseConcRefinement >> >> Please review this change to the control of concurrent refinement. >> >> This new controller takes a different approach to the problem, addressing a >> number of issues. >> >> The old controller used a multiple of the target number of cards to determine >> the range over which increasing numbers of refinement threads should be >> activated, and finally activating mutator refinement. This has a variety of >> problems. It doesn't account for the processing rate, the rate of new dirty >> cards, or the time available to perform the processing. This often leads to >> unnecessary spikes in the number of running refinement threads. It also tends >> to drive the pending number to the target quickly and keep it there, removing >> the benefit from having pending dirty cards filter out new cards for nearby >> writes. It can't delay and leave excess cards in the queue because it could >> be a long time before another buffer is enqueued. >> >> The old controller was triggered by mutator threads enqueing card buffers, >> when the number of cards in the queue exceeded a threshold near the target. >> This required a complex activation protocol between the mutators and the >> refinement threads. >> >> With the new controller there is a primary refinement thread that periodically >> estimates how many refinement threads need to be running to reach the target >> in time for the next GC, along with whether to also activate mutator >> refinement. If the primary thread stops running because it isn't currently >> needed, it sleeps for a period and reevaluates on wakeup. This eliminates any >> involvement in the activation of refinement threads by mutator threads. >> >> The estimate of how many refinement threads are needed uses a prediction of >> time until the next GC, the number of buffered cards, the predicted rate of >> new dirty cards, and the predicted refinement rate. The number of running >> threads is adjusted based on these periodically performed estimates. >> >> This new approach allows more dirty cards to be left in the queue until late >> in the mutator phase, typically reducing the rate of new dirty cards, which >> reduces the amount of concurrent refinement work needed. >> >> It also smooths out the number of running refinement threads, eliminating the >> unnecessarily large spikes that are common with the old method. One benefit >> is that the number of refinement threads (lazily) allocated is often much >> lower now. (This plus UseDynamicNumberOfGCThreads mitigates the problem >> described in JDK-8153225.) >> >> This change also provides a new method for calculating for the number of dirty >> cards that should be pending at the start of a GC. While this calculation is >> conceptually distinct from the thread control, the two were significanly >> intertwined in the old controller. Changing this calculation separately and >> first would have changed the behavior of the old controller in ways that might >> have introduced regressions. Changing it after the thread control was changed >> would have made it more difficult to test and measure the thread control in a >> desirable configuration. >> >> The old calculation had various problems that are described in JDK-8155996. >> In particular, it can get more or less stuck at low values, and is slow to >> respond to changes. >> >> The old controller provided a number of product options, none of which were >> very useful for real applications, and none of which are very applicable to >> the new controller. All of these are being obsoleted. >> >> -XX:-G1UseAdaptiveConcRefinement >> -XX:G1ConcRefinementGreenZone= >> -XX:G1ConcRefinementYellowZone= >> -XX:G1ConcRefinementRedZone= >> -XX:G1ConcRefinementThresholdStep= >> >> The new controller *could* use G1ConcRefinementGreenZone to provide a fixed >> value for the target number of cards, though it is poorly named for that. >> >> A configuration that was useful for some kinds of debugging and testing was to >> disable G1UseAdaptiveConcRefinement and set g1ConcRefinementGreenZone to a >> very large value, effectively disabling concurrent refinement. To support >> this use case with the new controller, the -XX:-G1UseConcRefinement diagnostic >> option has been added (see JDK-8155996). >> >> The other options are meaningless for the new controller. >> >> Because of these option changes, a CSR and a release note need to accompany >> this change. >> >> Testing: >> mach5 tier1-6 >> various performance tests. >> local (linux-x64) tier1 with -XX:-G1UseConcRefinement >> >> Performance testing found no regressions, but also little or no improvement >> with default options, which was expected. With default options most of our >> performance tests do very little concurrent refinement. And even for those >> that do, while the old controller had a number of problems, the impact of >> those problems is small and hard to measure for most applications. >> >> When reducing G1RSetUpdatingPauseTimePercent the new controller seems to fare >> better, particularly when also reducing MaxGCPauseMillis. specjbb2015 with >> MaxGCPauseMillis=75 and G1RSetUpdatingPauseTimePercent=3 (and other options >> held constant) showed a statistically significant improvement of about 4.5% >> for critical-jOPS. Using the changed controller, the difference between this >> configuration and the default is fairly small, while the baseline shows >> significant degradation with the more restrictive options. >> >> For all tests and configurations the new controller often creates many fewer >> refinement threads. > > Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: > > - wanted vs needed nomenclature > - remove several spurious "scan" > - delay => wait_time_ms src/hotspot/share/gc/g1/g1Analytics.cpp line 251: > 249: double G1Analytics::predict_dirtied_cards_in_thread_buffers() const { > 250: return predict_zero_bounded(_dirtied_cards_in_thread_buffers_seq); > 251: } I believe this sequence captures #dirty cards in thread buffers at GC pause start. However, I don't think it follows a normal distribution because of the buffer-size clamping. In comparison, the dirty-cards-generation-rate (`predict_dirtied_cards_rate_ms`) more likely follows a normal distribution. src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 97: > 95: } > 96: > 97: if (UseDynamicNumberOfGCThreads) { I actually think failing-early is more desirable if the requested number of threads can't be satisfied. Semi-related, when `UseDynamicNumberOfGCThreads == true`, thread-allocation-failure has diff consequence depending whether it's in start-up or not -- such discrepancy incurs some complexity in the code. src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 203: > 201: } > 202: > 203: void G1ConcurrentRefine::update_pending_cards_target(double logged_cards_time_ms, Since this method doesn't always do the update, maybe prefix the name with `try_`. src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 339: > 337: } > 338: Atomic::store(&_threads_wanted, new_wanted); > 339: _dcqs.set_max_cards(mutator_threshold); Preexisting: `set_mutator_threshold` is probably more precise. src/hotspot/share/gc/g1/g1ConcurrentRefineThreadsNeeded.cpp line 66: > 64: double alloc_bytes_rate = alloc_region_rate * HeapRegion::GrainBytes; > 65: if (alloc_bytes_rate == 0.0) { > 66: _predicted_time_until_next_gc_ms = 0.0; I don't get why time-till-next-gc is zero when the alloc rate is at its minimal -- by continuity, I'd expect this to be the max of time-till-next-gc, i.e. `one_hour_ms`. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From ayang at openjdk.org Mon Sep 26 11:59:28 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 26 Sep 2022 11:59:28 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v2] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 07:01:30 GMT, Kim Barrett wrote: >> 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal >> 8155996: Improve concurrent refinement green zone control >> 8134303: Introduce -XX:-G1UseConcRefinement >> >> Please review this change to the control of concurrent refinement. >> >> This new controller takes a different approach to the problem, addressing a >> number of issues. >> >> The old controller used a multiple of the target number of cards to determine >> the range over which increasing numbers of refinement threads should be >> activated, and finally activating mutator refinement. This has a variety of >> problems. It doesn't account for the processing rate, the rate of new dirty >> cards, or the time available to perform the processing. This often leads to >> unnecessary spikes in the number of running refinement threads. It also tends >> to drive the pending number to the target quickly and keep it there, removing >> the benefit from having pending dirty cards filter out new cards for nearby >> writes. It can't delay and leave excess cards in the queue because it could >> be a long time before another buffer is enqueued. >> >> The old controller was triggered by mutator threads enqueing card buffers, >> when the number of cards in the queue exceeded a threshold near the target. >> This required a complex activation protocol between the mutators and the >> refinement threads. >> >> With the new controller there is a primary refinement thread that periodically >> estimates how many refinement threads need to be running to reach the target >> in time for the next GC, along with whether to also activate mutator >> refinement. If the primary thread stops running because it isn't currently >> needed, it sleeps for a period and reevaluates on wakeup. This eliminates any >> involvement in the activation of refinement threads by mutator threads. >> >> The estimate of how many refinement threads are needed uses a prediction of >> time until the next GC, the number of buffered cards, the predicted rate of >> new dirty cards, and the predicted refinement rate. The number of running >> threads is adjusted based on these periodically performed estimates. >> >> This new approach allows more dirty cards to be left in the queue until late >> in the mutator phase, typically reducing the rate of new dirty cards, which >> reduces the amount of concurrent refinement work needed. >> >> It also smooths out the number of running refinement threads, eliminating the >> unnecessarily large spikes that are common with the old method. One benefit >> is that the number of refinement threads (lazily) allocated is often much >> lower now. (This plus UseDynamicNumberOfGCThreads mitigates the problem >> described in JDK-8153225.) >> >> This change also provides a new method for calculating for the number of dirty >> cards that should be pending at the start of a GC. While this calculation is >> conceptually distinct from the thread control, the two were significanly >> intertwined in the old controller. Changing this calculation separately and >> first would have changed the behavior of the old controller in ways that might >> have introduced regressions. Changing it after the thread control was changed >> would have made it more difficult to test and measure the thread control in a >> desirable configuration. >> >> The old calculation had various problems that are described in JDK-8155996. >> In particular, it can get more or less stuck at low values, and is slow to >> respond to changes. >> >> The old controller provided a number of product options, none of which were >> very useful for real applications, and none of which are very applicable to >> the new controller. All of these are being obsoleted. >> >> -XX:-G1UseAdaptiveConcRefinement >> -XX:G1ConcRefinementGreenZone= >> -XX:G1ConcRefinementYellowZone= >> -XX:G1ConcRefinementRedZone= >> -XX:G1ConcRefinementThresholdStep= >> >> The new controller *could* use G1ConcRefinementGreenZone to provide a fixed >> value for the target number of cards, though it is poorly named for that. >> >> A configuration that was useful for some kinds of debugging and testing was to >> disable G1UseAdaptiveConcRefinement and set g1ConcRefinementGreenZone to a >> very large value, effectively disabling concurrent refinement. To support >> this use case with the new controller, the -XX:-G1UseConcRefinement diagnostic >> option has been added (see JDK-8155996). >> >> The other options are meaningless for the new controller. >> >> Because of these option changes, a CSR and a release note need to accompany >> this change. >> >> Testing: >> mach5 tier1-6 >> various performance tests. >> local (linux-x64) tier1 with -XX:-G1UseConcRefinement >> >> Performance testing found no regressions, but also little or no improvement >> with default options, which was expected. With default options most of our >> performance tests do very little concurrent refinement. And even for those >> that do, while the old controller had a number of problems, the impact of >> those problems is small and hard to measure for most applications. >> >> When reducing G1RSetUpdatingPauseTimePercent the new controller seems to fare >> better, particularly when also reducing MaxGCPauseMillis. specjbb2015 with >> MaxGCPauseMillis=75 and G1RSetUpdatingPauseTimePercent=3 (and other options >> held constant) showed a statistically significant improvement of about 4.5% >> for critical-jOPS. Using the changed controller, the difference between this >> configuration and the default is fairly small, while the baseline shows >> significant degradation with the more restrictive options. >> >> For all tests and configurations the new controller often creates many fewer >> refinement threads. > > Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: > > - lengthen some names > - improve comments for primary do_refinement_step > - add is_pending_cards_target_initialized src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 238: > 236: predicted_thread_buffer_cards, > 237: goal_ms); > 238: if (_thread_control.max_num_threads() == 0) { I'd expect it to be non-zero if `G1UseConcRefinement == true`. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From kbarrett at openjdk.org Mon Sep 26 12:26:19 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 26 Sep 2022 12:26:19 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v2] In-Reply-To: References: Message-ID: <3aDPaUY5E8ZRgOiQDWU5j9wr73IUbzMQbdLeRTvb2ac=.87581200-f5c3-472e-847c-8cb46eba1d0c@github.com> On Thu, 22 Sep 2022 13:28:40 GMT, Albert Mingkun Yang wrote: >> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: >> >> - lengthen some names >> - improve comments for primary do_refinement_step >> - add is_pending_cards_target_initialized > > src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 238: > >> 236: predicted_thread_buffer_cards, >> 237: goal_ms); >> 238: if (_thread_control.max_num_threads() == 0) { > > I'd expect it to be non-zero if `G1UseConcRefinement == true`. One can set -XX:G1ConcRefinementThreads=0, and just let the mutator threads do refinement. There's a known problem that mutator threads won't "catch up" if there is more refinement work to be done than the refinement threads can manage, which of course is the case if there aren't any refinement threads. https://bugs.openjdk.org/browse/JDK-8293616 ------------- PR: https://git.openjdk.org/jdk/pull/10256 From kbarrett at openjdk.org Mon Sep 26 12:45:24 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 26 Sep 2022 12:45:24 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Sat, 24 Sep 2022 13:50:47 GMT, Albert Mingkun Yang wrote: >> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: >> >> - wanted vs needed nomenclature >> - remove several spurious "scan" >> - delay => wait_time_ms > > src/hotspot/share/gc/g1/g1ConcurrentRefineThreadsNeeded.cpp line 66: > >> 64: double alloc_bytes_rate = alloc_region_rate * HeapRegion::GrainBytes; >> 65: if (alloc_bytes_rate == 0.0) { >> 66: _predicted_time_until_next_gc_ms = 0.0; > > I don't get why time-till-next-gc is zero when the alloc rate is at its minimal -- by continuity, I'd expect this to be the max of time-till-next-gc, i.e. `one_hour_ms`. A zero value for the prediction indicates that we don't have a valid prediction, because we're starting up the VM and don't have data yet. That puts us in a place where we can't really do much with the predictive model. Later clauses (no refinement needed, or time is short) also "handle" this case, though maybe there should be some commentary about that. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From kbarrett at openjdk.org Mon Sep 26 12:54:24 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 26 Sep 2022 12:54:24 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: <5GTCzh8QtA9ofXnu_6FedPBMGoG4yZWX40LoXQ1FD_s=.861803ed-7b13-4749-8367-eb809da3f066@github.com> On Sat, 24 Sep 2022 14:24:54 GMT, Albert Mingkun Yang wrote: >> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: >> >> - wanted vs needed nomenclature >> - remove several spurious "scan" >> - delay => wait_time_ms > > src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 97: > >> 95: } >> 96: >> 97: if (UseDynamicNumberOfGCThreads) { > > I actually think failing-early is more desirable if the requested number of threads can't be satisfied. Semi-related, when `UseDynamicNumberOfGCThreads == true`, thread-allocation-failure has diff consequence depending whether it's in start-up or not -- such discrepancy incurs some complexity in the code. Sorry, I don't think I'm understanding the first part of the comment. We can't know at startup whether we can allocate the threads if we don't allocate them at startup. And we don't want to allocate them unless/until we need them. The difference in behavior for startup vs later for thread allocation failure is intentional, and not new to this change. That was discussed back when support for lazy thread creation was added. If not being lazy, then hard fail if allocation fails. If being lazy, report but try to continue without the additional thread(s). ------------- PR: https://git.openjdk.org/jdk/pull/10256 From kbarrett at openjdk.org Mon Sep 26 13:04:30 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 26 Sep 2022 13:04:30 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Sat, 24 Sep 2022 14:44:29 GMT, Albert Mingkun Yang wrote: >> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: >> >> - wanted vs needed nomenclature >> - remove several spurious "scan" >> - delay => wait_time_ms > > src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 203: > >> 201: } >> 202: >> 203: void G1ConcurrentRefine::update_pending_cards_target(double logged_cards_time_ms, > > Since this method doesn't always do the update, maybe prefix the name with `try_`. That it might leave the value unchanged when the data isn't good is an implementation detail, not part of the API. A common case where this arises is during application startup, when there might not be much or any GC refinement to do (little or no oldgen). The caller should just always treat it as doing an update, and not do something different depending on a try_ result. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From dzhang at openjdk.org Mon Sep 26 13:10:19 2022 From: dzhang at openjdk.org (Dingli Zhang) Date: Mon, 26 Sep 2022 13:10:19 GMT Subject: RFR: 8293770: RISC-V: Reuse runtime call trampolines [v2] In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 02:42:53 GMT, Dingli Zhang wrote: >> Follow up [JDK-8280152](https://bugs.openjdk.org/browse/JDK-8280152), this case also exists in riscv. >> >> Benchmark als, chi-square, dec-tree, log-regression, naive-bayes, page-rank, fj-kmeans, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~2.1% reduction on average. >> >> ## Testing: >> >> - hotspot and jdk tier1 on unmatched board without new failures >> - hotspot/jtreg/compiler/sharedstubs/SharedTrampolineTest.java with fastdebug on qemu >> >> >> ## Results >> #### Results from [Renaissance 0.14.1](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.1) >> >> - riscv64 >> >> +--------------------------------------------------------------------------------------------------------+ >> | | Before | After | >> | Benchmark |---------------------------------------------------------------------------------------| >> | | non-profiled nmethods | profiled nmethods | non-profiled nmethods | profiled nmethods | >> +----------------+-----------------------+-------------------+-----------------------+-------------------| >> | als | 15628 | 39421 | 12341 | 26681 | >> | chi-square | 6349 | 20268 | 6033 | 20252 | >> | dec-tree | 11058 | 42443 | 10774 | 43880 | >> | log-regression | 10939 | 38237 | 12071 | 44199 | >> | naive-bayes | 9023 | 29563 | 9294 | 30948 | >> | page-rank | 6054 | 17041 | 5812 | 17353 | >> | fj-kmeans | 692 | 2893 | 651 | 3354 | >> | reactors | 2126 | 4073 | 1876 | 4106 | >> | future-genetic | 1306 | 4118 | 1226 | 4142 | >> | mnemonics | 726 | 2659 | 706 | 2684 | >> | dotty | 26059 | 24417 | 24585 | 25379 | >> | scala-kmeans | 564 | 3122 | 543 | 3132 | >> | finagle-http | 6188 | 12455 | 6102 | 12295 | >> | sum | 96712 | 240710 | 92014 | 238405 | >> +--------------------------------------------------------------------------------------------------------+ > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Simplify targe related jal call in macroAssembler_riscv.cpp > I have the same concern here as [1]. Did you looked into it? > > [1] https://github.com/openjdk/jdk/pull/9405#pullrequestreview-1076140575 Hi @RealFYang Thank you for the comments! Each `CodeBuffer` has its own independent `_shared_trampoline_requests`, which is a field of the `CodeBuffer`. The initialization process of `_shared_trampoline_requests` associated with the codebuffer can be seen in `src/ hotspot/share/opto/output.cpp: PhaseOutput::Output()` and each compiled task/thread have its own `CodeBuffer` to store the machine code, so multiple compiler threads will not share the buffer simultaneously. ------------- PR: https://git.openjdk.org/jdk/pull/10260 From kbarrett at openjdk.org Mon Sep 26 13:23:27 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 26 Sep 2022 13:23:27 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Sun, 25 Sep 2022 12:43:43 GMT, Albert Mingkun Yang wrote: >> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: >> >> - wanted vs needed nomenclature >> - remove several spurious "scan" >> - delay => wait_time_ms > > src/hotspot/share/gc/g1/g1Analytics.cpp line 251: > >> 249: double G1Analytics::predict_dirtied_cards_in_thread_buffers() const { >> 250: return predict_zero_bounded(_dirtied_cards_in_thread_buffers_seq); >> 251: } > > I believe this sequence captures #dirty cards in thread buffers at GC pause start. However, I don't think it follows a normal distribution because of the buffer-size clamping. In comparison, the dirty-cards-generation-rate (`predict_dirtied_cards_rate_ms`) more likely follows a normal distribution. The number of dirty cards in thread buffers at the start of GC pause is exactly what this is supposed to capture. We discount the number of cards that can be processed in the budgeted time by this prediction to get the target number of cards in the queue. It's not a very accurate prediction, but it's still worth doing. For some applications and configurations I've tested (with low G1RSetUpdatingPauseTimePercent) it might be 5-10% of the target. A model based on the number of threads tends to do very poorly for some applications. This is entirely different from predict_dirtied_cards_rate_ms, which is a different value and has different uses. > src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 339: > >> 337: } >> 338: Atomic::store(&_threads_wanted, new_wanted); >> 339: _dcqs.set_max_cards(mutator_threshold); > > Preexisting: `set_mutator_threshold` is probably more precise. Agreed. s/max_cards/mutator_refinement_threshold/, and tweaked a few comments. Will be in the next push. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From fyang at openjdk.org Mon Sep 26 14:25:21 2022 From: fyang at openjdk.org (Fei Yang) Date: Mon, 26 Sep 2022 14:25:21 GMT Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov wrote: > Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR. > > benchmark results: > > before: > > Benchmark Mode Cnt Score Error Units > DoubleClassCheck.testIsFiniteBranch avgt 15 52.824 ? 1.744 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 16.104 ? 0.358 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 14.366 ? 2.174 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 49.821 ? 0.330 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 14.702 ? 0.335 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 14.749 ? 0.496 ns/op > > after: > > DoubleClassCheck.testIsFiniteBranch avgt 15 48.921 ? 0.557 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 13.716 ? 0.304 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 9.152 ? 0.158 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 47.740 ? 2.028 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 13.299 ? 0.282 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 9.185 ? 0.396 ns/op > > Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way. > > Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues. I find the cause of the fluctuations for 'testIsFiniteBranch' lies in randomness of the input. @Benchmark @OperationsPerInvocation(BUFFER_SIZE) public void testIsFiniteBranch() { for (int i = 0; i < BUFFER_SIZE; i++) { cmovOutputs[i] = Float.isFinite(inputs[i]) ? call() : 7; } } Here the C2 JIT code for invoking 'call()' has changed with this patch. The register allocation is different and hence the difference of saving and restoring of live registers around the method call. So the probability of invoking this method call will affect the JMH result, which is not the case for the other two JMH tests. For the other two JMH tests, I see the performance gain on SiFive platform comes from C2 loop unrolling. Since your change benefit the other two JMH tests on both SiFive and C906 platforms, looks good to me. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10391 From coleenp at openjdk.org Mon Sep 26 15:38:20 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 26 Sep 2022 15:38:20 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 10:13:18 GMT, Kim Barrett wrote: >> Good idea! I implemented this instead. > > We can eliminate this problem: > "I guess the risk is that you get mtInternal if you forget the parameter to new." > > We can instead have CHeapObj that *only* allocates with mtFoo, and > CHeapObj<> that *requires* specifying the flag when allocating the memory. (I > did something like this for the CHeapAllocator in my prototype for Standard > Library usage.) As part of that, we can also have the MEMFLAGS argument (when > needed) always be the first argument in the placement list. > > Very(!) lightly tested: > https://github.com/kimbarrett/openjdk-jdk/tree/dynamic-memflags Or you could have the class that requires dynamic mtFlag be declared with mtNone and assert in one place in AllocateHeap that mt != mtNone. Actually that assert might already be there. Can't really puzzle out what Kim's change does. ------------- PR: https://git.openjdk.org/jdk/pull/10412 From jwaters at openjdk.org Mon Sep 26 15:38:52 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 26 Sep 2022 15:38:52 GMT Subject: RFR: 8292016: Split Windows API error handling from errors passed through the runtime in the JDK [v21] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: Split Windows API error handling from errors passed through the runtime ------------- Changes: https://git.openjdk.org/jdk/pull/9870/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=20 Stats: 160 lines in 14 files changed: 67 ins; 33 del; 60 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From ihse at openjdk.org Mon Sep 26 15:39:28 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 Sep 2022 15:39:28 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v3] In-Reply-To: References: Message-ID: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Trigger GHA to compile with all warnings before aborting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/ac15b0b1..031acab5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From jwaters at openjdk.org Mon Sep 26 15:47:51 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 26 Sep 2022 15:47:51 GMT Subject: RFR: 8292016: Split Windows API error handling from errors passed through the runtime in the JDK [v22] In-Reply-To: References: Message-ID: > Second attempt at resolving [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less intrusive approach this time > > Side note: While it might be preferred to remove this entirely, other areas of the JDK also use the same flawed logic, and removing this would simply push the issue elsewhere. Fixing this might result in a solution which can be used in those areas in the future. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/43744e90..622af5c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=20-21 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From joehw at openjdk.org Mon Sep 26 16:16:34 2022 From: joehw at openjdk.org (Joe Wang) Date: Mon, 26 Sep 2022 16:16:34 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni We have discussed several times in the past that we don't touch upstream (in this case, Apache) code unless the change is essential. In general, if you fix a bug in a class, it's fine to fix other non-essential things within the class, such as code styles, javadocs, typos as in this case, etc. Otherwise, I would suggest you contribute such changes to the upstream projects. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Mon Sep 26 16:51:36 2022 From: mernst at openjdk.org (Michael Ernst) Date: Mon, 26 Sep 2022 16:51:36 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Reinstate typos in Apache code that is copied into the JDK - Merge ../jdk-openjdk into typos-typos - Remove file that was removed upstream - Fix inconsistency in capitalization - Undo change in zlip - Fix typos ------------- Changes: https://git.openjdk.org/jdk/pull/10029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=01 Stats: 85 lines in 76 files changed: 0 ins; 0 del; 85 mod Patch: https://git.openjdk.org/jdk/pull/10029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029 PR: https://git.openjdk.org/jdk/pull/10029 From joehw at openjdk.org Mon Sep 26 17:04:25 2022 From: joehw at openjdk.org (Joe Wang) Date: Mon, 26 Sep 2022 17:04:25 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Thanks for the update! ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Mon Sep 26 17:10:27 2022 From: duke at openjdk.org (Aryan Patil) Date: Mon, 26 Sep 2022 17:10:27 GMT Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov wrote: > Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR. > > benchmark results: > > before: > > Benchmark Mode Cnt Score Error Units > DoubleClassCheck.testIsFiniteBranch avgt 15 52.824 ? 1.744 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 16.104 ? 0.358 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 14.366 ? 2.174 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 49.821 ? 0.330 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 14.702 ? 0.335 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 14.749 ? 0.496 ns/op > > after: > > DoubleClassCheck.testIsFiniteBranch avgt 15 48.921 ? 0.557 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 13.716 ? 0.304 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 9.152 ? 0.158 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 47.740 ? 2.028 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 13.299 ? 0.282 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 9.185 ? 0.396 ns/op > > Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way. > > Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues. LGTM ------------- Marked as reviewed by AryanP45 at github.com (no known OpenJDK username). PR: https://git.openjdk.org/jdk/pull/10391 From shade at openjdk.org Mon Sep 26 17:17:17 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 Sep 2022 17:17:17 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v3] In-Reply-To: References: Message-ID: <8M4RH1K1EEGtHLPqWX-U4EmIyB4zws1Aq0ECGTgHgCM=.4fd2f758-6a9f-4a18-bc3d-d3e499b88eb3@github.com> On Mon, 26 Sep 2022 15:39:28 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. >> >> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. >> >> Some warnings didn't trigger in any file anymore, and could just be removed. >> >> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. >> >> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. >> >> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. >> >> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). >> >> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Trigger GHA to compile with all warnings before aborting I ran all {x86_32, x86_64, aarch64, arm, powerpc64le, arm, riscv64} x {server} x {release,fastdebug} with GCC 10, and these are the new additions: diff --git a/make/common/MakeBase.gmk b/make/common/MakeBase.gmk index fa1d44396df..915b175a649 100644 --- a/make/common/MakeBase.gmk +++ b/make/common/MakeBase.gmk @@ -195,7 +195,7 @@ $(eval $(call SetupLogging)) ################################################################################ -MAX_PARAMS := 64 +MAX_PARAMS := 96 PARAM_SEQUENCE := $(call sequence, 2, $(MAX_PARAMS)) # Template for creating a macro taking named parameters. To use it, assign the diff --git a/make/hotspot/lib/CompileJvm.gmk b/make/hotspot/lib/CompileJvm.gmk index ca38551c67d..7c37d5e2929 100644 --- a/make/hotspot/lib/CompileJvm.gmk +++ b/make/hotspot/lib/CompileJvm.gmk @@ -85,7 +85,7 @@ CFLAGS_VM_VERSION := \ DISABLED_WARNINGS_gcc := ignored-qualifiers comment int-in-bool-context \ array-bounds implicit-fallthrough parentheses missing-field-initializers \ - delete-non-virtual-dtor unknown-pragmas maybe-uninitialized + delete-non-virtual-dtor unknown-pragmas maybe-uninitialized shift-negative-value DISABLED_WARNINGS_clang := ignored-qualifiers sometimes-uninitialized \ missing-braces delete-non-abstract-non-virtual-dtor unknown-pragmas @@ -162,9 +162,16 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBJVM, \ DISABLED_WARNINGS_gcc_loopnode.cpp := sequence-point, \ DISABLED_WARNINGS_gcc_macroArrayCopy.cpp := shift-negative-value, \ DISABLED_WARNINGS_gcc_mulnode.cpp := shift-negative-value, \ + DISABLED_WARNINGS_gcc_ad_ppc.cpp := empty-body, \ DISABLED_WARNINGS_gcc_postaloc.cpp := address, \ DISABLED_WARNINGS_gcc_sharedRuntimeTrig.cpp := misleading-indentation, \ + DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_aarch64.cpp := misleading-indentation, \ + DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_ppc.cpp := misleading-indentation, \ + DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_riscv.cpp := misleading-indentation, \ DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_x86.cpp := misleading-indentation, \ + DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_aarch64.cpp := misleading-indentation, \ + DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_ppc.cpp := misleading-indentation, \ + DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_riscv.cpp := misleading-indentation, \ DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_x86.cpp := misleading-indentation, \ DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1.cpp := misleading-indentation, \ DISABLED_WARNINGS_gcc_signals_posix.cpp := cast-function-type, \ Unfortunately, in s390x case, the warning is in `assembler_s390.hpp`, which means a lot of compilation units fail. Therefore I introduced `shift-negative-value` back. I did not remove the per-file `shift-negative-value`-s, though. I shall deal with `misleading-indentation` the coding that produces these warnings some time later, maybe even ahead of this PR. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From lancea at openjdk.org Mon Sep 26 19:38:20 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 26 Sep 2022 19:38:20 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Thank you for your efforts on the cleaning up these typos I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review. I realize the changes are fairly trivial but this will most likely expedite getting your changes back ------------- PR: https://git.openjdk.org/jdk/pull/10029 From ayang at openjdk.org Mon Sep 26 20:58:17 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 26 Sep 2022 20:58:17 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 13:21:14 GMT, Kim Barrett wrote: >> src/hotspot/share/gc/g1/g1Analytics.cpp line 251: >> >>> 249: double G1Analytics::predict_dirtied_cards_in_thread_buffers() const { >>> 250: return predict_zero_bounded(_dirtied_cards_in_thread_buffers_seq); >>> 251: } >> >> I believe this sequence captures #dirty cards in thread buffers at GC pause start. However, I don't think it follows a normal distribution because of the buffer-size clamping. In comparison, the dirty-cards-generation-rate (`predict_dirtied_cards_rate_ms`) more likely follows a normal distribution. > > The number of dirty cards in thread buffers at the start of GC pause is > exactly what this is supposed to capture. We discount the number of cards that > can be processed in the budgeted time by this prediction to get the target > number of cards in the queue. It's not a very accurate prediction, but it's > still worth doing. For some applications and configurations I've tested (with > low G1RSetUpdatingPauseTimePercent) it might be 5-10% of the target. A model > based on the number of threads tends to do very poorly for some applications. > > This is entirely different from predict_dirtied_cards_rate_ms, which is a > different value and has different uses. My reasoning is that #cards in the bounded thread-buffers doesn't necessarily follow a normal distribution, so one can't predict the future valuse using avg + std. Taking an extreme example of a single thread-buffer, if the population avg is ~buffer_capacity, #cards in the thread-buffer can exhibit large jumps btw 0 and ~buffer_capacity due to the implicit modulo operation. > It's not a very accurate prediction, but it's still worth doing. Which benchmark shows its effect? I hard-coded `size_t predicted_thread_buffer_cards = 0;` in `G1Policy::record_young_collection_end` but can't see much difference. Normally, #cards in global dirty queue should be >> #cards in thread-local buffers. > A zero value for the prediction indicates that we don't have a valid prediction Why not? It's still possible that the alloc-rate is zero after start-up; I mean alloc-rate is up to applications. On a related note, there's special treatment for too-close upcoming GC pause later on, `if (_predicted_time_until_next_gc_ms > _update_period_ms) {`. Shouldn't there be sth similar for too-far upcoming GC pause? IOW, `incoming_rate * _predicted_time_until_next_gc_ms;` would be unreliable for farther prediction, right? ------------- PR: https://git.openjdk.org/jdk/pull/10256 From sspitsyn at openjdk.org Tue Sep 27 00:18:26 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 27 Sep 2022 00:18:26 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 21:47:06 GMT, David Holmes wrote: >> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). >> >> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. >> >> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). >> >> Testing: tiers 1-3 > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into 8293592-JVM_StopThread > - Removal all special handling of ThreadDeath. > - Remove all references to the stillborn field > - Initial commit: remove JVM_StopThread > - Merge > - Updates to Java Thread Primitive Deprecation page > - Repalce "it" with "victim thread" > - Merge > - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop > - become -> became in javadoc > - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 This looks good to me. I do not see any issues. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10400 From dzhang at openjdk.org Tue Sep 27 01:59:56 2022 From: dzhang at openjdk.org (Dingli Zhang) Date: Tue, 27 Sep 2022 01:59:56 GMT Subject: RFR: 8293770: RISC-V: Reuse runtime call trampolines [v3] In-Reply-To: References: Message-ID: > Follow up [JDK-8280152](https://bugs.openjdk.org/browse/JDK-8280152), this case also exists in riscv. > > Benchmark als, chi-square, dec-tree, log-regression, naive-bayes, page-rank, fj-kmeans, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~2.1% reduction on average. > > ## Testing: > > - hotspot and jdk tier1 on unmatched board without new failures > - hotspot/jtreg/compiler/sharedstubs/SharedTrampolineTest.java with fastdebug on qemu > > > ## Results > #### Results from [Renaissance 0.14.1](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.1) > > - riscv64 > > +--------------------------------------------------------------------------------------------------------+ > | | Before | After | > | Benchmark |---------------------------------------------------------------------------------------| > | | non-profiled nmethods | profiled nmethods | non-profiled nmethods | profiled nmethods | > +----------------+-----------------------+-------------------+-----------------------+-------------------| > | als | 15628 | 39421 | 12341 | 26681 | > | chi-square | 6349 | 20268 | 6033 | 20252 | > | dec-tree | 11058 | 42443 | 10774 | 43880 | > | log-regression | 10939 | 38237 | 12071 | 44199 | > | naive-bayes | 9023 | 29563 | 9294 | 30948 | > | page-rank | 6054 | 17041 | 5812 | 17353 | > | fj-kmeans | 692 | 2893 | 651 | 3354 | > | reactors | 2126 | 4073 | 1876 | 4106 | > | future-genetic | 1306 | 4118 | 1226 | 4142 | > | mnemonics | 726 | 2659 | 706 | 2684 | > | dotty | 26059 | 24417 | 24585 | 25379 | > | scala-kmeans | 564 | 3122 | 543 | 3132 | > | finagle-http | 6188 | 12455 | 6102 | 12295 | > | sum | 96712 | 240710 | 92014 | 238405 | > +--------------------------------------------------------------------------------------------------------+ Dingli Zhang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Fix alignment - Simplify targe related jal call in macroAssembler_riscv.cpp - Port JDK-8280152 to RISC-V Co-authored-by: zifeihan ------------- Changes: https://git.openjdk.org/jdk/pull/10260/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10260&range=02 Stats: 72 lines in 4 files changed: 61 ins; 4 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10260/head:pull/10260 PR: https://git.openjdk.org/jdk/pull/10260 From dzhang at openjdk.org Tue Sep 27 02:08:05 2022 From: dzhang at openjdk.org (Dingli Zhang) Date: Tue, 27 Sep 2022 02:08:05 GMT Subject: RFR: 8293770: RISC-V: Reuse runtime call trampolines [v2] In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 06:36:58 GMT, Feilong Jiang wrote: > Copyright of codeBuffer_riscv.hpp should be update to 2022. Hi @feilongjiang Thank you for the comments! Maybe I should not need to update the copyright after I modify the file because I am not an employee of the above company. ------------- PR: https://git.openjdk.org/jdk/pull/10260 From dholmes at openjdk.org Tue Sep 27 04:25:18 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Sep 2022 04:25:18 GMT Subject: RFR: 8292016: Split Windows API error handling from errors passed through the runtime in the JDK [v22] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 15:47:51 GMT, Julian Waters wrote: >> EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime. > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Whitespace This seems to be trying to future-proof the reporting code by introducing a duality that is not actually needed at present in some cases. That means the code is untested. Are there planned uses of `RUNTIME` in the very near future? src/java.base/share/native/libjava/jni_util.h line 339: > 337: char *jniEntryName); > 338: > 339: // RUNTIME - Errors that were passed through the runtime If "runtime" means "C runtime" (as the system description suggests) then please say that. src/java.base/share/native/libjava/jni_util.h line 348: > 346: > 347: JNIEXPORT size_t JNICALL > 348: getLastErrorString(char *buf, size_t len, ErrorOrigin origin); AFAICS we never pass RUNTIME to `getLastErrorString` src/java.base/share/native/libjli/java.h line 145: > 143: */ > 144: JNIEXPORT void JNICALL > 145: JLI_ReportErrorMessageSys(ErrorOrigin origin, const char * message, ...); AFAICS we never pass RUNTIME to `JLI_ReportErrorMessageSys`. src/java.base/unix/native/libjli/java_md_common.c line 207: > 205: va_start(vl, fmt); > 206: vfprintf(stderr, fmt, vl); > 207: if (errno != 0) { Is `vfprintf` guaranteed to not set `errno`? ------------- PR: https://git.openjdk.org/jdk/pull/9870 From dholmes at openjdk.org Tue Sep 27 05:00:24 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Sep 2022 05:00:24 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 00:15:17 GMT, Serguei Spitsyn wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into 8293592-JVM_StopThread >> - Removal all special handling of ThreadDeath. >> - Remove all references to the stillborn field >> - Initial commit: remove JVM_StopThread >> - Merge >> - Updates to Java Thread Primitive Deprecation page >> - Repalce "it" with "victim thread" >> - Merge >> - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop >> - become -> became in javadoc >> - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 > > This looks good to me. > I do not see any issues. > Thanks, > Serguei Thanks @sspitsyn ! ------------- PR: https://git.openjdk.org/jdk/pull/10400 From dholmes at openjdk.org Tue Sep 27 05:58:06 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Sep 2022 05:58:06 GMT Subject: RFR: 8294293: Remove unused _width and _newlines field in outputStream [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 08:38:40 GMT, Johan Sj?len wrote: >> src/hotspot/share/utilities/ostream.cpp line 904: >> >>> 902: if (has_log_file()) { >>> 903: int nl0 = _newlines; >>> 904: xmlTextStream::write(s, len); >> >> xmlTextStream::write seems to be unused after this change. > > It does seem that way. The `outputStream::write` method is the function which all subclasses of `outputStream` implements, so we shouldn't remove this function without removing `xmlTextStream`. That's probably a separate RFE, and perhaps not desirable as it'd require merging the class into `defaultStream`. I'm confused by this part of the change. How can the original code call `xmlTextStream::write` without an instance of `xmlTextStream` to apply it to??? ------------- PR: https://git.openjdk.org/jdk/pull/10411 From xgong at openjdk.org Tue Sep 27 06:15:17 2022 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 27 Sep 2022 06:15:17 GMT Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 08:51:24 GMT, Xiaohong Gong wrote: > "`VectorSupport.indexVector()`" is used to compute a vector that contains the index values based on a given vector and a scale value (`i.e. index = vec + iota * scale`). This function is widely used in other APIs like "`VectorMask.indexInRange`" which is useful to the tail loop vectorization. And it can be easily implemented with the vector instructions. > > This patch adds the vector intrinsic implementation of it. The steps are: > > 1) Load the const "iota" vector. > > We extend the "`vector_iota_indices`" stubs from byte to other integral types. For floating point vectors, it needs an additional vector cast to get the right iota values. > > 2) Compute indexes with "`vec + iota * scale`" > > Here is the performance result to the new added micro benchmark on ARM NEON: > > Benchmark Gain > IndexVectorBenchmark.byteIndexVector 1.477 > IndexVectorBenchmark.doubleIndexVector 5.031 > IndexVectorBenchmark.floatIndexVector 5.342 > IndexVectorBenchmark.intIndexVector 5.529 > IndexVectorBenchmark.longIndexVector 3.177 > IndexVectorBenchmark.shortIndexVector 5.841 > > > Please help to review and share the feedback! Thanks in advance! Hi, could anyone please help to take a look at this PR? Thanks in advance for your time! ------------- PR: https://git.openjdk.org/jdk/pull/10332 From dholmes at openjdk.org Tue Sep 27 06:22:46 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Sep 2022 06:22:46 GMT Subject: RFR: 8294160: misc crash dump improvements In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 07:53:42 GMT, Dean Long wrote: > Try to recover and output meaningful information in more situations, such as: > - when a pointer is in Method metadata memory range, but the memory is not committed > - when we call a bad address > > When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information. I'm not familiar with all the aspects of this in enough detail so just a couple of observational comments. src/hotspot/os/posix/signals_posix.cpp line 629: > 627: // Check for UD trap caused by NOP patching. > 628: // If it is, patch return address to be deopt handler. > 629: if (!signal_was_handled && pc != NULL && os::is_readable_pointer(pc)) { If these new conditions are not met then what happens? What code will get the unreadable, or null pc to process? src/hotspot/share/utilities/vmError.cpp line 353: > 351: > 352: // see if it's a valid frame > 353: if (fr.sp() != nullptr && os::is_readable_pointer(fr.sp())) { Why did you completely change the notion of "valid frame" here? ------------- PR: https://git.openjdk.org/jdk/pull/10387 From jsjolen at openjdk.org Tue Sep 27 07:27:27 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 27 Sep 2022 07:27:27 GMT Subject: RFR: 8294293: Remove unused _width and _newlines field in outputStream [v2] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 05:54:28 GMT, David Holmes wrote: >> It does seem that way. The `outputStream::write` method is the function which all subclasses of `outputStream` implements, so we shouldn't remove this function without removing `xmlTextStream`. That's probably a separate RFE, and perhaps not desirable as it'd require merging the class into `defaultStream`. > > I'm confused by this part of the change. How can the original code call `xmlTextStream::write` without an instance of `xmlTextStream` to apply it to??? `defaultStream` inherits from `xmlTextStream` and `defaultStream::write` exists, so this specifies to call the superclass method, and not its own method. In long form: `this->xmlTextStream::write` (haven't attempted to compile) ------------- PR: https://git.openjdk.org/jdk/pull/10411 From fyang at openjdk.org Tue Sep 27 07:28:32 2022 From: fyang at openjdk.org (Fei Yang) Date: Tue, 27 Sep 2022 07:28:32 GMT Subject: RFR: 8294430: riscv: small refactoring for movptr_with_offset Message-ID: The name of function 'movptr_with_offset' looks misleading. It actually returns an offset to its caller. We could rename this function to 'movptr' so that it overloads existing function 'movptr'. void movptr(Register Rd, address addr); - void movptr_with_offset(Register Rd, address addr, int32_t &offset); + void movptr(Register Rd, address addr, int32_t &offset); Testing: Tier1 hotspot tested on HiFive Unmatched board. ------------- Commit messages: - 8294430: riscv: small refactoring for movptr_with_offset Changes: https://git.openjdk.org/jdk/pull/10439/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10439&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294430 Stats: 28 lines in 10 files changed: 0 ins; 2 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/10439.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10439/head:pull/10439 PR: https://git.openjdk.org/jdk/pull/10439 From svkamath at openjdk.org Tue Sep 27 07:40:19 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Tue, 27 Sep 2022 07:40:19 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v10] In-Reply-To: References: Message-ID: > 8289552: Make intrinsic conversions between bit representations of half precision values and floats Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Addressed review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9781/files - new: https://git.openjdk.org/jdk/pull/9781/files/bd55803a..c6128b1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=08-09 Stats: 83 lines in 5 files changed: 37 ins; 38 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9781.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781 PR: https://git.openjdk.org/jdk/pull/9781 From svkamath at openjdk.org Tue Sep 27 07:40:24 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Tue, 27 Sep 2022 07:40:24 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Wed, 21 Sep 2022 17:49:51 GMT, Jatin Bhateja wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed review comments > > src/hotspot/share/opto/convertnode.cpp line 166: > >> 164: //============================================================================= >> 165: //------------------------------Value------------------------------------------ >> 166: const Type* ConvF2HFNode::Value(PhaseGVN* phase) const { > > IR framework based test will compliment newly introduced IR nodes. Will add IR framework based test in addition to the gtest. > src/hotspot/share/opto/convertnode.hpp line 107: > >> 105: class ConvF2HFNode : public Node { >> 106: public: >> 107: ConvF2HFNode( Node *in1 ) : Node(0,in1) {} > > Additional space b/w , and in1 Hi Jatin, this spacing is similar to other class declarations in the file. So I will keep it consistent. Thanks. > src/hotspot/share/opto/convertnode.hpp line 146: > >> 144: class ConvHF2FNode : public Node { >> 145: public: >> 146: ConvHF2FNode( Node *in1 ) : Node(0,in1) {} > > Space b/w , and in1 Same reasoning as above. > src/hotspot/share/runtime/sharedRuntime.cpp line 452: > >> 450: // Reference implementation at src/java.base/share/classes/java/lang/Float.java:floatToFloat16 >> 451: JRT_LEAF(jshort, SharedRuntime::f2hf(jfloat x)) >> 452: jint doppel = SharedRuntime::f2i(x); > > Newly added constant value computation runtime routines can be validated by a gtest. I have created a bug entry for the gtest. Will add it in a separate PR. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From svkamath at openjdk.org Tue Sep 27 07:46:19 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Tue, 27 Sep 2022 07:46:19 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Wed, 21 Sep 2022 16:41:19 GMT, Vladimir Kozlov wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed review comments > > tier2 and 3 passed. I will wait update with test and JVMCI fix before doing more testing. @vnkozlov I have made the requested changes. Thanks a lot for your help. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From rehn at openjdk.org Tue Sep 27 08:05:19 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 27 Sep 2022 08:05:19 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: <-5Dm6rla6Uq1BWSlvsaVKXwLsbd0c2tgewPhpygfqZ0=.283a80a5-5025-4460-8ede-68a37e668764@github.com> On Fri, 23 Sep 2022 21:47:06 GMT, David Holmes wrote: >> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). >> >> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. >> >> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). >> >> Testing: tiers 1-3 > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into 8293592-JVM_StopThread > - Removal all special handling of ThreadDeath. > - Remove all references to the stillborn field > - Initial commit: remove JVM_StopThread > - Merge > - Updates to Java Thread Primitive Deprecation page > - Repalce "it" with "victim thread" > - Merge > - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop > - become -> became in javadoc > - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 Looks good, thank for fixing. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10400 From fjiang at openjdk.org Tue Sep 27 08:18:43 2022 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 27 Sep 2022 08:18:43 GMT Subject: RFR: 8294430: RISC-V: Small refactoring for movptr_with_offset In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 07:20:11 GMT, Fei Yang wrote: > The name of function 'movptr_with_offset' looks misleading. It actually returns an offset to its caller. > We could rename this function to 'movptr' so that it overloads existing function 'movptr'. > > > void movptr(Register Rd, address addr); > - void movptr_with_offset(Register Rd, address addr, int32_t &offset); > + void movptr(Register Rd, address addr, int32_t &offset); > > > Testing: Tier1 hotspot on HiFive Linux-riscv64 Unmatched board. Looks fine, thanks! ------------- Marked as reviewed by fjiang (Author). PR: https://git.openjdk.org/jdk/pull/10439 From haosun at openjdk.org Tue Sep 27 09:16:54 2022 From: haosun at openjdk.org (Hao Sun) Date: Tue, 27 Sep 2022 09:16:54 GMT Subject: RFR: 8294359: Interpreter(AArch64) intrinsify Thread.currentThread() Message-ID: <4_NS99FGLWdfBMRtO8zpcFs0CxSSojL6R5428Wy83To=.bb96e085-7742-425f-b8bf-3d366f3b050b@github.com> JDK-8278793 supported Thread.currentThread() intrinsification for interpreter(x64) part so as to get JVM startup benefit. In this patch, we implement the AArch64 part. Testings: tier1~3 and jdk_loom passed on Linux/AArch64. ------------- Commit messages: - 8294359: Interpreter(AArch64) intrinsify Thread.currentThread() Changes: https://git.openjdk.org/jdk/pull/10441/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10441&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294359 Stats: 15 lines in 4 files changed: 11 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10441.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10441/head:pull/10441 PR: https://git.openjdk.org/jdk/pull/10441 From aph at openjdk.org Tue Sep 27 09:30:53 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 27 Sep 2022 09:30:53 GMT Subject: RFR: 8294359: Interpreter(AArch64) intrinsify Thread.currentThread() In-Reply-To: <4_NS99FGLWdfBMRtO8zpcFs0CxSSojL6R5428Wy83To=.bb96e085-7742-425f-b8bf-3d366f3b050b@github.com> References: <4_NS99FGLWdfBMRtO8zpcFs0CxSSojL6R5428Wy83To=.bb96e085-7742-425f-b8bf-3d366f3b050b@github.com> Message-ID: On Tue, 27 Sep 2022 09:09:05 GMT, Hao Sun wrote: > JDK-8278793 supported Thread.currentThread() intrinsification for interpreter(x64) part so as to get JVM startup benefit. > > In this patch, we implement the AArch64 part. > > Testings: tier1~3 and jdk_loom passed on Linux/AArch64. Looks good. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.org/jdk/pull/10441 From yadongwang at openjdk.org Tue Sep 27 09:50:20 2022 From: yadongwang at openjdk.org (Yadong Wang) Date: Tue, 27 Sep 2022 09:50:20 GMT Subject: RFR: 8294430: RISC-V: Small refactoring for movptr_with_offset In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 07:20:11 GMT, Fei Yang wrote: > The name of function 'movptr_with_offset' looks misleading. It actually returns an offset to its caller. > We could rename this function to 'movptr' so that it overloads existing function 'movptr'. > > > void movptr(Register Rd, address addr); > - void movptr_with_offset(Register Rd, address addr, int32_t &offset); > + void movptr(Register Rd, address addr, int32_t &offset); > > > Testing: Tier1 hotspot on HiFive Linux-riscv64 Unmatched board. lgtm ------------- Marked as reviewed by yadongwang (Author). PR: https://git.openjdk.org/jdk/pull/10439 From shade at openjdk.org Tue Sep 27 10:13:25 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 Sep 2022 10:13:25 GMT Subject: RFR: 8294359: Interpreter(AArch64) intrinsify Thread.currentThread() In-Reply-To: <4_NS99FGLWdfBMRtO8zpcFs0CxSSojL6R5428Wy83To=.bb96e085-7742-425f-b8bf-3d366f3b050b@github.com> References: <4_NS99FGLWdfBMRtO8zpcFs0CxSSojL6R5428Wy83To=.bb96e085-7742-425f-b8bf-3d366f3b050b@github.com> Message-ID: On Tue, 27 Sep 2022 09:09:05 GMT, Hao Sun wrote: > JDK-8278793 supported Thread.currentThread() intrinsification for interpreter(x64) part so as to get JVM startup benefit. > > In this patch, we implement the AArch64 part. > > Testings: tier1~3 and jdk_loom passed on Linux/AArch64. Looks fine. (I had to look up definitions for `rscratch1` and `rscratch2` to make sure they do not collide with `r0`) ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10441 From avoitylov at openjdk.org Tue Sep 27 10:34:21 2022 From: avoitylov at openjdk.org (Aleksei Voitylov) Date: Tue, 27 Sep 2022 10:34:21 GMT Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V In-Reply-To: References: Message-ID: <8oUXKGdFua0Px3qX0MkyHaegyTk-hsah12SDmZiu_qk=.222f6369-d18a-4ccb-bf67-dd03d04eb0fc@github.com> On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov wrote: > Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR. > > benchmark results: > > before: > > Benchmark Mode Cnt Score Error Units > DoubleClassCheck.testIsFiniteBranch avgt 15 52.824 ? 1.744 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 16.104 ? 0.358 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 14.366 ? 2.174 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 49.821 ? 0.330 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 14.702 ? 0.335 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 14.749 ? 0.496 ns/op > > after: > > DoubleClassCheck.testIsFiniteBranch avgt 15 48.921 ? 0.557 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 13.716 ? 0.304 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 9.152 ? 0.158 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 47.740 ? 2.028 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 13.299 ? 0.282 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 9.185 ? 0.396 ns/op > > Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way. > > Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues. @vnkozlov could you or someone familiar with C2 look at shared C2 HotSpot changes? I did test it on x86, but any extra testing could help as well. ------------- PR: https://git.openjdk.org/jdk/pull/10391 From shade at openjdk.org Tue Sep 27 10:37:16 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 Sep 2022 10:37:16 GMT Subject: RFR: 8294430: RISC-V: Small refactoring for movptr_with_offset In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 07:20:11 GMT, Fei Yang wrote: > The name of function 'movptr_with_offset' looks misleading. It actually returns an offset to its caller. > We could rename this function to 'movptr' so that it overloads existing function 'movptr'. > > > void movptr(Register Rd, address addr); > - void movptr_with_offset(Register Rd, address addr, int32_t &offset); > + void movptr(Register Rd, address addr, int32_t &offset); > > > Testing: Tier1 hotspot on HiFive Linux-riscv64 Unmatched board. Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10439 From ihse at openjdk.org Tue Sep 27 10:48:20 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 10:48:20 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v4] In-Reply-To: References: Message-ID: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Add warnings for additional platforms (thanks shipilev!) - Revert "Trigger GHA to compile with all warnings before aborting" This reverts commit 031acab542c0693d5ee4f90c6f94452206bbb203. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/031acab5..ee608421 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=02-03 Stats: 13 lines in 3 files changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Tue Sep 27 10:48:22 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 10:48:22 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v3] In-Reply-To: <8M4RH1K1EEGtHLPqWX-U4EmIyB4zws1Aq0ECGTgHgCM=.4fd2f758-6a9f-4a18-bc3d-d3e499b88eb3@github.com> References: <8M4RH1K1EEGtHLPqWX-U4EmIyB4zws1Aq0ECGTgHgCM=.4fd2f758-6a9f-4a18-bc3d-d3e499b88eb3@github.com> Message-ID: On Mon, 26 Sep 2022 17:13:40 GMT, Aleksey Shipilev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Trigger GHA to compile with all warnings before aborting > > I ran all {x86_32, x86_64, aarch64, arm, powerpc64le, arm, riscv64} x {server} x {release,fastdebug} with GCC 10, and these are the new additions: > > > diff --git a/make/common/MakeBase.gmk b/make/common/MakeBase.gmk > index fa1d44396df..915b175a649 100644 > --- a/make/common/MakeBase.gmk > +++ b/make/common/MakeBase.gmk > @@ -195,7 +195,7 @@ $(eval $(call SetupLogging)) > > ################################################################################ > > -MAX_PARAMS := 64 > +MAX_PARAMS := 96 > PARAM_SEQUENCE := $(call sequence, 2, $(MAX_PARAMS)) > > # Template for creating a macro taking named parameters. To use it, assign the > diff --git a/make/hotspot/lib/CompileJvm.gmk b/make/hotspot/lib/CompileJvm.gmk > index ca38551c67d..7c37d5e2929 100644 > --- a/make/hotspot/lib/CompileJvm.gmk > +++ b/make/hotspot/lib/CompileJvm.gmk > @@ -85,7 +85,7 @@ CFLAGS_VM_VERSION := \ > > DISABLED_WARNINGS_gcc := ignored-qualifiers comment int-in-bool-context \ > array-bounds implicit-fallthrough parentheses missing-field-initializers \ > - delete-non-virtual-dtor unknown-pragmas maybe-uninitialized > + delete-non-virtual-dtor unknown-pragmas maybe-uninitialized shift-negative-value > > DISABLED_WARNINGS_clang := ignored-qualifiers sometimes-uninitialized \ > missing-braces delete-non-abstract-non-virtual-dtor unknown-pragmas > @@ -162,9 +162,16 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBJVM, \ > DISABLED_WARNINGS_gcc_loopnode.cpp := sequence-point, \ > DISABLED_WARNINGS_gcc_macroArrayCopy.cpp := shift-negative-value, \ > DISABLED_WARNINGS_gcc_mulnode.cpp := shift-negative-value, \ > + DISABLED_WARNINGS_gcc_ad_ppc.cpp := empty-body, \ > DISABLED_WARNINGS_gcc_postaloc.cpp := address, \ > DISABLED_WARNINGS_gcc_sharedRuntimeTrig.cpp := misleading-indentation, \ > + DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_aarch64.cpp := misleading-indentation, \ > + DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_ppc.cpp := misleading-indentation, \ > + DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_riscv.cpp := misleading-indentation, \ > DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_x86.cpp := misleading-indentation, \ > + DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_aarch64.cpp := misleading-indentation, \ > + DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_ppc.cpp := misleading-indentation, \ > + DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_riscv.cpp := misleading-indentation, \ > DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_x86.cpp := misleading-indentation, \ > DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1.cpp := misleading-indentation, \ > DISABLED_WARNINGS_gcc_signals_posix.cpp := cast-function-type, \ > > > Unfortunately, in s390x case, the warning is in `assembler_s390.hpp`, which means a lot of compilation units fail. Therefore I introduced `shift-negative-value` back. I did not remove the per-file `shift-negative-value`-s, though. > > I shall deal with `misleading-indentation` the coding that produces these warnings some time later, maybe even ahead of this PR. Thanks @shipilev! I incorporated your patch, but I made the shift-negative-value conditional on s390x. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From shade at openjdk.org Tue Sep 27 10:48:22 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 Sep 2022 10:48:22 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v3] In-Reply-To: <8M4RH1K1EEGtHLPqWX-U4EmIyB4zws1Aq0ECGTgHgCM=.4fd2f758-6a9f-4a18-bc3d-d3e499b88eb3@github.com> References: <8M4RH1K1EEGtHLPqWX-U4EmIyB4zws1Aq0ECGTgHgCM=.4fd2f758-6a9f-4a18-bc3d-d3e499b88eb3@github.com> Message-ID: On Mon, 26 Sep 2022 17:13:40 GMT, Aleksey Shipilev wrote: > I shall deal with `misleading-indentation` the coding that produces these warnings some time later, maybe even ahead of this PR. This would be #10444. We can integrate them in whatever order. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Tue Sep 27 10:57:59 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 10:57:59 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v2] In-Reply-To: <90OTsoZSmHOgDEDHsqPbsuodVH8U-pLO4bfRXszp6bU=.1f06f500-3f4c-42b7-8f9c-e428d272da92@github.com> References: <90OTsoZSmHOgDEDHsqPbsuodVH8U-pLO4bfRXszp6bU=.1f06f500-3f4c-42b7-8f9c-e428d272da92@github.com> Message-ID: On Sat, 24 Sep 2022 03:33:34 GMT, Kim Barrett wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - ppc64 triggers shift-negative-value on gcc :-( >> - s390 triggers shift-negative-value on gcc :-( > > There used to be more comments around the warning disables. The Windows ones > had comments that gave titles to the numeric codes. And I think there were > some comments that discussed why a warning was disabled rather than fixing > code. I don't know when that all disappeared, but it was quite a while ago, > and I still miss that commentary. @kimbarrett I promised a list of warnings that were previously globally (within hotspot) disabled, but are not now. Here it is: ### gcc address cast-function-type char-subscripts empty-body misleading-indentation sequence-point shift-negative-value strict-overflow ### clang char-subscripts delete-non-virtual-dtor misleading-indentation mismatched-tags missing-field-initializers shift-negative-value tautological-compare undefined-var-template ### visual studio 4100 - 'identifier': unreferenced formal parameter 4127 - conditional expression is constant 4201 - nonstandard extension used: nameless struct/union 4351 - new behavior: elements of array ?array? will be default initialized (according to google, but it is undocumented!!!) 4511 - 'class': copy constructor was implicitly defined as deleted 4512 - 'class': assignment operator was implicitly defined as deleted 4514 - 'function': unreferenced inline function has been removed ------------- PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Tue Sep 27 11:01:25 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 11:01:25 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v4] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 10:48:20 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. >> >> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. >> >> Some warnings didn't trigger in any file anymore, and could just be removed. >> >> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. >> >> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. >> >> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. >> >> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). >> >> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Add warnings for additional platforms (thanks shipilev!) > - Revert "Trigger GHA to compile with all warnings before aborting" > > This reverts commit 031acab542c0693d5ee4f90c6f94452206bbb203. The following warnings are truly globally disabled (for all native code in the JDK): ### gcc unused unused-parameter ### clang unused unused-parameter unknown-warning-option ### visual studio 4800 - Implicit conversion from 'type' to bool. Possible information loss 5105 - macro expansion producing 'defined' has undefined behavior [this is for broken microsoft SDK code with new preprocessor] ------------- PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Tue Sep 27 11:06:16 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 11:06:16 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v3] In-Reply-To: References: <8M4RH1K1EEGtHLPqWX-U4EmIyB4zws1Aq0ECGTgHgCM=.4fd2f758-6a9f-4a18-bc3d-d3e499b88eb3@github.com> Message-ID: On Tue, 27 Sep 2022 10:43:25 GMT, Aleksey Shipilev wrote: >> I ran all {x86_32, x86_64, aarch64, arm, powerpc64le, arm, riscv64} x {server} x {release,fastdebug} with GCC 10, and these are the new additions: >> >> >> diff --git a/make/common/MakeBase.gmk b/make/common/MakeBase.gmk >> index fa1d44396df..915b175a649 100644 >> --- a/make/common/MakeBase.gmk >> +++ b/make/common/MakeBase.gmk >> @@ -195,7 +195,7 @@ $(eval $(call SetupLogging)) >> >> ################################################################################ >> >> -MAX_PARAMS := 64 >> +MAX_PARAMS := 96 >> PARAM_SEQUENCE := $(call sequence, 2, $(MAX_PARAMS)) >> >> # Template for creating a macro taking named parameters. To use it, assign the >> diff --git a/make/hotspot/lib/CompileJvm.gmk b/make/hotspot/lib/CompileJvm.gmk >> index ca38551c67d..7c37d5e2929 100644 >> --- a/make/hotspot/lib/CompileJvm.gmk >> +++ b/make/hotspot/lib/CompileJvm.gmk >> @@ -85,7 +85,7 @@ CFLAGS_VM_VERSION := \ >> >> DISABLED_WARNINGS_gcc := ignored-qualifiers comment int-in-bool-context \ >> array-bounds implicit-fallthrough parentheses missing-field-initializers \ >> - delete-non-virtual-dtor unknown-pragmas maybe-uninitialized >> + delete-non-virtual-dtor unknown-pragmas maybe-uninitialized shift-negative-value >> >> DISABLED_WARNINGS_clang := ignored-qualifiers sometimes-uninitialized \ >> missing-braces delete-non-abstract-non-virtual-dtor unknown-pragmas >> @@ -162,9 +162,16 @@ $(eval $(call SetupJdkLibrary, BUILD_LIBJVM, \ >> DISABLED_WARNINGS_gcc_loopnode.cpp := sequence-point, \ >> DISABLED_WARNINGS_gcc_macroArrayCopy.cpp := shift-negative-value, \ >> DISABLED_WARNINGS_gcc_mulnode.cpp := shift-negative-value, \ >> + DISABLED_WARNINGS_gcc_ad_ppc.cpp := empty-body, \ >> DISABLED_WARNINGS_gcc_postaloc.cpp := address, \ >> DISABLED_WARNINGS_gcc_sharedRuntimeTrig.cpp := misleading-indentation, \ >> + DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_aarch64.cpp := misleading-indentation, \ >> + DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_ppc.cpp := misleading-indentation, \ >> + DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_riscv.cpp := misleading-indentation, \ >> DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_x86.cpp := misleading-indentation, \ >> + DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_aarch64.cpp := misleading-indentation, \ >> + DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_ppc.cpp := misleading-indentation, \ >> + DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_riscv.cpp := misleading-indentation, \ >> DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1_x86.cpp := misleading-indentation, \ >> DISABLED_WARNINGS_gcc_shenandoahBarrierSetC1.cpp := misleading-indentation, \ >> DISABLED_WARNINGS_gcc_signals_posix.cpp := cast-function-type, \ >> >> >> Unfortunately, in s390x case, the warning is in `assembler_s390.hpp`, which means a lot of compilation units fail. Therefore I introduced `shift-negative-value` back. I did not remove the per-file `shift-negative-value`-s, though. >> >> I shall deal with `misleading-indentation` the coding that produces these warnings some time later, maybe even ahead of this PR. > >> I shall deal with `misleading-indentation` the coding that produces these warnings some time later, maybe even ahead of this PR. > > This would be #10444. We can integrate them in whatever order. @shipilev The code history will probably be more straightforward if your fix goes in first. There's no real hurry with this one. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From duke at openjdk.org Tue Sep 27 11:08:55 2022 From: duke at openjdk.org (AJ Ferguson) Date: Tue, 27 Sep 2022 11:08:55 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 [v3] In-Reply-To: References: Message-ID: <78MJYU3qgFvL7LF5eLrljPch8hmIbBgXrJE0jm4JU8M=.d0ef0307-3699-4b30-85a1-74a374774cb3@github.com> > Fix cipher state corruption when encrypting/decrypting less than 16 bytes at a time. AJ Ferguson has updated the pull request incrementally with one additional commit since the last revision: Add regression test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9635/files - new: https://git.openjdk.org/jdk/pull/9635/files/360304cf..8fc3e429 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9635&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9635&range=01-02 Stats: 95 lines in 1 file changed: 95 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9635.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9635/head:pull/9635 PR: https://git.openjdk.org/jdk/pull/9635 From duke at openjdk.org Tue Sep 27 11:08:55 2022 From: duke at openjdk.org (AJ Ferguson) Date: Tue, 27 Sep 2022 11:08:55 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 23:53:17 GMT, Sandhya Viswanathan wrote: >> Hello @smita-kamath, thank you for taking the time to look at this PR. The changes you posted look good to me. I have added your improvements and updated the branch. > > @AJ-Ferguson Please do add a test for this case. @sviswa7 @vnkozlov I have added the test. Please let me know if there are any issues. ------------- PR: https://git.openjdk.org/jdk/pull/9635 From jsjolen at openjdk.org Tue Sep 27 11:27:56 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 27 Sep 2022 11:27:56 GMT Subject: RFR: 8293691: converting a defined BasicType value to a string should not crash the VM Message-ID: Hi, This implements Kim's suggested fix for this ticket. ------------- Commit messages: - Change impl of type2name Changes: https://git.openjdk.org/jdk/pull/10447/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10447&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293691 Stats: 15 lines in 2 files changed: 11 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10447.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10447/head:pull/10447 PR: https://git.openjdk.org/jdk/pull/10447 From alanb at openjdk.org Tue Sep 27 11:40:30 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 Sep 2022 11:40:30 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v3] In-Reply-To: References: Message-ID: On Sat, 24 Sep 2022 06:50:45 GMT, Alan Bateman wrote: >> Degrade Thread.suspend/resume to throw UOE unconditionally. >> >> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. >> >> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. >> >> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Remove tests from exclude list > - Merge > - Update DegradedMethodsThrowUOE to test Thread.stop > - Merge > - Update modifyThread and modifyThreadGroup targets > - Merge > - Fix typo in test comment > - Keep link to threadPrimitiveDeprecation.html > - Merge > - Tests > - ... and 1 more: https://git.openjdk.org/jdk/compare/543851db...6aa38889 Wakeup bot ------------- PR: https://git.openjdk.org/jdk/pull/10324 From alanb at openjdk.org Tue Sep 27 11:47:20 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 Sep 2022 11:47:20 GMT Subject: Integrated: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman wrote: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). This pull request has now been integrated. Changeset: 1abf971b Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/1abf971b93222f422c0026cee944a6db214f955a Stats: 454 lines in 16 files changed: 136 ins; 255 del; 63 mod 8249627: Degrade Thread.suspend and Thread.resume Reviewed-by: cjplummer, sspitsyn, dholmes, jpai ------------- PR: https://git.openjdk.org/jdk/pull/10324 From kbarrett at openjdk.org Tue Sep 27 12:15:07 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 27 Sep 2022 12:15:07 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v4] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 10:48:20 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. >> >> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. >> >> Some warnings didn't trigger in any file anymore, and could just be removed. >> >> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. >> >> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. >> >> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. >> >> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). >> >> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Add warnings for additional platforms (thanks shipilev!) > - Revert "Trigger GHA to compile with all warnings before aborting" > > This reverts commit 031acab542c0693d5ee4f90c6f94452206bbb203. Changes requested by kbarrett (Reviewer). make/hotspot/lib/CompileJvm.gmk line 95: > 93: > 94: DISABLED_WARNINGS_clang := ignored-qualifiers sometimes-uninitialized \ > 95: missing-braces delete-non-abstract-non-virtual-dtor unknown-pragmas Per JDK-9240259, -Wshift-negative-value should remain globally disabled, for all of gcc and clang (and xlc, where it hasn't been removed). Per discussion for JDK-8211073, -Wempty-body should remain globally disabled for gcc. As for the other gcc and clang warnings being removed from the globally disabled lists, that looks okay to me. I'm particularly happy to see -Wstrict-overflow removed from that list, and that we don't seem to have any of those any more. I've not looked at the changes to warnings for Windows. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From shade at openjdk.org Tue Sep 27 12:18:32 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 Sep 2022 12:18:32 GMT Subject: RFR: 8293691: converting a defined BasicType value to a string should not crash the VM In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 11:21:40 GMT, Johan Sj?len wrote: > Hi, > > This implements Kim's suggested fix for this ticket. Looks okay to me, with a nit. src/hotspot/share/utilities/globalDefinitions.cpp line 240: > 238: }; > 239: const char* type2name(BasicType t) { > 240: if (t < (T_CONFLICT + 1)) { Looks cleaner to do `if (t <= T_CONFLICT)`, maybe? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10447 From shade at openjdk.org Tue Sep 27 12:28:49 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 Sep 2022 12:28:49 GMT Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot Message-ID: There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good. C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check. Build-tested this with product of: - GCC 10 - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64} - {server, zero} - {release, fastdebug} Linux x86_64 fastdebug `tier1` is fine. ------------- Commit messages: - Also javaClasses.cpp - Fix Changes: https://git.openjdk.org/jdk/pull/10444/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10444&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294438 Stats: 44 lines in 5 files changed: 7 ins; 6 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/10444.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10444/head:pull/10444 PR: https://git.openjdk.org/jdk/pull/10444 From ihse at openjdk.org Tue Sep 27 12:28:50 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 12:28:50 GMT Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 10:28:54 GMT, Aleksey Shipilev wrote: > There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good. > > C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check. > > Build-tested this with product of: > - GCC 10 > - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64} > - {server, zero} > - {release, fastdebug} > > Linux x86_64 fastdebug `tier1` is fine. So enabling the warning actually exposed a bug? That's always nice to see, and a good argument for keeping up with the hygiene work of minimizing the amount of disabled warnings. ------------- PR: https://git.openjdk.org/jdk/pull/10444 From shade at openjdk.org Tue Sep 27 12:28:50 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 Sep 2022 12:28:50 GMT Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 11:02:28 GMT, Magnus Ihse Bursie wrote: > So enabling the warning actually exposed a bug? That's always nice to see, and a good argument for keeping up with the hygiene work of minimizing the amount of disabled warnings. Yes. It is hard to judge how innocuous that bug really is, because (handwaves) compilers. ------------- PR: https://git.openjdk.org/jdk/pull/10444 From coleenp at openjdk.org Tue Sep 27 12:40:26 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 27 Sep 2022 12:40:26 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 21:47:06 GMT, David Holmes wrote: >> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). >> >> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. >> >> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). >> >> Testing: tiers 1-3 > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into 8293592-JVM_StopThread > - Removal all special handling of ThreadDeath. > - Remove all references to the stillborn field > - Initial commit: remove JVM_StopThread > - Merge > - Updates to Java Thread Primitive Deprecation page > - Repalce "it" with "victim thread" > - Merge > - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop > - become -> became in javadoc > - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10400 From tschatzl at openjdk.org Tue Sep 27 12:48:24 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 27 Sep 2022 12:48:24 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 06:39:33 GMT, Kim Barrett wrote: >> 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal >> 8155996: Improve concurrent refinement green zone control >> 8134303: Introduce -XX:-G1UseConcRefinement >> >> Please review this change to the control of concurrent refinement. >> >> This new controller takes a different approach to the problem, addressing a >> number of issues. >> >> The old controller used a multiple of the target number of cards to determine >> the range over which increasing numbers of refinement threads should be >> activated, and finally activating mutator refinement. This has a variety of >> problems. It doesn't account for the processing rate, the rate of new dirty >> cards, or the time available to perform the processing. This often leads to >> unnecessary spikes in the number of running refinement threads. It also tends >> to drive the pending number to the target quickly and keep it there, removing >> the benefit from having pending dirty cards filter out new cards for nearby >> writes. It can't delay and leave excess cards in the queue because it could >> be a long time before another buffer is enqueued. >> >> The old controller was triggered by mutator threads enqueing card buffers, >> when the number of cards in the queue exceeded a threshold near the target. >> This required a complex activation protocol between the mutators and the >> refinement threads. >> >> With the new controller there is a primary refinement thread that periodically >> estimates how many refinement threads need to be running to reach the target >> in time for the next GC, along with whether to also activate mutator >> refinement. If the primary thread stops running because it isn't currently >> needed, it sleeps for a period and reevaluates on wakeup. This eliminates any >> involvement in the activation of refinement threads by mutator threads. >> >> The estimate of how many refinement threads are needed uses a prediction of >> time until the next GC, the number of buffered cards, the predicted rate of >> new dirty cards, and the predicted refinement rate. The number of running >> threads is adjusted based on these periodically performed estimates. >> >> This new approach allows more dirty cards to be left in the queue until late >> in the mutator phase, typically reducing the rate of new dirty cards, which >> reduces the amount of concurrent refinement work needed. >> >> It also smooths out the number of running refinement threads, eliminating the >> unnecessarily large spikes that are common with the old method. One benefit >> is that the number of refinement threads (lazily) allocated is often much >> lower now. (This plus UseDynamicNumberOfGCThreads mitigates the problem >> described in JDK-8153225.) >> >> This change also provides a new method for calculating for the number of dirty >> cards that should be pending at the start of a GC. While this calculation is >> conceptually distinct from the thread control, the two were significanly >> intertwined in the old controller. Changing this calculation separately and >> first would have changed the behavior of the old controller in ways that might >> have introduced regressions. Changing it after the thread control was changed >> would have made it more difficult to test and measure the thread control in a >> desirable configuration. >> >> The old calculation had various problems that are described in JDK-8155996. >> In particular, it can get more or less stuck at low values, and is slow to >> respond to changes. >> >> The old controller provided a number of product options, none of which were >> very useful for real applications, and none of which are very applicable to >> the new controller. All of these are being obsoleted. >> >> -XX:-G1UseAdaptiveConcRefinement >> -XX:G1ConcRefinementGreenZone= >> -XX:G1ConcRefinementYellowZone= >> -XX:G1ConcRefinementRedZone= >> -XX:G1ConcRefinementThresholdStep= >> >> The new controller *could* use G1ConcRefinementGreenZone to provide a fixed >> value for the target number of cards, though it is poorly named for that. >> >> A configuration that was useful for some kinds of debugging and testing was to >> disable G1UseAdaptiveConcRefinement and set g1ConcRefinementGreenZone to a >> very large value, effectively disabling concurrent refinement. To support >> this use case with the new controller, the -XX:-G1UseConcRefinement diagnostic >> option has been added (see JDK-8155996). >> >> The other options are meaningless for the new controller. >> >> Because of these option changes, a CSR and a release note need to accompany >> this change. >> >> Testing: >> mach5 tier1-6 >> various performance tests. >> local (linux-x64) tier1 with -XX:-G1UseConcRefinement >> >> Performance testing found no regressions, but also little or no improvement >> with default options, which was expected. With default options most of our >> performance tests do very little concurrent refinement. And even for those >> that do, while the old controller had a number of problems, the impact of >> those problems is small and hard to measure for most applications. >> >> When reducing G1RSetUpdatingPauseTimePercent the new controller seems to fare >> better, particularly when also reducing MaxGCPauseMillis. specjbb2015 with >> MaxGCPauseMillis=75 and G1RSetUpdatingPauseTimePercent=3 (and other options >> held constant) showed a statistically significant improvement of about 4.5% >> for critical-jOPS. Using the changed controller, the difference between this >> configuration and the default is fairly small, while the baseline shows >> significant degradation with the more restrictive options. >> >> For all tests and configurations the new controller often creates many fewer >> refinement threads. > > Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: > > - wanted vs needed nomenclature > - remove several spurious "scan" > - delay => wait_time_ms Some typos. Going to do some testing. src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 77: > 75: } else { > 76: delete t; > 77: } Not sure this early-bail out is necessary; C++ seems to define `nullptr` values passed to `delete` well enough (https://en.cppreference.com/w/cpp/language/delete) to skip this complication. Feel free to ignore. src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 219: > 217: // Deduct predicted cards in thread buffers to get target. > 218: size_t new_target = budget - MIN2(budget, predicted_thread_buffer_cards); > 219: // Add some hysterisis with previous values. Suggestion: // Add some hysteresis with previous values. src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 233: > 231: size_t predicted_thread_buffer_cards, > 232: double goal_ms) { > 233: if (!G1UseConcRefinement) return; I would prefer either braces or an additional newline after this statement. When initially reading this I thought there were some indentation error. src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 198: > 196: void reduce_threads_wanted(); > 197: > 198: // Test whethre the thread designated by worker_id should be active. s/whethre/whether src/hotspot/share/gc/g1/g1ConcurrentRefineThreadsNeeded.cpp line 44: > 42: // Estimate how many concurrent refinement threads we need to run to achieve > 43: // the target number of card by the time the next GC happens. There are > 44: // several additional desirements we'd like to achieve while meeting that According to https://en.wiktionary.org/wiki/desirement this is defined as Something that is [desired](https://en.wiktionary.org/wiki/desired), but not absolutely required. (This word was new to me). I think that "desirements" already includes the phrase "we'd like to achieve". I.e. something that is desired, but is not absolutely required is already something "we'd like to achieve". So I would like to suggest to either remove the phrase "we'd like to achieve" or reformulate the sentence as "... several additional/secondary goals we would like to achieve while meeting that (main) goal". src/hotspot/share/gc/g1/g1ConcurrentRefineThreadsNeeded.cpp line 79: > 77: // Estimate number of cards that need to be processed before next GC. There > 78: // are no incoming cards when time is short, because the controller activates > 79: // refinement by mutator threads when there to a GC, to stay on target even "refinement by mutator threads when there to a GC" I do not understand this part of the sentence, what does "there to a gc" mean? Maybe this should means: "..., because in this case the controller activates refinement by mutator threads to stay on target even..." src/hotspot/share/gc/g1/g1ConcurrentRefineThreadsNeeded.cpp line 116: > 114: // excess cards to process. Just one thread might not be sufficient, but > 115: // we don't have any idea how many we actually need. Eventually the > 116: // prediction machinary will warm up and we'll be able to get estimates. s/machinary/machinery ------------- Changes requested by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/10256 From tschatzl at openjdk.org Tue Sep 27 12:48:25 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 27 Sep 2022 12:48:25 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 20:54:12 GMT, Albert Mingkun Yang wrote: > Why not? It's still possible that the alloc-rate is zero after start-up; I mean alloc-rate is up to applications. Allocation rate is the rate of allocation between GCs, to have a GC, you (almost) need non-zero allocation rate (not with periodic gcs). ------------- PR: https://git.openjdk.org/jdk/pull/10256 From coleenp at openjdk.org Tue Sep 27 13:01:23 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 27 Sep 2022 13:01:23 GMT Subject: RFR: 8293691: converting a defined BasicType value to a string should not crash the VM In-Reply-To: References: Message-ID: <7-BkB2eA5lJzVo3JYU4a5O_hcHj0aqJkIsQSnrghfhw=.43d92ba4-53ef-4045-803e-d0f286b2580a@github.com> On Tue, 27 Sep 2022 11:21:40 GMT, Johan Sj?len wrote: > Hi, > > This implements Kim's suggested fix for this ticket. Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/10447 From shade at openjdk.org Tue Sep 27 13:15:30 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 Sep 2022 13:15:30 GMT Subject: RFR: 8293691: converting a defined BasicType value to a string should not crash the VM In-Reply-To: <31_ViZ1hdHZxjXkcy0ElQTB5EnYwEZ_CV5WD8sDzNeQ=.15d1b869-7d74-44b6-ace7-442c2d173985@github.com> References: <31_ViZ1hdHZxjXkcy0ElQTB5EnYwEZ_CV5WD8sDzNeQ=.15d1b869-7d74-44b6-ace7-442c2d173985@github.com> Message-ID: On Tue, 27 Sep 2022 13:10:56 GMT, Johan Sj?len wrote: >> src/hotspot/share/utilities/globalDefinitions.cpp line 240: >> >>> 238: }; >>> 239: const char* type2name(BasicType t) { >>> 240: if (t < (T_CONFLICT + 1)) { >> >> Looks cleaner to do `if (t <= T_CONFLICT)`, maybe? > > Hm, yeah. This looks like this to create symmetry with the declaration of `type2name_tab`: > > > extern const char* type2name_tab[T_CONFLICT+1]; // Map a BasicType to a char* > > > But the symmetry is lost here as they're in 2 different files now. I'd like a RFE where `type2name_tab` is no longer external which will make the symmetry apparent again. Can we ignore this nit in anticipation of that change? I honestly don't care about this nit either way :) You decide. ------------- PR: https://git.openjdk.org/jdk/pull/10447 From jsjolen at openjdk.org Tue Sep 27 13:15:29 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 27 Sep 2022 13:15:29 GMT Subject: RFR: 8293691: converting a defined BasicType value to a string should not crash the VM In-Reply-To: References: Message-ID: <31_ViZ1hdHZxjXkcy0ElQTB5EnYwEZ_CV5WD8sDzNeQ=.15d1b869-7d74-44b6-ace7-442c2d173985@github.com> On Tue, 27 Sep 2022 12:14:04 GMT, Aleksey Shipilev wrote: >> Hi, >> >> This implements Kim's suggested fix for this ticket. > > src/hotspot/share/utilities/globalDefinitions.cpp line 240: > >> 238: }; >> 239: const char* type2name(BasicType t) { >> 240: if (t < (T_CONFLICT + 1)) { > > Looks cleaner to do `if (t <= T_CONFLICT)`, maybe? Hm, yeah. This looks like this to create symmetry with the declaration of `type2name_tab`: extern const char* type2name_tab[T_CONFLICT+1]; // Map a BasicType to a char* But the symmetry is lost here as they're in 2 different files now. I'd like a RFE where `type2name_tab` is no longer external which will make the symmetry apparent again. Can we ignore this nit in anticipation of that change? ------------- PR: https://git.openjdk.org/jdk/pull/10447 From jsjolen at openjdk.org Tue Sep 27 13:15:30 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 27 Sep 2022 13:15:30 GMT Subject: RFR: 8293691: converting a defined BasicType value to a string should not crash the VM In-Reply-To: References: <31_ViZ1hdHZxjXkcy0ElQTB5EnYwEZ_CV5WD8sDzNeQ=.15d1b869-7d74-44b6-ace7-442c2d173985@github.com> Message-ID: On Tue, 27 Sep 2022 13:12:25 GMT, Aleksey Shipilev wrote: >> Hm, yeah. This looks like this to create symmetry with the declaration of `type2name_tab`: >> >> >> extern const char* type2name_tab[T_CONFLICT+1]; // Map a BasicType to a char* >> >> >> But the symmetry is lost here as they're in 2 different files now. I'd like a RFE where `type2name_tab` is no longer external which will make the symmetry apparent again. Can we ignore this nit in anticipation of that change? > > I honestly don't care about this nit either way :) You decide. Alright, I'll let it be then :). ------------- PR: https://git.openjdk.org/jdk/pull/10447 From jbhateja at openjdk.org Tue Sep 27 13:20:12 2022 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 27 Sep 2022 13:20:12 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v10] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 07:40:19 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments test/jdk/java/lang/Float/Binary16ConversionNaN.java line 30: > 28: * @run main Binary16ConversionNaN > 29: * @run main/othervm -XX:+UnlockDiagnosticVMOptions > 30: * -XX:DisableIntrinsic=_float16ToFloat,_floatToFloat16 Binary16ConversionNaN Test is not excising newly added intrinsic code, you may need to adjust the compile threshold and disable tiered compilation. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From jbhateja at openjdk.org Tue Sep 27 13:24:27 2022 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 27 Sep 2022 13:24:27 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v10] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 07:40:19 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comments I have verified my other comments, we can either handle auto-vectorization of newly added intrinsic in this patch of create a follow up PR. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From sjohanss at openjdk.org Tue Sep 27 14:03:30 2022 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 27 Sep 2022 14:03:30 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 06:39:33 GMT, Kim Barrett wrote: >> 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal >> 8155996: Improve concurrent refinement green zone control >> 8134303: Introduce -XX:-G1UseConcRefinement >> >> Please review this change to the control of concurrent refinement. >> >> This new controller takes a different approach to the problem, addressing a >> number of issues. >> >> The old controller used a multiple of the target number of cards to determine >> the range over which increasing numbers of refinement threads should be >> activated, and finally activating mutator refinement. This has a variety of >> problems. It doesn't account for the processing rate, the rate of new dirty >> cards, or the time available to perform the processing. This often leads to >> unnecessary spikes in the number of running refinement threads. It also tends >> to drive the pending number to the target quickly and keep it there, removing >> the benefit from having pending dirty cards filter out new cards for nearby >> writes. It can't delay and leave excess cards in the queue because it could >> be a long time before another buffer is enqueued. >> >> The old controller was triggered by mutator threads enqueing card buffers, >> when the number of cards in the queue exceeded a threshold near the target. >> This required a complex activation protocol between the mutators and the >> refinement threads. >> >> With the new controller there is a primary refinement thread that periodically >> estimates how many refinement threads need to be running to reach the target >> in time for the next GC, along with whether to also activate mutator >> refinement. If the primary thread stops running because it isn't currently >> needed, it sleeps for a period and reevaluates on wakeup. This eliminates any >> involvement in the activation of refinement threads by mutator threads. >> >> The estimate of how many refinement threads are needed uses a prediction of >> time until the next GC, the number of buffered cards, the predicted rate of >> new dirty cards, and the predicted refinement rate. The number of running >> threads is adjusted based on these periodically performed estimates. >> >> This new approach allows more dirty cards to be left in the queue until late >> in the mutator phase, typically reducing the rate of new dirty cards, which >> reduces the amount of concurrent refinement work needed. >> >> It also smooths out the number of running refinement threads, eliminating the >> unnecessarily large spikes that are common with the old method. One benefit >> is that the number of refinement threads (lazily) allocated is often much >> lower now. (This plus UseDynamicNumberOfGCThreads mitigates the problem >> described in JDK-8153225.) >> >> This change also provides a new method for calculating for the number of dirty >> cards that should be pending at the start of a GC. While this calculation is >> conceptually distinct from the thread control, the two were significanly >> intertwined in the old controller. Changing this calculation separately and >> first would have changed the behavior of the old controller in ways that might >> have introduced regressions. Changing it after the thread control was changed >> would have made it more difficult to test and measure the thread control in a >> desirable configuration. >> >> The old calculation had various problems that are described in JDK-8155996. >> In particular, it can get more or less stuck at low values, and is slow to >> respond to changes. >> >> The old controller provided a number of product options, none of which were >> very useful for real applications, and none of which are very applicable to >> the new controller. All of these are being obsoleted. >> >> -XX:-G1UseAdaptiveConcRefinement >> -XX:G1ConcRefinementGreenZone= >> -XX:G1ConcRefinementYellowZone= >> -XX:G1ConcRefinementRedZone= >> -XX:G1ConcRefinementThresholdStep= >> >> The new controller *could* use G1ConcRefinementGreenZone to provide a fixed >> value for the target number of cards, though it is poorly named for that. >> >> A configuration that was useful for some kinds of debugging and testing was to >> disable G1UseAdaptiveConcRefinement and set g1ConcRefinementGreenZone to a >> very large value, effectively disabling concurrent refinement. To support >> this use case with the new controller, the -XX:-G1UseConcRefinement diagnostic >> option has been added (see JDK-8155996). >> >> The other options are meaningless for the new controller. >> >> Because of these option changes, a CSR and a release note need to accompany >> this change. >> >> Testing: >> mach5 tier1-6 >> various performance tests. >> local (linux-x64) tier1 with -XX:-G1UseConcRefinement >> >> Performance testing found no regressions, but also little or no improvement >> with default options, which was expected. With default options most of our >> performance tests do very little concurrent refinement. And even for those >> that do, while the old controller had a number of problems, the impact of >> those problems is small and hard to measure for most applications. >> >> When reducing G1RSetUpdatingPauseTimePercent the new controller seems to fare >> better, particularly when also reducing MaxGCPauseMillis. specjbb2015 with >> MaxGCPauseMillis=75 and G1RSetUpdatingPauseTimePercent=3 (and other options >> held constant) showed a statistically significant improvement of about 4.5% >> for critical-jOPS. Using the changed controller, the difference between this >> configuration and the default is fairly small, while the baseline shows >> significant degradation with the more restrictive options. >> >> For all tests and configurations the new controller often creates many fewer >> refinement threads. > > Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: > > - wanted vs needed nomenclature > - remove several spurious "scan" > - delay => wait_time_ms Did some testing with the patch to get a feel for the log changes and found a couple of things that we might want to improved. src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 345: > 343: num_cards, > 344: _threads_needed.predicted_cards_at_next_gc(), > 345: _threads_needed.predicted_time_until_next_gc_ms()); During my testing with fixed IR jbb I saw this kind of frequently: [19,856s][trace][gc,refine ] Activated worker 0, current: 79255 [19,856s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79255, predicted: 79255, time: 0,00ms [19,856s][trace][gc,refine ] Deactivated worker 0, cards: 79255, refined 0, rate 0,00c/ms [19,906s][trace][gc,refine ] Activated worker 0, current: 79511 [19,906s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79511, predicted: 79511, time: 0,00ms [19,906s][trace][gc,refine ] Deactivated worker 0, cards: 79511, refined 0, rate 0,00c/ms [19,956s][trace][gc,refine ] Activated worker 0, current: 79511 [19,956s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79511, predicted: 79511, time: 0,00ms [19,956s][trace][gc,refine ] Deactivated worker 0, cards: 79511, refined 0, rate 0,00c/ms [20,007s][trace][gc,refine ] Activated worker 0, current: 79511 [20,007s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79511, predicted: 79511, time: 0,00ms [20,007s][trace][gc,refine ] Deactivated worker 0, cards: 79511, refined 0, rate 0,00c/ms [20,057s][trace][gc,refine ] Activated worker 0, current: 79767 [20,057s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79767, predicted: 79767, time: 0,00ms [20,057s][trace][gc,refine ] Deactivated worker 0, cards: 79767, refined 0, rate 0,00c/ms [20,107s][trace][gc,refine ] Activated worker 0, current: 79767 [20,107s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79767, predicted: 79767, time: 0,00ms [20,107s][trace][gc,refine ] Deactivated worker 0, cards: 79767, refined 0, rate 0,00c/ms >From what I can tell, in those cases we are not really updating the refinement threads, but keeping them at 0. I think this log should only be printed under the condition that `new_wanted` is different from `old_wanted`. Makes sense? src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 61: > 59: SuspendibleThreadSetJoiner sts_join; > 60: G1ConcurrentRefineStats active_stats_start = _refinement_stats; > 61: report_active("Activated"); Because `G1ConcurrentRefineThread::run_service()` is shared between the primary and secondary thread there will be an "Activated" log message for each periodic wake of the primary refinement thread. This is on the trace level, but I think we should only call `report_active()` when we know there is work to be done by the thread, not just checks. src/hotspot/share/gc/g1/g1Policy.cpp line 963: > 961: hcc_cards, > 962: merge_hcc_time_ms, > 963: (exceeded_goal ? " (exceeded goal)" : "")); Since the pending cards target is initialized to `SIZE_MAX`, the first GC this will always print: GC(0) GC refinement: goal: 18446744073709551615 ... Not sure if printing 0 is much better but it looks more "buggy" to print `SIZE_MAX` imo. ------------- Changes requested by sjohanss (Reviewer). PR: https://git.openjdk.org/jdk/pull/10256 From ihse at openjdk.org Tue Sep 27 14:03:52 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 14:03:52 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v5] In-Reply-To: References: Message-ID: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Well this is not shell script. *duh* ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/ee608421..52503c99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Tue Sep 27 14:36:43 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 14:36:43 GMT Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 10:28:54 GMT, Aleksey Shipilev wrote: > There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good. > > C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check. > > Build-tested this with product of: > - GCC 10 > - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64} > - {server, zero} > - {release, fastdebug} > > Linux x86_64 fastdebug `tier1` is fine. The build part of this PR is OK ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/jdk/pull/10444 From ihse at openjdk.org Tue Sep 27 14:48:27 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 14:48:27 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v4] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 12:11:23 GMT, Kim Barrett wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add warnings for additional platforms (thanks shipilev!) >> - Revert "Trigger GHA to compile with all warnings before aborting" >> >> This reverts commit 031acab542c0693d5ee4f90c6f94452206bbb203. > > make/hotspot/lib/CompileJvm.gmk line 95: > >> 93: >> 94: DISABLED_WARNINGS_clang := ignored-qualifiers sometimes-uninitialized \ >> 95: missing-braces delete-non-abstract-non-virtual-dtor unknown-pragmas > > Per JDK-9240259, -Wshift-negative-value should remain globally disabled, for > all of gcc and clang (and xlc, where it hasn't been removed). > > Per discussion for JDK-8211073, -Wempty-body should remain globally disabled > for gcc. > > As for the other gcc and clang warnings being removed from the globally > disabled lists, that looks okay to me. I'm particularly happy to see > -Wstrict-overflow removed from that list, and that we don't seem to have any > of those any more. > > I've not looked at the changes to warnings for Windows. You mentioned shift-negative-value earlier in this PR. I apologize I forgot about it. I can't find any discussion about JDK-8211073 wrt to `-Wempty-body` (are you sure this is the correct bug ID?), but I can put that as well to the globally disabled set. As for xlc, I have no access to that compiler and I have therefore not done much changes here. But I think xlc compiles with "warnings as errors" off by default so most likely the people still supporting the AIX port don't care that much about warnings. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From tschatzl at openjdk.org Tue Sep 27 14:49:58 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 27 Sep 2022 14:49:58 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 13:51:35 GMT, Stefan Johansson wrote: >> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: >> >> - wanted vs needed nomenclature >> - remove several spurious "scan" >> - delay => wait_time_ms > > src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 345: > >> 343: num_cards, >> 344: _threads_needed.predicted_cards_at_next_gc(), >> 345: _threads_needed.predicted_time_until_next_gc_ms()); > > During my testing with fixed IR jbb I saw this kind of frequently: > > [19,856s][trace][gc,refine ] Activated worker 0, current: 79255 > [19,856s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79255, predicted: 79255, time: 0,00ms > [19,856s][trace][gc,refine ] Deactivated worker 0, cards: 79255, refined 0, rate 0,00c/ms > [19,906s][trace][gc,refine ] Activated worker 0, current: 79511 > [19,906s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79511, predicted: 79511, time: 0,00ms > [19,906s][trace][gc,refine ] Deactivated worker 0, cards: 79511, refined 0, rate 0,00c/ms > [19,956s][trace][gc,refine ] Activated worker 0, current: 79511 > [19,956s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79511, predicted: 79511, time: 0,00ms > [19,956s][trace][gc,refine ] Deactivated worker 0, cards: 79511, refined 0, rate 0,00c/ms > [20,007s][trace][gc,refine ] Activated worker 0, current: 79511 > [20,007s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79511, predicted: 79511, time: 0,00ms > [20,007s][trace][gc,refine ] Deactivated worker 0, cards: 79511, refined 0, rate 0,00c/ms > [20,057s][trace][gc,refine ] Activated worker 0, current: 79767 > [20,057s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79767, predicted: 79767, time: 0,00ms > [20,057s][trace][gc,refine ] Deactivated worker 0, cards: 79767, refined 0, rate 0,00c/ms > [20,107s][trace][gc,refine ] Activated worker 0, current: 79767 > [20,107s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79767, predicted: 79767, time: 0,00ms > [20,107s][trace][gc,refine ] Deactivated worker 0, cards: 79767, refined 0, rate 0,00c/ms > > > From what I can tell, in those cases we are not really updating the refinement threads, but keeping them at 0. I think this log should only be printed under the condition that `new_wanted` is different from `old_wanted`. Makes sense? I think this is fine as is, we want updates to the current state and predictions too (also currently looking at logs). Maybe there is need for more detailed (trace-level?) logging though, still unsure. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From kbarrett at openjdk.org Tue Sep 27 15:20:22 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 27 Sep 2022 15:20:22 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v4] In-Reply-To: References: Message-ID: <6BjCl03lP6FEGb55GKZwOnAJIO0siLJNQGr69IzeS-Q=.79466af4-f157-49e6-88b9-6bfc236874d3@github.com> On Tue, 27 Sep 2022 14:44:18 GMT, Magnus Ihse Bursie wrote: >> make/hotspot/lib/CompileJvm.gmk line 95: >> >>> 93: >>> 94: DISABLED_WARNINGS_clang := ignored-qualifiers sometimes-uninitialized \ >>> 95: missing-braces delete-non-abstract-non-virtual-dtor unknown-pragmas >> >> Per JDK-9240259, -Wshift-negative-value should remain globally disabled, for >> all of gcc and clang (and xlc, where it hasn't been removed). >> >> Per discussion for JDK-8211073, -Wempty-body should remain globally disabled >> for gcc. >> >> As for the other gcc and clang warnings being removed from the globally >> disabled lists, that looks okay to me. I'm particularly happy to see >> -Wstrict-overflow removed from that list, and that we don't seem to have any >> of those any more. >> >> I've not looked at the changes to warnings for Windows. > > You mentioned shift-negative-value earlier in this PR. I apologize I forgot about it. > > I can't find any discussion about JDK-8211073 wrt to `-Wempty-body` (are you sure this is the correct bug ID?), but I can put that as well to the globally disabled set. > > As for xlc, I have no access to that compiler and I have therefore not done much changes here. But I think xlc compiles with "warnings as errors" off by default so most likely the people still supporting the AIX port don't care that much about warnings. JDK-8211073 is the correct bug id. JDK-8211073 Remove -Wno-extra from Hotspot There were two attempts at addressing this, about a year apart. The first one can be found here: https://mail.openjdk.org/pipermail/hotspot-dev/2018-September/034314.html and continuing here: https://mail.openjdk.org/pipermail/hotspot-dev/2018-October/034496.html with the explanation for disabling `-Wempty-body` here: https://mail.openjdk.org/pipermail/hotspot-dev/2018-October/034526.html The second, successful, attempt at it is here: https://mail.openjdk.org/pipermail/hotspot-dev/2019-October/039808.html Leaving xlc to the relevant port maintainers seems like a wise choice. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Tue Sep 27 15:32:22 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 15:32:22 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v6] In-Reply-To: References: Message-ID: <85q5kwRw0QE13gVVLiSla-O3WgmvGr4OwT4TiqLAlZ8=.3ff9637f-efb2-41fe-aa50-0d029c351835@github.com> > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Add shift-negative-value for macroAssembler_arm.cpp, and re-sort lines ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/52503c99..c473626c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=04-05 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From kbarrett at openjdk.org Tue Sep 27 15:35:24 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 27 Sep 2022 15:35:24 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 14:45:40 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 345: >> >>> 343: num_cards, >>> 344: _threads_needed.predicted_cards_at_next_gc(), >>> 345: _threads_needed.predicted_time_until_next_gc_ms()); >> >> During my testing with fixed IR jbb I saw this kind of frequently: >> >> [19,856s][trace][gc,refine ] Activated worker 0, current: 79255 >> [19,856s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79255, predicted: 79255, time: 0,00ms >> [19,856s][trace][gc,refine ] Deactivated worker 0, cards: 79255, refined 0, rate 0,00c/ms >> [19,906s][trace][gc,refine ] Activated worker 0, current: 79511 >> [19,906s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79511, predicted: 79511, time: 0,00ms >> [19,906s][trace][gc,refine ] Deactivated worker 0, cards: 79511, refined 0, rate 0,00c/ms >> [19,956s][trace][gc,refine ] Activated worker 0, current: 79511 >> [19,956s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79511, predicted: 79511, time: 0,00ms >> [19,956s][trace][gc,refine ] Deactivated worker 0, cards: 79511, refined 0, rate 0,00c/ms >> [20,007s][trace][gc,refine ] Activated worker 0, current: 79511 >> [20,007s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79511, predicted: 79511, time: 0,00ms >> [20,007s][trace][gc,refine ] Deactivated worker 0, cards: 79511, refined 0, rate 0,00c/ms >> [20,057s][trace][gc,refine ] Activated worker 0, current: 79767 >> [20,057s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79767, predicted: 79767, time: 0,00ms >> [20,057s][trace][gc,refine ] Deactivated worker 0, cards: 79767, refined 0, rate 0,00c/ms >> [20,107s][trace][gc,refine ] Activated worker 0, current: 79767 >> [20,107s][debug][gc,refine ] Updating refinement threads: wanted 0, cards: 79767, predicted: 79767, time: 0,00ms >> [20,107s][trace][gc,refine ] Deactivated worker 0, cards: 79767, refined 0, rate 0,00c/ms >> >> >> From what I can tell, in those cases we are not really updating the refinement threads, but keeping them at 0. I think this log should only be printed under the condition that `new_wanted` is different from `old_wanted`. Makes sense? > > I think this is fine as is, we want updates to the current state and predictions too (also currently looking at logs). Maybe there is need for more detailed (trace-level?) logging though, still unsure. The current cards, predicted cards, and predicted time until GC are, I think, all interesting here. The point is to give some indication of what the controller is doing and why. (The activation/deactivation messages are probably less interesting now, but that's why I demoted them to trace level.) For looking at what's going on with refinement `-Xlog:gc+refine*=debug` is now the thing to use. I wouldn't want to demote the above to trace level, and only logging on changes to wanted wouldn't provide that additional detail that I found useful in making sure things were working properly. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From ihse at openjdk.org Tue Sep 27 15:38:38 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 15:38:38 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v7] In-Reply-To: References: Message-ID: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Make "shift-negative-value" and "empty-body" globally disabled ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/c473626c..355ed0d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=05-06 Stats: 14 lines in 1 file changed: 0 ins; 10 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Tue Sep 27 15:38:38 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 15:38:38 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v4] In-Reply-To: <6BjCl03lP6FEGb55GKZwOnAJIO0siLJNQGr69IzeS-Q=.79466af4-f157-49e6-88b9-6bfc236874d3@github.com> References: <6BjCl03lP6FEGb55GKZwOnAJIO0siLJNQGr69IzeS-Q=.79466af4-f157-49e6-88b9-6bfc236874d3@github.com> Message-ID: On Tue, 27 Sep 2022 15:16:44 GMT, Kim Barrett wrote: >> You mentioned shift-negative-value earlier in this PR. I apologize I forgot about it. >> >> I can't find any discussion about JDK-8211073 wrt to `-Wempty-body` (are you sure this is the correct bug ID?), but I can put that as well to the globally disabled set. >> >> As for xlc, I have no access to that compiler and I have therefore not done much changes here. But I think xlc compiles with "warnings as errors" off by default so most likely the people still supporting the AIX port don't care that much about warnings. > > JDK-8211073 is the correct bug id. > > JDK-8211073 Remove -Wno-extra from Hotspot > > There were two attempts at addressing this, about a year apart. > The first one can be found here: > https://mail.openjdk.org/pipermail/hotspot-dev/2018-September/034314.html > and continuing here: > https://mail.openjdk.org/pipermail/hotspot-dev/2018-October/034496.html > with the explanation for disabling `-Wempty-body` here: > https://mail.openjdk.org/pipermail/hotspot-dev/2018-October/034526.html > > The second, successful, attempt at it is here: > https://mail.openjdk.org/pipermail/hotspot-dev/2019-October/039808.html > > Leaving xlc to the relevant port maintainers seems like a wise choice. Thanks. I tried searching but my mail archives did not include all of that discussion. I have now globally disabled empty-body and shift-negative-value for all of hotspot. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From kbarrett at openjdk.org Tue Sep 27 15:51:42 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 27 Sep 2022 15:51:42 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 12:54:30 GMT, Stefan Johansson wrote: >> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: >> >> - wanted vs needed nomenclature >> - remove several spurious "scan" >> - delay => wait_time_ms > > src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 61: > >> 59: SuspendibleThreadSetJoiner sts_join; >> 60: G1ConcurrentRefineStats active_stats_start = _refinement_stats; >> 61: report_active("Activated"); > > Because `G1ConcurrentRefineThread::run_service()` is shared between the primary and secondary thread there will be an "Activated" log message for each periodic wake of the primary refinement thread. This is on the trace level, but I think we should only call `report_active()` when we know there is work to be done by the thread, not just checks. The point of this message is mostly to see when these threads are (potentially) competing with application threads for processor time, which occurs regardless of whether they do anything or just quickly go back to waiting. At this point the primary thread doesn't know whether there is work to be done, since it hasn't (successfully) called update_threads_periodically yet. (It can't call that until inside the STS context, since it isn't thread-safe against a GC. It can't usefully call it between the STS entry and the report, since it might not succeed and need to be retried, which we deal with by trying to do some work before trying again, instead of useless spinning.) The same is true when a thread is resumed after a safepoint (even more so there, since a secondary thread might already be unwanted). Conditionally reporting activation would need to be mirrored when reporting deactivation. For all those reasons, I think it should be left as is. > src/hotspot/share/gc/g1/g1Policy.cpp line 963: > >> 961: hcc_cards, >> 962: merge_hcc_time_ms, >> 963: (exceeded_goal ? " (exceeded goal)" : "")); > > Since the pending cards target is initialized to `SIZE_MAX`, the first GC this will always print: > > GC(0) GC refinement: goal: 18446744073709551615 ... > > > Not sure if printing 0 is much better but it looks more "buggy" to print `SIZE_MAX` imo. Oh, I forgot about that. I was going to try to come up with something better there, like somehow printing "unlimited" or something like that. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From ihse at openjdk.org Tue Sep 27 16:04:01 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 16:04:01 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v8] In-Reply-To: References: Message-ID: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie 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 19 additional commits since the last revision: - Merge branch 'master' into hotspot-warnings-per-file - Make "shift-negative-value" and "empty-body" globally disabled - Add shift-negative-value for macroAssembler_arm.cpp, and re-sort lines - Well this is not shell script. *duh* - Add warnings for additional platforms (thanks shipilev!) - Revert "Trigger GHA to compile with all warnings before aborting" This reverts commit 031acab542c0693d5ee4f90c6f94452206bbb203. - Trigger GHA to compile with all warnings before aborting - ppc64 triggers shift-negative-value on gcc :-( - s390 triggers shift-negative-value on gcc :-( - Remove zero warnings - ... and 9 more: https://git.openjdk.org/jdk/compare/c21f1107...a558d378 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/355ed0d3..a558d378 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=06-07 Stats: 4186 lines in 114 files changed: 2691 ins; 1270 del; 225 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From kvn at openjdk.org Tue Sep 27 16:04:35 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 27 Sep 2022 16:04:35 GMT Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V In-Reply-To: References: Message-ID: <_srvgaMcXUDIvMxpQHD_y8jNH8pLEuOt7Uxdpi6dnaU=.14b20934-d921-4e84-b391-344a5f35e114@github.com> On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov wrote: > Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR. > > benchmark results: > > before: > > Benchmark Mode Cnt Score Error Units > DoubleClassCheck.testIsFiniteBranch avgt 15 52.824 ? 1.744 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 16.104 ? 0.358 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 14.366 ? 2.174 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 49.821 ? 0.330 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 14.702 ? 0.335 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 14.749 ? 0.496 ns/op > > after: > > DoubleClassCheck.testIsFiniteBranch avgt 15 48.921 ? 0.557 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 13.716 ? 0.304 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 9.152 ? 0.158 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 47.740 ? 2.028 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 13.299 ? 0.282 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 9.185 ? 0.396 ns/op > > Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way. > > Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues. I don't think old tests TestFloatClassCheck.java and TestDoubleClassCheck.java are modified correctly - they do nothing now. They have to run compiled methods and verify results. Other then that changes seem fine. ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10391 From jwaters at openjdk.org Tue Sep 27 16:19:20 2022 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 27 Sep 2022 16:19:20 GMT Subject: RFR: 8292016: Split Windows API error handling from errors passed through the runtime in the JDK [v22] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 04:22:59 GMT, David Holmes wrote: > This seems to be trying to future-proof the reporting code by introducing a duality that is not actually needed at present in some cases. That means the code is untested. Are there planned uses of `RUNTIME` in the very near future? The only use of it is to differentiate Windows API errors from the regular errno ones thus far, I doubt this will change any time soon. Honestly speaking I'm not very happy with the changes here, and it's been pretty tricky trying to come up with an elegant solution to this issue, but I'm not sure if the alternative of deleting all the error reporting utilities across the JDK and using what C already has (for instance perror) is acceptable in this case, because pretty much all of them have this same problem (and is also why I refrained from outright removing JLI_ReportErrorMessageSys initially like Thomas suggested). On the flip side, all of them don't seem to be used in _too many_ places, and can be rather easily replaced, so it is a little tempting to remove them and just sidestep the problem instead. Are any of these a part of the public JNI API? ------------- PR: https://git.openjdk.org/jdk/pull/9870 From kvn at openjdk.org Tue Sep 27 16:25:22 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 27 Sep 2022 16:25:22 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 [v3] In-Reply-To: <78MJYU3qgFvL7LF5eLrljPch8hmIbBgXrJE0jm4JU8M=.d0ef0307-3699-4b30-85a1-74a374774cb3@github.com> References: <78MJYU3qgFvL7LF5eLrljPch8hmIbBgXrJE0jm4JU8M=.d0ef0307-3699-4b30-85a1-74a374774cb3@github.com> Message-ID: On Tue, 27 Sep 2022 11:08:55 GMT, AJ Ferguson wrote: >> Fix cipher state corruption when encrypting/decrypting less than 16 bytes at a time. > > AJ Ferguson has updated the pull request incrementally with one additional commit since the last revision: > > Add regression test Good. I submitted testing. ------------- PR: https://git.openjdk.org/jdk/pull/9635 From kvn at openjdk.org Tue Sep 27 16:35:20 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 27 Sep 2022 16:35:20 GMT Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov wrote: > Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR. > > benchmark results: > > before: > > Benchmark Mode Cnt Score Error Units > DoubleClassCheck.testIsFiniteBranch avgt 15 52.824 ? 1.744 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 16.104 ? 0.358 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 14.366 ? 2.174 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 49.821 ? 0.330 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 14.702 ? 0.335 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 14.749 ? 0.496 ns/op > > after: > > DoubleClassCheck.testIsFiniteBranch avgt 15 48.921 ? 0.557 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 13.716 ? 0.304 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 9.152 ? 0.158 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 47.740 ? 2.028 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 13.299 ? 0.282 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 9.185 ? 0.396 ns/op > > Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way. > > Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues. Not enough coffee at the morning ;^) Finally noticed how new and old test interact. Changes are fine and I submitted testing. ------------- PR: https://git.openjdk.org/jdk/pull/10391 From shade at openjdk.org Tue Sep 27 16:45:25 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 Sep 2022 16:45:25 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v8] In-Reply-To: References: Message-ID: <_WJZt6ON2-vyQRFw2P9AnUBPAVHUkL2TOSdcIiGxP6s=.50844106-4332-4978-8e98-8e97955aa15e@github.com> On Tue, 27 Sep 2022 16:04:01 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. >> >> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. >> >> Some warnings didn't trigger in any file anymore, and could just be removed. >> >> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. >> >> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. >> >> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. >> >> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). >> >> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. > > Magnus Ihse Bursie 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 19 additional commits since the last revision: > > - Merge branch 'master' into hotspot-warnings-per-file > - Make "shift-negative-value" and "empty-body" globally disabled > - Add shift-negative-value for macroAssembler_arm.cpp, and re-sort lines > - Well this is not shell script. *duh* > - Add warnings for additional platforms (thanks shipilev!) > - Revert "Trigger GHA to compile with all warnings before aborting" > > This reverts commit 031acab542c0693d5ee4f90c6f94452206bbb203. > - Trigger GHA to compile with all warnings before aborting > - ppc64 triggers shift-negative-value on gcc :-( > - s390 triggers shift-negative-value on gcc :-( > - Remove zero warnings > - ... and 9 more: https://git.openjdk.org/jdk/compare/24315475...a558d378 Related: hopefully eliminating `sequence-point` warning with #10454. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Tue Sep 27 16:51:21 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 16:51:21 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9] In-Reply-To: References: Message-ID: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Don't need empty-body for ad_ppc.cpp now that it is globally disabled ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/a558d378..36ab7010 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From sjohanss at openjdk.org Tue Sep 27 17:03:11 2022 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 27 Sep 2022 17:03:11 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 15:33:08 GMT, Kim Barrett wrote: >> I think this is fine as is, we want updates to the current state and predictions too (also currently looking at logs). Maybe there is need for more detailed (trace-level?) logging though, still unsure. > > The current cards, predicted cards, and predicted time until GC are, I think, all interesting here. The point is to give some indication of what the controller is doing and why. (The activation/deactivation messages are probably less interesting now, but that's why I demoted them to trace level.) For looking at what's going on with refinement `-Xlog:gc+refine*=debug` is now the thing to use. I wouldn't want to demote the above to trace level, and only logging on changes to wanted wouldn't provide that additional detail that I found useful in making sure things were working properly. I agree that the other numbers are interesting, even if there is no change. Maybe the initial message could be altered depending on if we are going to update the number of threads. Or be more generic, something like: [20,057s][debug][gc,refine ] Concurrent refinement: wanted threads: 0, cards: 79767, predicted: 79767, time: 0,00ms ------------- PR: https://git.openjdk.org/jdk/pull/10256 From sjohanss at openjdk.org Tue Sep 27 17:03:14 2022 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 27 Sep 2022 17:03:14 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 15:48:13 GMT, Kim Barrett wrote: >> src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 61: >> >>> 59: SuspendibleThreadSetJoiner sts_join; >>> 60: G1ConcurrentRefineStats active_stats_start = _refinement_stats; >>> 61: report_active("Activated"); >> >> Because `G1ConcurrentRefineThread::run_service()` is shared between the primary and secondary thread there will be an "Activated" log message for each periodic wake of the primary refinement thread. This is on the trace level, but I think we should only call `report_active()` when we know there is work to be done by the thread, not just checks. > > The point of this message is mostly to see when these threads are > (potentially) competing with application threads for processor time, which > occurs regardless of whether they do anything or just quickly go back to > waiting. > > At this point the primary thread doesn't know whether there is work to be > done, since it hasn't (successfully) called update_threads_periodically yet. > (It can't call that until inside the STS context, since it isn't thread-safe > against a GC. It can't usefully call it between the STS entry and the report, > since it might not succeed and need to be retried, which we deal with by > trying to do some work before trying again, instead of useless spinning.) > The same is true when a thread is resumed after a safepoint (even more so > there, since a secondary thread might already be unwanted). > > Conditionally reporting activation would need to be mirrored when reporting > deactivation. > > For all those reasons, I think it should be left as is. I agree that fixing it would come with some additional logic, the current approach is very nice and simple. Given that this is on trace level I can live with the additional messages =) ------------- PR: https://git.openjdk.org/jdk/pull/10256 From shade at openjdk.org Tue Sep 27 17:31:26 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 Sep 2022 17:31:26 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 16:51:21 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. >> >> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. >> >> Some warnings didn't trigger in any file anymore, and could just be removed. >> >> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. >> >> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. >> >> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. >> >> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). >> >> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Don't need empty-body for ad_ppc.cpp now that it is globally disabled Related: hopefully eliminating `char-subscripts` warning with #10455. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From shade at openjdk.org Tue Sep 27 17:34:44 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 Sep 2022 17:34:44 GMT Subject: RFR: 8294468: Fix char-subscripts warnings in Hotspot Message-ID: There seem to be the only place in Hotspot where this warning fires, yet the warning is disabled wholesale for Hotspot. This is not good. I can trace the addition of char-subscripts exclusion to [JDK-8211029](https://bugs.openjdk.org/browse/JDK-8211029) (Sep 2018). The only place in Hotspot where in fires is present from the initial load (2007). The underlying problem that this warning tells us about is that `char` might be signed on some platforms, so we can potentially access the negative index. It is not a bug in our current code, that bounds the value of `k` under `MAXID-1`, which is `19`. Additional testing: - [ ] Linux x86_64 fastdebug `tier1` - [x] The build matrix of: - GCC 10 - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64} - {server} - {release, fastdebug} ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/10455/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10455&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294468 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10455.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10455/head:pull/10455 PR: https://git.openjdk.org/jdk/pull/10455 From rs at jelastic.com Tue Sep 27 17:47:11 2022 From: rs at jelastic.com (Ruslan Synytsky) Date: Tue, 27 Sep 2022 20:47:11 +0300 Subject: Container-aware heap sizing for OpenJDK In-Reply-To: References: Message-ID: Hi Man, thank you for the additional clarification. Now it seems a great time to get [1] and [2] implemented, so AHS can > actually converge. Are there recent prototypes for them? What are the main > problems in those prototypes? Jonathan and I could take a look and help get > them implemented. > The latest implementation of CurrentMaxHeapSize is here http://cr.openjdk.java.net/~tschatzl/jelastic/cmx/. It's only for G1. Please take a look and let us know if you have a better idea for implementation, or if we can collaborate on the existing code. Re SoftMaxHeapSize in G1 - I'm afraid no work has been done yet, but I might be wrong. Regards -- *Ruslan Synytsky *| CTO | Virtuozzo | rs at virtuozzo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlong at openjdk.org Tue Sep 27 18:13:20 2022 From: dlong at openjdk.org (Dean Long) Date: Tue, 27 Sep 2022 18:13:20 GMT Subject: RFR: 8293691: converting a defined BasicType value to a string should not crash the VM In-Reply-To: References: Message-ID: <0KRk9sCVynLv3RDDWXi6GJtKI4rbldyqwh9mtMT3iGc=.38c4ca01-d09e-4bc1-a782-2f3bc4603d2a@github.com> On Tue, 27 Sep 2022 11:21:40 GMT, Johan Sj?len wrote: > Hi, > > This implements Kim's suggested fix for this ticket. src/hotspot/share/utilities/globalDefinitions.cpp line 240: > 238: }; > 239: const char* type2name(BasicType t) { > 240: if (t < (T_CONFLICT + 1)) { Suggestion: if (t < ARRAY_SIZE(type2name_tab)) { ------------- PR: https://git.openjdk.org/jdk/pull/10447 From dlong at openjdk.org Tue Sep 27 18:22:27 2022 From: dlong at openjdk.org (Dean Long) Date: Tue, 27 Sep 2022 18:22:27 GMT Subject: RFR: 8294160: misc crash dump improvements [v2] In-Reply-To: References: Message-ID: > Try to recover and output meaningful information in more situations, such as: > - when a pointer is in Method metadata memory range, but the memory is not committed > - when we call a bad address > > When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information. Dean Long has updated the pull request incrementally with one additional commit since the last revision: revert unneeded changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10387/files - new: https://git.openjdk.org/jdk/pull/10387/files/a06a47a2..ec02ee5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10387&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10387&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10387.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10387/head:pull/10387 PR: https://git.openjdk.org/jdk/pull/10387 From dlong at openjdk.org Tue Sep 27 18:22:29 2022 From: dlong at openjdk.org (Dean Long) Date: Tue, 27 Sep 2022 18:22:29 GMT Subject: RFR: 8294160: misc crash dump improvements [v2] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 06:19:51 GMT, David Holmes wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> revert unneeded changes > > src/hotspot/share/utilities/vmError.cpp line 353: > >> 351: >> 352: // see if it's a valid frame >> 353: if (fr.sp() != nullptr && os::is_readable_pointer(fr.sp())) { > > Why did you completely change the notion of "valid frame" here? I needed for an early version of the patch, but I can remove it now. Using sp() instead of pc() could possibly give more progress on weird native frames, and is_readable_pointer() prevents some crashes during stack walking. ------------- PR: https://git.openjdk.org/jdk/pull/10387 From svkamath at openjdk.org Tue Sep 27 18:28:32 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Tue, 27 Sep 2022 18:28:32 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v10] In-Reply-To: References: Message-ID: <5Ba3iixerNzWeHZno7wPBc0tpS8pGM3-LE7JJy3kfrI=.224be6ee-8da8-43b0-8390-0d8e65e0069e@github.com> On Tue, 27 Sep 2022 13:20:51 GMT, Jatin Bhateja wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed review comments > > I have verified my other comments, we can either handle auto-vectorization of newly added intrinsic in this patch of create a follow up PR. @jatin-bhateja I will handle auto-vectorization in a follow up PR. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From dlong at openjdk.org Tue Sep 27 18:29:36 2022 From: dlong at openjdk.org (Dean Long) Date: Tue, 27 Sep 2022 18:29:36 GMT Subject: RFR: 8294160: misc crash dump improvements [v2] In-Reply-To: References: Message-ID: <3pS8F7UlVwR__31U1S3BWdZovmm0UASYXAQZYyEa5_0=.51600186-bdc0-4803-abb8-ce74683ab11d@github.com> On Tue, 27 Sep 2022 06:17:18 GMT, David Holmes wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> revert unneeded changes > > src/hotspot/os/posix/signals_posix.cpp line 629: > >> 627: // Check for UD trap caused by NOP patching. >> 628: // If it is, patch return address to be deopt handler. >> 629: if (!signal_was_handled && pc != NULL && os::is_readable_pointer(pc)) { > > If these new conditions are not met then what happens? What code will get the unreadable, or null pc to process? It will fall through and treat the signal as unhandled, resulting in a crash dump. The old code was wrong for these reasons: - It would assert in the signal handler if PC was 0 - It would crash in the signal handler if PC was not in readable memory - It ignored the previously adjusted value of PC, which means trap-based NOP patching probably wouldn't have worked on platforms that need the PC adjusted, like s390 ------------- PR: https://git.openjdk.org/jdk/pull/10387 From ihse at openjdk.org Tue Sep 27 18:35:19 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 18:35:19 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 17:27:30 GMT, Aleksey Shipilev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't need empty-body for ad_ppc.cpp now that it is globally disabled > > Related: hopefully eliminating `char-subscripts` warning with #10455. @shipilev I had hoped this PR would trigger warning hunting in Hotspot, but I did not anticipate that it would happen even before it was pushed! ;-) Let me know when you are done fixing individual warnings; there seem to be little point in integrating this until these fixes has started to slow down. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From shade at openjdk.org Tue Sep 27 18:44:19 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 Sep 2022 18:44:19 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9] In-Reply-To: References: Message-ID: <_O1386bHeagTrVI68UU0GbvMWV8XtiRE3phbjYFZ81A=.b35c61a2-af07-43f8-8fab-cb218059e465@github.com> On Tue, 27 Sep 2022 17:27:30 GMT, Aleksey Shipilev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't need empty-body for ad_ppc.cpp now that it is globally disabled > > Related: hopefully eliminating `char-subscripts` warning with #10455. > @shipilev I had hoped this PR would trigger warning hunting in Hotspot, but I did not anticipate that it would happen even before it was pushed! ;-) Let me know when you are done fixing individual warnings; there seem to be little point in integrating this until these fixes has started to slow down. Well, as I dig deeper into this mess, my PRs that fix the warnings stray away from being trivial, and build changes are a small parts of them. The actual "meat" of the patches requires review. So, I am actually thinking we should integrate this PR first, wait a little, collate possible build failures due to missing disabled warnings, adding more affected files in these declarations. It would make the actual warning fix PRs more to the point: they would have to only touch the files where warnings were specifically disabled. (The same goes for JDK-side PRs, I think) ------------- PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Tue Sep 27 19:09:25 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 Sep 2022 19:09:25 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9] In-Reply-To: <_O1386bHeagTrVI68UU0GbvMWV8XtiRE3phbjYFZ81A=.b35c61a2-af07-43f8-8fab-cb218059e465@github.com> References: <_O1386bHeagTrVI68UU0GbvMWV8XtiRE3phbjYFZ81A=.b35c61a2-af07-43f8-8fab-cb218059e465@github.com> Message-ID: On Tue, 27 Sep 2022 18:40:09 GMT, Aleksey Shipilev wrote: >> Related: hopefully eliminating `char-subscripts` warning with #10455. > >> @shipilev I had hoped this PR would trigger warning hunting in Hotspot, but I did not anticipate that it would happen even before it was pushed! ;-) Let me know when you are done fixing individual warnings; there seem to be little point in integrating this until these fixes has started to slow down. > > Well, as I dig deeper into this mess, my PRs that fix the warnings stray away from being trivial, and build changes are a small parts of them. The actual "meat" of the patches requires review. So, I am actually thinking we should integrate this PR first, wait a little, collate possible build failures due to missing disabled warnings, adding more affected files in these declarations. It would make the actual warning fix PRs more to the point: they would have to only touch the files where warnings were specifically disabled. (The same goes for JDK-side PRs, I think) @shipilev So you want me to integrate this first, and then you follow up with your fixes? ------------- PR: https://git.openjdk.org/jdk/pull/10414 From kvn at openjdk.org Tue Sep 27 20:41:24 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 27 Sep 2022 20:41:24 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 [v3] In-Reply-To: <78MJYU3qgFvL7LF5eLrljPch8hmIbBgXrJE0jm4JU8M=.d0ef0307-3699-4b30-85a1-74a374774cb3@github.com> References: <78MJYU3qgFvL7LF5eLrljPch8hmIbBgXrJE0jm4JU8M=.d0ef0307-3699-4b30-85a1-74a374774cb3@github.com> Message-ID: On Tue, 27 Sep 2022 11:08:55 GMT, AJ Ferguson wrote: >> Fix cipher state corruption when encrypting/decrypting less than 16 bytes at a time. > > AJ Ferguson has updated the pull request incrementally with one additional commit since the last revision: > > Add regression test Testing passed. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9635 From kvn at openjdk.org Tue Sep 27 20:41:24 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 27 Sep 2022 20:41:24 GMT Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V In-Reply-To: References: Message-ID: <3v5iAlfcimDqNkND28c4uNkGM-EUcqkbEjhwyIPUM8k=.e9e4a5ec-a76d-4041-af01-9f10b556b481@github.com> On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov wrote: > Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR. > > benchmark results: > > before: > > Benchmark Mode Cnt Score Error Units > DoubleClassCheck.testIsFiniteBranch avgt 15 52.824 ? 1.744 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 16.104 ? 0.358 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 14.366 ? 2.174 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 49.821 ? 0.330 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 14.702 ? 0.335 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 14.749 ? 0.496 ns/op > > after: > > DoubleClassCheck.testIsFiniteBranch avgt 15 48.921 ? 0.557 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 13.716 ? 0.304 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 9.152 ? 0.158 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 47.740 ? 2.028 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 13.299 ? 0.282 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 9.185 ? 0.396 ns/op > > Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way. > > Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues. Testing passed. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10391 From sviswanathan at openjdk.org Tue Sep 27 20:47:20 2022 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 27 Sep 2022 20:47:20 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 [v3] In-Reply-To: <78MJYU3qgFvL7LF5eLrljPch8hmIbBgXrJE0jm4JU8M=.d0ef0307-3699-4b30-85a1-74a374774cb3@github.com> References: <78MJYU3qgFvL7LF5eLrljPch8hmIbBgXrJE0jm4JU8M=.d0ef0307-3699-4b30-85a1-74a374774cb3@github.com> Message-ID: On Tue, 27 Sep 2022 11:08:55 GMT, AJ Ferguson wrote: >> Fix cipher state corruption when encrypting/decrypting less than 16 bytes at a time. > > AJ Ferguson has updated the pull request incrementally with one additional commit since the last revision: > > Add regression test Looks good to me as well. ------------- Marked as reviewed by sviswanathan (Reviewer). PR: https://git.openjdk.org/jdk/pull/9635 From duke at openjdk.org Tue Sep 27 20:52:22 2022 From: duke at openjdk.org (AJ Ferguson) Date: Tue, 27 Sep 2022 20:52:22 GMT Subject: RFR: 8292158: AES-CTR cipher state corruption with AVX-512 [v3] In-Reply-To: <78MJYU3qgFvL7LF5eLrljPch8hmIbBgXrJE0jm4JU8M=.d0ef0307-3699-4b30-85a1-74a374774cb3@github.com> References: <78MJYU3qgFvL7LF5eLrljPch8hmIbBgXrJE0jm4JU8M=.d0ef0307-3699-4b30-85a1-74a374774cb3@github.com> Message-ID: On Tue, 27 Sep 2022 11:08:55 GMT, AJ Ferguson wrote: >> Fix cipher state corruption when encrypting/decrypting less than 16 bytes at a time. > > AJ Ferguson has updated the pull request incrementally with one additional commit since the last revision: > > Add regression test Thank you for the reviews. ------------- PR: https://git.openjdk.org/jdk/pull/9635 From dholmes at openjdk.org Tue Sep 27 21:04:21 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Sep 2022 21:04:21 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: <-5Dm6rla6Uq1BWSlvsaVKXwLsbd0c2tgewPhpygfqZ0=.283a80a5-5025-4460-8ede-68a37e668764@github.com> References: <-5Dm6rla6Uq1BWSlvsaVKXwLsbd0c2tgewPhpygfqZ0=.283a80a5-5025-4460-8ede-68a37e668764@github.com> Message-ID: On Tue, 27 Sep 2022 08:01:48 GMT, Robbin Ehn wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into 8293592-JVM_StopThread >> - Removal all special handling of ThreadDeath. >> - Remove all references to the stillborn field >> - Initial commit: remove JVM_StopThread >> - Merge >> - Updates to Java Thread Primitive Deprecation page >> - Repalce "it" with "victim thread" >> - Merge >> - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop >> - become -> became in javadoc >> - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 > > Looks good, thank for fixing. Thanks @robehn and @coleenp ! ------------- PR: https://git.openjdk.org/jdk/pull/10400 From dholmes at openjdk.org Tue Sep 27 21:07:30 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Sep 2022 21:07:30 GMT Subject: Integrated: 8293592: Remove JVM_StopThread, stillborn, and related cleanup In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes wrote: > Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). > > Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. > > Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). > > Testing: tiers 1-3 This pull request has now been integrated. Changeset: 763d4bf0 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/763d4bf0749e54f74821e5155f672ed24d6f2fcd Stats: 208 lines in 18 files changed: 19 ins; 146 del; 43 mod 8293592: Remove JVM_StopThread, stillborn, and related cleanup Reviewed-by: alanb, sspitsyn, rehn, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/10400 From lmesnik at openjdk.org Tue Sep 27 21:30:26 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 27 Sep 2022 21:30:26 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. addressed review comments from Chris; added VirtualThread.java update from Alan Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10321 From lmesnik at openjdk.org Tue Sep 27 21:43:08 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 27 Sep 2022 21:43:08 GMT Subject: RFR: 8294483: Remove vmTestbase/nsk/jvmti/GetThreadState tests. Message-ID: <_Ly0VOxB3rQUksG6V-anyYLKdbTaOHBgsPBKNfteIjU=.c6adfd1f-4c4c-4fe1-a661-ed786cbdb883@github.com> Tests in the vmTestbase/nsk/jvmti/GetThreadState were ported to serviceability/jvmti/thread/GetThreadState and should be removed. ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/10457/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10457&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294483 Stats: 2417 lines in 21 files changed: 0 ins; 2417 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10457.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10457/head:pull/10457 PR: https://git.openjdk.org/jdk/pull/10457 From kbarrett at openjdk.org Tue Sep 27 21:44:27 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 27 Sep 2022 21:44:27 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 16:55:54 GMT, Stefan Johansson wrote: >> The current cards, predicted cards, and predicted time until GC are, I think, all interesting here. The point is to give some indication of what the controller is doing and why. (The activation/deactivation messages are probably less interesting now, but that's why I demoted them to trace level.) For looking at what's going on with refinement `-Xlog:gc+refine*=debug` is now the thing to use. I wouldn't want to demote the above to trace level, and only logging on changes to wanted wouldn't provide that additional detail that I found useful in making sure things were working properly. > > I agree that the other numbers are interesting, even if there is no change. Maybe the initial message could be altered depending on if we are going to update the number of threads. Or be more generic, something like: > > [20,057s][debug][gc,refine ] Concurrent refinement: wanted threads: 0, cards: 79767, predicted: 79767, time: 0,00ms Yes, that seems better. Change will be in my next push. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From kvn at openjdk.org Tue Sep 27 21:49:26 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 27 Sep 2022 21:49:26 GMT Subject: RFR: 8294483: Remove vmTestbase/nsk/jvmti/GetThreadState tests. In-Reply-To: <_Ly0VOxB3rQUksG6V-anyYLKdbTaOHBgsPBKNfteIjU=.c6adfd1f-4c4c-4fe1-a661-ed786cbdb883@github.com> References: <_Ly0VOxB3rQUksG6V-anyYLKdbTaOHBgsPBKNfteIjU=.c6adfd1f-4c4c-4fe1-a661-ed786cbdb883@github.com> Message-ID: On Tue, 27 Sep 2022 21:36:32 GMT, Leonid Mesnik wrote: > Tests in the vmTestbase/nsk/jvmti/GetThreadState were ported to serviceability/jvmti/thread/GetThreadState and should be removed. Good ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10457 From dholmes at openjdk.org Tue Sep 27 21:55:18 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Sep 2022 21:55:18 GMT Subject: RFR: 8294483: Remove vmTestbase/nsk/jvmti/GetThreadState tests. In-Reply-To: <_Ly0VOxB3rQUksG6V-anyYLKdbTaOHBgsPBKNfteIjU=.c6adfd1f-4c4c-4fe1-a661-ed786cbdb883@github.com> References: <_Ly0VOxB3rQUksG6V-anyYLKdbTaOHBgsPBKNfteIjU=.c6adfd1f-4c4c-4fe1-a661-ed786cbdb883@github.com> Message-ID: On Tue, 27 Sep 2022 21:36:32 GMT, Leonid Mesnik wrote: > Tests in the vmTestbase/nsk/jvmti/GetThreadState were ported to serviceability/jvmti/thread/GetThreadState and should be removed. Seems fine. I was very surprised to discover that these tests copied way back in 2018! Thanks for fixing. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10457 From kbarrett at openjdk.org Tue Sep 27 22:51:23 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 27 Sep 2022 22:51:23 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 20:54:37 GMT, Albert Mingkun Yang wrote: >> The number of dirty cards in thread buffers at the start of GC pause is >> exactly what this is supposed to capture. We discount the number of cards that >> can be processed in the budgeted time by this prediction to get the target >> number of cards in the queue. It's not a very accurate prediction, but it's >> still worth doing. For some applications and configurations I've tested (with >> low G1RSetUpdatingPauseTimePercent) it might be 5-10% of the target. A model >> based on the number of threads tends to do very poorly for some applications. >> >> This is entirely different from predict_dirtied_cards_rate_ms, which is a >> different value and has different uses. > > My reasoning is that #cards in the bounded thread-buffers doesn't necessarily follow a normal distribution, so one can't predict the future valuse using avg + std. Taking an extreme example of a single thread-buffer, if the population avg is ~buffer_capacity, #cards in the thread-buffer can exhibit large jumps btw 0 and ~buffer_capacity due to the implicit modulo operation. > >> It's not a very accurate prediction, but it's > still worth doing. > > Which benchmark shows its effect? I hard-coded `size_t predicted_thread_buffer_cards = 0;` in `G1Policy::record_young_collection_end` but can't see much difference. Normally, #cards in global dirty queue should be >> #cards in thread-local buffers. Here's an example log line from my development machine: [241.020s][debug][gc,ergo,refine ] GC(27) GC refinement: goal: 86449 + 8201 / 2.00ms, actual: 100607 / 2.32ms, HCC: 1024 / 0.00ms (exceeded goal) Note the cards in thread buffers prediction (8149) is approaching 10% of the goal. This is from specjbb2015 with `-Xmx40g -XX:MaxGCPauseMillis=100 -XX:G1RSetUpdatingPauseTimePercent=2` on a machine with 32 cores. specjbb2015 with default pause time and refinement budget probably won't see much impact from the cards still in buffers because the goal will be so much larger. OTOH, such a configuration also probably does very little concurrent refinement. Lest one thinks that configuration is unreasonable or unlikely, part of the point of this change is to improve the behavior with a smaller percentage of a pause budgeted for refinement. That allows more time in a pause for other things, like evacuation. (Even with that more restrictive condiguration specjbb2015 still doesn't do much concurrent refinement. For example, during the mutator phase before that GC there was never more than one refinement thread running, and it was only running for about the last 5% of the phase.) I'm using the prediction infrastructure to get a moving average over several recent samples, to get a number that has some basis. The stdev implicit in that infrastructure makes the result a bit higher than the average. I think probably doesn't matter much, as none of the inputs nor the calculations that use them are very precise. But the behavior does seem to be worse (in the sense of more frequently blowing the associated budget and by larger amounts) if this isn't accounted for to some extent. But maybe your point is more about the stddev, and that should not be included. I can see that, and could just use the moving average. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From lmesnik at openjdk.org Tue Sep 27 22:51:27 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 27 Sep 2022 22:51:27 GMT Subject: Integrated: 8294483: Remove vmTestbase/nsk/jvmti/GetThreadState tests. In-Reply-To: <_Ly0VOxB3rQUksG6V-anyYLKdbTaOHBgsPBKNfteIjU=.c6adfd1f-4c4c-4fe1-a661-ed786cbdb883@github.com> References: <_Ly0VOxB3rQUksG6V-anyYLKdbTaOHBgsPBKNfteIjU=.c6adfd1f-4c4c-4fe1-a661-ed786cbdb883@github.com> Message-ID: On Tue, 27 Sep 2022 21:36:32 GMT, Leonid Mesnik wrote: > Tests in the vmTestbase/nsk/jvmti/GetThreadState were ported to serviceability/jvmti/thread/GetThreadState and should be removed. This pull request has now been integrated. Changeset: f8d9fa88 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/f8d9fa88735d8451108a0664990b8fc7409338e9 Stats: 2417 lines in 21 files changed: 0 ins; 2417 del; 0 mod 8294483: Remove vmTestbase/nsk/jvmti/GetThreadState tests. Reviewed-by: kvn, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/10457 From kbarrett at openjdk.org Tue Sep 27 23:07:20 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 27 Sep 2022 23:07:20 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: <0ImHXzJG6wYi0mfenmh1DWbS2xGIxOAsTHnxOULtZig=.79f84783-963c-4fbd-aef2-c9baee486e9a@github.com> On Tue, 27 Sep 2022 11:33:05 GMT, Thomas Schatzl wrote: >> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision: >> >> - wanted vs needed nomenclature >> - remove several spurious "scan" >> - delay => wait_time_ms > > src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 77: > >> 75: } else { >> 76: delete t; >> 77: } > > Not sure this early-bail out is necessary; C++ seems to define `nullptr` values passed to `delete` well enough (https://en.cppreference.com/w/cpp/language/delete) to skip this complication. > Feel free to ignore. The assert that nothing strange has happened is part of the point here. And there could be lots of thread entries on a sufficiently large machine. > src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 219: > >> 217: // Deduct predicted cards in thread buffers to get target. >> 218: size_t new_target = budget - MIN2(budget, predicted_thread_buffer_cards); >> 219: // Add some hysterisis with previous values. > > Suggestion: > > // Add some hysteresis with previous values. Done. > src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 233: > >> 231: size_t predicted_thread_buffer_cards, >> 232: double goal_ms) { >> 233: if (!G1UseConcRefinement) return; > > I would prefer either braces or an additional newline after this statement. When initially reading this I thought there were some indentation error. Done. > src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 198: > >> 196: void reduce_threads_wanted(); >> 197: >> 198: // Test whethre the thread designated by worker_id should be active. > > s/whethre/whether Done. > src/hotspot/share/gc/g1/g1ConcurrentRefineThreadsNeeded.cpp line 44: > >> 42: // Estimate how many concurrent refinement threads we need to run to achieve >> 43: // the target number of card by the time the next GC happens. There are >> 44: // several additional desirements we'd like to achieve while meeting that > > According to https://en.wiktionary.org/wiki/desirement this is defined as > > Something that is [desired](https://en.wiktionary.org/wiki/desired), but not absolutely required. > > (This word was new to me). > > I think that "desirements" already includes the phrase "we'd like to achieve". I.e. something that is desired, but is not absolutely required is already something "we'd like to achieve". > > So I would like to suggest to either remove the phrase "we'd like to achieve" or reformulate the sentence as "... several additional/secondary goals we would like to achieve while meeting that (main) goal". Done. Using "secondary goals". > src/hotspot/share/gc/g1/g1ConcurrentRefineThreadsNeeded.cpp line 79: > >> 77: // Estimate number of cards that need to be processed before next GC. There >> 78: // are no incoming cards when time is short, because the controller activates >> 79: // refinement by mutator threads when there to a GC, to stay on target even > > "refinement by mutator threads when there to a GC" I do not understand this part of the sentence, what does "there to a gc" mean? > > Maybe this should means: > > "..., because in this case the controller activates refinement by mutator threads to stay on target even..." Done. Something like that was intended. Not sure what happened, maybe I got interrupted in the middle of editing. > src/hotspot/share/gc/g1/g1ConcurrentRefineThreadsNeeded.cpp line 116: > >> 114: // excess cards to process. Just one thread might not be sufficient, but >> 115: // we don't have any idea how many we actually need. Eventually the >> 116: // prediction machinary will warm up and we'll be able to get estimates. > > s/machinary/machinery Done. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From mernst at openjdk.org Tue Sep 27 23:16:16 2022 From: mernst at openjdk.org (Michael Ernst) Date: Tue, 27 Sep 2022 23:16:16 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> References: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> Message-ID: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com> On Mon, 26 Sep 2022 19:36:02 GMT, Lance Andersen wrote: > Thank you for your efforts on the cleaning up these typos > > I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review. > > I realize the changes are fairly trivial but this will most likely expedite getting your changes back Feel free to break up the pull request if that is what is needed to free it from red tape. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From dholmes at openjdk.org Tue Sep 27 23:46:15 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Sep 2022 23:46:15 GMT Subject: RFR: 8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications [v4] In-Reply-To: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com> References: <5LZVfXnTpbyr_NWeYid9qzKrnZ6t2b7ZL5BtHEZ4Syc=.bff15db2-726a-4976-89f1-edd826d75bf2@github.com> Message-ID: On Tue, 20 Sep 2022 10:37:41 GMT, David Holmes wrote: >> This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref: >> >> JDK-8290196 12.8: Clarify the definition of program exit >> https://bugs.openjdk.org/browse/JDK-8290196 >> >> JDK-8290388 5.7: Clarify the definition of JVM termination >> https://bugs.openjdk.org/browse/JDK-8290388 >> >> JDK-8290036 Define and specify Runtime shutdown sequence >> https://bugs.openjdk.org/browse/JDK-8290036 >> >> Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes: >> >> 1. The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this) >> >> 2. We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot. >> >> Issue 2 covers the code change, and regression test, in this PR. >> >> In addition the specification changes can be seen here: >> >> - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html >> - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html >> - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html >> >> The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment. >> >> Thank you. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix JniVersion test CSR is now approved. ------------- PR: https://git.openjdk.org/jdk/pull/10352 From dholmes at openjdk.org Wed Sep 28 00:01:58 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Sep 2022 00:01:58 GMT Subject: Integrated: 8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 00:55:32 GMT, David Holmes wrote: > This update is primarily about changes to the JNI Invocation API specification, mainly in relation to `DestroyJavaVM`. The motivation for the changes is to align with changes being made to the JLS, JVMS and `java.lang.Runtime`, specifications in relation to VM termination - ref: > > JDK-8290196 12.8: Clarify the definition of program exit > https://bugs.openjdk.org/browse/JDK-8290196 > > JDK-8290388 5.7: Clarify the definition of JVM termination > https://bugs.openjdk.org/browse/JDK-8290388 > > JDK-8290036 Define and specify Runtime shutdown sequence > https://bugs.openjdk.org/browse/JDK-8290036 > > Mostly these are just non-normative changes to the JNI spec prose but there are two actual specification changes: > > 1. The fact it is an error to detach a thread with active Java frames was only mentioned in the overview section, not in the actual `DetachCurrentThread` specification. (Just an oversight - the VM already checked this) > > 2. We need to make it an error to call `DestroyJavaVM` from an attached thread with active Java frames (as this can't work for the same reason we disallow `DetachCurrentThread`). This requires an implementation change in Hotspot. > > Issue 2 covers the code change, and regression test, in this PR. > > In addition the specification changes can be seen here: > > - specdiff: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/diff.html > - original: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-original.html > - new: http://cr.openjdk.java.net/~dholmes/8290482/8290482-jni-spec/jni-invocation-new.html > > The specification itself is not open but comments on the spec changes are welcome - though please see the JBS issue and CSR request first. The revised wording has already been extensively reviewed/negotiated between Alex Buckley, Stuart Marks and myself, so any change must either be a glaring error/problem or else a trivial adjustment. > > Thank you. This pull request has now been integrated. Changeset: e5b65c40 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/e5b65c40ea032c6955311593e02ed44f14dfe80a Stats: 112 lines in 6 files changed: 108 ins; 1 del; 3 mod 8290482: Update JNI Specification of DestroyJavaVM for better alignment with JLS, JVMS, and Java SE API Specifications Reviewed-by: rehn, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/10352 From duke at openjdk.org Wed Sep 28 00:16:26 2022 From: duke at openjdk.org (AJ Ferguson) Date: Wed, 28 Sep 2022 00:16:26 GMT Subject: Integrated: 8292158: AES-CTR cipher state corruption with AVX-512 In-Reply-To: References: Message-ID: <_cndDEQ6XuzgQ0TQJfnKOPebwBWm77xFLauHZLUW8sI=.3feceb0b-a926-42f9-9d81-820bfd0cb21d@github.com> On Tue, 26 Jul 2022 03:12:10 GMT, AJ Ferguson wrote: > Fix cipher state corruption when encrypting/decrypting less than 16 bytes at a time. This pull request has now been integrated. Changeset: 9d76ac8a Author: AJ Ferguson Committer: Sandhya Viswanathan URL: https://git.openjdk.org/jdk/commit/9d76ac8a4453bc51d9dca2ad6c60259cfb2c4203 Stats: 99 lines in 2 files changed: 98 ins; 0 del; 1 mod 8292158: AES-CTR cipher state corruption with AVX-512 Reviewed-by: kvn, svkamath, sviswanathan ------------- PR: https://git.openjdk.org/jdk/pull/9635 From fyang at openjdk.org Wed Sep 28 00:23:19 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 28 Sep 2022 00:23:19 GMT Subject: RFR: 8294430: RISC-V: Small refactoring for movptr_with_offset In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 07:20:11 GMT, Fei Yang wrote: > The name of function 'movptr_with_offset' looks misleading. It actually returns an offset to its caller. > We could rename this function to 'movptr' so that it overloads existing function 'movptr'. > > > void movptr(Register Rd, address addr); > - void movptr_with_offset(Register Rd, address addr, int32_t &offset); > + void movptr(Register Rd, address addr, int32_t &offset); > > > Testing: Tier1 hotspot on HiFive Linux-riscv64 Unmatched board. @All: Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/10439 From fyang at openjdk.org Wed Sep 28 00:26:09 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 28 Sep 2022 00:26:09 GMT Subject: Integrated: 8294430: RISC-V: Small refactoring for movptr_with_offset In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 07:20:11 GMT, Fei Yang wrote: > The name of function 'movptr_with_offset' looks misleading. It actually returns an offset to its caller. > We could rename this function to 'movptr' so that it overloads existing function 'movptr'. > > > void movptr(Register Rd, address addr); > - void movptr_with_offset(Register Rd, address addr, int32_t &offset); > + void movptr(Register Rd, address addr, int32_t &offset); > > > Testing: Tier1 hotspot on HiFive Linux-riscv64 Unmatched board. This pull request has now been integrated. Changeset: d827fd83 Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/d827fd830afda58e30b667e61fc4653423db9d39 Stats: 28 lines in 10 files changed: 0 ins; 2 del; 26 mod 8294430: RISC-V: Small refactoring for movptr_with_offset Reviewed-by: fjiang, yadongwang, shade ------------- PR: https://git.openjdk.org/jdk/pull/10439 From dholmes at openjdk.org Wed Sep 28 01:19:07 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Sep 2022 01:19:07 GMT Subject: RFR: 8292016: Split Windows API error handling from errors passed through the runtime in the JDK [v22] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 16:14:43 GMT, Julian Waters wrote: > Are any of these a part of the public JNI API? No this is all internal-use-only ------------- PR: https://git.openjdk.org/jdk/pull/9870 From dholmes at openjdk.org Wed Sep 28 01:28:05 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Sep 2022 01:28:05 GMT Subject: RFR: 8294160: misc crash dump improvements [v2] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 18:22:27 GMT, Dean Long wrote: >> Try to recover and output meaningful information in more situations, such as: >> - when a pointer is in Method metadata memory range, but the memory is not committed >> - when we call a bad address >> >> When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > revert unneeded changes src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp line 357: > 355: // point to garbage if entry point in an nmethod is corrupted. Leave > 356: // this at the end, and hope for the best. > 357: address pc = os::fetch_frame_from_context(uc).pc(); What is the difference between `ucontext_get_pc(uc)` and getting the pc from the frame from the uc? How many pc's can a ucontext have? ------------- PR: https://git.openjdk.org/jdk/pull/10387 From dholmes at openjdk.org Wed Sep 28 01:50:40 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Sep 2022 01:50:40 GMT Subject: RFR: 8294293: Remove unused _width and _newlines field in outputStream [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 08:44:44 GMT, Johan Sj?len wrote: >> 1. `_width` is unused so I deleted it >> 2. `_newlines` was used in one place, and only to check if any new lines had been seen. I removed `_newlines` and instead used `update_position`'s unused return value to indicate whether any newlines has been seen. This required expanding the call of `xmlTextStream::write` in `defaultStream`. >> >> This removes some cruft from `outputStream` and saves us 8 bytes on the size of `outputStream`. >> >> I also noted that `_position` isn't number of chars into a line, but rather a "visual position". It's a bit surprising, which is why I added this comment. This can be seen in the `\t` case in `update_position`. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Remove include Okay this seems reasonable. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10411 From dholmes at openjdk.org Wed Sep 28 01:50:40 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Sep 2022 01:50:40 GMT Subject: RFR: 8294293: Remove unused _width and _newlines field in outputStream [v2] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 07:23:18 GMT, Johan Sj?len wrote: >> I'm confused by this part of the change. How can the original code call `xmlTextStream::write` without an instance of `xmlTextStream` to apply it to??? > > `defaultStream` inherits from `xmlTextStream` and `defaultStream::write` exists, so this specifies to call the superclass method, and not its own method. In long form: `this->xmlTextStream::write` (haven't attempted to compile) Ah! Thanks - I had missed this code was in `defaultStream`. It seems a bit klunky to break encapsulation and effectively inline the super write() call so that we can get access to whether a newline was seen - but monitoring `_newlines` across the write call is at least as bad. I guess this is the problem of trying to have a flushable stream extend a non-flushable superclass - you somehow need to see inside the write to know if there were newlines. The new code at least saves the need for the field. ------------- PR: https://git.openjdk.org/jdk/pull/10411 From dholmes at openjdk.org Wed Sep 28 02:12:20 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Sep 2022 02:12:20 GMT Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 10:28:54 GMT, Aleksey Shipilev wrote: > There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good. > > C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check. > > Build-tested this with product of: > - GCC 10 > - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64} > - {server, zero} > - {release, fastdebug} > > Linux x86_64 fastdebug `tier1` is fine. Changes look good! That C1 code is very strangely written! Thanks src/hotspot/share/classfile/javaClasses.cpp line 3926: > 3924: if (k == NULL) return NULL; > 3925: InstanceKlass* ik = InstanceKlass::cast(k); > 3926: if (!ik->is_initialized()) ik->initialize(CHECK_NULL); That's actually a bug! ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10444 From dholmes at openjdk.org Wed Sep 28 02:27:22 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Sep 2022 02:27:22 GMT Subject: RFR: 8294468: Fix char-subscripts warnings in Hotspot In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 17:27:03 GMT, Aleksey Shipilev wrote: > There seem to be the only place in Hotspot where this warning fires, yet the warning is disabled wholesale for Hotspot. This is not good. > > I can trace the addition of char-subscripts exclusion to [JDK-8211029](https://bugs.openjdk.org/browse/JDK-8211029) (Sep 2018). The only place in Hotspot where in fires is present from the initial load (2007). > > The underlying problem that this warning tells us about is that `char` might be signed on some platforms, so we can potentially access the negative index. It is not a bug in our current code, that bounds the value of `k` under `MAXID-1`, which is `19`. > > Additional testing: > - [ ] Linux x86_64 fastdebug `tier1` > - [x] The build matrix of: > - GCC 10 > - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64} > - {server} > - {release, fastdebug} Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10455 From haosun at openjdk.org Wed Sep 28 02:47:25 2022 From: haosun at openjdk.org (Hao Sun) Date: Wed, 28 Sep 2022 02:47:25 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 16:51:21 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. >> >> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. >> >> Some warnings didn't trigger in any file anymore, and could just be removed. >> >> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. >> >> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. >> >> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. >> >> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). >> >> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Don't need empty-body for ad_ppc.cpp now that it is globally disabled make/hotspot/lib/CompileJvm.gmk line 162: > 160: DISABLED_WARNINGS_gcc_postaloc.cpp := address, \ > 161: DISABLED_WARNINGS_gcc_sharedRuntimeTrig.cpp := misleading-indentation, \ > 162: DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_aarch64.cpp := misleading-indentation, \ Suggestion: DISABLED_WARNINGS_gcc_shenandoahBarrierSet.cpp := misleading-indentation, \ DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_aarch64.cpp := misleading-indentation, \ I got the following warning for `client` build, i.e. `--disable-precompiled-headers --with-debug-level=release --with-jvm-variants=client`. === Output from failing command(s) repeated here === * For target hotspot_variant-client_libjvm_objs_shenandoahBarrierSet.o: In file included from /tmp/jdk-test/jdk_src/src/hotspot/share/gc/shenandoah/henandoahBarrierSet.cpp:34: ------------- PR: https://git.openjdk.org/jdk/pull/10414 From dlong at openjdk.org Wed Sep 28 04:06:21 2022 From: dlong at openjdk.org (Dean Long) Date: Wed, 28 Sep 2022 04:06:21 GMT Subject: RFR: 8294160: misc crash dump improvements [v2] In-Reply-To: References: Message-ID: <2yNRptjzAcFlrRBBJVGxiQYvPB2WvS8FQZVlfYxesVs=.3e37f094-4e37-4090-a7de-6920ed2ac521@github.com> On Wed, 28 Sep 2022 01:24:34 GMT, David Holmes wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> revert unneeded changes > > src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp line 357: > >> 355: // point to garbage if entry point in an nmethod is corrupted. Leave >> 356: // this at the end, and hope for the best. >> 357: address pc = os::fetch_frame_from_context(uc).pc(); > > What is the difference between `ucontext_get_pc(uc)` and getting the pc from the frame from the uc? How many pc's can a ucontext have? The former returns the PC where the crash happened, which could be in unreadable memory. Blindly inspecting that memory will cause error reporting to crash. The latter returns the PC of a frame constructed from the context, and _possibly adjusted to reflect where the caller was when it made the bad call_, which is more useful for getting stack backtraces and less likely to crash error reporting. When error reporting crashes we recover, but we don't get the information it was dumping when it crashed. ------------- PR: https://git.openjdk.org/jdk/pull/10387 From dholmes at openjdk.org Wed Sep 28 04:27:25 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Sep 2022 04:27:25 GMT Subject: RFR: 8294160: misc crash dump improvements [v2] In-Reply-To: References: Message-ID: <4g49q1iwkeMPS34OR_y3w4iV0o4J6OvcStEUWz2jSec=.61b0a015-4369-4116-8f40-575072ec5588@github.com> On Tue, 27 Sep 2022 18:22:27 GMT, Dean Long wrote: >> Try to recover and output meaningful information in more situations, such as: >> - when a pointer is in Method metadata memory range, but the memory is not committed >> - when we call a bad address >> >> When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > revert unneeded changes Okay seems quite reasonable. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10387 From sspitsyn at openjdk.org Wed Sep 28 04:45:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Sep 2022 04:45:22 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. addressed review comments from Chris; added VirtualThread.java update from Alan Thank you for review, Leonid! ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Wed Sep 28 04:48:14 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Sep 2022 04:48:14 GMT Subject: Integrated: 8293613: need to properly handle and hide tmp VTMS transitions In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 09:13:11 GMT, Serguei Spitsyn wrote: > There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. > > There are a couple of details of this fix to highlight: > - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. > - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. > - Suspending threads in temporary transition is allowed. > > The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. This pull request has now been integrated. Changeset: 79ccc791 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/79ccc791f275be7cfea95ff0ce8cf7361c7f08ad Stats: 148 lines in 10 files changed: 80 ins; 3 del; 65 mod 8293613: need to properly handle and hide tmp VTMS transitions Reviewed-by: cjplummer, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/10321 From haosun at openjdk.org Wed Sep 28 05:34:30 2022 From: haosun at openjdk.org (Hao Sun) Date: Wed, 28 Sep 2022 05:34:30 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 16:51:21 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. >> >> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. >> >> Some warnings didn't trigger in any file anymore, and could just be removed. >> >> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. >> >> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. >> >> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. >> >> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). >> >> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Don't need empty-body for ad_ppc.cpp now that it is globally disabled I tried multiple build modes on both x86-64 and aarch64 with GCC-11 and GCC-12, and found these two issues. make/hotspot/lib/CompileJvm.gmk line 160: > 158: DISABLED_WARNINGS_gcc_javaClasses.cpp := misleading-indentation, \ > 159: DISABLED_WARNINGS_gcc_loopnode.cpp := sequence-point, \ > 160: DISABLED_WARNINGS_gcc_postaloc.cpp := address, \ Suggestion: DISABLED_WARNINGS_gcc_cgroupV1Subsystem_linux.cpp := address, \ DISABLED_WARNINGS_gcc_cgroupV2Subsystem_linux.cpp := address, \ DISABLED_WARNINGS_gcc_postaloc.cpp := address, \ I got the following warning for `release` build with `gcc-12`. === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_objs_cgroupV1Subsystem_linux.o: ------------- PR: https://git.openjdk.org/jdk/pull/10414 From shade at openjdk.org Wed Sep 28 05:51:22 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Sep 2022 05:51:22 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9] In-Reply-To: <_O1386bHeagTrVI68UU0GbvMWV8XtiRE3phbjYFZ81A=.b35c61a2-af07-43f8-8fab-cb218059e465@github.com> References: <_O1386bHeagTrVI68UU0GbvMWV8XtiRE3phbjYFZ81A=.b35c61a2-af07-43f8-8fab-cb218059e465@github.com> Message-ID: <8_QnRLL5eeb5Q4cakU-l_ObzMzoiwFAde2FQAYajDB0=.7b0c57a4-e9b1-4c9c-8227-db2dda134839@github.com> On Tue, 27 Sep 2022 18:40:09 GMT, Aleksey Shipilev wrote: >> Related: hopefully eliminating `char-subscripts` warning with #10455. > >> @shipilev I had hoped this PR would trigger warning hunting in Hotspot, but I did not anticipate that it would happen even before it was pushed! ;-) Let me know when you are done fixing individual warnings; there seem to be little point in integrating this until these fixes has started to slow down. > > Well, as I dig deeper into this mess, my PRs that fix the warnings stray away from being trivial, and build changes are a small parts of them. The actual "meat" of the patches requires review. So, I am actually thinking we should integrate this PR first, wait a little, collate possible build failures due to missing disabled warnings, adding more affected files in these declarations. It would make the actual warning fix PRs more to the point: they would have to only touch the files where warnings were specifically disabled. (The same goes for JDK-side PRs, I think) > @shipilev So you want me to integrate this first, and then you follow up with your fixes? Yes, I think that would be better. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From njian at openjdk.org Wed Sep 28 05:59:01 2022 From: njian at openjdk.org (Ningsheng Jian) Date: Wed, 28 Sep 2022 05:59:01 GMT Subject: RFR: 8294261: AArch64: Use pReg instead of pRegGov when possible Message-ID: Currently we allocate SVE predicate register p0-p6 for pRegGov operand, which are used as governing predicates for load/store and arithmetic, and also define pReg operand for all allocatable predicate registers. Since some SVE instructions are fine to use/define p8-p15, e.g. predicate operations, this patch makes the matcher work for mixed use of pRegGov and pReg, and tries to match pReg when possible. If a predicate reg is defined as pReg but used as pRegGov, register allocator will handle that properly. With p8-p15 being used as non-temp register, we need to save them as well when saving all registers. The code of setting predicate reg slot in OopMap in RegisterSaver::save_live_registers() is also removed, because on safepoint, vector masks have been transformed to vector [1]. Tested on different SVE systems. Also tested with making RA to allocate p8-p15 first for vReg operand, so that a p8-p15 reg has more chance to be allocated, and if an SVE instruction, emitted by ad rule, does not accept p8-p5, assembler will crash. [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/vector.cpp#L265 ------------- Commit messages: - 8294261: AArch64: Use pReg instead of pRegGov when possible Changes: https://git.openjdk.org/jdk/pull/10461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10461&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294261 Stats: 103 lines in 6 files changed: 6 ins; 17 del; 80 mod Patch: https://git.openjdk.org/jdk/pull/10461.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10461/head:pull/10461 PR: https://git.openjdk.org/jdk/pull/10461 From shade at openjdk.org Wed Sep 28 06:04:19 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Sep 2022 06:04:19 GMT Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot In-Reply-To: References: Message-ID: <8ksRN6s9BNy3_UfKNaBHVXYjhghjZ23c6zyRA5rGMF8=.a17888df-486c-466e-a8ca-5bf2775ddd73@github.com> On Wed, 28 Sep 2022 02:06:44 GMT, David Holmes wrote: >> There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good. >> >> C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check. >> >> Build-tested this with product of: >> - GCC 10 >> - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64} >> - {server, zero} >> - {release, fastdebug} >> >> Linux x86_64 fastdebug `tier1` is fine. > > src/hotspot/share/classfile/javaClasses.cpp line 3926: > >> 3924: if (k == NULL) return NULL; >> 3925: InstanceKlass* ik = InstanceKlass::cast(k); >> 3926: if (!ik->is_initialized()) ik->initialize(CHECK_NULL); > > That's actually a bug! How is this a bu... ah. Oh! The second statement from `CHECK_NULL` is effectively out of `if (!ik->is_initialized())` block! ------------- PR: https://git.openjdk.org/jdk/pull/10444 From xlinzheng at openjdk.org Wed Sep 28 06:34:58 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 28 Sep 2022 06:34:58 GMT Subject: RFR: 8294366: RISC-V: RVC: Partially mark out incompressible regions Message-ID: <7aIMgQ7ci4WeF_NN0WAc5e5WwgUOYochPsDaW6a5P0Q=.d9d035be-958f-4c00-916f-1dc45fad6c0e@github.com> Shortly, the current RVC implementation in the RISC-V backend is a "whitelist mode", merely compressing instructions marked by "CompressibleRegion" that covers just part of C2 matching rules and stub code (only ~5% compression rate). Due to the originally existing large backend code base and to spread the coverage to nearly all instructions generated by the backend, we cannot modify them little by little, but should implement a "blacklist mode" (a compression rate to ~20% if complete), to exclude compressions from: 1. relocations 2. patchable instructions 3. fixed length code slices whose code size is calculated Please check the discussions in the riscv-port mailing list[1] to go in for more details. This patch contains the first half of implementations which does not change the program behavior: it just introduces an "IncompressibleRegion" to indicate a piece of code "not compressible", marking out the patchable instructions and fixed-length code slices that are not able to compress by RVC. Besides, this patch also temporarily removes some automatic compression logic of branch instructions like "jal"s and "beq"s, for MachBranchNodes' fake labels could hamper the automatic compression as well and for making code clean. Please also check the discussions in the thread[1]. Please check the unsquashed commits to have a better review of the patch. Tested a hotspot tier1 and tier2 with the option UseRVC turning on. [1] https://mail.openjdk.org/pipermail/riscv-port-dev/2022-September/000615.html Thanks, Xiaolin ------------- Commit messages: - [5] RVC: IncompressibleRegions for patchable labels - [4] RVC: IncompressibleRegions for fixed length code slices - [3] RVC: IncompressibleRegions for patchable nops - [2] RVC: Disable auto transformations for branch instructions - [1] RVC: Add the IncompressibleRegion Changes: https://git.openjdk.org/jdk/pull/10421/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10421&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294366 Stats: 93 lines in 9 files changed: 42 ins; 35 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/10421.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10421/head:pull/10421 PR: https://git.openjdk.org/jdk/pull/10421 From xlinzheng at openjdk.org Wed Sep 28 06:37:06 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 28 Sep 2022 06:37:06 GMT Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites Message-ID: A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them. This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before. Originally some non-patchable callsites: ;; 0x401ab1dc40 0x000000401372b324: lui t0,0x201 0x000000401372b328: addi t0,t0,-680 # 0x0000000000200d58 0x000000401372b32c: slli t0,t0,0xb 0x000000401372b32e: addi t0,t0,1905 0x000000401372b332: slli t0,t0,0x6 0x000000401372b334: jalr t0 Now: 0x000000401b2bd9f4: lui t0,0x4003 0x000000401b2bd9f8: addiw t0,t0,-1275 0x000000401b2bd9fc: slli t0,t0,0xc 0x000000401b2bda00: jalr 1080(t0) # 0x0000000004003438 Not so much, but the main purpose is to clarify the usage of movptr and li. The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1. ------------- Commit messages: - Further - Further cleanup - Change Non-patchable movptr to li, for movptr is defined implicitly for patchable usages Changes: https://git.openjdk.org/jdk/pull/10462/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294492 Stats: 75 lines in 8 files changed: 29 ins; 15 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/10462.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10462/head:pull/10462 PR: https://git.openjdk.org/jdk/pull/10462 From dlong at openjdk.org Wed Sep 28 06:41:30 2022 From: dlong at openjdk.org (Dean Long) Date: Wed, 28 Sep 2022 06:41:30 GMT Subject: RFR: 8294160: misc crash dump improvements [v2] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 18:22:27 GMT, Dean Long wrote: >> Try to recover and output meaningful information in more situations, such as: >> - when a pointer is in Method metadata memory range, but the memory is not committed >> - when we call a bad address >> >> When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > revert unneeded changes Thanks David. ------------- PR: https://git.openjdk.org/jdk/pull/10387 From xlinzheng at openjdk.org Wed Sep 28 06:58:15 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 28 Sep 2022 06:58:15 GMT Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites [v2] In-Reply-To: References: Message-ID: > A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them. > > This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before. > > Originally some non-patchable callsites: > > ;; 0x401ab1dc40 > 0x000000401372b324: lui t0,0x201 > 0x000000401372b328: addi t0,t0,-680 # 0x0000000000200d58 > 0x000000401372b32c: slli t0,t0,0xb > 0x000000401372b32e: addi t0,t0,1905 > 0x000000401372b332: slli t0,t0,0x6 > 0x000000401372b334: jalr t0 > > Now: > > 0x000000401b2bd9f4: lui t0,0x4003 > 0x000000401b2bd9f8: addiw t0,t0,-1275 > 0x000000401b2bd9fc: slli t0,t0,0xc > 0x000000401b2bda00: jalr 1080(t0) # 0x0000000004003438 > > Not so much, but the main purpose is to clarify the usage of movptr and li. > > The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1. Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10462/files - new: https://git.openjdk.org/jdk/pull/10462/files/62cf62ca..ad15d6b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10462.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10462/head:pull/10462 PR: https://git.openjdk.org/jdk/pull/10462 From ihse at openjdk.org Wed Sep 28 07:39:31 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Sep 2022 07:39:31 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v10] In-Reply-To: References: Message-ID: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Add misleading-indentation for client (thanks @shqking) Co-authored-by: Hao Sun ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/36ab7010..7b281f97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=08-09 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Wed Sep 28 07:39:33 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Sep 2022 07:39:33 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 02:41:51 GMT, Hao Sun wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't need empty-body for ad_ppc.cpp now that it is globally disabled > > make/hotspot/lib/CompileJvm.gmk line 162: > >> 160: DISABLED_WARNINGS_gcc_postaloc.cpp := address, \ >> 161: DISABLED_WARNINGS_gcc_sharedRuntimeTrig.cpp := misleading-indentation, \ >> 162: DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_aarch64.cpp := misleading-indentation, \ > > Suggestion: > > DISABLED_WARNINGS_gcc_shenandoahBarrierSet.cpp := misleading-indentation, \ > DISABLED_WARNINGS_gcc_shenandoahBarrierSetAssembler_aarch64.cpp := misleading-indentation, \ > > > I got the following warning for `client` build, i.e. `--disable-precompiled-headers --with-debug-level=release --with-jvm-variants=client`. > > === Output from failing command(s) repeated here === > * For target hotspot_variant-client_libjvm_objs_shenandoahBarrierSet.o: > In file included from /tmp/jdk-test/jdk_src/src/hotspot/share/gc/shenandoah/henandoahBarrierSet.cpp:34: Oh, client builds! I forgot about those. Thanks for reminding me. I'll test the full set of JVM variants as well. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Wed Sep 28 07:41:57 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Sep 2022 07:41:57 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v11] In-Reply-To: References: Message-ID: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: add address for cgroupV1Subsystem_linux.cpp (thanks @shqking) Co-authored-by: Hao Sun ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/7b281f97..89168078 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=09-10 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Wed Sep 28 07:41:57 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Sep 2022 07:41:57 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9] In-Reply-To: References: Message-ID: <4AJHQkMVyof_z0nSQAoT00jXgnPD0DKYC3u3RFcoLws=.b7ae1bd2-f0a4-45fe-84c0-ab49f6e39633@github.com> On Wed, 28 Sep 2022 04:37:03 GMT, Hao Sun wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't need empty-body for ad_ppc.cpp now that it is globally disabled > > make/hotspot/lib/CompileJvm.gmk line 160: > >> 158: DISABLED_WARNINGS_gcc_javaClasses.cpp := misleading-indentation, \ >> 159: DISABLED_WARNINGS_gcc_loopnode.cpp := sequence-point, \ >> 160: DISABLED_WARNINGS_gcc_postaloc.cpp := address, \ > > Suggestion: > > DISABLED_WARNINGS_gcc_cgroupV1Subsystem_linux.cpp := address, \ > DISABLED_WARNINGS_gcc_cgroupV2Subsystem_linux.cpp := address, \ > DISABLED_WARNINGS_gcc_postaloc.cpp := address, \ > > > I got the following warning for `release` build with `gcc-12`. > > === Output from failing command(s) repeated here === > * For target hotspot_variant-server_libjvm_objs_cgroupV1Subsystem_linux.o: I'm just curious: do you remember what you used to provoke this warning? ------------- PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Wed Sep 28 07:49:19 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Sep 2022 07:49:19 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v12] In-Reply-To: References: Message-ID: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: TESTING: enable all variants ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/89168078..58083856 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=10-11 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From haosun at openjdk.org Wed Sep 28 07:50:34 2022 From: haosun at openjdk.org (Hao Sun) Date: Wed, 28 Sep 2022 07:50:34 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v9] In-Reply-To: <4AJHQkMVyof_z0nSQAoT00jXgnPD0DKYC3u3RFcoLws=.b7ae1bd2-f0a4-45fe-84c0-ab49f6e39633@github.com> References: <4AJHQkMVyof_z0nSQAoT00jXgnPD0DKYC3u3RFcoLws=.b7ae1bd2-f0a4-45fe-84c0-ab49f6e39633@github.com> Message-ID: On Wed, 28 Sep 2022 07:38:56 GMT, Magnus Ihse Bursie wrote: >> make/hotspot/lib/CompileJvm.gmk line 160: >> >>> 158: DISABLED_WARNINGS_gcc_javaClasses.cpp := misleading-indentation, \ >>> 159: DISABLED_WARNINGS_gcc_loopnode.cpp := sequence-point, \ >>> 160: DISABLED_WARNINGS_gcc_postaloc.cpp := address, \ >> >> Suggestion: >> >> DISABLED_WARNINGS_gcc_cgroupV1Subsystem_linux.cpp := address, \ >> DISABLED_WARNINGS_gcc_cgroupV2Subsystem_linux.cpp := address, \ >> DISABLED_WARNINGS_gcc_postaloc.cpp := address, \ >> >> >> I got the following warning for `release` build with `gcc-12`. >> >> === Output from failing command(s) repeated here === >> * For target hotspot_variant-server_libjvm_objs_cgroupV1Subsystem_linux.o: > > I'm just curious: do you remember what you used to provoke this warning? It's the `release` build with `gcc-12` version on Ubuntu 22.04. See the configuration as below. ==================================================== A new configuration has been successfully created in ------------- PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Wed Sep 28 08:01:28 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Sep 2022 08:01:28 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v13] In-Reply-To: References: Message-ID: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: TESTING GHA v2: Previous attempt was botched ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/58083856..4a51a15c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=11-12 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Wed Sep 28 08:03:21 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Sep 2022 08:03:21 GMT Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot In-Reply-To: <8ksRN6s9BNy3_UfKNaBHVXYjhghjZ23c6zyRA5rGMF8=.a17888df-486c-466e-a8ca-5bf2775ddd73@github.com> References: <8ksRN6s9BNy3_UfKNaBHVXYjhghjZ23c6zyRA5rGMF8=.a17888df-486c-466e-a8ca-5bf2775ddd73@github.com> Message-ID: On Wed, 28 Sep 2022 06:00:43 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 3926: >> >>> 3924: if (k == NULL) return NULL; >>> 3925: InstanceKlass* ik = InstanceKlass::cast(k); >>> 3926: if (!ik->is_initialized()) ik->initialize(CHECK_NULL); >> >> That's actually a bug! > > How is this a bu... ah. Oh! The second statement from `CHECK_NULL` is effectively out of `if (!ik->is_initialized())` block! Two, and counting. :-) ------------- PR: https://git.openjdk.org/jdk/pull/10444 From haosun at openjdk.org Wed Sep 28 08:48:22 2022 From: haosun at openjdk.org (Hao Sun) Date: Wed, 28 Sep 2022 08:48:22 GMT Subject: RFR: 8294359: Interpreter(AArch64) intrinsify Thread.currentThread() In-Reply-To: <4_NS99FGLWdfBMRtO8zpcFs0CxSSojL6R5428Wy83To=.bb96e085-7742-425f-b8bf-3d366f3b050b@github.com> References: <4_NS99FGLWdfBMRtO8zpcFs0CxSSojL6R5428Wy83To=.bb96e085-7742-425f-b8bf-3d366f3b050b@github.com> Message-ID: On Tue, 27 Sep 2022 09:09:05 GMT, Hao Sun wrote: > JDK-8278793 supported Thread.currentThread() intrinsification for interpreter(x64) part so as to get JVM startup benefit. > > In this patch, we implement the AArch64 part. > > Testings: tier1~3 and jdk_loom passed on Linux/AArch64. Thanks for your review! I think the GHA failure is due to the network issue, not related to this PR. ------------- PR: https://git.openjdk.org/jdk/pull/10441 From dholmes at openjdk.org Wed Sep 28 08:52:42 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Sep 2022 08:52:42 GMT Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot In-Reply-To: References: <8ksRN6s9BNy3_UfKNaBHVXYjhghjZ23c6zyRA5rGMF8=.a17888df-486c-466e-a8ca-5bf2775ddd73@github.com> Message-ID: On Wed, 28 Sep 2022 07:59:56 GMT, Magnus Ihse Bursie wrote: >> How is this a bu... ah. Oh! The second statement from `CHECK_NULL` is effectively out of `if (!ik->is_initialized())` block! > > Two, and counting. :-) Yep another CHECK macro gotcha! ------------- PR: https://git.openjdk.org/jdk/pull/10444 From dholmes at openjdk.org Wed Sep 28 08:52:42 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Sep 2022 08:52:42 GMT Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot In-Reply-To: References: <8ksRN6s9BNy3_UfKNaBHVXYjhghjZ23c6zyRA5rGMF8=.a17888df-486c-466e-a8ca-5bf2775ddd73@github.com> Message-ID: <9l11mgsBpRrdHBND5x1HYGExEGWA_oJ0TQk_sRgFgLw=.0a1bb878-21ec-4d80-9192-6ead602b433d@github.com> On Wed, 28 Sep 2022 08:47:46 GMT, David Holmes wrote: >> Two, and counting. :-) > > Yep another CHECK macro gotcha! Harmless in this case as no pre-existing exception should be pending. ------------- PR: https://git.openjdk.org/jdk/pull/10444 From ihse at openjdk.org Wed Sep 28 09:08:23 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Sep 2022 09:08:23 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v14] In-Reply-To: References: Message-ID: <5slHtUlqd_3lk8tvJkwEdQMKx9R-hxHUZqNUAVUyLNc=.d919f6ed-4842-481d-82ad-edb569db6966@github.com> > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Pass additional arguments to GHA runs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/4a51a15c..30847dd4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=12-13 Stats: 42 lines in 5 files changed: 34 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From fyang at openjdk.org Wed Sep 28 09:18:35 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 28 Sep 2022 09:18:35 GMT Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites [v2] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 06:58:15 GMT, Xiaolin Zheng wrote: >> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them. >> >> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before. >> >> Originally some non-patchable callsites: >> >> ;; 0x401ab1dc40 >> 0x000000401372b324: lui t0,0x201 >> 0x000000401372b328: addi t0,t0,-680 # 0x0000000000200d58 >> 0x000000401372b32c: slli t0,t0,0xb >> 0x000000401372b32e: addi t0,t0,1905 >> 0x000000401372b332: slli t0,t0,0x6 >> 0x000000401372b334: jalr t0 >> >> Now: >> >> 0x000000401b2bd9f4: lui t0,0x4003 >> 0x000000401b2bd9f8: addiw t0,t0,-1275 >> 0x000000401b2bd9fc: slli t0,t0,0xc >> 0x000000401b2bda00: jalr 1080(t0) # 0x0000000004003438 >> >> Not so much, but the main purpose is to clarify the usage of movptr and li. >> >> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1. > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Fix I have several comments. src/hotspot/cpu/riscv/assembler_riscv.cpp line 119: > 117: } > 118: > 119: void Assembler::li(Register Rd, int64_t imm, int32_t &offset) { It looks to me that we don't need to introduce another 'li' function here. I think you can mask out the lower 12bits of the address and move the result to register with existing 'mv' function. And keep the lower 12bits in offset at the same time. This could be implemented in your new 'mv' function. src/hotspot/cpu/riscv/assembler_riscv.cpp line 228: > 226: } > 227: > 228: INSN(call, x1); Better to move functions like 'ret' and 'call' to macroAssembler_riscv.hpp src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 567: > 565: Label *retaddr) { > 566: push_reg(RegSet::of(t0, xmethod), sp); // push << t0 & xmethod >> to sp > 567: call(entry_point, t0); Looks like we could use the default temp register 't0' for all use of 'call'. ------------- Changes requested by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10462 From haosun at openjdk.org Wed Sep 28 10:06:43 2022 From: haosun at openjdk.org (Hao Sun) Date: Wed, 28 Sep 2022 10:06:43 GMT Subject: Integrated: 8294359: Interpreter(AArch64) intrinsify Thread.currentThread() In-Reply-To: <4_NS99FGLWdfBMRtO8zpcFs0CxSSojL6R5428Wy83To=.bb96e085-7742-425f-b8bf-3d366f3b050b@github.com> References: <4_NS99FGLWdfBMRtO8zpcFs0CxSSojL6R5428Wy83To=.bb96e085-7742-425f-b8bf-3d366f3b050b@github.com> Message-ID: On Tue, 27 Sep 2022 09:09:05 GMT, Hao Sun wrote: > JDK-8278793 supported Thread.currentThread() intrinsification for interpreter(x64) part so as to get JVM startup benefit. > > In this patch, we implement the AArch64 part. > > Testings: tier1~3 and jdk_loom passed on Linux/AArch64. This pull request has now been integrated. Changeset: ea616710 Author: Hao Sun Committer: Ningsheng Jian URL: https://git.openjdk.org/jdk/commit/ea6167104ebb16394f60d72999214221b8b9400f Stats: 15 lines in 4 files changed: 11 ins; 0 del; 4 mod 8294359: Interpreter(AArch64) intrinsify Thread.currentThread() Reviewed-by: aph, shade ------------- PR: https://git.openjdk.org/jdk/pull/10441 From jsjolen at openjdk.org Wed Sep 28 10:45:00 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 28 Sep 2022 10:45:00 GMT Subject: RFR: 8293691: converting a defined BasicType value to a string should not crash the VM [v2] In-Reply-To: References: Message-ID: <94ESvfZVeiBH-t36grd2jji9WdvcbbEtRJWyYgt96js=.d880d03a-593c-4584-9fd4-1ab5afce9aba@github.com> > Hi, > > This implements Kim's suggested fix for this ticket. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Use ARRAY_SIZE instead ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10447/files - new: https://git.openjdk.org/jdk/pull/10447/files/28899c6d..442216a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10447&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10447&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10447.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10447/head:pull/10447 PR: https://git.openjdk.org/jdk/pull/10447 From jsjolen at openjdk.org Wed Sep 28 10:45:03 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 28 Sep 2022 10:45:03 GMT Subject: RFR: 8293691: converting a defined BasicType value to a string should not crash the VM [v2] In-Reply-To: <0KRk9sCVynLv3RDDWXi6GJtKI4rbldyqwh9mtMT3iGc=.38c4ca01-d09e-4bc1-a782-2f3bc4603d2a@github.com> References: <0KRk9sCVynLv3RDDWXi6GJtKI4rbldyqwh9mtMT3iGc=.38c4ca01-d09e-4bc1-a782-2f3bc4603d2a@github.com> Message-ID: On Tue, 27 Sep 2022 18:09:14 GMT, Dean Long wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Use ARRAY_SIZE instead > > src/hotspot/share/utilities/globalDefinitions.cpp line 240: > >> 238: }; >> 239: const char* type2name(BasicType t) { >> 240: if (t < (T_CONFLICT + 1)) { > > Suggestion: > > if (t < ARRAY_SIZE(type2name_tab)) { Fixed ------------- PR: https://git.openjdk.org/jdk/pull/10447 From xlinzheng at openjdk.org Wed Sep 28 11:09:42 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 28 Sep 2022 11:09:42 GMT Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites [v3] In-Reply-To: References: Message-ID: > A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them. > > This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before. > > Originally some non-patchable callsites: > > ;; 0x401ab1dc40 > 0x000000401372b324: lui t0,0x201 > 0x000000401372b328: addi t0,t0,-680 # 0x0000000000200d58 > 0x000000401372b32c: slli t0,t0,0xb > 0x000000401372b32e: addi t0,t0,1905 > 0x000000401372b332: slli t0,t0,0x6 > 0x000000401372b334: jalr t0 > > Now: > > 0x000000401b2bd9f4: lui t0,0x4003 > 0x000000401b2bd9f8: addiw t0,t0,-1275 > 0x000000401b2bd9fc: slli t0,t0,0xc > 0x000000401b2bda00: jalr 1080(t0) # 0x0000000004003438 > > Not so much, but the main purpose is to clarify the usage of movptr and li. > > The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1. Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: Fix as to comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10462/files - new: https://git.openjdk.org/jdk/pull/10462/files/ad15d6b2..4985dcf4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=01-02 Stats: 89 lines in 7 files changed: 16 ins; 57 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/10462.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10462/head:pull/10462 PR: https://git.openjdk.org/jdk/pull/10462 From xlinzheng at openjdk.org Wed Sep 28 11:09:43 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 28 Sep 2022 11:09:43 GMT Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites [v2] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 09:09:33 GMT, Fei Yang wrote: >> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix > > src/hotspot/cpu/riscv/assembler_riscv.cpp line 119: > >> 117: } >> 118: >> 119: void Assembler::li(Register Rd, int64_t imm, int32_t &offset) { > > It looks to me that we don't need to introduce another 'li' function here. I think you can mask out the lower 12bits of the address and move the result to register with existing 'mv' function. And keep the lower 12bits in offset at the same time. This could be implemented in your new 'mv' function. Thanks for the advice, very reasonable. I have changed that (need further testing). Others all done. ------------- PR: https://git.openjdk.org/jdk/pull/10462 From bkilambi at openjdk.org Wed Sep 28 11:24:18 2022 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Wed, 28 Sep 2022 11:24:18 GMT Subject: RFR: 8293488: Add EOR3 backend rule for aarch64 SHA3 extension In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 11:13:40 GMT, Bhavana Kilambi wrote: > Arm ISA v8.2A and v9.0A include SHA3 feature extensions and one of those SHA3 instructions - "eor3" performs an exclusive OR of three vectors. This is helpful in applications that have multiple, consecutive "eor" operations which can be reduced by clubbing them into fewer operations using the "eor3" instruction. For example - > > eor a, a, b > eor a, a, c > > can be optimized to single instruction - `eor3 a, b, c` > > This patch adds backend rules for Neon and SVE2 "eor3" instructions and a micro benchmark to assess the performance gains with this patch. Following are the results of the included micro benchmark on a 128-bit aarch64 machine that supports Neon, SVE2 and SHA3 features - > > > Benchmark gain > TestEor3.test1Int 10.87% > TestEor3.test1Long 8.84% > TestEor3.test2Int 21.68% > TestEor3.test2Long 21.04% > > > The numbers shown are performance gains with using Neon eor3 instruction over the master branch that uses multiple "eor" instructions instead. Similar gains can be observed with the SVE2 "eor3" version as well since the "eor3" instruction is unpredicated and the machine under test uses a maximum vector width of 128 bits which makes the SVE2 code generation very similar to the one with Neon. Could anyone please take a look at this PR and give their feedback ? Thank you .. ------------- PR: https://git.openjdk.org/jdk/pull/10407 From fyang at openjdk.org Wed Sep 28 11:43:35 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 28 Sep 2022 11:43:35 GMT Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites [v3] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 11:09:42 GMT, Xiaolin Zheng wrote: >> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them. >> >> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before. >> >> Originally some non-patchable callsites: >> >> ;; 0x401ab1dc40 >> 0x000000401372b324: lui t0,0x201 >> 0x000000401372b328: addi t0,t0,-680 # 0x0000000000200d58 >> 0x000000401372b32c: slli t0,t0,0xb >> 0x000000401372b32e: addi t0,t0,1905 >> 0x000000401372b332: slli t0,t0,0x6 >> 0x000000401372b334: jalr t0 >> >> Now: >> >> 0x000000401b2bd9f4: lui t0,0x4003 >> 0x000000401b2bd9f8: addiw t0,t0,-1275 >> 0x000000401b2bd9fc: slli t0,t0,0xc >> 0x000000401b2bda00: jalr 1080(t0) # 0x0000000004003438 >> >> Not so much, but the main purpose is to clarify the usage of movptr and li. >> >> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1. > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Fix as to comments Looks better. One extra suggestion. src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 531: > 529: // mv > 530: void mv(Register Rd, address addr) { li(Rd, (int64_t)addr); } > 531: void mv(Register Rd, address addr, int32_t &offset) { We should add necessary comment for this function, like: "Split address into a lower 12-bit sign-extended offset and the remainder so that the offset could be encoded in jalr or load/store instruction." ------------- Changes requested by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10462 From jwaters at openjdk.org Wed Sep 28 12:14:34 2022 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 28 Sep 2022 12:14:34 GMT Subject: RFR: 8292016: Split Windows API error handling from errors passed through the runtime in the JDK [v22] In-Reply-To: References: Message-ID: <0SGomU7hjPXkdsZXjiET_RcLHN1YrF10WBNVgKmZwbw=.a0414214-170d-416b-887c-10983adf47a0@github.com> On Mon, 26 Sep 2022 15:47:51 GMT, Julian Waters wrote: >> EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime. > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Whitespace Ah alright, will try removing all of them and checking whether behaviour changes rise up in that case. Will push if none result from the change ------------- PR: https://git.openjdk.org/jdk/pull/9870 From xlinzheng at openjdk.org Wed Sep 28 12:35:31 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 28 Sep 2022 12:35:31 GMT Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites [v4] In-Reply-To: References: Message-ID: > A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them. > > This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before. > > Originally some non-patchable callsites: > > ;; 0x401ab1dc40 > 0x000000401372b324: lui t0,0x201 > 0x000000401372b328: addi t0,t0,-680 # 0x0000000000200d58 > 0x000000401372b32c: slli t0,t0,0xb > 0x000000401372b32e: addi t0,t0,1905 > 0x000000401372b332: slli t0,t0,0x6 > 0x000000401372b334: jalr t0 > > Now: > > 0x000000401b2bd9f4: lui t0,0x4003 > 0x000000401b2bd9f8: addiw t0,t0,-1275 > 0x000000401b2bd9fc: slli t0,t0,0xc > 0x000000401b2bda00: jalr 1080(t0) # 0x0000000004003438 > > Not so much, but the main purpose is to clarify the usage of movptr and li. > > The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1. Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: Comments, with one & ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10462/files - new: https://git.openjdk.org/jdk/pull/10462/files/4985dcf4..60608a30 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10462.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10462/head:pull/10462 PR: https://git.openjdk.org/jdk/pull/10462 From xlinzheng at openjdk.org Wed Sep 28 12:35:34 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 28 Sep 2022 12:35:34 GMT Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites [v3] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 11:37:53 GMT, Fei Yang wrote: >> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix as to comments > > src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 531: > >> 529: // mv >> 530: void mv(Register Rd, address addr) { li(Rd, (int64_t)addr); } >> 531: void mv(Register Rd, address addr, int32_t &offset) { > > We should add necessary comment for this function, like: > "Split address into a lower 12-bit sign-extended offset and the remainder so that the offset could be encoded in jalr or load/store instruction." done - added. ------------- PR: https://git.openjdk.org/jdk/pull/10462 From coleenp at openjdk.org Wed Sep 28 13:00:25 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 28 Sep 2022 13:00:25 GMT Subject: RFR: 8294438: Fix misleading-indentation warnings in hotspot In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 10:28:54 GMT, Aleksey Shipilev wrote: > There are number of places where misleading-indentation is reported by GCC. Currently, the warning is disabled for the entirety of Hotspot, which is not good. > > C1 does an unusual style here. Changing it globally would touch a lot of lines. Instead of doing that, I fit the existing style while also resolving the warnings. Note this actually solves a bug in `lir_alloc_array`, where `do_temp` are called without a check. > > Build-tested this with product of: > - GCC 10 > - {i686, x86_64, aarch64, powerpc64le, s390x, armhf, riscv64} > - {server, zero} > - {release, fastdebug} > > Linux x86_64 fastdebug `tier1` is fine. Nice fix and enabling the warning. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/10444 From dfuchs at openjdk.org Wed Sep 28 13:24:26 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 28 Sep 2022 13:24:26 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com> References: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com> Message-ID: On Tue, 27 Sep 2022 23:12:43 GMT, Michael Ernst wrote: > Feel free to break up the pull request if that is what is needed to free it from red tape. Only you can do that @mernst ------------- PR: https://git.openjdk.org/jdk/pull/10029 From fyang at openjdk.org Wed Sep 28 13:25:25 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 28 Sep 2022 13:25:25 GMT Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites [v4] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 12:35:31 GMT, Xiaolin Zheng wrote: >> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them. >> >> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before. >> >> Originally some non-patchable callsites: >> >> ;; 0x401ab1dc40 >> 0x000000401372b324: lui t0,0x201 >> 0x000000401372b328: addi t0,t0,-680 # 0x0000000000200d58 >> 0x000000401372b32c: slli t0,t0,0xb >> 0x000000401372b32e: addi t0,t0,1905 >> 0x000000401372b332: slli t0,t0,0x6 >> 0x000000401372b334: jalr t0 >> >> Now: >> >> 0x000000401b2bd9f4: lui t0,0x4003 >> 0x000000401b2bd9f8: addiw t0,t0,-1275 >> 0x000000401b2bd9fc: slli t0,t0,0xc >> 0x000000401b2bda00: jalr 1080(t0) # 0x0000000004003438 >> >> Not so much, but the main purpose is to clarify the usage of movptr and li. >> >> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1. > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Comments, with one & Updated change looks good. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10462 From duke at openjdk.org Wed Sep 28 13:28:00 2022 From: duke at openjdk.org (Matias Saavedra Silva) Date: Wed, 28 Sep 2022 13:28:00 GMT Subject: RFR: 8293515: heapShared.cpp: rename JavaThread parameter to current Message-ID: Replaced instances of THREAD with current and placed the parameter at the beginning rather than the end. Necessary instances of THREAD were initialized with current. Verified with tier 1 tests. Please review. ------------- Commit messages: - 8293515: heapShared.cpp: rename JavaThread parameter to current Changes: https://git.openjdk.org/jdk/pull/10451/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10451&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293515 Stats: 17 lines in 3 files changed: 2 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/10451.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10451/head:pull/10451 PR: https://git.openjdk.org/jdk/pull/10451 From jsjolen at openjdk.org Wed Sep 28 13:45:53 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 28 Sep 2022 13:45:53 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3] In-Reply-To: References: Message-ID: > Here's a suggested solution for the ticket mentioned and a use case for outputStream. I'm not attached to the name. > > This saves space for all allocated outputStreams, which is nice. It also makes the purpose of ResourceObj more clear ("please handle the life cycle for me"), reducing the need for it. > > Thank you for considering it. Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Introduce new, invalid, memory flag - delete _print_inlining_stream - Merge remote-tracking branch 'origin/master' into dyn-cheapobj - Avoid leaking predString - Try out Coleen's suggestion - DynCHeapObj ------------- Changes: https://git.openjdk.org/jdk/pull/10412/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10412&range=02 Stats: 47 lines in 15 files changed: 9 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/10412.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10412/head:pull/10412 PR: https://git.openjdk.org/jdk/pull/10412 From jsjolen at openjdk.org Wed Sep 28 13:45:54 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 28 Sep 2022 13:45:54 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3] In-Reply-To: References: Message-ID: <8HwXXsQs7ymwwOCwOYVeyISo6akG2_XBOVf2ILTjFuQ=.5b323620-ca06-4200-9301-2f64bbc85374@github.com> On Mon, 26 Sep 2022 15:34:29 GMT, Coleen Phillimore wrote: >> We can eliminate this problem: >> "I guess the risk is that you get mtInternal if you forget the parameter to new." >> >> We can instead have CHeapObj that *only* allocates with mtFoo, and >> CHeapObj<> that *requires* specifying the flag when allocating the memory. (I >> did something like this for the CHeapAllocator in my prototype for Standard >> Library usage.) As part of that, we can also have the MEMFLAGS argument (when >> needed) always be the first argument in the placement list. >> >> Very(!) lightly tested: >> https://github.com/kimbarrett/openjdk-jdk/tree/dynamic-memflags > > Or you could have the class that requires dynamic mtFlag be declared with mtNone and assert in one place in AllocateHeap that mt != mtNone. Actually that assert might already be there. Can't really puzzle out what Kim's change does. I added a mtInvalid flag and did the assert. mtNone seems to be dealt with in some code, I'm not sure if it's appropriate to use it as an invalid value. Regardless, mtInvalid is a better name (for this purpose), so maybe we can change mtNone to mtInvalid in the future? ------------- PR: https://git.openjdk.org/jdk/pull/10412 From fyang at openjdk.org Wed Sep 28 13:57:25 2022 From: fyang at openjdk.org (Fei Yang) Date: Wed, 28 Sep 2022 13:57:25 GMT Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites [v4] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 12:35:31 GMT, Xiaolin Zheng wrote: >> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them. >> >> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before. >> >> Originally some non-patchable callsites: >> >> ;; 0x401ab1dc40 >> 0x000000401372b324: lui t0,0x201 >> 0x000000401372b328: addi t0,t0,-680 # 0x0000000000200d58 >> 0x000000401372b32c: slli t0,t0,0xb >> 0x000000401372b32e: addi t0,t0,1905 >> 0x000000401372b332: slli t0,t0,0x6 >> 0x000000401372b334: jalr t0 >> >> Now: >> >> 0x000000401b2bd9f4: lui t0,0x4003 >> 0x000000401b2bd9f8: addiw t0,t0,-1275 >> 0x000000401b2bd9fc: slli t0,t0,0xc >> 0x000000401b2bda00: jalr 1080(t0) # 0x0000000004003438 >> >> Not so much, but the main purpose is to clarify the usage of movptr and li. >> >> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1. > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Comments, with one & src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 534: > 532: // Split address into a lower 12-bit sign-extended offset and the remainder, > 533: // so that the offset could be encoded in jalr or load/store instruction. > 534: offset = ((int32_t)(uintptr_t)addr << 20) >> 20; Would you mind one more tweak here? Considering that the type of 'offset' is int32_t, I think it will be more readable here if we convert 'addr' into int64_t type instead of uintptr_t. ------------- PR: https://git.openjdk.org/jdk/pull/10462 From xlinzheng at openjdk.org Wed Sep 28 14:02:57 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 28 Sep 2022 14:02:57 GMT Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites [v5] In-Reply-To: References: Message-ID: > A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them. > > This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before. > > Originally some non-patchable callsites: > > ;; 0x401ab1dc40 > 0x000000401372b324: lui t0,0x201 > 0x000000401372b328: addi t0,t0,-680 # 0x0000000000200d58 > 0x000000401372b32c: slli t0,t0,0xb > 0x000000401372b32e: addi t0,t0,1905 > 0x000000401372b332: slli t0,t0,0x6 > 0x000000401372b334: jalr t0 > > Now: > > 0x000000401b2bd9f4: lui t0,0x4003 > 0x000000401b2bd9f8: addiw t0,t0,-1275 > 0x000000401b2bd9fc: slli t0,t0,0xc > 0x000000401b2bda00: jalr 1080(t0) # 0x0000000004003438 > > Not so much, but the main purpose is to clarify the usage of movptr and li. > > The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1. Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: Canonicalize signed extensions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10462/files - new: https://git.openjdk.org/jdk/pull/10462/files/60608a30..fe56ee07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10462&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10462.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10462/head:pull/10462 PR: https://git.openjdk.org/jdk/pull/10462 From xlinzheng at openjdk.org Wed Sep 28 14:02:58 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Wed, 28 Sep 2022 14:02:58 GMT Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites [v4] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 13:52:02 GMT, Fei Yang wrote: >> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: >> >> Comments, with one & > > src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 534: > >> 532: // Split address into a lower 12-bit sign-extended offset and the remainder, >> 533: // so that the offset could be encoded in jalr or load/store instruction. >> 534: offset = ((int32_t)(uintptr_t)addr << 20) >> 20; > > Would you mind one more tweak here? Considering that the type of 'offset' is int32_t, I think it will be more readable here if we convert 'addr' into int64_t type instead of uintptr_t. Of course. Also changed other uintptr_t usages to int64_t. ------------- PR: https://git.openjdk.org/jdk/pull/10462 From mernst at openjdk.org Wed Sep 28 14:49:20 2022 From: mernst at openjdk.org (Michael Ernst) Date: Wed, 28 Sep 2022 14:49:20 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Regarding breaking up the pull request: * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape. * I have spent a nontrivial amount of time on these fixes. There have been long delays, which forced me to resolve merge conflicts. I was told that the changes are "mostly fine" without any indication of what is wrong. I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted. * No one has explained what to do. "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is. I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to corrections. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From dfuchs at openjdk.org Wed Sep 28 15:13:39 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 28 Sep 2022 15:13:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 14:45:54 GMT, Michael Ernst wrote: >> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Reinstate typos in Apache code that is copied into the JDK >> - Merge ../jdk-openjdk into typos-typos >> - Remove file that was removed upstream >> - Fix inconsistency in capitalization >> - Undo change in zlip >> - Fix typos > > Regarding breaking up the pull request: > * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape. > * Despite my repeated requests, no one has justified that *this particular pull request* needs the expertise of different teams. The only reasons stated have been custom and bureaucracy. > * I have spent a nontrivial amount of time on these fixes. There have been long delays, which forced me to resolve merge conflicts. I was told that the changes are "mostly fine" without any indication of what is wrong. I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted. > * I was condescendingly told "We have discussed several times in the past ..." even though I was not privy to those discussions. No pointer to documentation in the JDK itself, about pull requests, was given. > * No one has explained what to do. "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is. > > I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to contributions. Hi @mernst, sorry if this is how it appears. Pull requests that involve changes spanning a large set of files are notoriously harder to review since they require a reviewer from each different area to chime in. Basically you will need one reviewer from each of these areas: - client - compiler - core-libs - hotspot - i18n - javadoc - jmx - net - nio - security - serviceability Jaikiran suggested to reduce the scope of this PR in his first comment: https://github.com/openjdk/jdk/pull/10029#issuecomment-1236588632 as did several other reviewers. Sorry if the meaning (or reason) was not clear. best regards, ------------- PR: https://git.openjdk.org/jdk/pull/10029 From aivanov at openjdk.org Wed Sep 28 15:28:24 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Sep 2022 15:28:24 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Wed Sep 28 15:35:40 2022 From: mernst at openjdk.org (Michael Ernst) Date: Wed, 28 Sep 2022 15:35:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 15:26:13 GMT, Alexey Ivanov wrote: > The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`. The title was edited by someone other than me, as you can see from the PR history. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From coleenp at openjdk.org Wed Sep 28 15:57:24 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 28 Sep 2022 15:57:24 GMT Subject: RFR: 8293691: converting a defined BasicType value to a string should not crash the VM [v2] In-Reply-To: <94ESvfZVeiBH-t36grd2jji9WdvcbbEtRJWyYgt96js=.d880d03a-593c-4584-9fd4-1ab5afce9aba@github.com> References: <94ESvfZVeiBH-t36grd2jji9WdvcbbEtRJWyYgt96js=.d880d03a-593c-4584-9fd4-1ab5afce9aba@github.com> Message-ID: On Wed, 28 Sep 2022 10:45:00 GMT, Johan Sj?len wrote: >> Hi, >> >> This implements Kim's suggested fix for this ticket. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Use ARRAY_SIZE instead Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10447 From dlong at openjdk.org Wed Sep 28 17:17:25 2022 From: dlong at openjdk.org (Dean Long) Date: Wed, 28 Sep 2022 17:17:25 GMT Subject: RFR: 8293691: converting a defined BasicType value to a string should not crash the VM [v2] In-Reply-To: <94ESvfZVeiBH-t36grd2jji9WdvcbbEtRJWyYgt96js=.d880d03a-593c-4584-9fd4-1ab5afce9aba@github.com> References: <94ESvfZVeiBH-t36grd2jji9WdvcbbEtRJWyYgt96js=.d880d03a-593c-4584-9fd4-1ab5afce9aba@github.com> Message-ID: On Wed, 28 Sep 2022 10:45:00 GMT, Johan Sj?len wrote: >> Hi, >> >> This implements Kim's suggested fix for this ticket. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Use ARRAY_SIZE instead Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10447 From svkamath at openjdk.org Wed Sep 28 17:40:36 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Wed, 28 Sep 2022 17:40:36 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v11] In-Reply-To: References: Message-ID: <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com> > 8289552: Make intrinsic conversions between bit representations of half precision values and floats Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: Addressed review comment to update test case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9781/files - new: https://git.openjdk.org/jdk/pull/9781/files/c6128b1b..8ccc0657 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9781&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9781.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9781/head:pull/9781 PR: https://git.openjdk.org/jdk/pull/9781 From kvn at openjdk.org Wed Sep 28 17:59:41 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 28 Sep 2022 17:59:41 GMT Subject: RFR: 8293409: [vectorapi] Intrinsify VectorSupport.indexVector In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 08:51:24 GMT, Xiaohong Gong wrote: > "`VectorSupport.indexVector()`" is used to compute a vector that contains the index values based on a given vector and a scale value (`i.e. index = vec + iota * scale`). This function is widely used in other APIs like "`VectorMask.indexInRange`" which is useful to the tail loop vectorization. And it can be easily implemented with the vector instructions. > > This patch adds the vector intrinsic implementation of it. The steps are: > > 1) Load the const "iota" vector. > > We extend the "`vector_iota_indices`" stubs from byte to other integral types. For floating point vectors, it needs an additional vector cast to get the right iota values. > > 2) Compute indexes with "`vec + iota * scale`" > > Here is the performance result to the new added micro benchmark on ARM NEON: > > Benchmark Gain > IndexVectorBenchmark.byteIndexVector 1.477 > IndexVectorBenchmark.doubleIndexVector 5.031 > IndexVectorBenchmark.floatIndexVector 5.342 > IndexVectorBenchmark.intIndexVector 5.529 > IndexVectorBenchmark.longIndexVector 3.177 > IndexVectorBenchmark.shortIndexVector 5.841 > > > Please help to review and share the feedback! Thanks in advance! @jatin-bhateja and @sviswa7 please look on this enhancement as Vector API experts. ------------- PR: https://git.openjdk.org/jdk/pull/10332 From coleenp at openjdk.org Wed Sep 28 18:12:23 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 28 Sep 2022 18:12:23 GMT Subject: RFR: 8293515: heapShared.cpp: rename JavaThread parameter to current In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 13:51:39 GMT, Matias Saavedra Silva wrote: > Replaced instances of THREAD with current and placed the parameter at the beginning rather than the end. Necessary instances of THREAD were initialized with current. Verified with tier 1 tests. Please review. This looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/10451 From ihse at openjdk.org Wed Sep 28 18:19:24 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Sep 2022 18:19:24 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v15] In-Reply-To: References: Message-ID: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Add missing sub workflow inputs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/30847dd4..32cda464 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=13-14 Stats: 18 lines in 3 files changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From coleenp at openjdk.org Wed Sep 28 18:23:34 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 28 Sep 2022 18:23:34 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 13:45:53 GMT, Johan Sj?len wrote: >> Here's a suggested solution for the ticket mentioned and a use case for outputStream. I'm not attached to the name. >> >> This saves space for all allocated outputStreams, which is nice. It also makes the purpose of ResourceObj more clear ("please handle the life cycle for me"), reducing the need for it. >> >> Thank you for considering it. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Introduce new, invalid, memory flag > - delete _print_inlining_stream > - Merge remote-tracking branch 'origin/master' into dyn-cheapobj > - Avoid leaking predString > - Try out Coleen's suggestion > - DynCHeapObj Changes requested by coleenp (Reviewer). src/hotspot/share/opto/compile.hpp line 1064: > 1062: delete _print_inlining_stream; > 1063: }; > 1064: compile.cpp has print_inlining_stream_free() calls which will leak the stringStream now if called. I think this function needs to be removed and it should call the reset function to reinitialize the stream. There should be compiler tests that will fail if print_inlining_stream_free() is called with a null _print_inlining_stream pointer (I think the delete should fail (?) with null) src/hotspot/share/utilities/ostream.hpp line 45: > 43: // This allows for redirection via -XX:+DisplayVMOutputToStdout and > 44: // -XX:+DisplayVMOutputToStderr > 45: class outputStream : public CHeapObj { Were you going to change this to mtInvalid to require all components to pass the appropriate mtComponent flag? People might bikeshed on the name mtInvalid - it could also be mtOverride or mtDynamic. In any case, this is a nice improvement. ------------- PR: https://git.openjdk.org/jdk/pull/10412 From ihse at openjdk.org Wed Sep 28 18:30:25 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Sep 2022 18:30:25 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v16] In-Reply-To: References: Message-ID: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Revert "TESTING GHA v2: Previous attempt was botched" This reverts commit 4a51a15cd73ebc6aa96ad04f9b1eb88e2683c82f. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/32cda464..48d4e4f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=14-15 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From shade at openjdk.org Wed Sep 28 18:36:22 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Sep 2022 18:36:22 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v16] In-Reply-To: References: Message-ID: <0BxGpAacaOrLUEN44j-F1y8S8dKTQrvmCB08D3rkrQo=.228fde12-7ab9-4522-97fb-ac3f76a7c4ce@github.com> On Wed, 28 Sep 2022 18:30:25 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. >> >> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. >> >> Some warnings didn't trigger in any file anymore, and could just be removed. >> >> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. >> >> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. >> >> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. >> >> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). >> >> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Revert "TESTING GHA v2: Previous attempt was botched" > > This reverts commit 4a51a15cd73ebc6aa96ad04f9b1eb88e2683c82f. Still having fun with it? I now have the capability to quickly build everything with GCC 9..12 (but 12 has problems on their own). GHA is a subset of that build matrix. I can give this PR a spin, if your PR is at stable point. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From ihse at openjdk.org Wed Sep 28 19:52:27 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 Sep 2022 19:52:27 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v17] In-Reply-To: References: Message-ID: > After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. > > Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. > > Some warnings didn't trigger in any file anymore, and could just be removed. > > Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. > > I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. > > I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. > > It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). > > Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Revert jvm variants hack ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10414/files - new: https://git.openjdk.org/jdk/pull/10414/files/48d4e4f3..d6c52a2a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10414&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10414.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10414/head:pull/10414 PR: https://git.openjdk.org/jdk/pull/10414 From ccheung at openjdk.org Wed Sep 28 21:25:17 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 28 Sep 2022 21:25:17 GMT Subject: RFR: 8293515: heapShared.cpp: rename JavaThread parameter to current In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 13:51:39 GMT, Matias Saavedra Silva wrote: > Replaced instances of THREAD with current and placed the parameter at the beginning rather than the end. Necessary instances of THREAD were initialized with current. Verified with tier 1 tests. Please review. Looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk/pull/10451 From duke at openjdk.org Wed Sep 28 21:29:38 2022 From: duke at openjdk.org (Matias Saavedra Silva) Date: Wed, 28 Sep 2022 21:29:38 GMT Subject: Integrated: 8293515: heapShared.cpp: rename JavaThread parameter to current In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 13:51:39 GMT, Matias Saavedra Silva wrote: > Replaced instances of THREAD with current and placed the parameter at the beginning rather than the end. Necessary instances of THREAD were initialized with current. Verified with tier 1 tests. Please review. This pull request has now been integrated. Changeset: 88731924 Author: Matias Saavedra Silva Committer: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/887319243351c198152f49ead3e4790442c52d95 Stats: 17 lines in 3 files changed: 2 ins; 2 del; 13 mod 8293515: heapShared.cpp: rename JavaThread parameter to current Reviewed-by: coleenp, ccheung ------------- PR: https://git.openjdk.org/jdk/pull/10451 From vlivanov at openjdk.org Wed Sep 28 21:31:33 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 28 Sep 2022 21:31:33 GMT Subject: RFR: 8294160: misc crash dump improvements [v2] In-Reply-To: References: Message-ID: <2XNlpaadktynPmtoquJJX9Fq9LjLRamKilcku1yHRa8=.4ecb796f-311a-4596-b5f9-f42c3ab14072@github.com> On Tue, 27 Sep 2022 18:22:27 GMT, Dean Long wrote: >> Try to recover and output meaningful information in more situations, such as: >> - when a pointer is in Method metadata memory range, but the memory is not committed >> - when we call a bad address >> >> When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > revert unneeded changes Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/10387 From dlong at openjdk.org Wed Sep 28 23:16:24 2022 From: dlong at openjdk.org (Dean Long) Date: Wed, 28 Sep 2022 23:16:24 GMT Subject: RFR: 8294160: misc crash dump improvements [v2] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 18:22:27 GMT, Dean Long wrote: >> Try to recover and output meaningful information in more situations, such as: >> - when a pointer is in Method metadata memory range, but the memory is not committed >> - when we call a bad address >> >> When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > revert unneeded changes Thanks Vladimir. ------------- PR: https://git.openjdk.org/jdk/pull/10387 From dlong at openjdk.org Wed Sep 28 23:17:47 2022 From: dlong at openjdk.org (Dean Long) Date: Wed, 28 Sep 2022 23:17:47 GMT Subject: Integrated: 8294160: misc crash dump improvements In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 07:53:42 GMT, Dean Long wrote: > Try to recover and output meaningful information in more situations, such as: > - when a pointer is in Method metadata memory range, but the memory is not committed > - when we call a bad address > > When calling a bad address, we usually don't get a meaningful stack backtrace, but in many situations we can if we know where to find the caller information. This pull request has now been integrated. Changeset: 6f8f28e7 Author: Dean Long URL: https://git.openjdk.org/jdk/commit/6f8f28e7566701b195ecc855f3e802cd7145e9aa Stats: 26 lines in 5 files changed: 20 ins; 2 del; 4 mod 8294160: misc crash dump improvements Reviewed-by: dholmes, vlivanov ------------- PR: https://git.openjdk.org/jdk/pull/10387 From xlinzheng at openjdk.org Thu Sep 29 03:28:44 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 29 Sep 2022 03:28:44 GMT Subject: RFR: 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites [v5] In-Reply-To: References: Message-ID: <15NhpCDCxb4wyMs-evRpPfO2igG5-hfegjRV539OSXQ=.6afe4711-b712-4bf9-a58e-aec42050a6b7@github.com> On Wed, 28 Sep 2022 14:02:57 GMT, Xiaolin Zheng wrote: >> A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them. >> >> This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before. >> >> Originally some non-patchable callsites: >> >> ;; 0x401ab1dc40 >> 0x000000401372b324: lui t0,0x201 >> 0x000000401372b328: addi t0,t0,-680 # 0x0000000000200d58 >> 0x000000401372b32c: slli t0,t0,0xb >> 0x000000401372b32e: addi t0,t0,1905 >> 0x000000401372b332: slli t0,t0,0x6 >> 0x000000401372b334: jalr t0 >> >> Now: >> >> 0x000000401b2bd9f4: lui t0,0x4003 >> 0x000000401b2bd9f8: addiw t0,t0,-1275 >> 0x000000401b2bd9fc: slli t0,t0,0xc >> 0x000000401b2bda00: jalr 1080(t0) # 0x0000000004003438 >> >> Not so much, but the main purpose is to clarify the usage of movptr and li. >> >> The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1. > > Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Canonicalize signed extensions Hotspot tier1~4 seems okay on QEMU with fastdebug build. I guess we can move on if no other comments. ------------- PR: https://git.openjdk.org/jdk/pull/10462 From xlinzheng at openjdk.org Thu Sep 29 07:23:42 2022 From: xlinzheng at openjdk.org (Xiaolin Zheng) Date: Thu, 29 Sep 2022 07:23:42 GMT Subject: Integrated: 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 06:28:53 GMT, Xiaolin Zheng wrote: > A cleanup which can also reduce some code size. The main purpose is to separate the current mixed movptr usages: movptr's semantics allow it to be used for fixed-length patchable addresses. In the current backend several callsites which are not patchable use movptr (6 instructions) as well, but that's unnecessary for we can use li(1~6 instructions) to substitute them. > > This patch extracts the last 12-bit offset from the li(), a recursive function, to merge it into the rest "jalr/ld/sd..." that can accept a 12-bit offset as an operand, same as the movptr_with_offset before. > > Originally some non-patchable callsites: > > ;; 0x401ab1dc40 > 0x000000401372b324: lui t0,0x201 > 0x000000401372b328: addi t0,t0,-680 # 0x0000000000200d58 > 0x000000401372b32c: slli t0,t0,0xb > 0x000000401372b32e: addi t0,t0,1905 > 0x000000401372b332: slli t0,t0,0x6 > 0x000000401372b334: jalr t0 > > Now: > > 0x000000401b2bd9f4: lui t0,0x4003 > 0x000000401b2bd9f8: addiw t0,t0,-1275 > 0x000000401b2bd9fc: slli t0,t0,0xc > 0x000000401b2bda00: jalr 1080(t0) # 0x0000000004003438 > > Not so much, but the main purpose is to clarify the usage of movptr and li. > > The first commit has gone through a hotspot tier1~tier4; the other ones are testing under a hotspot tier1. This pull request has now been integrated. Changeset: 1decdcee Author: Xiaolin Zheng Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/1decdcee71eae3344aaf2c0223d40a2b57a044b9 Stats: 103 lines in 8 files changed: 21 ins; 52 del; 30 mod 8294492: RISC-V: Use li instead of patchable movptr at non-patchable callsites Reviewed-by: fyang ------------- PR: https://git.openjdk.org/jdk/pull/10462 From shade at openjdk.org Thu Sep 29 08:03:26 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 29 Sep 2022 08:03:26 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v16] In-Reply-To: <0BxGpAacaOrLUEN44j-F1y8S8dKTQrvmCB08D3rkrQo=.228fde12-7ab9-4522-97fb-ac3f76a7c4ce@github.com> References: <0BxGpAacaOrLUEN44j-F1y8S8dKTQrvmCB08D3rkrQo=.228fde12-7ab9-4522-97fb-ac3f76a7c4ce@github.com> Message-ID: On Wed, 28 Sep 2022 18:34:11 GMT, Aleksey Shipilev wrote: > Still having fun with it? I now have the capability to quickly build everything with GCC 9..12 (but 12 has problems on their own). GHA is a subset of that build matrix. I can give this PR a spin, if your PR is at stable point. Current PR at d6c52a2a25edbe1c06f0d2303dac80129ede763f passes the matrix of: - `make hotspot` - GCC {9, 10, 11, 12} - {x86_32, x86_64, aarch64, armhf, ppc64le, s390x, riscv64} - {server, zero, minimal, client, optimized} - {fastdebug, release} It only took ~350 CPU-hours and ~600 GB of disk space to build :P ------------- PR: https://git.openjdk.org/jdk/pull/10414 From jsjolen at openjdk.org Thu Sep 29 08:52:16 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 29 Sep 2022 08:52:16 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 18:21:09 GMT, Coleen Phillimore wrote: >> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Introduce new, invalid, memory flag >> - delete _print_inlining_stream >> - Merge remote-tracking branch 'origin/master' into dyn-cheapobj >> - Avoid leaking predString >> - Try out Coleen's suggestion >> - DynCHeapObj > > src/hotspot/share/opto/compile.hpp line 1064: > >> 1062: delete _print_inlining_stream; >> 1063: }; >> 1064: > > compile.cpp has print_inlining_stream_free() calls which will leak the stringStream now if called. I think this function needs to be removed and it should call the reset function to reinitialize the stream. > There should be compiler tests that will fail if print_inlining_stream_free() is called with a null _print_inlining_stream pointer (I think the delete should fail (?) with null) This is removed as part of https://github.com/openjdk/jdk/pull/10396 . The function used to be here but I merged with upstream when that went in. delete on null is OK, just like with free. ------------- PR: https://git.openjdk.org/jdk/pull/10412 From kbarrett at openjdk.org Thu Sep 29 09:52:14 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 29 Sep 2022 09:52:14 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v17] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 19:52:27 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. >> >> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. >> >> Some warnings didn't trigger in any file anymore, and could just be removed. >> >> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. >> >> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. >> >> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. >> >> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). >> >> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Revert jvm variants hack make/hotspot/lib/CompileJvm.gmk line 101: > 99: DISABLED_WARNINGS_xlc := tautological-compare shift-negative-value > 100: > 101: DISABLED_WARNINGS_microsoft := 4624 4244 4291 4146 I went through the list of Visual Studio warnings being removed from the global suppression list. clang: tautological-compare windows: 4127 - conditional expression is constant I'm not sure we want these turned on. This is the kind of thing that can happen quite easily with macros and/or in a code base that uses things like conditional compilation to support multiple platforms. Working around these warnings when they arise can make for significant code uglification. OTOH, I guess it *could* catch some programming mistakes. Maybe these could remain surppressed for this change, and discussed separately? 4100 - 'identifier': unreferenced formal parameter I'm very surprised removing this doesn't cause problems, as I'm sure I've seen named but unused parameters. Maybe they've been cleaned up over time? I think some compiler (probably Visual Studio) used to be unhappy with unnamed parameters, which made this hard to avoid in some cases. Fortunately, that doesn't seem to be a problem anymore. Removal okay. 4201 - nonstandard extension used: nameless struct/union Removal okay. 4351 - new behavior: elements of array ?array? will be default initialized (according to google, but it is undocumented!!!) This one seems to have been dropped by more recent versions of VS. There are places where we use the feature, expecting the new behavior. Removal okay. 4511 - 'class': copy constructor was implicitly defined as deleted 4512 - 'class': assignment operator was implicitly defined as deleted I think that if the indicated situations were to exist and the warnings hadn't been suppressed that we'd get link-time errors instead. Removal okay. 4514 - 'function': unreferenced inline function has been removed I think we don't want this turned on, but it's also off by default. Removal okay. ------------- PR: https://git.openjdk.org/jdk/pull/10414 From jsjolen at openjdk.org Thu Sep 29 09:56:24 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 29 Sep 2022 09:56:24 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 13:45:53 GMT, Johan Sj?len wrote: >> Here's a suggested solution for the ticket mentioned and a use case for outputStream. I'm not attached to the name. >> >> This saves space for all allocated outputStreams, which is nice. It also makes the purpose of ResourceObj more clear ("please handle the life cycle for me"), reducing the need for it. >> >> Thank you for considering it. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Introduce new, invalid, memory flag > - delete _print_inlining_stream > - Merge remote-tracking branch 'origin/master' into dyn-cheapobj > - Avoid leaking predString > - Try out Coleen's suggestion > - DynCHeapObj I still have to go through all of this and check for memory leaks, just FYI. ------------- PR: https://git.openjdk.org/jdk/pull/10412 From shade at openjdk.org Thu Sep 29 10:48:38 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 29 Sep 2022 10:48:38 GMT Subject: RFR: 8294211: Zero: Decode arch-specific error context if possible [v3] In-Reply-To: <68x5tTa2dHOc-tAj6OfoLSK2MNK2GN2io8qj1POUT2I=.b4ef9779-3b2a-4af4-aa1b-166375420547@github.com> References: <68x5tTa2dHOc-tAj6OfoLSK2MNK2GN2io8qj1POUT2I=.b4ef9779-3b2a-4af4-aa1b-166375420547@github.com> Message-ID: > After POSIX signal refactorings, Zero error handling had "regressed" a bit: Zero always gets `NULL` as `pc` in error handling code, and thus it fails with SEGV at pc=0x0. We can do better by implementing context decoding where possible. > > Unfortunately, this introduces some arch-specific code in Zero code. The arch-specific code is copy-pasted (with inline definitions, if needed) from the relevant `os_linux_*.cpp` files. The unimplemented arches would still report the same confusing `hs_err`-s. We can emulate (and thus test) the generic behavior using new diagnostic VM option. > > This reverts parts of [JDK-8259392](https://bugs.openjdk.org/browse/JDK-8259392). > > Sample test: > > > import java.lang.reflect.*; > import sun.misc.Unsafe; > > public class Crash { > public static void main(String... args) throws Exception { > Field f = Unsafe.class.getDeclaredField("theUnsafe"); > f.setAccessible(true); > Unsafe u = (Unsafe) f.get(null); > u.getInt(42); // accesing via broken ptr > } > } > > > Linux x86_64 Zero fastdebug crash currently: > > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000000000000, pid=538793, tid=538794 > # > ... > # (no native frame info) > ... > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a > > > Linux x86_64 Zero fastdebug crash with this patch: > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007fbbbf08b584, pid=520119, tid=520120 > # > ... > # Problematic frame: > # V [libjvm.so+0xcbe584] Unsafe_GetInt+0xe4 > .... > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a > > > Linux x86_64 Zero fastdebug crash with this patch and `-XX:-DecodeErrorContext`: > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x0000000000000000, pid=520268, tid=520269 > # > ... > # Problematic frame: > # C 0x0000000000000000 > ... > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a > > > Additional testing: > - [x] Linux x86_64 Zero fastdebug eyeballing crash logs > - [x] Linux x86_64 Zero fastdebug, `tier1` > - [x] Linux {x86_64, x86_32, aarch64, arm, riscv64, s390x, ppc64le, ppc64be} Zero fastdebug builds Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8294211-zero-error-context - Style nits - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10397/files - new: https://git.openjdk.org/jdk/pull/10397/files/26c768e9..3c3299e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10397&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10397&range=01-02 Stats: 14860 lines in 347 files changed: 7035 ins; 6332 del; 1493 mod Patch: https://git.openjdk.org/jdk/pull/10397.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10397/head:pull/10397 PR: https://git.openjdk.org/jdk/pull/10397 From shade at openjdk.org Thu Sep 29 10:55:23 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 29 Sep 2022 10:55:23 GMT Subject: RFR: 8294314: Minimize disabled warnings in hotspot [v17] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 19:52:27 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now possible to disable warnings for individual files instead for whole libraries. I used this opportunity to go through all disabled warnings in hotspot. >> >> Any warnings that were only triggered in a few files were removed from hotspot as a whole, and changed to be only disabled for those files. >> >> Some warnings didn't trigger in any file anymore, and could just be removed. >> >> Overall, this reduced the number of disabled warnings by roughly half for gcc, clang and visual studio. The remaining warnings are sorted in "frequency", that is, the first listed warnings are triggered in the most number of files, while the last in the fewest number of files. So if anyone were to try to address the remaining warnings, it would make sense to chop of this list from the back. >> >> I believe the warnings that are disabled on a per-file basis can most likely be fixed relatively easily. >> >> I have verified this by Oracle's internal CI system, and GitHub Actions. (But I have not yet gotten a fully green run due to instabilities in GHA, however this patch can't reasonably have anything to do with that.) As always, warnings tend to differ a bit between compilers, so if someone wants to take this on a spin with some other version, please go ahead. If I missed some warning, in worst case we'll just have to add it back again, and in the meanwhile `configure --disable-warnings-as-errors` is an okay workaround. >> >> It also turned out that JDK-8294281 did not save the new per-file warnings in VarDeps, so I had to move $1_WARNINGS_FLAGS from $1_BASE_CFLAGS to $1_CFLAGS (and similar for C++). >> >> Annoyingly, the assert macro triggers `tautological-constant-out-of-range-compare` on clang, so while this is a single problem in a single file, this erupts all over the place in debug builds. If this can be fixed, the ugly extra `DISABLED_WARNINGS_clang += tautological-constant-out-of-range-compare` for non-release builds can be removed. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Revert jvm variants hack Also consider transplanting the `-Wno*` clauses from `JvmOverrideFiles.gmk`? ------------- PR: https://git.openjdk.org/jdk/pull/10414 From kbarrett at openjdk.org Thu Sep 29 11:10:10 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 29 Sep 2022 11:10:10 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3] In-Reply-To: <8HwXXsQs7ymwwOCwOYVeyISo6akG2_XBOVf2ILTjFuQ=.5b323620-ca06-4200-9301-2f64bbc85374@github.com> References: <8HwXXsQs7ymwwOCwOYVeyISo6akG2_XBOVf2ILTjFuQ=.5b323620-ca06-4200-9301-2f64bbc85374@github.com> Message-ID: On Wed, 28 Sep 2022 13:41:06 GMT, Johan Sj?len wrote: >> Or you could have the class that requires dynamic mtFlag be declared with mtNone and assert in one place in AllocateHeap that mt != mtNone. Actually that assert might already be there. Can't really puzzle out what Kim's change does. > > I added a mtInvalid flag and did the assert. mtNone seems to be dealt with in some code, I'm not sure if it's appropriate to use it as an invalid value. Regardless, mtInvalid is a better name (for this purpose), so maybe we can change mtNone to mtInvalid in the future? A much simpler (in the sense of avoiding the use of advanced template features) alternative to the one I posted earlier. (Thanks to @stefank for the suggestion.) https://github.com/openjdk/jdk/compare/master...kimbarrett:openjdk-jdk:dynamic-memflags-specialize I dislike the current proposed approach of adding an optional MEMFLAGS argument to all the CHeapObj allocation functions. ------------- PR: https://git.openjdk.org/jdk/pull/10412 From jwaters at openjdk.org Thu Sep 29 12:48:57 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 29 Sep 2022 12:48:57 GMT Subject: RFR: 8292016: Split Windows API error handling from errors passed through the runtime in the JDK [v23] In-Reply-To: References: Message-ID: <848hjAUCbJoQ73DcSuGU-NTyqVOysvrBnBAWL5kjPlo=.19910ff8-4e4f-4efe-a323-fef8b403a770@github.com> > EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime. Julian Waters 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 remote-tracking branch 'upstream/master' into rework - Cleanup - Replace JLI_ReportErrorMessageSys with JLI_Perror - Merge remote-tracking branch 'upstream/master' into rework - Whitespace - Split Windows API error handling from errors passed through the runtime ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/622af5c6..80ef56dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=21-22 Stats: 11159 lines in 266 files changed: 5381 ins; 4933 del; 845 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From kbarrett at openjdk.org Thu Sep 29 13:28:24 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 29 Sep 2022 13:28:24 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 22:49:01 GMT, Kim Barrett wrote: >> My reasoning is that #cards in the bounded thread-buffers doesn't necessarily follow a normal distribution, so one can't predict the future valuse using avg + std. Taking an extreme example of a single thread-buffer, if the population avg is ~buffer_capacity, #cards in the thread-buffer can exhibit large jumps btw 0 and ~buffer_capacity due to the implicit modulo operation. >> >>> It's not a very accurate prediction, but it's >> still worth doing. >> >> Which benchmark shows its effect? I hard-coded `size_t predicted_thread_buffer_cards = 0;` in `G1Policy::record_young_collection_end` but can't see much difference. Normally, #cards in global dirty queue should be >> #cards in thread-local buffers. > > Here's an example log line from my development machine: > [241.020s][debug][gc,ergo,refine ] GC(27) GC refinement: goal: 86449 + 8201 / 2.00ms, actual: 100607 / 2.32ms, HCC: 1024 / 0.00ms (exceeded goal) > Note the cards in thread buffers prediction (8149) is approaching 10% of the goal. > This is from specjbb2015 with > `-Xmx40g -XX:MaxGCPauseMillis=100 -XX:G1RSetUpdatingPauseTimePercent=2` > on a machine with 32 cores. > > specjbb2015 with default pause time and refinement budget probably won't see > much impact from the cards still in buffers because the goal will be so much > larger. OTOH, such a configuration also probably does very little concurrent > refinement. > > Lest one thinks that configuration is unreasonable or unlikely, part of the > point of this change is to improve the behavior with a smaller percentage of a > pause budgeted for refinement. That allows more time in a pause for other > things, like evacuation. (Even with that more restrictive condiguration > specjbb2015 still doesn't do much concurrent refinement. For example, during > the mutator phase before that GC there was never more than one refinement > thread running, and it was only running for about the last 5% of the phase.) > > I'm using the prediction infrastructure to get a moving average over several > recent samples, to get a number that has some basis. The stdev implicit in > that infrastructure makes the result a bit higher than the average. I think > probably doesn't matter much, as none of the inputs nor the calculations that > use them are very precise. But the behavior does seem to be worse (in the > sense of more frequently blowing the associated budget and by larger amounts) > if this isn't accounted for to some extent. > > But maybe your point is more about the stddev, and that should not be > included. I can see that, and could just use the moving average. I experimented with using the average rather than the prediction. The difference between the two is not large (estimating just by eye, average difference is in the neighborhood of 10%). Using the average seems more appropriate though, so I don't mind changing to it. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From kbarrett at openjdk.org Thu Sep 29 13:33:33 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 29 Sep 2022 13:33:33 GMT Subject: RFR: 8137022: Concurrent refinement thread adjustment and (de-)activation suboptimal [v3] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 15:49:36 GMT, Kim Barrett wrote: >> src/hotspot/share/gc/g1/g1Policy.cpp line 963: >> >>> 961: hcc_cards, >>> 962: merge_hcc_time_ms, >>> 963: (exceeded_goal ? " (exceeded goal)" : "")); >> >> Since the pending cards target is initialized to `SIZE_MAX`, the first GC this will always print: >> >> GC(0) GC refinement: goal: 18446744073709551615 ... >> >> >> Not sure if printing 0 is much better but it looks more "buggy" to print `SIZE_MAX` imo. > > Oh, I forgot about that. I was going to try to come up with something better there, like somehow printing "unlimited" or something like that. Stefan and I talked about this offline, and decided to leave it as is for now. - Printing a string like "unlimited" for that case makes parsing more complicated. - Printing 0 can be confusing because that's a valid value. Neither of us likes log messages that contain "lies". - Suppressing the message in this case loses the information used to calculate the first normal value. ------------- PR: https://git.openjdk.org/jdk/pull/10256 From jbhateja at openjdk.org Thu Sep 29 15:22:25 2022 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 29 Sep 2022 15:22:25 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v11] In-Reply-To: <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com> References: <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com> Message-ID: On Wed, 28 Sep 2022 17:40:36 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comment to update test case Thanks @smita-kamath, patch looks good to me. ------------- Marked as reviewed by jbhateja (Reviewer). PR: https://git.openjdk.org/jdk/pull/9781 From jwaters at openjdk.org Thu Sep 29 15:38:29 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 29 Sep 2022 15:38:29 GMT Subject: RFR: 8292016: Split Windows API error handling from errors passed through the runtime in the JDK [v24] In-Reply-To: References: Message-ID: > EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Remove getErrorString ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/80ef56dc..00c955ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=22-23 Stats: 110 lines in 8 files changed: 0 ins; 102 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From shade at openjdk.org Thu Sep 29 16:13:14 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 29 Sep 2022 16:13:14 GMT Subject: RFR: 8294591: Fix cast-function-type warning in TemplateTable Message-ID: After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have `templateTable.cpp` excluded with cast-function-type warning. The underlying cause for it is casting functions for `ldc` bytecodes, which take `bool`-typed handlers: ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/10493/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10493&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294591 Stats: 44 lines in 10 files changed: 9 ins; 0 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/10493.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10493/head:pull/10493 PR: https://git.openjdk.org/jdk/pull/10493 From shade at openjdk.org Thu Sep 29 16:13:38 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 29 Sep 2022 16:13:38 GMT Subject: RFR: 8294211: Zero: Decode arch-specific error context if possible [v3] In-Reply-To: References: <68x5tTa2dHOc-tAj6OfoLSK2MNK2GN2io8qj1POUT2I=.b4ef9779-3b2a-4af4-aa1b-166375420547@github.com> Message-ID: On Thu, 29 Sep 2022 10:48:38 GMT, Aleksey Shipilev wrote: >> After POSIX signal refactorings, Zero error handling had "regressed" a bit: Zero always gets `NULL` as `pc` in error handling code, and thus it fails with SEGV at pc=0x0. We can do better by implementing context decoding where possible. >> >> Unfortunately, this introduces some arch-specific code in Zero code. The arch-specific code is copy-pasted (with inline definitions, if needed) from the relevant `os_linux_*.cpp` files. The unimplemented arches would still report the same confusing `hs_err`-s. We can emulate (and thus test) the generic behavior using new diagnostic VM option. >> >> This reverts parts of [JDK-8259392](https://bugs.openjdk.org/browse/JDK-8259392). >> >> Sample test: >> >> >> import java.lang.reflect.*; >> import sun.misc.Unsafe; >> >> public class Crash { >> public static void main(String... args) throws Exception { >> Field f = Unsafe.class.getDeclaredField("theUnsafe"); >> f.setAccessible(true); >> Unsafe u = (Unsafe) f.get(null); >> u.getInt(42); // accesing via broken ptr >> } >> } >> >> >> Linux x86_64 Zero fastdebug crash currently: >> >> >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=538793, tid=538794 >> # >> ... >> # (no native frame info) >> ... >> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a >> >> >> Linux x86_64 Zero fastdebug crash with this patch: >> >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00007fbbbf08b584, pid=520119, tid=520120 >> # >> ... >> # Problematic frame: >> # V [libjvm.so+0xcbe584] Unsafe_GetInt+0xe4 >> .... >> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a >> >> >> Linux x86_64 Zero fastdebug crash with this patch and `-XX:-DecodeErrorContext`: >> >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x0000000000000000, pid=520268, tid=520269 >> # >> ... >> # Problematic frame: >> # C 0x0000000000000000 >> ... >> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000002a >> >> >> Additional testing: >> - [x] Linux x86_64 Zero fastdebug eyeballing crash logs >> - [x] Linux x86_64 Zero fastdebug, `tier1` >> - [x] Linux {x86_64, x86_32, aarch64, arm, riscv64, s390x, ppc64le, ppc64be} Zero fastdebug builds > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8294211-zero-error-context > - Style nits > - Fix I think this still works. Any other reviews, please? ------------- PR: https://git.openjdk.org/jdk/pull/10397 From shade at openjdk.org Thu Sep 29 16:26:24 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 29 Sep 2022 16:26:24 GMT Subject: RFR: 8294591: Fix cast-function-type warning in TemplateTable [v2] In-Reply-To: References: Message-ID: > After [JDK-8294314](https://bugs.openjdk.org/browse/JDK-8294314), we would have `templateTable.cpp` excluded with cast-function-type warning. The underlying cause for it is casting functions for `ldc` bytecodes, which take `bool`-typed handlers: Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Also disable warnings in gtests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10493/files - new: https://git.openjdk.org/jdk/pull/10493/files/9be451ad..3f310c8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10493&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10493&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10493.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10493/head:pull/10493 PR: https://git.openjdk.org/jdk/pull/10493 From vladimir.kozlov at oracle.com Thu Sep 29 17:20:33 2022 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Sep 2022 10:20:33 -0700 Subject: =?UTF-8?Q?New_HotSpot_Group_Member=3a_Roberto_Casta=c3=b1eda_Lozano?= Message-ID: Voting for Roberto Casta?eda Lozano [1] is now closed. Yes: 16 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Vladimir Kozlov [1] https://mail.openjdk.org/pipermail/hotspot-dev/2022-September/064240.html From vladimir.kozlov at oracle.com Thu Sep 29 17:25:16 2022 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Sep 2022 10:25:16 -0700 Subject: Result: New HotSpot Group Member: Tobias Holenstein Message-ID: <67ae1092-ef8a-c46f-b1ac-c019a783fcd5@oracle.com> Voting for Tobias Holenstein [1] is now closed. Yes: 17 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Vladimir Kozlov [1] https://mail.openjdk.org/pipermail/hotspot-dev/2022-September/064243.html From vladimir.kozlov at oracle.com Thu Sep 29 17:31:41 2022 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Sep 2022 10:31:41 -0700 Subject: =?UTF-8?Q?Result=3a_New_HotSpot_Group_Member=3a_Roberto_Casta=c3=b1?= =?UTF-8?Q?eda_Lozano?= Message-ID: <506873e6-e56f-2e4c-2a5a-d03f2c0bf71f@oracle.com> Voting for Roberto Casta?eda Lozano [1] is now closed. Yes: 16 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Vladimir Kozlov [1] https://mail.openjdk.org/pipermail/hotspot-dev/2022-September/064240.html From svkamath at openjdk.org Thu Sep 29 17:49:27 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Thu, 29 Sep 2022 17:49:27 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Wed, 21 Sep 2022 16:41:19 GMT, Vladimir Kozlov wrote: >> Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed review comments > > tier2 and 3 passed. I will wait update with test and JVMCI fix before doing more testing. @vnkozlov I have addressed all review comments. Could you please run the patch through your testing? Thanks a lot for all the help. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From kvn at openjdk.org Thu Sep 29 18:17:33 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 29 Sep 2022 18:17:33 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v11] In-Reply-To: <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com> References: <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com> Message-ID: On Wed, 28 Sep 2022 17:40:36 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comment to update test case I submitted new testing (for version 10). ------------- PR: https://git.openjdk.org/jdk/pull/9781 From kvn at openjdk.org Thu Sep 29 18:39:24 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 29 Sep 2022 18:39:24 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Thu, 29 Sep 2022 17:45:49 GMT, Smita Kamath wrote: >> tier2 and 3 passed. I will wait update with test and JVMCI fix before doing more testing. > > @vnkozlov I have addressed all review comments. Could you please run the patch through your testing? Thanks a lot for all the help. @smita-kamath I have builds failures. Please, build and test yourself to verify changes. src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evcvtps2ph(Address, KRegister, XMMRegister, int, int)': src/hotspot/cpu/x86/assembler_x86.cpp:1950:15: error: no matching function for call to 'Assembler::emit_operand(XMMRegister&, Address&)' emit_operand(src, dst); ------------- PR: https://git.openjdk.org/jdk/pull/9781 From avoitylov at openjdk.org Thu Sep 29 18:48:17 2022 From: avoitylov at openjdk.org (Aleksei Voitylov) Date: Thu, 29 Sep 2022 18:48:17 GMT Subject: RFR: 8294198: Implement isFinite intrinsic for RISC-V In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 17:20:02 GMT, Joe Darcy wrote: >> Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR. >> >> benchmark results: >> >> before: >> >> Benchmark Mode Cnt Score Error Units >> DoubleClassCheck.testIsFiniteBranch avgt 15 52.824 ? 1.744 ns/op >> DoubleClassCheck.testIsFiniteCMov avgt 15 16.104 ? 0.358 ns/op >> DoubleClassCheck.testIsFiniteStore avgt 15 14.366 ? 2.174 ns/op >> FloatClassCheck.testIsFiniteBranch avgt 15 49.821 ? 0.330 ns/op >> FloatClassCheck.testIsFiniteCMov avgt 15 14.702 ? 0.335 ns/op >> FloatClassCheck.testIsFiniteStore avgt 15 14.749 ? 0.496 ns/op >> >> after: >> >> DoubleClassCheck.testIsFiniteBranch avgt 15 48.921 ? 0.557 ns/op >> DoubleClassCheck.testIsFiniteCMov avgt 15 13.716 ? 0.304 ns/op >> DoubleClassCheck.testIsFiniteStore avgt 15 9.152 ? 0.158 ns/op >> FloatClassCheck.testIsFiniteBranch avgt 15 47.740 ? 2.028 ns/op >> FloatClassCheck.testIsFiniteCMov avgt 15 13.299 ? 0.282 ns/op >> FloatClassCheck.testIsFiniteStore avgt 15 9.185 ? 0.396 ns/op >> >> Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way. >> >> Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues. > > The java.lang.* changes look fine if the rest of the work proceeds. Thank you @jddarcy @RealFYang @vnkozlov for your reviews. I also ran the benchmarks with -XX:LoopUnrollLimit=0 -XX:LoopMaxUnroll=0 and see the improvement with these flags as well. ------------- PR: https://git.openjdk.org/jdk/pull/10391 From avoitylov at openjdk.org Thu Sep 29 18:54:40 2022 From: avoitylov at openjdk.org (Aleksei Voitylov) Date: Thu, 29 Sep 2022 18:54:40 GMT Subject: Integrated: 8294198: Implement isFinite intrinsic for RISC-V In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 12:56:49 GMT, Aleksei Voitylov wrote: > Unlike on x86 (see 8285868 and the discussion in review), isFinite intrinsic turned out to be profitable on RISC-V using the same fclass instruction as for 8293695 (isInfinite instrinsic). Therefore, I'm proposing to have it added on RISC-V in this PR. > > benchmark results: > > before: > > Benchmark Mode Cnt Score Error Units > DoubleClassCheck.testIsFiniteBranch avgt 15 52.824 ? 1.744 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 16.104 ? 0.358 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 14.366 ? 2.174 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 49.821 ? 0.330 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 14.702 ? 0.335 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 14.749 ? 0.496 ns/op > > after: > > DoubleClassCheck.testIsFiniteBranch avgt 15 48.921 ? 0.557 ns/op > DoubleClassCheck.testIsFiniteCMov avgt 15 13.716 ? 0.304 ns/op > DoubleClassCheck.testIsFiniteStore avgt 15 9.152 ? 0.158 ns/op > FloatClassCheck.testIsFiniteBranch avgt 15 47.740 ? 2.028 ns/op > FloatClassCheck.testIsFiniteCMov avgt 15 13.299 ? 0.282 ns/op > FloatClassCheck.testIsFiniteStore avgt 15 9.185 ? 0.396 ns/op > > Existing isInfinite jtreg test was altered to be able to use common code for isFinite test and fine-grained requires tag filtering. Existing benchmark was modified to include isFinite case. A typo ("Atleast" -> "At least") was fixed on the way. > > Test passed on both release and fastdebug builds. Hotspot tier1 tests were run on x86_64 and RISC-V with no issues. This pull request has now been integrated. Changeset: aeef3ecd Author: Aleksei Voitylov Committer: Vladimir Kozlov URL: https://git.openjdk.org/jdk/commit/aeef3ecdc4d99d4bfb9e762cb038d9571c3c56df Stats: 363 lines in 17 files changed: 315 ins; 47 del; 1 mod 8294198: Implement isFinite intrinsic for RISC-V Reviewed-by: fyang, kvn ------------- PR: https://git.openjdk.org/jdk/pull/10391 From qamai at openjdk.org Thu Sep 29 20:22:57 2022 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Sep 2022 20:22:57 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v10] In-Reply-To: References: Message-ID: > This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: > > vptest xmm0, xmm1 > jb if_true > if_false: > > instead of: > > vptest xmm0, xmm1 > setb r10 > movzbl r10 > testl r10 > jne if_true > if_false: > > The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: > > Before After > Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change > ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% > > I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - remove untaken code paths - Merge branch 'master' into improveVTest - Merge branch 'master' into improveVTest - Merge branch 'master' into improveVTest - fix merge problems - Merge branch 'master' into improveVTest - refactor x86 - revert renaming temp - style + use rscratch instead of tmp - fix - ... and 17 more: https://git.openjdk.org/jdk/compare/3419363e...de28e400 ------------- Changes: https://git.openjdk.org/jdk/pull/9855/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=09 Stats: 491 lines in 23 files changed: 212 ins; 171 del; 108 mod Patch: https://git.openjdk.org/jdk/pull/9855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9855/head:pull/9855 PR: https://git.openjdk.org/jdk/pull/9855 From qamai at openjdk.org Thu Sep 29 20:29:24 2022 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Sep 2022 20:29:24 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v11] In-Reply-To: References: Message-ID: > This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: > > vptest xmm0, xmm1 > jb if_true > if_false: > > instead of: > > vptest xmm0, xmm1 > setb r10 > movzbl r10 > testl r10 > jne if_true > if_false: > > The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: > > Before After > Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change > ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% > ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% > ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% > ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% > ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% > ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% > ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% > ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% > > I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: redundant casts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9855/files - new: https://git.openjdk.org/jdk/pull/9855/files/de28e400..3480504c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9855&range=09-10 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9855.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9855/head:pull/9855 PR: https://git.openjdk.org/jdk/pull/9855 From qamai at openjdk.org Thu Sep 29 20:29:28 2022 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Sep 2022 20:29:28 GMT Subject: RFR: 8292289: [vectorapi] Improve the implementation of VectorTestNode [v10] In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 20:22:57 GMT, Quan Anh Mai wrote: >> This patch modifies the node generation of `VectorSupport::test` to emit a `CMoveINode`, which is picked up by `BoolNode::Ideal(PhaseGVN*, bool)` to connect the `VectorTestNode` directly to the `BoolNode`, removing the redundant operations of materialising the test result in a GP register and do a `CmpI` to get back the flags. As a result, `VectorMask::alltrue` is compiled into machine codes: >> >> vptest xmm0, xmm1 >> jb if_true >> if_false: >> >> instead of: >> >> vptest xmm0, xmm1 >> setb r10 >> movzbl r10 >> testl r10 >> jne if_true >> if_false: >> >> The results of `jdk.incubator.vector.ArrayMismatchBenchmark` shows noticeable improvements: >> >> Before After >> Benchmark Prefix Size Mode Cnt Score Error Score Error Units Change >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 9 thrpt 10 217345.383 ? 8316.444 222279.381 ? 2660.983 ops/ms +2.3% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 257 thrpt 10 113918.406 ? 1618.836 116268.691 ? 1291.899 ops/ms +2.1% >> ArrayMismatchBenchmark.mismatchVectorByte 0.5 100000 thrpt 10 702.066 ? 72.862 797.806 ? 16.429 ops/ms +13.6% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 9 thrpt 10 146096.564 ? 2401.258 145338.910 ? 687.453 ops/ms -0.5% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 257 thrpt 10 60598.181 ? 1259.397 69041.519 ? 1073.156 ops/ms +13.9% >> ArrayMismatchBenchmark.mismatchVectorByte 1.0 100000 thrpt 10 316.814 ? 10.975 408.770 ? 5.281 ops/ms +29.0% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 9 thrpt 10 195674.549 ? 1200.166 188482.433 ? 1872.076 ops/ms -3.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 257 thrpt 10 44357.169 ? 473.013 42293.411 ? 2838.255 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorDouble 0.5 100000 thrpt 10 68.199 ? 5.410 67.628 ? 3.241 ops/ms -0.8% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 9 thrpt 10 107722.450 ? 1677.607 111060.400 ? 982.230 ops/ms +3.1% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 257 thrpt 10 16692.645 ? 1002.599 21440.506 ? 1618.266 ops/ms +28.4% >> ArrayMismatchBenchmark.mismatchVectorDouble 1.0 100000 thrpt 10 32.984 ? 0.548 33.202 ? 2.365 ops/ms +0.7% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 9 thrpt 10 335458.217 ? 3154.842 379944.254 ? 5703.134 ops/ms +13.3% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 257 thrpt 10 58505.302 ? 786.312 56721.368 ? 2497.052 ops/ms -3.0% >> ArrayMismatchBenchmark.mismatchVectorInt 0.5 100000 thrpt 10 133.037 ? 11.415 139.537 ? 4.667 ops/ms +4.9% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 9 thrpt 10 117943.802 ? 2281.349 112409.365 ? 2110.055 ops/ms -4.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 257 thrpt 10 27060.015 ? 795.619 33756.613 ? 826.533 ops/ms +24.7% >> ArrayMismatchBenchmark.mismatchVectorInt 1.0 100000 thrpt 10 57.558 ? 8.927 66.951 ? 4.381 ops/ms +16.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 9 thrpt 10 182963.715 ? 1042.497 182438.405 ? 2120.832 ops/ms -0.3% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 257 thrpt 10 36672.215 ? 614.821 35397.398 ? 1609.235 ops/ms -3.5% >> ArrayMismatchBenchmark.mismatchVectorLong 0.5 100000 thrpt 10 66.438 ? 2.142 65.427 ? 2.270 ops/ms -1.5% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 9 thrpt 10 110393.047 ? 497.853 115165.845 ? 5381.674 ops/ms +4.3% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 257 thrpt 10 14720.765 ? 661.350 19871.096 ? 201.464 ops/ms +35.0% >> ArrayMismatchBenchmark.mismatchVectorLong 1.0 100000 thrpt 10 30.760 ? 0.821 31.933 ? 1.352 ops/ms +3.8% >> >> I have not been able to conduct throughout testing on AVX512 and Aarch64 so any help would be invaluable. Thank you very much. > > Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - remove untaken code paths > - Merge branch 'master' into improveVTest > - Merge branch 'master' into improveVTest > - Merge branch 'master' into improveVTest > - fix merge problems > - Merge branch 'master' into improveVTest > - refactor x86 > - revert renaming temp > - style + use rscratch instead of tmp > - fix > - ... and 17 more: https://git.openjdk.org/jdk/compare/3419363e...de28e400 Similar to what has been discussed in #10192 , a mask of 512 bits is not matched into an XMMRegister, I have removed the untaken code paths. ------------- PR: https://git.openjdk.org/jdk/pull/9855 From svkamath at openjdk.org Fri Sep 30 00:13:26 2022 From: svkamath at openjdk.org (Smita Kamath) Date: Fri, 30 Sep 2022 00:13:26 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: <6q8gs4wdve3OSfdHZsca1jVyt_RxZAvYZTm-Ve8GFtE=.11f0ecfa-9944-44cb-ba8d-d1e231dbb13d@github.com> On Thu, 29 Sep 2022 18:34:41 GMT, Vladimir Kozlov wrote: >> @vnkozlov I have addressed all review comments. Could you please run the patch through your testing? Thanks a lot for all the help. > > @smita-kamath I have builds failures. Please, build and test yourself to verify changes. > > src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evcvtps2ph(Address, KRegister, XMMRegister, int, int)': > src/hotspot/cpu/x86/assembler_x86.cpp:1950:15: error: no matching function for call to 'Assembler::emit_operand(XMMRegister&, Address&)' > emit_operand(src, dst); Hi @vnkozlov, I apologize for the inconvenience. However, I don't see any build failures on Windows or Linux. Can you please let me know the platform for which your build fails? Thanks a lot. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From sviswanathan at openjdk.org Fri Sep 30 00:19:23 2022 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 30 Sep 2022 00:19:23 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Thu, 29 Sep 2022 18:34:41 GMT, Vladimir Kozlov wrote: >> @vnkozlov I have addressed all review comments. Could you please run the patch through your testing? Thanks a lot for all the help. > > @smita-kamath I have builds failures. Please, build and test yourself to verify changes. > > src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evcvtps2ph(Address, KRegister, XMMRegister, int, int)': > src/hotspot/cpu/x86/assembler_x86.cpp:1950:15: error: no matching function for call to 'Assembler::emit_operand(XMMRegister&, Address&)' > emit_operand(src, dst); @vnkozlov I also don't see any build issue. I tried creating a dummy draft PR under my fork to get the GHA to run. But looks like now-a-days GHA doesn't run on draft PR. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From darcy at openjdk.org Fri Sep 30 00:40:24 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 00:40:24 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org Message-ID: With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. Updates were made using a shell script. I"ll run a copyright updater before any push. ------------- Commit messages: - JDK-8294618: Update openjdk.java.net => openjdk.org Changes: https://git.openjdk.org/jdk/pull/10501/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294618 Stats: 79 lines in 39 files changed: 0 ins; 0 del; 79 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 00:54:05 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 00:54:05 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2] In-Reply-To: References: Message-ID: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com> > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: - Update copyright. - Revert unintended update to binary file. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/b12d774f..2f257762 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00-01 Stats: 10 lines in 11 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From mikael at openjdk.org Fri Sep 30 00:54:06 2022 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 30 Sep 2022 00:54:06 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2] In-Reply-To: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com> References: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com> Message-ID: On Fri, 30 Sep 2022 00:50:13 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright. > - Revert unintended update to binary file. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10501 From mikael at openjdk.org Fri Sep 30 00:54:08 2022 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 30 Sep 2022 00:54:08 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 00:33:57 GMT, Joe Darcy wrote: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Switch to https where needed/applicable while at it? ------------- PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 01:01:29 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 01:01:29 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v3] In-Reply-To: References: Message-ID: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Undo manpage update. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/2f257762..04dfc3ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 01:11:45 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 01:11:45 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: http -> https ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/04dfc3ef..cee96d0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02-03 Stats: 22 lines in 6 files changed: 0 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 01:11:45 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 01:11:45 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 00:48:02 GMT, Mikael Vidstedt wrote: > Switch to https where needed/applicable while at it? Good idea; might as well do the update in a single changeset. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From sviswanathan at openjdk.org Fri Sep 30 03:15:32 2022 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 30 Sep 2022 03:15:32 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Thu, 29 Sep 2022 18:34:41 GMT, Vladimir Kozlov wrote: >> @vnkozlov I have addressed all review comments. Could you please run the patch through your testing? Thanks a lot for all the help. > > @smita-kamath I have builds failures. Please, build and test yourself to verify changes. > > src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evcvtps2ph(Address, KRegister, XMMRegister, int, int)': > src/hotspot/cpu/x86/assembler_x86.cpp:1950:15: error: no matching function for call to 'Assembler::emit_operand(XMMRegister&, Address&)' > emit_operand(src, dst); @vnkozlov I spoke too soon. All the GHA tests passed in the dummy draft PR I created using Smita's patch: https://github.com/openjdk/jdk/pull/10500 Please take a look. No build failures reported and all tier1 tests passed. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From fyang at openjdk.org Fri Sep 30 04:00:31 2022 From: fyang at openjdk.org (Fei Yang) Date: Fri, 30 Sep 2022 04:00:31 GMT Subject: RFR: 8293770: RISC-V: Reuse runtime call trampolines [v3] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 01:59:56 GMT, Dingli Zhang wrote: >> Follow up [JDK-8280152](https://bugs.openjdk.org/browse/JDK-8280152), this case also exists in riscv. >> >> Benchmark als, chi-square, dec-tree, log-regression, naive-bayes, page-rank, fj-kmeans, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~2.1% reduction on average. >> >> ## Testing: >> >> - hotspot and jdk tier1 on unmatched board without new failures >> - hotspot/jtreg/compiler/sharedstubs/SharedTrampolineTest.java with fastdebug on qemu >> >> >> ## Results >> #### Results from [Renaissance 0.14.1](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.1) >> >> - riscv64 >> >> +--------------------------------------------------------------------------------------------------------+ >> | | Before | After | >> | Benchmark |---------------------------------------------------------------------------------------| >> | | non-profiled nmethods | profiled nmethods | non-profiled nmethods | profiled nmethods | >> +----------------+-----------------------+-------------------+-----------------------+-------------------| >> | als | 15628 | 39421 | 12341 | 26681 | >> | chi-square | 6349 | 20268 | 6033 | 20252 | >> | dec-tree | 11058 | 42443 | 10774 | 43880 | >> | log-regression | 10939 | 38237 | 12071 | 44199 | >> | naive-bayes | 9023 | 29563 | 9294 | 30948 | >> | page-rank | 6054 | 17041 | 5812 | 17353 | >> | fj-kmeans | 692 | 2893 | 651 | 3354 | >> | reactors | 2126 | 4073 | 1876 | 4106 | >> | future-genetic | 1306 | 4118 | 1226 | 4142 | >> | mnemonics | 726 | 2659 | 706 | 2684 | >> | dotty | 26059 | 24417 | 24585 | 25379 | >> | scala-kmeans | 564 | 3122 | 543 | 3132 | >> | finagle-http | 6188 | 12455 | 6102 | 12295 | >> | sum | 96712 | 240710 | 92014 | 238405 | >> +--------------------------------------------------------------------------------------------------------+ > > Dingli Zhang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Fix alignment > - Simplify targe related jal call in macroAssembler_riscv.cpp > - Port JDK-8280152 to RISC-V > > Co-authored-by: zifeihan Updated change looks good. Since this changes a shared test, better to have another review. Maybe @shipilev ? ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.org/jdk/pull/10260 From iris at openjdk.org Fri Sep 30 04:11:19 2022 From: iris at openjdk.org (Iris Clark) Date: Fri, 30 Sep 2022 04:11:19 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > http -> https Marked as reviewed by iris (Reviewer). src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: > 32: * the following link: > 33: * > 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c The domain for hg wasn't changed to openjdk.org. The original URL is correct. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From joe.darcy at oracle.com Fri Sep 30 04:41:06 2022 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 29 Sep 2022 21:41:06 -0700 Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: <857259f1-daa2-46a0-ded8-24d866482707@oracle.com> Thanks for catching that Iris; I'll changes those to git URLs. -Joe On 9/29/2022 9:11 PM, Iris Clark wrote: > On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: > >>> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >>> >>> Updates were made using a shell script. I"ll run a copyright updater before any push. >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> http -> https > Marked as reviewed by iris (Reviewer). > > src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: > >> 32: * the following link: >> 33: * >> 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c > The domain for hg wasn't changed to openjdk.org. The original URL is correct. > > ------------- > > PR: https://git.openjdk.org/jdk/pull/10501 From rrich at openjdk.org Fri Sep 30 05:59:42 2022 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 30 Sep 2022 05:59:42 GMT Subject: RFR: 8294580: frame::interpreter_frame_print_on() crashes if free BasicObjectLock exists in frame Message-ID: Add null check before dereferencing BasicObjectLock::_obj. BasicObjectLocks are marked as free by setting _obj to null. I've done manual testing: ./images/jdk/bin/java -Xlog:continuations=trace -XX:+VerifyContinuations --enable-preview VTSleepAfterUnlock with the test attached to the JBS item. Example output: [0.349s][trace][continuations] Interpreted frame (sp=0x000000011d5c6398 unextended sp=0x000000011d5c63b8, fp=0x000000011d5c6420, real_fp=0x000000011d5c6420, pc=0x00007f0ff0199c6a) [0.349s][trace][continuations] ~return entry points [0x00007f0ff0199820, 0x00007f0ff019a2e8] 2760 bytes [0.349s][trace][continuations] - local [0x000000011d5c3550]; #0 [0.349s][trace][continuations] - local [0x000000011d5c3550]; #1 [0.349s][trace][continuations] - local [0x0000000000000000]; #2 [0.349s][trace][continuations] - stack [0x0000000000000064]; #1 [0.349s][trace][continuations] - stack [0x0000000000000000]; #0 [0.349s][trace][continuations] - obj [null] [0.349s][trace][continuations] - lock [monitor mark(is_neutral no_hash age=0)] [0.349s][trace][continuations] - monitor[0x000000011d5c63d8] [0.349s][trace][continuations] - bcp [0x00007f0fa8400401]; @17 [0.349s][trace][continuations] - locals [0x000000011d5c6440] [0.349s][trace][continuations] - method [0x00007f0fa8400430]; virtual void VTSleepAfterUnlock.sleepAfterUnlock() ------------- Commit messages: - Add null check Changes: https://git.openjdk.org/jdk/pull/10486/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10486&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294580 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10486.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10486/head:pull/10486 PR: https://git.openjdk.org/jdk/pull/10486 From shade at openjdk.org Fri Sep 30 06:52:23 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 30 Sep 2022 06:52:23 GMT Subject: RFR: 8293770: RISC-V: Reuse runtime call trampolines [v3] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 01:59:56 GMT, Dingli Zhang wrote: >> Follow up [JDK-8280152](https://bugs.openjdk.org/browse/JDK-8280152), this case also exists in riscv. >> >> Benchmark als, chi-square, dec-tree, log-regression, naive-bayes, page-rank, fj-kmeans, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~2.1% reduction on average. >> >> ## Testing: >> >> - hotspot and jdk tier1 on unmatched board without new failures >> - hotspot/jtreg/compiler/sharedstubs/SharedTrampolineTest.java with fastdebug on qemu >> >> >> ## Results >> #### Results from [Renaissance 0.14.1](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.1) >> >> - riscv64 >> >> +--------------------------------------------------------------------------------------------------------+ >> | | Before | After | >> | Benchmark |---------------------------------------------------------------------------------------| >> | | non-profiled nmethods | profiled nmethods | non-profiled nmethods | profiled nmethods | >> +----------------+-----------------------+-------------------+-----------------------+-------------------| >> | als | 15628 | 39421 | 12341 | 26681 | >> | chi-square | 6349 | 20268 | 6033 | 20252 | >> | dec-tree | 11058 | 42443 | 10774 | 43880 | >> | log-regression | 10939 | 38237 | 12071 | 44199 | >> | naive-bayes | 9023 | 29563 | 9294 | 30948 | >> | page-rank | 6054 | 17041 | 5812 | 17353 | >> | fj-kmeans | 692 | 2893 | 651 | 3354 | >> | reactors | 2126 | 4073 | 1876 | 4106 | >> | future-genetic | 1306 | 4118 | 1226 | 4142 | >> | mnemonics | 726 | 2659 | 706 | 2684 | >> | dotty | 26059 | 24417 | 24585 | 25379 | >> | scala-kmeans | 564 | 3122 | 543 | 3132 | >> | finagle-http | 6188 | 12455 | 6102 | 12295 | >> | sum | 96712 | 240710 | 92014 | 238405 | >> +--------------------------------------------------------------------------------------------------------+ > > Dingli Zhang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Fix alignment > - Simplify targe related jal call in macroAssembler_riscv.cpp > - Port JDK-8280152 to RISC-V > > Co-authored-by: zifeihan The test change is pretty trivial, TBH. I have not looked into RISC-V parts. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/10260 From dzhang at openjdk.org Fri Sep 30 07:04:31 2022 From: dzhang at openjdk.org (Dingli Zhang) Date: Fri, 30 Sep 2022 07:04:31 GMT Subject: RFR: 8293770: RISC-V: Reuse runtime call trampolines [v2] In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 06:36:58 GMT, Feilong Jiang wrote: >> Dingli Zhang has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. > > Copyright of codeBuffer_riscv.hpp should be update to 2022. @feilongjiang @RealFYang @shipilev Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/10260 From dzhang at openjdk.org Fri Sep 30 07:36:25 2022 From: dzhang at openjdk.org (Dingli Zhang) Date: Fri, 30 Sep 2022 07:36:25 GMT Subject: Integrated: 8293770: RISC-V: Reuse runtime call trampolines In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 02:58:42 GMT, Dingli Zhang wrote: > Follow up [JDK-8280152](https://bugs.openjdk.org/browse/JDK-8280152), this case also exists in riscv. > > Benchmark als, chi-square, dec-tree, log-regression, naive-bayes, page-rank, fj-kmeans, reactors, future-genetic, mnemonics, dotty, scala-kmeans, and finagle-http in Renaissance (0.14.1) are tested. The sum of the used size of CodeHeap 'non-profiled nmethods' and CodeHeap 'profiled nmethods' shows ~2.1% reduction on average. > > ## Testing: > > - hotspot and jdk tier1 on unmatched board without new failures > - hotspot/jtreg/compiler/sharedstubs/SharedTrampolineTest.java with fastdebug on qemu > > > ## Results > #### Results from [Renaissance 0.14.1](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.1) > > - riscv64 > > +--------------------------------------------------------------------------------------------------------+ > | | Before | After | > | Benchmark |---------------------------------------------------------------------------------------| > | | non-profiled nmethods | profiled nmethods | non-profiled nmethods | profiled nmethods | > +----------------+-----------------------+-------------------+-----------------------+-------------------| > | als | 15628 | 39421 | 12341 | 26681 | > | chi-square | 6349 | 20268 | 6033 | 20252 | > | dec-tree | 11058 | 42443 | 10774 | 43880 | > | log-regression | 10939 | 38237 | 12071 | 44199 | > | naive-bayes | 9023 | 29563 | 9294 | 30948 | > | page-rank | 6054 | 17041 | 5812 | 17353 | > | fj-kmeans | 692 | 2893 | 651 | 3354 | > | reactors | 2126 | 4073 | 1876 | 4106 | > | future-genetic | 1306 | 4118 | 1226 | 4142 | > | mnemonics | 726 | 2659 | 706 | 2684 | > | dotty | 26059 | 24417 | 24585 | 25379 | > | scala-kmeans | 564 | 3122 | 543 | 3132 | > | finagle-http | 6188 | 12455 | 6102 | 12295 | > | sum | 96712 | 240710 | 92014 | 238405 | > +--------------------------------------------------------------------------------------------------------+ This pull request has now been integrated. Changeset: 7c60e6d2 Author: Dingli Zhang Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/7c60e6d2d6d92d58e94bf3965b8eacc09ca9c4fe Stats: 72 lines in 4 files changed: 61 ins; 4 del; 7 mod 8293770: RISC-V: Reuse runtime call trampolines Co-authored-by: zifeihan Reviewed-by: fyang, shade ------------- PR: https://git.openjdk.org/jdk/pull/10260 From bkilambi at openjdk.org Fri Sep 30 10:01:27 2022 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Fri, 30 Sep 2022 10:01:27 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v11] In-Reply-To: <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com> References: <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com> Message-ID: <5pqC4k2fyhaYIa9d6D3Dciv2ohYR-JCPvYW7lZsbXhw=.4a3071d6-39b8-4828-86a4-9c3871401844@github.com> On Wed, 28 Sep 2022 17:40:36 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comment to update test case Hi, would you be adding IR tests to verify the generation of the the newly introduced IR nodes? ------------- PR: https://git.openjdk.org/jdk/pull/9781 From qamai at openjdk.org Fri Sep 30 10:08:33 2022 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 30 Sep 2022 10:08:33 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v11] In-Reply-To: <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com> References: <_Ghl2lsnrBhiWvVD3TMiwGo6SfQLl6idczb1QVqLa_I=.7cfa48e2-2987-43e0-a689-0e3462e4d270@github.com> Message-ID: On Wed, 28 Sep 2022 17:40:36 GMT, Smita Kamath wrote: >> 8289552: Make intrinsic conversions between bit representations of half precision values and floats > > Smita Kamath has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review comment to update test case src/hotspot/cpu/x86/x86.ad line 3674: > 3672: %} > 3673: > 3674: instruct convF2HF_mem_reg(memory mem, regF src, kReg ktmp, rRegI rtmp) %{ You can use `kmovwl` instead which will relax the avx512bw constraint, however, you will need avx512vl for `evcvtps2ph`. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From qamai at openjdk.org Fri Sep 30 11:05:08 2022 From: qamai at openjdk.org (Quan Anh Mai) Date: Fri, 30 Sep 2022 11:05:08 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Fri, 30 Sep 2022 03:13:09 GMT, Sandhya Viswanathan wrote: >> @smita-kamath I have builds failures. Please, build and test yourself to verify changes. >> >> src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evcvtps2ph(Address, KRegister, XMMRegister, int, int)': >> src/hotspot/cpu/x86/assembler_x86.cpp:1950:15: error: no matching function for call to 'Assembler::emit_operand(XMMRegister&, Address&)' >> emit_operand(src, dst); > > @vnkozlov I spoke too soon. All the GHA tests passed in the dummy draft PR I created using Smita's patch: > https://github.com/openjdk/jdk/pull/10500 > Please take a look. No build failures reported and all tier1 tests passed. @sviswa7 The failure is due to [JDK-8293618](https://bugs.openjdk.org/browse/JDK-8293618), @smita-kamath please merge with master. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From ihse at openjdk.org Fri Sep 30 14:01:18 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 30 Sep 2022 14:01:18 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > http -> https $ grep -rl doc make -e openjdk.java.net doc/hotspot-unit-tests.html doc/hotspot-style.html doc/building.html doc/hotspot-unit-tests.md doc/hotspot-style.md doc/building.md make/Doctor.gmk make/jdk/src/classes/build/tools/taglet/Incubating.java make/autoconf/configure.ac make/conf/branding.conf Think you can fix those as well? Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..? ------------- PR: https://git.openjdk.org/jdk/pull/10501 From weijun at openjdk.org Fri Sep 30 14:18:28 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 30 Sep 2022 14:18:28 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 04:05:51 GMT, Iris Clark wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> http -> https > > src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: > >> 32: * the following link: >> 33: * >> 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c > > The domain for hg wasn't changed to openjdk.org. The original URL is correct. Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`? ------------- PR: https://git.openjdk.org/jdk/pull/10501 From jsjolen at openjdk.org Fri Sep 30 14:48:50 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 30 Sep 2022 14:48:50 GMT Subject: Integrated: 8294293: Remove unused _width and _newlines field in outputStream In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 15:59:39 GMT, Johan Sj?len wrote: > 1. `_width` is unused so I deleted it > 2. `_newlines` was used in one place, and only to check if any new lines had been seen. I removed `_newlines` and instead used `update_position`'s unused return value to indicate whether any newlines has been seen. This required expanding the call of `xmlTextStream::write` in `defaultStream`. > > This removes some cruft from `outputStream` and saves us 8 bytes on the size of `outputStream`. > > I also noted that `_position` isn't number of chars into a line, but rather a "visual position". It's a bit surprising, which is why I added this comment. This can be seen in the `\t` case in `update_position`. This pull request has now been integrated. Changeset: 052a9249 Author: Johan Sj?len Committer: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/052a924985c9a095c5b45bfdc139b451bb41158e Stats: 25 lines in 2 files changed: 3 ins; 8 del; 14 mod 8294293: Remove unused _width and _newlines field in outputStream Reviewed-by: rehn, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/10411 From jwaters at openjdk.org Fri Sep 30 16:47:25 2022 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 30 Sep 2022 16:47:25 GMT Subject: RFR: 8292016: Split Windows API error handling from errors passed through the runtime in the JDK [v25] In-Reply-To: References: Message-ID: > EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Progress ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/00c955ee..ea8678b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=23-24 Stats: 79 lines in 6 files changed: 67 ins; 3 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Fri Sep 30 17:10:25 2022 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 30 Sep 2022 17:10:25 GMT Subject: RFR: 8292016: Split Windows API error handling from errors passed through the runtime in the JDK [v26] In-Reply-To: References: Message-ID: > EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: JNU_ThrowByNameWithMessageAndLastError ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/ea8678b2..973fb766 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=24-25 Stats: 93 lines in 8 files changed: 58 ins; 1 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Fri Sep 30 17:13:08 2022 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 30 Sep 2022 17:13:08 GMT Subject: RFR: 8292016: Split Windows API error handling from errors passed through the runtime in the JDK [v27] In-Reply-To: References: Message-ID: > EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/973fb766..6ad4d68a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=25-26 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From jwaters at openjdk.org Fri Sep 30 17:18:42 2022 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 30 Sep 2022 17:18:42 GMT Subject: RFR: 8292016: Split Windows API error handling from errors passed through the runtime in the JDK [v28] In-Reply-To: References: Message-ID: <3RSCtmrpHyE-sB9JivBhgx1LJLZEKUv5ZofgljzL4oQ=.d1cc0ea7-7f11-4fc7-b4df-3879fa2bdc4c@github.com> > EDIT: Cave and add the ErrorOrigin enum, to differentiate which error type the error reporting functions in libjava will look up. RUNTIME refers to errors passed through the runtime via errno, and SYSTEM is for native errors not visible to the runtime. Julian Waters 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 12 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into rework - Cleanup - Cleanup - JNU_ThrowByNameWithMessageAndLastError - Progress - Remove getErrorString - Merge remote-tracking branch 'upstream/master' into rework - Cleanup - Replace JLI_ReportErrorMessageSys with JLI_Perror - Merge remote-tracking branch 'upstream/master' into rework - ... and 2 more: https://git.openjdk.org/jdk/compare/47a18bbb...a4fa093e ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9870/files - new: https://git.openjdk.org/jdk/pull/9870/files/6ad4d68a..a4fa093e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9870&range=26-27 Stats: 1843 lines in 102 files changed: 1078 ins; 335 del; 430 mod Patch: https://git.openjdk.org/jdk/pull/9870.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9870/head:pull/9870 PR: https://git.openjdk.org/jdk/pull/9870 From kvn at openjdk.org Fri Sep 30 17:28:31 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 30 Sep 2022 17:28:31 GMT Subject: RFR: 8289552: Make intrinsic conversions between bit representations of half precision values and floats [v8] In-Reply-To: References: <8LEJXqdKQPQe3lNuMSQql9YLgbcESJzfupkgORdvsFc=.807157d6-4506-4f04-ba20-a032d6ba973c@github.com> Message-ID: On Fri, 30 Sep 2022 03:13:09 GMT, Sandhya Viswanathan wrote: >> @smita-kamath I have builds failures. Please, build and test yourself to verify changes. >> >> src/hotspot/cpu/x86/assembler_x86.cpp: In member function 'void Assembler::evcvtps2ph(Address, KRegister, XMMRegister, int, int)': >> src/hotspot/cpu/x86/assembler_x86.cpp:1950:15: error: no matching function for call to 'Assembler::emit_operand(XMMRegister&, Address&)' >> emit_operand(src, dst); > > @vnkozlov I spoke too soon. All the GHA tests passed in the dummy draft PR I created using Smita's patch: > https://github.com/openjdk/jdk/pull/10500 > Please take a look. No build failures reported and all tier1 tests passed. > @sviswa7 The failure is due to [JDK-8293618](https://bugs.openjdk.org/browse/JDK-8293618), @smita-kamath please merge with master. Thanks. Yes, I tested with latest JDK sources which includes JDK-8293618. ------------- PR: https://git.openjdk.org/jdk/pull/9781 From prr at openjdk.org Fri Sep 30 17:42:29 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 30 Sep 2022 17:42:29 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 14:16:24 GMT, Weijun Wang wrote: >> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: >> >>> 32: * the following link: >>> 33: * >>> 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c >> >> The domain for hg wasn't changed to openjdk.org. The original URL is correct. > > Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`? This is correct. AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../" ------------- PR: https://git.openjdk.org/jdk/pull/10501 From joehw at openjdk.org Fri Sep 30 18:12:25 2022 From: joehw at openjdk.org (Joe Wang) Date: Fri, 30 Sep 2022 18:12:25 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > http -> https The ones in java.xml look good to me. ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 20:29:20 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 20:29:20 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v5] In-Reply-To: References: Message-ID: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy 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: - Update hg URLs to git. - Merge branch 'master' into JDK-8294618 - http -> https - Undo manpage update. - Update copyright. - Revert unintended update to binary file. - JDK-8294618: Update openjdk.java.net => openjdk.org ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/cee96d0a..fbaf3d4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03-04 Stats: 2670 lines in 133 files changed: 1729 ins; 406 del; 535 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 20:29:21 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 20:29:21 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 13:59:12 GMT, Magnus Ihse Bursie wrote: > Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..? Yes; I think it is sufficient to update src and doc with this PR. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 20:29:22 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 20:29:22 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race wrote: > This is correct. AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../" Update to persistent git links. ------------- PR: https://git.openjdk.org/jdk/pull/10501