From darcy at openjdk.java.net Wed Jun 1 03:18:44 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 1 Jun 2022 03:18:44 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v4] In-Reply-To: References: Message-ID: <5sIL5TbJnFl6ceoDWAQo0fMC32NgEdJ-9wrutOdz2TA=.8ae1c7e2-d98b-4609-a8af-d63e7cb843c9@github.com> > Time to start getting ready for JDK 20... 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 38 additional commits since the last revision: - Adjust deprecated options test. - Merge branch 'master' into JDK-8284858 - Update deprecated options test. - Merge branch 'master' into JDK-8284858 - Respond to review feedback. - Update symbol information for JDK 19 b24. - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - ... and 28 more: https://git.openjdk.java.net/jdk/compare/2ffc9a25...54e872b5 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8236/files - new: https://git.openjdk.java.net/jdk/pull/8236/files/eedd36bd..54e872b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=02-03 Stats: 1101 lines in 21 files changed: 708 ins; 170 del; 223 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236 From jjg at openjdk.java.net Wed Jun 1 03:27:40 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 1 Jun 2022 03:27:40 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v3] In-Reply-To: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com> References: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com> Message-ID: On Tue, 31 May 2022 20:32:13 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > 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 36 additional commits since the last revision: > > - Update deprecated options test. > - Merge branch 'master' into JDK-8284858 > - Respond to review feedback. > - Update symbol information for JDK 19 b24. > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Update symbol information for JDK 19 b23. > - ... and 26 more: https://git.openjdk.java.net/jdk/compare/44ff5c88...eedd36bd langtools files look OK, although I did skim through the auto-generated new data/symbols files. There are possibilities in the langtools file to simplify naming and default initialization of member fields in various places, in a separate PR, separate from these changes. ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8236 From dholmes at openjdk.java.net Wed Jun 1 04:44:39 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 1 Jun 2022 04:44:39 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v4] In-Reply-To: <5sIL5TbJnFl6ceoDWAQo0fMC32NgEdJ-9wrutOdz2TA=.8ae1c7e2-d98b-4609-a8af-d63e7cb843c9@github.com> References: <5sIL5TbJnFl6ceoDWAQo0fMC32NgEdJ-9wrutOdz2TA=.8ae1c7e2-d98b-4609-a8af-d63e7cb843c9@github.com> Message-ID: On Wed, 1 Jun 2022 03:18:44 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > 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 38 additional commits since the last revision: > > - Adjust deprecated options test. > - Merge branch 'master' into JDK-8284858 > - Update deprecated options test. > - Merge branch 'master' into JDK-8284858 > - Respond to review feedback. > - Update symbol information for JDK 19 b24. > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - ... and 28 more: https://git.openjdk.java.net/jdk/compare/c1abb195...54e872b5 Updates look good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8236 From stefank at openjdk.java.net Wed Jun 1 06:05:36 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 1 Jun 2022 06:05:36 GMT Subject: RFR: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark In-Reply-To: References: Message-ID: <5NxJcSGuxlIgkXKR4OtjVAfZRhZITnXRVsDNg4hj8-0=.77e357ed-5ab6-4ff4-9576-692ad9158659@github.com> On Mon, 30 May 2022 17:09:35 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that makes a few CLDG iterations no-keepalive during GC pauses? > > This fixes a bug where the `VerifyDuringGC` verification otherwise kept alive all classes, effectively disabling class unloading during (g1) concurrent mark. > > Afaict this verification code is only every called during GC pauses, so the change should be fine. > > As for the change itself, I tried to avoid cluttering the code with `ClassLoaderDataGraphIterator<>` by using typedefs - unfortunately only C++ 17 allows omitting the `<>` if all template parameters are defaulted. > > There is also a new test case for just this. > > Testing: tier1-5 > > Thanks, > Thomas src/hotspot/share/classfile/classLoaderDataGraph.cpp line 328: > 326: public: > 327: ClassLoaderDataGraphIteratorBase() : _next(ClassLoaderDataGraph::_head), _thread(Thread::current()), _hm(_thread) { > 328: _thread = Thread::current(); Pre-existing: this code sets the _thread variable twice. Maybe clean that up? ------------- PR: https://git.openjdk.java.net/jdk/pull/8949 From stefank at openjdk.java.net Wed Jun 1 06:25:32 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 1 Jun 2022 06:25:32 GMT Subject: RFR: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark In-Reply-To: References: Message-ID: On Mon, 30 May 2022 17:09:35 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that makes a few CLDG iterations no-keepalive during GC pauses? > > This fixes a bug where the `VerifyDuringGC` verification otherwise kept alive all classes, effectively disabling class unloading during (g1) concurrent mark. > > Afaict this verification code is only every called during GC pauses, so the change should be fine. > > As for the change itself, I tried to avoid cluttering the code with `ClassLoaderDataGraphIterator<>` by using typedefs - unfortunately only C++ 17 allows omitting the `<>` if all template parameters are defaulted. > > There is also a new test case for just this. > > Testing: tier1-5 > > Thanks, > Thomas It's unclear to me why this works. You've removed the "keep alive" property from the iterator, but it looks like the verification code still uses "keep alive" loads on the class loaders. Could you explain how this patch prevents those class loaders from being kept alive? src/hotspot/share/classfile/classLoaderDataGraph.cpp line 344: > 342: if (cld != NULL) { > 343: // Keep cld that is being returned alive. > 344: _holder = Handle(_thread, keep_alive ? cld->holder() : cld->holder_no_keepalive()); It's always scary when no_keepalive() read oops are stored, because then you need to make sure that they don't accidentally leak out over a safepoint. In this case we don't ever use _holder. I wonder if it wouldn't be better to remove _handle and rewrite the code as: if (keep_alive) { // Keep cld that is being returned alive. Handle(_thread, cld->holder); } src/hotspot/share/classfile/classLoaderDataGraph.cpp line 437: > 435: while (ClassLoaderData* cld = iter.get_next()) { > 436: if (cld->dictionary() != nullptr) { > 437: cld->dictionary()->verify(); If I'm reading the code correctly, it seems like this function keeps the class loader alive: void Dictionary::verify() { guarantee(number_of_entries() >= 0, "Verify of dictionary failed"); ClassLoaderData* cld = loader_data(); // class loader must be present; a null class loader is the // bootstrap loader guarantee(cld != NULL && (cld->the_null_class_loader_data() || cld->class_loader()->is_instance()), "checking type of class_loader"); The `cld->class_loader()` call resolves the OopHandle, which should keep it alive. src/hotspot/share/classfile/classLoaderDataGraph.cpp line 665: > 663: while (ClassLoaderData* cld = iter.get_next()) { > 664: cld->verify(); > 665: } The same comment as for the verify_dictionary() function. ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8949 From shade at openjdk.java.net Wed Jun 1 08:05:04 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 1 Jun 2022 08:05:04 GMT Subject: RFR: 8287637: Loom: Mismatched VirtualThread::state accessor Message-ID: Found this by reading the code, no test failure detected yet. The field is defined as: // virtual thread state, accessed by VM private volatile int state; The field is defined on VM side as: macro(_state_offset, k, "state", int_signature, false) And yet, it is accessed as `short`: u2 java_lang_VirtualThread::state(oop vthread) { return vthread->short_field_acquire(_state_offset); } I think this is just asking for trouble on different endianness: the partial `u2` read from `int` field can read the "higher" two bytes, not the "lower" two bytes. Additional testing: - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom` - [ ] Linux AArch64 fastdebug, `jdk_loom hotspot_loom` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/8967/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8967&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287637 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8967.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8967/head:pull/8967 PR: https://git.openjdk.java.net/jdk/pull/8967 From alanb at openjdk.java.net Wed Jun 1 08:52:31 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 1 Jun 2022 08:52:31 GMT Subject: RFR: 8287637: Loom: Mismatched VirtualThread::state accessor In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 07:57:34 GMT, Aleksey Shipilev wrote: > Found this by reading the code, no test failure detected yet. > > The field is defined as: > > > // virtual thread state, accessed by VM > private volatile int state; > > > The field is defined on VM side as: > > > macro(_state_offset, k, "state", int_signature, false) > > > And yet, it is accessed as `short`: > > > u2 java_lang_VirtualThread::state(oop vthread) { > return vthread->short_field_acquire(_state_offset); > } > > > I think this is just asking for trouble on different endianness: the partial `u2` read from `int` field can read the "higher" two bytes, not the "lower" two bytes. > > Additional testing: > - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom` > - [x] Linux AArch64 fastdebug, `jdk_loom hotspot_loom` It was a short at one point so I suspect this was just missed when the code was changed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8967 From sgehwolf at openjdk.java.net Wed Jun 1 09:27:22 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 1 Jun 2022 09:27:22 GMT Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code Message-ID: Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read. While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is meant to only use stringStream throughout the cgroups code. Testing: - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2 - [x] Added tests, which I've verified also pass before the stringStream change Thoughts? ------------- Commit messages: - Add cgroups v2 java test - use stringStream in cgroups v2 - Add gtest for cgroups v2 code path - 8287007: [cgroups] Consistently use stringStream throughout parsing code - 8287007: [cgroups] Consistently use stringStream throughout parsing code Changes: https://git.openjdk.java.net/jdk/pull/8969/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8969&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287007 Stats: 270 lines in 5 files changed: 235 ins; 19 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/8969.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8969/head:pull/8969 PR: https://git.openjdk.java.net/jdk/pull/8969 From tschatzl at openjdk.java.net Wed Jun 1 10:21:30 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 1 Jun 2022 10:21:30 GMT Subject: RFR: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 06:09:06 GMT, Stefan Karlsson wrote: >> Hi all, >> >> can I have reviews for this change that makes a few CLDG iterations no-keepalive during GC pauses? >> >> This fixes a bug where the `VerifyDuringGC` verification otherwise kept alive all classes, effectively disabling class unloading during (g1) concurrent mark. >> >> Afaict this verification code is only every called during GC pauses, so the change should be fine. >> >> As for the change itself, I tried to avoid cluttering the code with `ClassLoaderDataGraphIterator<>` by using typedefs - unfortunately only C++ 17 allows omitting the `<>` if all template parameters are defaulted. >> >> There is also a new test case for just this. >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > src/hotspot/share/classfile/classLoaderDataGraph.cpp line 437: > >> 435: while (ClassLoaderData* cld = iter.get_next()) { >> 436: if (cld->dictionary() != nullptr) { >> 437: cld->dictionary()->verify(); > > If I'm reading the code correctly, it seems like this function keeps the class loader alive: > > void Dictionary::verify() { > guarantee(number_of_entries() >= 0, "Verify of dictionary failed"); > > ClassLoaderData* cld = loader_data(); > // class loader must be present; a null class loader is the > // bootstrap loader > guarantee(cld != NULL && > (cld->the_null_class_loader_data() || cld->class_loader()->is_instance()), > "checking type of class_loader"); > > > The `cld->class_loader()` call resolves the OopHandle, which should keep it alive. That never happens because afaict `cld->the_null_class_loader_data()` is always non-NULL except during very early bootstrapping. I do not think it can ever be NULL for a java instantiated class loader, so the second clause is never executed there. Some additional logging in the test proved that. I can find three where this idiom is used to see whether the null CLD is initialized - I could add a static `is_null_class_loader_data_initialized()` predicate to `ClassLoaderData` - preferably in a separate CR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8949 From tschatzl at openjdk.java.net Wed Jun 1 10:27:21 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 1 Jun 2022 10:27:21 GMT Subject: RFR: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark [v2] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that makes a few CLDG iterations no-keepalive during GC pauses? > > This fixes a bug where the `VerifyDuringGC` verification otherwise kept alive all classes, effectively disabling class unloading during (g1) concurrent mark. > > Afaict this verification code is only every called during GC pauses, so the change should be fine. > > As for the change itself, I tried to avoid cluttering the code with `ClassLoaderDataGraphIterator<>` by using typedefs - unfortunately only C++ 17 allows omitting the `<>` if all template parameters are defaulted. > > There is also a new test case for just this. > > Testing: tier1-5 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: stefank review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8949/files - new: https://git.openjdk.java.net/jdk/pull/8949/files/f7b70b33..9e66fc7c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8949&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8949&range=00-01 Stats: 6 lines in 2 files changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8949.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8949/head:pull/8949 PR: https://git.openjdk.java.net/jdk/pull/8949 From tschatzl at openjdk.java.net Wed Jun 1 10:50:33 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 1 Jun 2022 10:50:33 GMT Subject: RFR: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark [v3] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that makes a few CLDG iterations no-keepalive during GC pauses? > > This fixes a bug where the `VerifyDuringGC` verification otherwise kept alive all classes, effectively disabling class unloading during (g1) concurrent mark. > > Afaict this verification code is only every called during GC pauses, so the change should be fine. > > As for the change itself, I tried to avoid cluttering the code with `ClassLoaderDataGraphIterator<>` by using typedefs - unfortunately only C++ 17 allows omitting the `<>` if all template parameters are defaulted. > > There is also a new test case for just this. > > Testing: tier1-5 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary test change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8949/files - new: https://git.openjdk.java.net/jdk/pull/8949/files/9e66fc7c..7f16efea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8949&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8949&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8949.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8949/head:pull/8949 PR: https://git.openjdk.java.net/jdk/pull/8949 From pchilanomate at openjdk.java.net Wed Jun 1 13:55:41 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 1 Jun 2022 13:55:41 GMT Subject: RFR: 8287512: continuationEntry.hpp has incomplete definitions [v2] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 15:33:27 GMT, Ron Pressler wrote: >> Please review this small change, which cleans up continuationEntry.hpp and fixes incomplete definitions. >> >> Passes tier1 > > Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: > > Rename ContinuationEntry::set_enter_nmethod and static fields Marked as reviewed by pchilanomate (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8944 From rpressler at openjdk.java.net Wed Jun 1 14:14:46 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Wed, 1 Jun 2022 14:14:46 GMT Subject: Integrated: 8287512: continuationEntry.hpp has incomplete definitions In-Reply-To: References: Message-ID: On Mon, 30 May 2022 10:34:34 GMT, Ron Pressler wrote: > Please review this small change, which cleans up continuationEntry.hpp and fixes incomplete definitions. > > Passes tier1 This pull request has now been integrated. Changeset: f8eb7a89 Author: Ron Pressler Committer: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/f8eb7a892f2fe78671d2211e35369c7ff2ed24fa Stats: 30 lines in 5 files changed: 7 ins; 8 del; 15 mod 8287512: continuationEntry.hpp has incomplete definitions Reviewed-by: coleenp, pchilanomate ------------- PR: https://git.openjdk.java.net/jdk/pull/8944 From iklam at openjdk.java.net Wed Jun 1 15:54:43 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 1 Jun 2022 15:54:43 GMT Subject: RFR: 8287398: Allow concurrent execution of hotspot docker tests [v2] In-Reply-To: References: Message-ID: On Mon, 30 May 2022 07:04:11 GMT, Aleksey Shipilev wrote: > Okay, as long as multiple iterations of these tests pass. I tested with `make test TEST=containers/docker JTREG="REPEAT_COUNT=50"` on a machine with 32 threads and it passed after 157 minuets. ------------- PR: https://git.openjdk.java.net/jdk/pull/8914 From iklam at openjdk.java.net Wed Jun 1 15:54:44 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 1 Jun 2022 15:54:44 GMT Subject: RFR: 8287398: Allow concurrent execution of hotspot docker tests [v2] In-Reply-To: References: Message-ID: <9onrEp4eoh3uutIzXDZhaPjn9-6T_g1c6e0EQlINwV4=.949f1f56-a95f-4014-b1f7-da25b2c5d529@github.com> On Fri, 27 May 2022 19:56:59 GMT, Mikhailo Seledtsov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> updated Common.imageName() to generate unique names > > Looks good to me, thanks. Thanks @mseledts @shipilev @jerboaa for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8914 From iklam at openjdk.java.net Wed Jun 1 15:54:46 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 1 Jun 2022 15:54:46 GMT Subject: Integrated: 8287398: Allow concurrent execution of hotspot docker tests In-Reply-To: References: Message-ID: On Fri, 27 May 2022 05:36:08 GMT, Ioi Lam wrote: > Remove the `exclusiveAccess.dirs=.` configuration (and thus the entire TEST.properties file) so that the test/hotspot/jtreg/containers/docker/*.java tests can be executed concurrently. This reduces total execution from about 8 minuets to about 2.5 minuets on my machine. > > In early days of JDK support for docker, we disabled concurrent execution as a precaution to avoid collisions in docker operations, such as building an image. Such collisions should no longer happen (each image is uniquely named). > > In comparison, in tests/jdk/jdk/internal/platform/docker there are no such limitations, and the 6 docker tests there can be executed in parallel without issue. This pull request has now been integrated. Changeset: 67ecd303 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/67ecd30327086c5d7628c4156f8d9dcccb0f4d09 Stats: 59 lines in 2 files changed: 26 ins; 25 del; 8 mod 8287398: Allow concurrent execution of hotspot docker tests Reviewed-by: shade, mseledtsov, sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/8914 From dcubed at openjdk.java.net Wed Jun 1 16:23:36 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 1 Jun 2022 16:23:36 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Thu, 19 May 2022 19:17:09 GMT, Patricio Chilano Mateo wrote: > On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. > To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: > - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. > - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. > > I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. > > I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. > > Thanks, > Patricio I'm planning to review this after I finish catching up from being on vacation. However, I don't think that @pchilano needs to wait for my review since the version of JDK-8284632 that we (tested and) integrated is @robehn's simpler rewrite of my original fix. If @robehn is happy with this fix, then I think it is okay for @pchilano to proceed once he is done with his testing. Since I also need to retest for the original memory leak, that will also delay when I'll be able to give @pchilano my complete feedback. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From coleenp at openjdk.java.net Wed Jun 1 16:34:41 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 1 Jun 2022 16:34:41 GMT Subject: RFR: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark [v3] In-Reply-To: References: Message-ID: <-AX4BQJPRJz-MO0RA1K5IL62iuP_8AWX1xCBBeGKjlE=.68fd8cbd-00ef-47ff-8d2a-d1d4e792801a@github.com> On Wed, 1 Jun 2022 10:50:33 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that makes a few CLDG iterations no-keepalive during GC pauses? >> >> This fixes a bug where the `VerifyDuringGC` verification otherwise kept alive all classes, effectively disabling class unloading during (g1) concurrent mark. >> >> Afaict this verification code is only every called during GC pauses, so the change should be fine. >> >> As for the change itself, I tried to avoid cluttering the code with `ClassLoaderDataGraphIterator<>` by using typedefs - unfortunately only C++ 17 allows omitting the `<>` if all template parameters are defaulted. >> >> There is also a new test case for just this. >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary test change This seems okay and worth adding the ClassLoaderdataGraphIteratorBase for this case. Please make the change in my comment though with this change, and retest your test. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8949 From coleenp at openjdk.java.net Wed Jun 1 16:34:44 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 1 Jun 2022 16:34:44 GMT Subject: RFR: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark [v3] In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 10:18:19 GMT, Thomas Schatzl wrote: >> src/hotspot/share/classfile/classLoaderDataGraph.cpp line 437: >> >>> 435: while (ClassLoaderData* cld = iter.get_next()) { >>> 436: if (cld->dictionary() != nullptr) { >>> 437: cld->dictionary()->verify(); >> >> If I'm reading the code correctly, it seems like this function keeps the class loader alive: >> >> void Dictionary::verify() { >> guarantee(number_of_entries() >= 0, "Verify of dictionary failed"); >> >> ClassLoaderData* cld = loader_data(); >> // class loader must be present; a null class loader is the >> // bootstrap loader >> guarantee(cld != NULL && >> (cld->the_null_class_loader_data() || cld->class_loader()->is_instance()), >> "checking type of class_loader"); >> >> >> The `cld->class_loader()` call resolves the OopHandle, which should keep it alive. > > That never happens because afaict `cld->the_null_class_loader_data()` is always non-NULL except during very early bootstrapping. I do not think it can ever be NULL for a java instantiated class loader, so the second clause is never executed there. Some additional logging in the test proved that. > > I can find three where this idiom is used to see whether the null CLD is initialized - I could add a static `is_null_class_loader_data_initialized()` predicate to `ClassLoaderData` - preferably in a separate CR. Yes, in this CR you should change "the_null_class_loader_data()" to "is_the_null_class_loader_data()" and verify that your test still works. ------------- PR: https://git.openjdk.java.net/jdk/pull/8949 From alanb at openjdk.java.net Thu Jun 2 11:29:37 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 2 Jun 2022 11:29:37 GMT Subject: RFR: 8287637: Loom: Mismatched VirtualThread::state accessor In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 07:57:34 GMT, Aleksey Shipilev wrote: > Found this by reading the code, no test failure detected yet. > > The field is defined on Java side as: > > > // virtual thread state, accessed by VM > private volatile int state; > > > The field is defined on VM side as: > > > macro(_state_offset, k, "state", int_signature, false) > > > And yet, it is accessed as `short`: > > > u2 java_lang_VirtualThread::state(oop vthread) { > return vthread->short_field_acquire(_state_offset); > } > > > I think this is just asking for trouble on different endianness: the partial `u2` read from `int` field can read the "higher" two bytes, not the "lower" two bytes. > > Additional testing: > - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom` > - [x] Linux AArch64 fastdebug, `jdk_loom hotspot_loom` Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8967 From mbaesken at openjdk.java.net Thu Jun 2 13:11:07 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 2 Jun 2022 13:11:07 GMT Subject: RFR: JDK-8287011: Container information could be improved Message-ID: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. ------------- Commit messages: - JDK-8287011 Changes: https://git.openjdk.java.net/jdk/pull/8991/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8991&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287011 Stats: 157 lines in 8 files changed: 154 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8991.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8991/head:pull/8991 PR: https://git.openjdk.java.net/jdk/pull/8991 From pchilanomate at openjdk.java.net Thu Jun 2 13:36:28 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 2 Jun 2022 13:36:28 GMT Subject: Integrated: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Thu, 19 May 2022 19:17:09 GMT, Patricio Chilano Mateo wrote: > On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. > To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: > - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. > - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. > > I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. > > I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 5acac223 Author: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/5acac2238fdc4ffe6ef290456e01cc559d811557 Stats: 84 lines in 5 files changed: 73 ins; 8 del; 3 mod 8286830: ~HandshakeState should not touch oops Reviewed-by: dholmes, rehn ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From mbaesken at openjdk.java.net Thu Jun 2 14:18:12 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 2 Jun 2022 14:18:12 GMT Subject: RFR: JDK-8287011: Container information could be improved [v2] In-Reply-To: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: > The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust output in os_linux.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8991/files - new: https://git.openjdk.java.net/jdk/pull/8991/files/55a74afb..a6f6cf8a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8991&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8991&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8991.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8991/head:pull/8991 PR: https://git.openjdk.java.net/jdk/pull/8991 From sgehwolf at openjdk.java.net Thu Jun 2 15:06:29 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 2 Jun 2022 15:06:29 GMT Subject: RFR: JDK-8287011: Container information could be improved [v2] In-Reply-To: References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: On Thu, 2 Jun 2022 14:18:12 GMT, Matthias Baesken wrote: >> The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust output in os_linux.cpp A couple of comments: - This introduces a couple of version specific info which is stubbed on the versions that don't support them. It's in conflict with the design of OSContainer to only contain metrics which are commonly supported (should do the same on all versions). On the JDK side those version specific metrics live in version specific classes. Not sure if this design applies well to hotspot code. - This is untested code. If anything, please add tests for this to `TestMisc.java` which uses PrintContainerInfo to exercise this code. - What's the use-case for those diagnostics? Usually on kubernetes swap is disabled so the swap info there is quite useless in that case. Why is the kernel memory info needed? The bug doesn't say *why* it's important to have. ------------- PR: https://git.openjdk.java.net/jdk/pull/8991 From darcy at openjdk.java.net Thu Jun 2 17:00:35 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 2 Jun 2022 17:00:35 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v5] In-Reply-To: References: Message-ID: > Time to start getting ready for JDK 20... 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 40 additional commits since the last revision: - Update symbols for JDK 19 b25. - Merge branch 'master' into JDK-8284858 - Adjust deprecated options test. - Merge branch 'master' into JDK-8284858 - Update deprecated options test. - Merge branch 'master' into JDK-8284858 - Respond to review feedback. - Update symbol information for JDK 19 b24. - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7a25d65...e495a579 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8236/files - new: https://git.openjdk.java.net/jdk/pull/8236/files/54e872b5..e495a579 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=03-04 Stats: 7203 lines in 242 files changed: 5859 ins; 868 del; 476 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236 From shade at openjdk.java.net Thu Jun 2 18:18:40 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 2 Jun 2022 18:18:40 GMT Subject: RFR: 8287637: Loom: Mismatched VirtualThread::state accessor In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 07:57:34 GMT, Aleksey Shipilev wrote: > Found this by reading the code, no test failure detected yet. > > The field is defined on Java side as: > > > // virtual thread state, accessed by VM > private volatile int state; > > > The field is defined on VM side as: > > > macro(_state_offset, k, "state", int_signature, false) > > > And yet, it is accessed as `short`: > > > u2 java_lang_VirtualThread::state(oop vthread) { > return vthread->short_field_acquire(_state_offset); > } > > > I think this is just asking for trouble on different endianness: the partial `u2` read from `int` field can read the "higher" two bytes, not the "lower" two bytes. > > Additional testing: > - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom` > - [x] Linux AArch64 fastdebug, `jdk_loom hotspot_loom` Thanks, any other reviews? ------------- PR: https://git.openjdk.java.net/jdk/pull/8967 From sgehwolf at openjdk.java.net Thu Jun 2 18:38:00 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 2 Jun 2022 18:38:00 GMT Subject: RFR: 8287741: Fix of JDK-8287107 (unused cgv1 freezer controller) was incomplete Message-ID: Please review this hotspot fix follow-up of JDK-8287107. The test which exercised this code was already added with JDK-8287107. I've now added an assert ensuring that we don't set the cgroup path multiple times. The fix is essentially the same as on the JDK side, skip setting the cgroup path when the hierarchy is non-zero which is equivalent to the empty string match that was done in the Java code. Testing: - [x] `test/hotspot/jtreg/containers/cgroup/CgroupSubsystemFactory.java` with fastdebug on x86_64. Asserts before the code fix, passes after. - [ ] GHA - still running. ------------- Commit messages: - 8287741: Fix of JDK-8287107 was incomplete Changes: https://git.openjdk.java.net/jdk/pull/9001/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9001&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287741 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/9001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9001/head:pull/9001 PR: https://git.openjdk.java.net/jdk/pull/9001 From iklam at openjdk.java.net Thu Jun 2 19:38:13 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 2 Jun 2022 19:38:13 GMT Subject: RFR: 8287741: Fix of JDK-8287107 (unused cgv1 freezer controller) was incomplete In-Reply-To: References: Message-ID: On Thu, 2 Jun 2022 18:30:38 GMT, Severin Gehwolf wrote: > Please review this hotspot fix follow-up of JDK-8287107. The test which exercised this code was already added with JDK-8287107. I've now added an assert ensuring that we don't set the cgroup path multiple times. The fix is essentially the same as on the JDK side, skip setting the cgroup path when the hierarchy is non-zero which is equivalent to the empty string match that was done in the Java code. > > Testing: > - [x] `test/hotspot/jtreg/containers/cgroup/CgroupSubsystemFactory.java` with fastdebug on x86_64. Asserts before the code fix, passes after. > - [ ] GHA - still running. LGTM! ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9001 From ccheung at openjdk.java.net Thu Jun 2 20:53:56 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 2 Jun 2022 20:53:56 GMT Subject: RFR: 8287101: CDS should check for file truncation for all regions Message-ID: Currently, only the `last_valid_region` is checked for file truncation for a CDS archive. If serial GC is used, file truncation is not detected because the `last_valid_region` is empty so `si->file_offset() == 0`. This change is for checking file truncation for all regions. Also add a test which truncates at the end of the file to trigger the "The shared archive file has been truncated." error. Testing: tiers 1 and 2, also ran the test case -XX:+UseSerialGC. ------------- Commit messages: - 8287101: CDS should check for file truncation for all regions Changes: https://git.openjdk.java.net/jdk/pull/9004/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9004&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287101 Stats: 46 lines in 3 files changed: 38 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/9004.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9004/head:pull/9004 PR: https://git.openjdk.java.net/jdk/pull/9004 From iris at openjdk.java.net Thu Jun 2 21:29:37 2022 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 2 Jun 2022 21:29:37 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v5] In-Reply-To: References: Message-ID: On Thu, 2 Jun 2022 17:00:35 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > 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 40 additional commits since the last revision: > > - Update symbols for JDK 19 b25. > - Merge branch 'master' into JDK-8284858 > - Adjust deprecated options test. > - Merge branch 'master' into JDK-8284858 > - Update deprecated options test. > - Merge branch 'master' into JDK-8284858 > - Respond to review feedback. > - Update symbol information for JDK 19 b24. > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - ... and 30 more: https://git.openjdk.java.net/jdk/compare/5a6d202d...e495a579 Changes still look good. ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8236 From iklam at openjdk.java.net Thu Jun 2 22:40:31 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 2 Jun 2022 22:40:31 GMT Subject: RFR: 8287101: CDS should check for file truncation for all regions In-Reply-To: References: Message-ID: On Thu, 2 Jun 2022 20:41:15 GMT, Calvin Cheung wrote: > Currently, only the `last_valid_region` is checked for file truncation for a CDS archive. If serial GC is used, file truncation is not detected because the `last_valid_region` is empty so `si->file_offset() == 0`. This change is for checking file truncation for all regions. > > Also add a test which truncates at the end of the file to trigger the "The shared archive file has been truncated." error. > > Testing: tiers 1 and 2, also ran the test case with -XX:+UseSerialGC. Looks good. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9004 From mbaesken at openjdk.java.net Fri Jun 3 06:56:31 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 3 Jun 2022 06:56:31 GMT Subject: RFR: JDK-8287011: Container information could be improved [v2] In-Reply-To: References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: On Thu, 2 Jun 2022 14:18:12 GMT, Matthias Baesken wrote: >> The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust output in os_linux.cpp > A couple of comments: > > * This introduces a couple of version specific info which is stubbed on the versions that don't support them. It's in conflict with the design of OSContainer to only contain metrics which are commonly supported (should do the same on all versions). On the JDK side those version specific metrics live in version specific classes. Not sure if this design applies well to hotspot code. > * This is untested code. If anything, please add tests for this to `TestMisc.java` which uses PrintContainerInfo to exercise this code. > * What's the use-case for those diagnostics? Usually on kubernetes swap is disabled so the swap info there is quite useless in that case. Why is the kernel memory info needed? The bug doesn't say _why_ it's important to have. Hi Severin, yes sure testing needs to be done, thanks for the advice regarding TestMisc.java. Regarding use-case I think Thomas Stuefe can give the best feedback. ------------- PR: https://git.openjdk.java.net/jdk/pull/8991 From duke at openjdk.java.net Fri Jun 3 07:04:53 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Fri, 3 Jun 2022 07:04:53 GMT Subject: RFR: 8287764: runtime/cds/serviceability/ReplaceCriticalClasses failed on localized Windows Message-ID: <92bwD6I4XdzOMv7YNxPss5Yu69QwuYuDaY3o7esO6Rs=.1a0cf50c-ae08-46b3-b995-941408d73374@github.com> The ReplaceCriticalClasses verifies CDS behavior when replacing the Readable interface as an example of a class that is read after JVMTI_PHASE_PRIMORDIAL. However, the order in which classes are loaded is affected by the language of the test environment, so the timing at which the Readable interface is loaded also changes on Windows with multibyte characters. Therefore, the Readable interface is not suitable for this test and should be removed. ------------- Commit messages: - 8287764: runtime/cds/serviceability/ReplaceCriticalClasses failed on localized Windows Changes: https://git.openjdk.java.net/jdk/pull/9009/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9009&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287764 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/9009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9009/head:pull/9009 PR: https://git.openjdk.java.net/jdk/pull/9009 From tschatzl at openjdk.java.net Fri Jun 3 08:01:49 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 3 Jun 2022 08:01:49 GMT Subject: RFR: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark [v4] In-Reply-To: References: Message-ID: <-iUCGVA9etcqOi9z4HHFkr7QMdE6J3b6k0rpxOFVxNw=.0a3995b7-0b62-474a-9419-9c6c760e72da@github.com> > Hi all, > > can I have reviews for this change that makes a few CLDG iterations no-keepalive during GC pauses? > > This fixes a bug where the `VerifyDuringGC` verification otherwise kept alive all classes, effectively disabling class unloading during (g1) concurrent mark. > > Afaict this verification code is only every called during GC pauses, so the change should be fine. > > As for the change itself, I tried to avoid cluttering the code with `ClassLoaderDataGraphIterator<>` by using typedefs - unfortunately only C++ 17 allows omitting the `<>` if all template parameters are defaulted. > > There is also a new test case for just this. > > Testing: tier1-5 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: coleenp, stefank reviews ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8949/files - new: https://git.openjdk.java.net/jdk/pull/8949/files/7f16efea..59911eac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8949&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8949&range=02-03 Stats: 8 lines in 3 files changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8949.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8949/head:pull/8949 PR: https://git.openjdk.java.net/jdk/pull/8949 From sgehwolf at openjdk.java.net Fri Jun 3 08:15:30 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 3 Jun 2022 08:15:30 GMT Subject: RFR: 8287741: Fix of JDK-8287107 (unused cgv1 freezer controller) was incomplete In-Reply-To: References: Message-ID: <3NXr7cgkODq_VqNjiJN9Kc7kcv1_4hbPQtEk5R4QisI=.892fbfd2-71a1-46ae-b88c-7a86861109db@github.com> On Thu, 2 Jun 2022 19:35:38 GMT, Ioi Lam wrote: > LGTM! Thanks for the review, @iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/9001 From coleenp at openjdk.java.net Fri Jun 3 12:08:31 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 3 Jun 2022 12:08:31 GMT Subject: RFR: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark [v4] In-Reply-To: <-iUCGVA9etcqOi9z4HHFkr7QMdE6J3b6k0rpxOFVxNw=.0a3995b7-0b62-474a-9419-9c6c760e72da@github.com> References: <-iUCGVA9etcqOi9z4HHFkr7QMdE6J3b6k0rpxOFVxNw=.0a3995b7-0b62-474a-9419-9c6c760e72da@github.com> Message-ID: On Fri, 3 Jun 2022 08:01:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that makes a few CLDG iterations no-keepalive during GC pauses? >> >> This fixes a bug where the `VerifyDuringGC` verification otherwise kept alive all classes, effectively disabling class unloading during (g1) concurrent mark. >> >> Afaict this verification code is only every called during GC pauses, so the change should be fine. >> >> As for the change itself, I tried to avoid cluttering the code with `ClassLoaderDataGraphIterator<>` by using typedefs - unfortunately only C++ 17 allows omitting the `<>` if all template parameters are defaulted. >> >> There is also a new test case for just this. >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > coleenp, stefank reviews Still good. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8949 From mbaesken at openjdk.java.net Fri Jun 3 14:05:27 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 3 Jun 2022 14:05:27 GMT Subject: RFR: JDK-8287011: Container information could be improved [v3] In-Reply-To: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: > The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: handle new cgroupv1 and v2 values in TestMisc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8991/files - new: https://git.openjdk.java.net/jdk/pull/8991/files/a6f6cf8a..e90a3046 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8991&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8991&range=01-02 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8991.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8991/head:pull/8991 PR: https://git.openjdk.java.net/jdk/pull/8991 From sgehwolf at openjdk.java.net Fri Jun 3 15:31:39 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 3 Jun 2022 15:31:39 GMT Subject: RFR: JDK-8287011: Container information could be improved [v3] In-Reply-To: References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: On Fri, 3 Jun 2022 14:05:27 GMT, Matthias Baesken wrote: >> The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > handle new cgroupv1 and v2 values in TestMisc Please consider pushing implementation details of the version specific printing to the implementation classes. src/hotspot/os/linux/cgroupSubsystem_linux.hpp line 261: > 259: > 260: virtual jlong memory_swap_current_in_bytes() = 0; > 261: virtual jlong memory_swap_max_limit_in_bytes() = 0; I'm really not fond of this increased API surface for properties which are only supported on one version, but not the other. The idea would be to use those for printing in `os_linux`, right? Could we not move the implementation detail to the version specific classes? I.e. define `virtual void print_version_specific_info(outputStream* st) = 0` here and in `osContainer_linux.hpp` then only call `OSContainer::print_version_specific_info(st)` in `os_linux` and be done with it? This would avoid the empty stub implementations in the version specific classes... src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 250: > 248: } > 249: > 250: These should really not be needed if we make the `print_version_specific_info(...)` function implementation defined. src/hotspot/os/linux/os_linux.cpp line 2271: > 2269: // the kmem (kernel memory) values are only available in cgroupv1 > 2270: if (p_ct != NULL && strcmp(p_ct, "cgroupv1") == 0) { > 2271: print_container_helper(st, OSContainer::kernel_memory_usage_in_bytes(), "kernel_memory_usage_in_bytes"); We wouldn't need the extra version checking gymnastics if we'd call an `OSContainer::print_version_specific_info(st);` here instead. test/hotspot/jtreg/containers/docker/TestMisc.java line 127: > 125: } > 126: String str = out.getOutput(); > 127: if (str.contains("cgroupv1")) { An alternative would be to pass a `Metrics` instance (`Metrics.systemMetrics()`) to `checkContainerInfo` and use: `"cgroupv1".equals(m.getProvider())` here instead. ------------- Changes requested by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8991 From shade at openjdk.java.net Fri Jun 3 16:47:36 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 3 Jun 2022 16:47:36 GMT Subject: Integrated: 8287637: Loom: Mismatched VirtualThread::state accessor In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 07:57:34 GMT, Aleksey Shipilev wrote: > Found this by reading the code, no test failure detected yet. > > The field is defined on Java side as: > > > // virtual thread state, accessed by VM > private volatile int state; > > > The field is defined on VM side as: > > > macro(_state_offset, k, "state", int_signature, false) > > > And yet, it is accessed as `short`: > > > u2 java_lang_VirtualThread::state(oop vthread) { > return vthread->short_field_acquire(_state_offset); > } > > > I think this is just asking for trouble on different endianness: the partial `u2` read from `int` field can read the "higher" two bytes, not the "lower" two bytes. > > Additional testing: > - [x] Linux x86_64 fastdebug, `jdk_loom hotspot_loom` > - [x] Linux AArch64 fastdebug, `jdk_loom hotspot_loom` This pull request has now been integrated. Changeset: ce5ae517 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/ce5ae51773974dfc324b5fff52accbe14a0c032e Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8287637: Loom: Mismatched VirtualThread::state accessor Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8967 From dcubed at openjdk.java.net Fri Jun 3 17:10:56 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 3 Jun 2022 17:10:56 GMT Subject: RFR: 8231491: JDI tc02x004 failed again due to wrong # of breakpoints Message-ID: A trivial fix that deletes an errant `debugee.resume()` call that causes a race between the debugger and debuggee. I've also corrected incorrect line number values mentioned in comments. This fix has been tested with the updated failing test both with and without the debug code that makes the failure easy to reproduce. The real test will be seeing if the failure stops reproducing in my stress testing runs on my M1 MacMini in my lab. ------------- Commit messages: - 8231491.cr0.patch Changes: https://git.openjdk.java.net/jdk/pull/9020/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9020&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231491 Stats: 5 lines in 2 files changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/9020.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9020/head:pull/9020 PR: https://git.openjdk.java.net/jdk/pull/9020 From dcubed at openjdk.java.net Fri Jun 3 17:10:57 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 3 Jun 2022 17:10:57 GMT Subject: RFR: 8231491: JDI tc02x004 failed again due to wrong # of breakpoints In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 17:02:44 GMT, Daniel D. Daugherty wrote: > A trivial fix that deletes an errant `debugee.resume()` call that causes a race > between the debugger and debuggee. I've also corrected incorrect line number > values mentioned in comments. > > This fix has been tested with the updated failing test both with and without the > debug code that makes the failure easy to reproduce. The real test will be seeing > if the failure stops reproducing in my stress testing runs on my M1 MacMini in > my lab. I've also looked at the other similar tests in vmTestbase/nsk/jdi/BScenarios and checked for the same errant `debugee.resume()` call. I didn't find any other cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/9020 From dcubed at openjdk.java.net Fri Jun 3 20:56:37 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 3 Jun 2022 20:56:37 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Thu, 19 May 2022 19:17:09 GMT, Patricio Chilano Mateo wrote: > On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. > To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: > - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. > - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. > > I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. > > I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. > > Thanks, > Patricio Sorry for the late review. I only found minor things. Please don't do anything with my review yet. I still need to add my tracker code and run this fix thru my stress testing. Very nice job resolving this issue. src/hotspot/share/runtime/thread.cpp line 1367: > 1365: void JavaThread::exit(bool destroy_vm, ExitType exit_type) { > 1366: assert(this == JavaThread::current(), "thread consistency check"); > 1367: assert(!is_exiting(), "should not be exiting or terminated already"); Hmmm... The old `destroy_vm == true` branch assert was: `assert(!is_terminated() && !is_exiting(), "must not be exiting");` and the new assert mesg has "or terminated", but the assert is only checking `!is_exiting()` and doesn't not include `!is_terminated()`. So the old assert checked both conditions and only mumbled about "exiting" and the new assert checks one condition and mumbles about both conditions. src/hotspot/share/runtime/thread.cpp line 1444: > 1442: // Also, no more async exceptions will be added to the queue after this point. > 1443: set_terminated(_thread_exiting); > 1444: ThreadService::current_thread_exiting(this, is_daemon(threadObj())); Previously, we didn't call `ThreadService::current_thread_exiting()` in the `destroy_vm == true` branch. Is that going to result in some change in behavior? src/hotspot/share/runtime/thread.cpp line 1539: > 1537: // Remove from list of active threads list, and notify VM thread if we are the last non-daemon thread. > 1538: // We call BarrierSet::barrier_set()->on_thread_detach() here so no touching of oops after this point. > 1539: Threads::remove(this, daemon); Thanks for adding the new comment line! test/hotspot/jtreg/runtime/Thread/StopAtExit.java line 95: > 93: threadCreator.setDaemon(true); > 94: threadCreator.start(); > 95: test(timeMax); Okay, but now the test is going to execute for twice `timeMax` which might be a bit of a surprise... In particular the usage() mesg is now wrong. test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 101: > 99: threadCreator.setDaemon(true); > 100: threadCreator.start(); > 101: test(timeMax); Okay, but now the test is going to execute for twice `timeMax` which might be a bit of a surprise... In particular the usage() mesg is now wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From dcubed at openjdk.java.net Fri Jun 3 20:56:39 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 3 Jun 2022 20:56:39 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 20:45:42 GMT, Daniel D. Daugherty wrote: >> On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. >> To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: >> - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. >> - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. >> >> I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. >> >> I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. >> >> Thanks, >> Patricio > > test/hotspot/jtreg/runtime/Thread/StopAtExit.java line 95: > >> 93: threadCreator.setDaemon(true); >> 94: threadCreator.start(); >> 95: test(timeMax); > > Okay, but now the test is going to execute for twice `timeMax` which might be > a bit of a surprise... In particular the usage() mesg is now wrong. Also, the `@bug` line is not updated with this bug ID. > test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 101: > >> 99: threadCreator.setDaemon(true); >> 100: threadCreator.start(); >> 101: test(timeMax); > > Okay, but now the test is going to execute for twice `timeMax` which might be > a bit of a surprise... In particular the usage() mesg is now wrong. Also, the `@bug` line is not updated with this bug ID. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From iklam at openjdk.java.net Fri Jun 3 20:58:11 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 3 Jun 2022 20:58:11 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating Message-ID: Added description of the new flag `-XX:+AutoCreateSharedArchive` to the `java` man page. ------------- Commit messages: - 8273853: Update the Java manpage for automatic CDS archive updating Changes: https://git.openjdk.java.net/jdk/pull/9024/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9024&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273853 Stats: 34 lines in 1 file changed: 31 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/9024.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9024/head:pull/9024 PR: https://git.openjdk.java.net/jdk/pull/9024 From iklam at openjdk.java.net Fri Jun 3 21:27:35 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 3 Jun 2022 21:27:35 GMT Subject: RFR: 8287764: runtime/cds/serviceability/ReplaceCriticalClasses failed on localized Windows In-Reply-To: <92bwD6I4XdzOMv7YNxPss5Yu69QwuYuDaY3o7esO6Rs=.1a0cf50c-ae08-46b3-b995-941408d73374@github.com> References: <92bwD6I4XdzOMv7YNxPss5Yu69QwuYuDaY3o7esO6Rs=.1a0cf50c-ae08-46b3-b995-941408d73374@github.com> Message-ID: On Fri, 3 Jun 2022 06:58:24 GMT, KIRIYAMA Takuya wrote: > The ReplaceCriticalClasses verifies CDS behavior when replacing the Readable interface as an example of a class that is read after JVMTI_PHASE_PRIMORDIAL. > However, the order in which classes are loaded is affected by the language of the test environment, so the timing at which the Readable interface is loaded also changes on Windows with multibyte characters. > Therefore, the Readable interface is not suitable for this test and should be removed. Looks good to me. I think this PR qualifies as a trivial change so only 1 reviewer is needed. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9009 From ccheung at openjdk.java.net Fri Jun 3 21:33:34 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 3 Jun 2022 21:33:34 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 20:45:24 GMT, Ioi Lam wrote: > Added description of the new flag `-XX:+AutoCreateSharedArchive` to the `java` man page. Looks good. One comment on the title of the new section. src/java.base/share/man/java.1 line 5536: > 5534: \f[CB]env\ JAVA_TOOL_OPTIONS=\-XX:+RecordDynamicDumpInfo\ bash\ app_start.sh\f[R] > 5535: .RE > 5536: .SS Using Dynamic CDS Archive File with \-XX:+AutoCreateSharedArchive Should the above be "Creating/Using Dynamic CDS Archive..."? ------------- PR: https://git.openjdk.java.net/jdk/pull/9024 From dcubed at openjdk.java.net Fri Jun 3 21:37:40 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 3 Jun 2022 21:37:40 GMT Subject: RFR: 8231491: JDI tc02x004 failed again due to wrong # of breakpoints In-Reply-To: References: Message-ID: <45cYl27FLuuvg094wDdCVgurydI-O4dMk62dM9Jq_30=.c21dcda7-e2cf-48e1-bea7-b6583babd95a@github.com> On Fri, 3 Jun 2022 17:02:44 GMT, Daniel D. Daugherty wrote: > A trivial fix that deletes an errant `debugee.resume()` call that causes a race > between the debugger and debuggee. I've also corrected incorrect line number > values mentioned in comments. > > This fix has been tested with the updated failing test both with and without the > debug code that makes the failure easy to reproduce. The real test will be seeing > if the failure stops reproducing in my stress testing runs on my M1 MacMini in > my lab. Did a Mach5 run that executed the updated test 50X on each of four platforms: - macosx-x64 - windows-x64 - linux-aarch64 - linux-x64 All runs passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/9020 From iklam at openjdk.java.net Fri Jun 3 21:44:38 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 3 Jun 2022 21:44:38 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 21:28:56 GMT, Calvin Cheung wrote: >> Added description of the new flag `-XX:+AutoCreateSharedArchive` to the `java` man page. > > src/java.base/share/man/java.1 line 5536: > >> 5534: \f[CB]env\ JAVA_TOOL_OPTIONS=\-XX:+RecordDynamicDumpInfo\ bash\ app_start.sh\f[R] >> 5535: .RE >> 5536: .SS Using Dynamic CDS Archive File with \-XX:+AutoCreateSharedArchive > > Should the above be "Creating/Using Dynamic CDS Archive..."? Actually my first version was "Creating/Using Dynamic CDS Archive...", but this line (section title) is too long and gets badly wrapped when the man page is viewed in a terminal using `nroff`. So I dropped the word "Creating" as the meaning should still be clear enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/9024 From cjplummer at openjdk.java.net Fri Jun 3 21:45:37 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 3 Jun 2022 21:45:37 GMT Subject: RFR: 8231491: JDI tc02x004 failed again due to wrong # of breakpoints In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 17:02:44 GMT, Daniel D. Daugherty wrote: > A trivial fix that deletes an errant `debugee.resume()` call that causes a race > between the debugger and debuggee. I've also corrected incorrect line number > values mentioned in comments. > > This fix has been tested with the updated failing test both with and without the > debug code that makes the failure easy to reproduce. The real test will be seeing > if the failure stops reproducing in my stress testing runs on my M1 MacMini in > my lab. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/9020 From dcubed at openjdk.java.net Fri Jun 3 21:56:32 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 3 Jun 2022 21:56:32 GMT Subject: RFR: 8231491: JDI tc02x004 failed again due to wrong # of breakpoints In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 21:43:02 GMT, Chris Plummer wrote: >> A trivial fix that deletes an errant `debugee.resume()` call that causes a race >> between the debugger and debuggee. I've also corrected incorrect line number >> values mentioned in comments. >> >> This fix has been tested with the updated failing test both with and without the >> debug code that makes the failure easy to reproduce. The real test will be seeing >> if the failure stops reproducing in my stress testing runs on my M1 MacMini in >> my lab. > > Marked as reviewed by cjplummer (Reviewer). @plummercj - Thanks for the review! Do you agree that this is a trivial change? ------------- PR: https://git.openjdk.java.net/jdk/pull/9020 From ccheung at openjdk.java.net Fri Jun 3 22:01:21 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 3 Jun 2022 22:01:21 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating In-Reply-To: References: Message-ID: <5RGbt72ClQ9KAgKf05oSiPf-cVKroO5M8lkokhP-lBs=.1e2c702a-4335-4ff6-8964-74e71694c0e1@github.com> On Fri, 3 Jun 2022 20:45:24 GMT, Ioi Lam wrote: > Added description of the new flag `-XX:+AutoCreateSharedArchive` to the `java` man page. Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/9024 From ccheung at openjdk.java.net Fri Jun 3 22:01:22 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 3 Jun 2022 22:01:22 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 21:40:34 GMT, Ioi Lam wrote: >> src/java.base/share/man/java.1 line 5536: >> >>> 5534: \f[CB]env\ JAVA_TOOL_OPTIONS=\-XX:+RecordDynamicDumpInfo\ bash\ app_start.sh\f[R] >>> 5535: .RE >>> 5536: .SS Using Dynamic CDS Archive File with \-XX:+AutoCreateSharedArchive >> >> Should the above be "Creating/Using Dynamic CDS Archive..."? > > Actually my first version was "Creating/Using Dynamic CDS Archive...", but this line (section title) is too long and gets badly wrapped when the man page is viewed in a terminal using `nroff`. So I dropped the word "Creating" as the meaning should still be clear enough. Ok. Approving as is. ------------- PR: https://git.openjdk.java.net/jdk/pull/9024 From cjplummer at openjdk.java.net Fri Jun 3 22:12:31 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Fri, 3 Jun 2022 22:12:31 GMT Subject: RFR: 8231491: JDI tc02x004 failed again due to wrong # of breakpoints In-Reply-To: References: Message-ID: <4OS7qONShcsw288Ep_4RJGWOuLxqhnrpUSpWRt_rNjc=.5d5db5d0-d6ba-4fa6-b8e7-83819137d4b7@github.com> On Fri, 3 Jun 2022 21:43:02 GMT, Chris Plummer wrote: >> A trivial fix that deletes an errant `debugee.resume()` call that causes a race >> between the debugger and debuggee. I've also corrected incorrect line number >> values mentioned in comments. >> >> This fix has been tested with the updated failing test both with and without the >> debug code that makes the failure easy to reproduce. The real test will be seeing >> if the failure stops reproducing in my stress testing runs on my M1 MacMini in >> my lab. > > Marked as reviewed by cjplummer (Reviewer). > @plummercj - Thanks for the review! > > Do you agree that this is a trivial change? Yes ------------- PR: https://git.openjdk.java.net/jdk/pull/9020 From dcubed at openjdk.java.net Fri Jun 3 22:18:37 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 3 Jun 2022 22:18:37 GMT Subject: RFR: 8231491: JDI tc02x004 failed again due to wrong # of breakpoints In-Reply-To: <4OS7qONShcsw288Ep_4RJGWOuLxqhnrpUSpWRt_rNjc=.5d5db5d0-d6ba-4fa6-b8e7-83819137d4b7@github.com> References: <4OS7qONShcsw288Ep_4RJGWOuLxqhnrpUSpWRt_rNjc=.5d5db5d0-d6ba-4fa6-b8e7-83819137d4b7@github.com> Message-ID: On Fri, 3 Jun 2022 22:08:50 GMT, Chris Plummer wrote: >> Marked as reviewed by cjplummer (Reviewer). > >> @plummercj - Thanks for the review! >> >> Do you agree that this is a trivial change? > > Yes @plummercj - Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/9020 From dcubed at openjdk.java.net Fri Jun 3 22:19:48 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 3 Jun 2022 22:19:48 GMT Subject: Integrated: 8231491: JDI tc02x004 failed again due to wrong # of breakpoints In-Reply-To: References: Message-ID: <0LB2apOGitfP7heb1TV-hCfagyV57Xglnq8OBXTj_qY=.cba6e634-cb00-43b9-aaca-bc0059f77000@github.com> On Fri, 3 Jun 2022 17:02:44 GMT, Daniel D. Daugherty wrote: > A trivial fix that deletes an errant `debugee.resume()` call that causes a race > between the debugger and debuggee. I've also corrected incorrect line number > values mentioned in comments. > > This fix has been tested with the updated failing test both with and without the > debug code that makes the failure easy to reproduce. The real test will be seeing > if the failure stops reproducing in my stress testing runs on my M1 MacMini in > my lab. This pull request has now been integrated. Changeset: e2cfe2e1 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/e2cfe2e14a03b638a5828625975716f9fed1f668 Stats: 5 lines in 2 files changed: 0 ins; 1 del; 4 mod 8231491: JDI tc02x004 failed again due to wrong # of breakpoints Reviewed-by: cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/9020 From pchilanomate at openjdk.java.net Fri Jun 3 22:37:38 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 3 Jun 2022 22:37:38 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Thu, 19 May 2022 19:17:09 GMT, Patricio Chilano Mateo wrote: > On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. > To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: > - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. > - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. > > I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. > > I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. > > Thanks, > Patricio Thanks for taking a look Dan. Let me know when you have the results of your stress testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From pchilanomate at openjdk.java.net Fri Jun 3 22:37:42 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 3 Jun 2022 22:37:42 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 20:34:36 GMT, Daniel D. Daugherty wrote: >> On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. >> To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: >> - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. >> - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. >> >> I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. >> >> I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. >> >> Thanks, >> Patricio > > src/hotspot/share/runtime/thread.cpp line 1367: > >> 1365: void JavaThread::exit(bool destroy_vm, ExitType exit_type) { >> 1366: assert(this == JavaThread::current(), "thread consistency check"); >> 1367: assert(!is_exiting(), "should not be exiting or terminated already"); > > Hmmm... The old `destroy_vm == true` branch assert was: > > `assert(!is_terminated() && !is_exiting(), "must not be exiting");` > > and the new assert mesg has "or terminated", but the assert is only > checking `!is_exiting()` and doesn't not include `!is_terminated()`. > So the old assert checked both conditions and only mumbled about > "exiting" and the new assert checks one condition and mumbles > about both conditions. is_exiting() also checks is_terminated() internally, so it returns true for the _thread_exiting, _thread_terminated and _vm_exited cases (false only for the _not_terminated case). Since the extra !is_terminated() check was redundant I removed it. Also since the assert will trigger for both the exiting and terminated cases I added both to the assert msg. > src/hotspot/share/runtime/thread.cpp line 1444: > >> 1442: // Also, no more async exceptions will be added to the queue after this point. >> 1443: set_terminated(_thread_exiting); >> 1444: ThreadService::current_thread_exiting(this, is_daemon(threadObj())); > > Previously, we didn't call `ThreadService::current_thread_exiting()` in the > `destroy_vm == true` branch. Is that going to result in some change in > behavior? That call decrements a counter used for some stats and for determining the size of the thread array in ThreadListEnumerator. But I don't see any issues on doing that since this thread is actually exiting. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From pchilanomate at openjdk.java.net Fri Jun 3 22:37:45 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 3 Jun 2022 22:37:45 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 20:52:46 GMT, Daniel D. Daugherty wrote: >> test/hotspot/jtreg/runtime/Thread/StopAtExit.java line 95: >> >>> 93: threadCreator.setDaemon(true); >>> 94: threadCreator.start(); >>> 95: test(timeMax); >> >> Okay, but now the test is going to execute for twice `timeMax` which might be >> a bit of a surprise... In particular the usage() mesg is now wrong. > > Also, the `@bug` line is not updated with this bug ID. Ok, we could fix this in a new bug. >> test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 101: >> >>> 99: threadCreator.setDaemon(true); >>> 100: threadCreator.start(); >>> 101: test(timeMax); >> >> Okay, but now the test is going to execute for twice `timeMax` which might be >> a bit of a surprise... In particular the usage() mesg is now wrong. > > Also, the `@bug` line is not updated with this bug ID. Ok, we could fix this in a new bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From dcubed at openjdk.java.net Sat Jun 4 15:25:34 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 4 Jun 2022 15:25:34 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: References: Message-ID: <3Jd4eXfIksAcu5eMQHaP6JwZLQcSPImAJbnuZMbWsBA=.986a2465-25c9-40b4-a92b-3210a5d99448@github.com> On Thu, 19 May 2022 19:17:09 GMT, Patricio Chilano Mateo wrote: > On 8284632 we added ~HandshakeState to cleanup any potential async operations left in the handshake queue. This could trigger the release of an oophandle from its associated oop-storage when trying to delete an AsyncExceptionHandshake object. Since the exiting JT already executed on_thread_detach() this is forbidden. > To fix this I used the original approach that @dcubed-ojdk posted on the 8284632 fix, which is cleaning up those operations before on_thread_detach() is executed. To make sure that no other async exception operation is added to the queue after that I did two things: > - Added a check in install_async_exception() to avoid installing the operation if the target already moved to the _thread_exiting state. > - Move the setting of the _thread_exiting state to include the case where JavaThread::exit() is called with destroy_vm=true. > > I also added another run to tests StopAtExit.java and SuspendAtExit.java with extra contention on the Threads_lock. That increases the odds of the target being handshake safe while being in the _thread_exiting state which allows testing for more pathological cases. > > I was able to reproduce the issue by running StopAtExit.java with -XX:+UseShenandoahGC and verified that the test now passes. I also run mach5 tiers1-3. Will run the upper tiers also and will do an additional pass after that. > > Thanks, > Patricio StressWrapper_StopAtExit.jtr release bits: ----------System.out:(10/297)---------- Agent_OnLoad started Agent_OnLoad finished About to execute for 7200 seconds. Executed 27471345 loops in 7200 seconds. About to execute for 7200 seconds. Executed 12930003 loops in 7200 seconds. vm_exit: dcubed_async_global_alloc_cnt=232552804 vm_exit: dcubed_async_global_release_cnt=232552804 ----------System.err:(1852/93678)---------- StressWrapper_StopAtExit.jtr fastdebug bits: ----------System.out:(10/294)---------- Agent_OnLoad started Agent_OnLoad finished About to execute for 7200 seconds. Executed 18516793 loops in 7200 seconds. About to execute for 7200 seconds. Executed 9128937 loops in 7200 seconds. vm_exit: dcubed_async_global_alloc_cnt=29621450 vm_exit: dcubed_async_global_release_cnt=29621450 ----------System.err:(1660/83996)---------- StressWrapper_StopAtExit.jtr slowdebug bits: ----------System.out:(10/293)---------- Agent_OnLoad started Agent_OnLoad finished About to execute for 7200 seconds. Executed 8147300 loops in 7200 seconds. About to execute for 7200 seconds. Executed 3913063 loops in 7200 seconds. vm_exit: dcubed_async_global_alloc_cnt=15924123 vm_exit: dcubed_async_global_release_cnt=15924123 ----------System.err:(691/34976)---------- No leaks detected in any config. ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From dcubed at openjdk.java.net Sun Jun 5 14:12:11 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sun, 5 Jun 2022 14:12:11 GMT Subject: Integrated: 8287837: ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp Message-ID: A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp. ------------- Commit messages: - 8287837: ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp Changes: https://git.openjdk.java.net/jdk/pull/9033/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9033&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287837 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/9033.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9033/head:pull/9033 PR: https://git.openjdk.java.net/jdk/pull/9033 From rriggs at openjdk.java.net Sun Jun 5 14:12:11 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Sun, 5 Jun 2022 14:12:11 GMT Subject: Integrated: 8287837: ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp In-Reply-To: References: Message-ID: On Sun, 5 Jun 2022 14:00:09 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/9033 From dcubed at openjdk.java.net Sun Jun 5 14:12:11 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sun, 5 Jun 2022 14:12:11 GMT Subject: Integrated: 8287837: ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp In-Reply-To: References: Message-ID: On Sun, 5 Jun 2022 14:05:42 GMT, Roger Riggs wrote: >> A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp. > > Marked as reviewed by rriggs (Reviewer). @RogerRiggs - Thanks for the fast review! Especially early on a Sunday!! ------------- PR: https://git.openjdk.java.net/jdk/pull/9033 From dcubed at openjdk.java.net Sun Jun 5 14:12:11 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sun, 5 Jun 2022 14:12:11 GMT Subject: Integrated: 8287837: ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp In-Reply-To: References: Message-ID: On Sun, 5 Jun 2022 14:00:09 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp. This pull request has now been integrated. Changeset: 3df4b034 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/3df4b034fbb49b9d9b3153807192fc999d7371ad Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8287837: ProblemList java/lang/ref/OOMEInReferenceHandler.java in -Xcomp Reviewed-by: rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/9033 From dholmes at openjdk.java.net Mon Jun 6 06:16:23 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 6 Jun 2022 06:16:23 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 20:45:24 GMT, Ioi Lam wrote: > Added description of the new flag `-XX:+AutoCreateSharedArchive` to the `java` man page. Some aspects of the description are not clear to me. Thanks, David src/java.base/share/man/java.1 line 5379: > 5377: .SS Manually Creating CDS Archives > 5378: .PP > 5379: CDS archives can be created manually with several methods: Pre-existing nit: s/with/using/ src/java.base/share/man/java.1 line 5555: > 5553: Otherwise the JVM will not load the specified archive. > 5554: Instead, it will automatically create (or update) the archive file at > 5555: exit. The use of "otherwise" and "instead" is unclear in the context of an existing archive file. What exactly will happen? 1. If the file exists and was created by the same JDK version then it will be used. 2. Regardless of (1) the named archive file will be written at VM exit, ready for use the next time? Is (2) correct even if the file exists and is from a different JDK version? Or do we only write the file if it either didn't exist, or is from the same JDK version? src/java.base/share/man/java.1 line 5563: > 5561: Therefore, if you upgrade to a newer JDK, > 5562: \f[CB]\-XX:+AutoCreateSharedArchive\f[R] will automatically recreate the > 5563: archive. But the first time you run it won't be able to use the existing archive file. This also suggests that the answer above is that the file will always get written at exit, regardless of the version or whether it pre-existed. ------------- PR: https://git.openjdk.java.net/jdk/pull/9024 From dholmes at openjdk.java.net Mon Jun 6 06:16:23 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 6 Jun 2022 06:16:23 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 21:57:45 GMT, Calvin Cheung wrote: >> Actually my first version was "Creating/Using Dynamic CDS Archive...", but this line (section title) is too long and gets badly wrapped when the man page is viewed in a terminal using `nroff`. So I dropped the word "Creating" as the meaning should still be clear enough. > > Ok. Approving as is. Based on the previous two subsections "Creating" would be the consistent way to express this. ------------- PR: https://git.openjdk.java.net/jdk/pull/9024 From duke at openjdk.java.net Mon Jun 6 06:55:32 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Mon, 6 Jun 2022 06:55:32 GMT Subject: RFR: 8287764: runtime/cds/serviceability/ReplaceCriticalClasses failed on localized Windows In-Reply-To: References: <92bwD6I4XdzOMv7YNxPss5Yu69QwuYuDaY3o7esO6Rs=.1a0cf50c-ae08-46b3-b995-941408d73374@github.com> Message-ID: On Fri, 3 Jun 2022 21:24:16 GMT, Ioi Lam wrote: >> The ReplaceCriticalClasses verifies CDS behavior when replacing the Readable interface as an example of a class that is read after JVMTI_PHASE_PRIMORDIAL. >> However, the order in which classes are loaded is affected by the language of the test environment, so the timing at which the Readable interface is loaded also changes on Windows with multibyte characters. >> Therefore, the Readable interface is not suitable for this test and should be removed. > > Looks good to me. I think this PR qualifies as a trivial change so only 1 reviewer is needed. @iklam Thank you for your review. I hope this change is integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/9009 From pchilanomate at openjdk.java.net Mon Jun 6 13:56:02 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 6 Jun 2022 13:56:02 GMT Subject: RFR: 8286830: ~HandshakeState should not touch oops In-Reply-To: <3Jd4eXfIksAcu5eMQHaP6JwZLQcSPImAJbnuZMbWsBA=.986a2465-25c9-40b4-a92b-3210a5d99448@github.com> References: <3Jd4eXfIksAcu5eMQHaP6JwZLQcSPImAJbnuZMbWsBA=.986a2465-25c9-40b4-a92b-3210a5d99448@github.com> Message-ID: On Sat, 4 Jun 2022 15:22:28 GMT, Daniel D. Daugherty wrote: > StressWrapper_StopAtExit.jtr release bits: > > ----------System.out:(10/297)---------- > > Agent_OnLoad started Agent_OnLoad finished > > About to execute for 7200 seconds. Executed 27471345 loops in 7200 seconds. About to execute for 7200 seconds. Executed 12930003 loops in 7200 seconds. vm_exit: dcubed_async_global_alloc_cnt=232552804 vm_exit: dcubed_async_global_release_cnt=232552804 ----------System.err:(1852/93678)---------- > > StressWrapper_StopAtExit.jtr fastdebug bits: > > ----------System.out:(10/294)---------- > > Agent_OnLoad started Agent_OnLoad finished > > About to execute for 7200 seconds. Executed 18516793 loops in 7200 seconds. About to execute for 7200 seconds. Executed 9128937 loops in 7200 seconds. vm_exit: dcubed_async_global_alloc_cnt=29621450 vm_exit: dcubed_async_global_release_cnt=29621450 ----------System.err:(1660/83996)---------- > > StressWrapper_StopAtExit.jtr slowdebug bits: > > ----------System.out:(10/293)---------- > > Agent_OnLoad started Agent_OnLoad finished > > About to execute for 7200 seconds. Executed 8147300 loops in 7200 seconds. About to execute for 7200 seconds. Executed 3913063 loops in 7200 seconds. vm_exit: dcubed_async_global_alloc_cnt=15924123 vm_exit: dcubed_async_global_release_cnt=15924123 ----------System.err:(691/34976)---------- > > No leaks detected in any config. > Great, thanks for confirming Dan! ------------- PR: https://git.openjdk.java.net/jdk/pull/8795 From iklam at openjdk.java.net Mon Jun 6 20:35:59 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 6 Jun 2022 20:35:59 GMT Subject: RFR: 8287764: runtime/cds/serviceability/ReplaceCriticalClasses failed on localized Windows In-Reply-To: References: <92bwD6I4XdzOMv7YNxPss5Yu69QwuYuDaY3o7esO6Rs=.1a0cf50c-ae08-46b3-b995-941408d73374@github.com> Message-ID: On Mon, 6 Jun 2022 06:53:03 GMT, KIRIYAMA Takuya wrote: >> Looks good to me. I think this PR qualifies as a trivial change so only 1 reviewer is needed. > > @iklam > Thank you for your review. > I hope this change is integrated. @tkiriyama thanks for fixing this issue! ------------- PR: https://git.openjdk.java.net/jdk/pull/9009 From iklam at openjdk.java.net Mon Jun 6 20:56:32 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 6 Jun 2022 20:56:32 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating [v2] In-Reply-To: References: Message-ID: > Added description of the new flag `-XX:+AutoCreateSharedArchive` to the `java` man page. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @dholmes-ora comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/9024/files - new: https://git.openjdk.java.net/jdk/pull/9024/files/c8034a6c..12bd8549 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9024&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9024&range=00-01 Stats: 26 lines in 1 file changed: 10 ins; 1 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/9024.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9024/head:pull/9024 PR: https://git.openjdk.java.net/jdk/pull/9024 From iklam at openjdk.java.net Mon Jun 6 20:56:37 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 6 Jun 2022 20:56:37 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating [v2] In-Reply-To: References: Message-ID: On Mon, 6 Jun 2022 06:11:55 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @dholmes-ora comments > > src/java.base/share/man/java.1 line 5563: > >> 5561: Therefore, if you upgrade to a newer JDK, >> 5562: \f[CB]\-XX:+AutoCreateSharedArchive\f[R] will automatically recreate the >> 5563: archive. > > But the first time you run it won't be able to use the existing archive file. This also suggests that the answer above is that the file will always get written at exit, regardless of the version or whether it pre-existed. Hi David, I have updated the text to be more precise about the behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/9024 From duke at openjdk.java.net Mon Jun 6 21:13:52 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Mon, 6 Jun 2022 21:13:52 GMT Subject: Integrated: 8287764: runtime/cds/serviceability/ReplaceCriticalClasses failed on localized Windows In-Reply-To: <92bwD6I4XdzOMv7YNxPss5Yu69QwuYuDaY3o7esO6Rs=.1a0cf50c-ae08-46b3-b995-941408d73374@github.com> References: <92bwD6I4XdzOMv7YNxPss5Yu69QwuYuDaY3o7esO6Rs=.1a0cf50c-ae08-46b3-b995-941408d73374@github.com> Message-ID: On Fri, 3 Jun 2022 06:58:24 GMT, KIRIYAMA Takuya wrote: > The ReplaceCriticalClasses verifies CDS behavior when replacing the Readable interface as an example of a class that is read after JVMTI_PHASE_PRIMORDIAL. > However, the order in which classes are loaded is affected by the language of the test environment, so the timing at which the Readable interface is loaded also changes on Windows with multibyte characters. > Therefore, the Readable interface is not suitable for this test and should be removed. This pull request has now been integrated. Changeset: c328f8fa Author: KIRIYAMA Takuya Committer: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/c328f8fa2a166ead49d23138e0d7e507c3ebba53 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8287764: runtime/cds/serviceability/ReplaceCriticalClasses failed on localized Windows Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/9009 From coleenp at openjdk.java.net Mon Jun 6 21:23:47 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 6 Jun 2022 21:23:47 GMT Subject: RFR: 8287101: CDS should check for file truncation for all regions In-Reply-To: References: Message-ID: <_1LrFz9vkdjhIdtM0f_iprQHp051KUbo5y1E1-e-7TI=.0f208870-3674-4a1c-ba75-5ab2df97e335@github.com> On Thu, 2 Jun 2022 20:41:15 GMT, Calvin Cheung wrote: > Currently, only the `last_valid_region` is checked for file truncation for a CDS archive. If serial GC is used, file truncation is not detected because the `last_valid_region` is empty so `si->file_offset() == 0`. This change is for checking file truncation for all regions. > > Also add a test which truncates at the end of the file to trigger the "The shared archive file has been truncated." error. > > Testing: tiers 1 and 2, also ran the test case with -XX:+UseSerialGC. Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9004 From ccheung at openjdk.java.net Mon Jun 6 21:59:23 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 6 Jun 2022 21:59:23 GMT Subject: RFR: 8287101: CDS should check for file truncation for all regions In-Reply-To: References: Message-ID: On Thu, 2 Jun 2022 22:36:49 GMT, Ioi Lam wrote: >> Currently, only the `last_valid_region` is checked for file truncation for a CDS archive. If serial GC is used, file truncation is not detected because the `last_valid_region` is empty so `si->file_offset() == 0`. This change is for checking file truncation for all regions. >> >> Also add a test which truncates at the end of the file to trigger the "The shared archive file has been truncated." error. >> >> Testing: tiers 1 and 2, also ran the test case with -XX:+UseSerialGC. > > Looks good. Thanks @iklam and @coleenp for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/9004 From ccheung at openjdk.java.net Mon Jun 6 21:59:25 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 6 Jun 2022 21:59:25 GMT Subject: Integrated: 8287101: CDS should check for file truncation for all regions In-Reply-To: References: Message-ID: On Thu, 2 Jun 2022 20:41:15 GMT, Calvin Cheung wrote: > Currently, only the `last_valid_region` is checked for file truncation for a CDS archive. If serial GC is used, file truncation is not detected because the `last_valid_region` is empty so `si->file_offset() == 0`. This change is for checking file truncation for all regions. > > Also add a test which truncates at the end of the file to trigger the "The shared archive file has been truncated." error. > > Testing: tiers 1 and 2, also ran the test case with -XX:+UseSerialGC. This pull request has now been integrated. Changeset: 124ba45f Author: Calvin Cheung URL: https://git.openjdk.java.net/jdk/commit/124ba45fb83985676136ecb3c55a781382fdbfd7 Stats: 46 lines in 3 files changed: 38 ins; 2 del; 6 mod 8287101: CDS should check for file truncation for all regions Reviewed-by: iklam, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/9004 From iklam at openjdk.java.net Mon Jun 6 22:53:54 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 6 Jun 2022 22:53:54 GMT Subject: RFR: 8287869: -XX:+AutoCreateSharedArchive doesn't work when JDK build is switched Message-ID: When you switch to a different build of the JDK (to a different version, or from product to debug), `-XX:+AutoCreateSharedArchive` should automatically regenerate the dynamic CDS archive. However, we have a bug where the information about the base archive is incorrectly stored in the dynamic archive. As a result, the new JDK will try to load the default base archive from the old JDK, causing CDS to be disabled, which means that the dynamic CDS archive cannot be generated at VM exit. The fix is to correctly set `GenericCDSFileMapHeader::__base_archive_name_{offset,size}` to zero when the default base archive is used. (Currently the fix can be validated only manually -- see JBS bug report. We are looking into a way to test this scenario automatically in the CI). ------------- Commit messages: - 8287869: -XX:+AutoCreateSharedArchive doesn't work when JDK build is switched Changes: https://git.openjdk.java.net/jdk/pull/9046/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9046&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287869 Stats: 13 lines in 2 files changed: 4 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/9046.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9046/head:pull/9046 PR: https://git.openjdk.java.net/jdk/pull/9046 From ccheung at openjdk.java.net Mon Jun 6 23:06:07 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 6 Jun 2022 23:06:07 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating [v2] In-Reply-To: References: Message-ID: On Mon, 6 Jun 2022 20:56:32 GMT, Ioi Lam wrote: >> Added description of the new flag `-XX:+AutoCreateSharedArchive` to the `java` man page. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora comments Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/9024 From iklam at openjdk.java.net Mon Jun 6 23:13:39 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 6 Jun 2022 23:13:39 GMT Subject: RFR: 8287872: Disable concurrent execution of hotspot docker tests Message-ID: Please review this quick fix. Before the cause of [JDK-8287744](https://bugs.openjdk.org/browse/JDK-8287744) is known, let's disable concurrent execution of hotspot docker tests to avoid failures in CI. ------------- Commit messages: - 8287872: Disable concurrent execution of hotspot docker tests Changes: https://git.openjdk.java.net/jdk/pull/9047/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9047&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287872 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/9047.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9047/head:pull/9047 PR: https://git.openjdk.java.net/jdk/pull/9047 From iklam at openjdk.java.net Mon Jun 6 23:24:55 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 6 Jun 2022 23:24:55 GMT Subject: RFR: JDK-8287011: Container information could be improved [v3] In-Reply-To: References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: On Fri, 3 Jun 2022 14:05:27 GMT, Matthias Baesken wrote: >> The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > handle new cgroupv1 and v2 values in TestMisc I think the issue title should be changed to "Improve container information", or maybe more specifically to "Improve container information in hs_err and logging". ------------- PR: https://git.openjdk.java.net/jdk/pull/8991 From mseledtsov at openjdk.java.net Tue Jun 7 01:12:15 2022 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Tue, 7 Jun 2022 01:12:15 GMT Subject: RFR: 8287872: Disable concurrent execution of hotspot docker tests In-Reply-To: References: Message-ID: On Mon, 6 Jun 2022 22:52:41 GMT, Ioi Lam wrote: > Please review this quick fix. > > Before the cause of [JDK-8287744](https://bugs.openjdk.org/browse/JDK-8287744) is known, let's disable concurrent execution of hotspot docker tests to avoid failures in CI. Looks good. ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk/pull/9047 From iklam at openjdk.java.net Tue Jun 7 04:25:14 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 7 Jun 2022 04:25:14 GMT Subject: RFR: 8287869: -XX:+AutoCreateSharedArchive doesn't work when JDK build is switched [v2] In-Reply-To: References: Message-ID: > When you switch to a different build of the JDK (to a different version, or from product to debug), `-XX:+AutoCreateSharedArchive` should automatically regenerate the dynamic CDS archive. > > However, we have a bug where the information about the base archive is incorrectly stored in the dynamic archive. As a result, the new JDK will try to load the default base archive from the old JDK, causing CDS to be disabled, which means that the dynamic CDS archive cannot be generated at VM exit. > > The fix is to correctly set `GenericCDSFileMapHeader::__base_archive_name_{offset,size}` to zero when the default base archive is used. > > (Currently the fix can be validated only manually -- see JBS bug report. We are looking into a way to test this scenario automatically in the CI). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed test cases ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/9046/files - new: https://git.openjdk.java.net/jdk/pull/9046/files/8eded2fa..560cc6e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9046&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9046&range=00-01 Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/9046.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9046/head:pull/9046 PR: https://git.openjdk.java.net/jdk/pull/9046 From iklam at openjdk.java.net Tue Jun 7 04:52:04 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 7 Jun 2022 04:52:04 GMT Subject: RFR: 8287872: Disable concurrent execution of hotspot docker tests In-Reply-To: References: Message-ID: <2q5UXeVAI5etjZVNAzzg1IpKc3wzj4ifsXdN7j-YOAQ=.e1784f05-1abc-49e4-ac9b-8758b4dbdf4d@github.com> On Tue, 7 Jun 2022 01:09:22 GMT, Mikhailo Seledtsov wrote: >> Please review this quick fix. >> >> Before the cause of [JDK-8287744](https://bugs.openjdk.org/browse/JDK-8287744) is known, let's disable concurrent execution of hotspot docker tests to avoid failures in CI. > > Looks good. @mseledts thanks for the review. I ran the tier-5 container tests and they all passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/9047 From iklam at openjdk.java.net Tue Jun 7 04:56:18 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 7 Jun 2022 04:56:18 GMT Subject: RFR: 8287869: -XX:+AutoCreateSharedArchive doesn't work when JDK build is switched [v3] In-Reply-To: References: Message-ID: > When you switch to a different build of the JDK (to a different version, or from product to debug), `-XX:+AutoCreateSharedArchive` should automatically regenerate the dynamic CDS archive. > > However, we have a bug where the information about the base archive is incorrectly stored in the dynamic archive. As a result, the new JDK will try to load the default base archive from the old JDK, causing CDS to be disabled, which means that the dynamic CDS archive cannot be generated at VM exit. > > The fix is to correctly set `GenericCDSFileMapHeader::__base_archive_name_{offset,size}` to zero when the default base archive is used. > > (Currently the fix can be validated only manually -- see JBS bug report. We are looking into a way to test this scenario automatically in the CI). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed trailing whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/9046/files - new: https://git.openjdk.java.net/jdk/pull/9046/files/560cc6e8..0eb22646 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9046&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9046&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/9046.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9046/head:pull/9046 PR: https://git.openjdk.java.net/jdk/pull/9046 From dholmes at openjdk.java.net Tue Jun 7 05:15:07 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 7 Jun 2022 05:15:07 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating [v2] In-Reply-To: References: Message-ID: On Mon, 6 Jun 2022 20:56:32 GMT, Ioi Lam wrote: >> Added description of the new flag `-XX:+AutoCreateSharedArchive` to the `java` man page. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora comments src/java.base/share/man/java.1 line 5567: > 5565: the archive at exit. > 5566: Thus, the archive will be ready to be loaded the next time the JVM is > 5567: launched with the same command line. This still seems rather complicated. Suggestion: > > If the specified archive file exists and was created by the same version (release and build number) of the JDK, then it will be loaded as a dynamic archive; otherwise it is ignored at VM startup. > > At VM exit, if the specified archive file does not exist, it will be created. If it exists but was created with a different (but post JDK 19) version of the JDK, then it will be replaced. In both cases the archive will be ready to be loaded the next time the JVM is launched with the same command line. > > If the specified archive file exists but was created by a JDK version prior to JDK 19, then it will be ignored: neither loaded at startup, nor replaced at exit. > ------------- PR: https://git.openjdk.java.net/jdk/pull/9024 From dholmes at openjdk.java.net Tue Jun 7 05:19:17 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 7 Jun 2022 05:19:17 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating [v2] In-Reply-To: References: Message-ID: On Mon, 6 Jun 2022 20:56:32 GMT, Ioi Lam wrote: >> Added description of the new flag `-XX:+AutoCreateSharedArchive` to the `java` man page. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora comments src/java.base/share/man/java.1 line 5569: > 5567: launched with the same command line. > 5568: .PP > 5569: Note that the contents of the CDS archive file are specific to each Suggestion: "Developers should note that the contents ..." ------------- PR: https://git.openjdk.java.net/jdk/pull/9024 From iklam at openjdk.java.net Tue Jun 7 05:30:08 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 7 Jun 2022 05:30:08 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating [v3] In-Reply-To: References: Message-ID: > Added description of the new flag `-XX:+AutoCreateSharedArchive` to the `java` man page. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Use text suggested by David ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/9024/files - new: https://git.openjdk.java.net/jdk/pull/9024/files/12bd8549..cefa77b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9024&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9024&range=01-02 Stats: 21 lines in 1 file changed: 0 ins; 4 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/9024.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9024/head:pull/9024 PR: https://git.openjdk.java.net/jdk/pull/9024 From dholmes at openjdk.java.net Tue Jun 7 05:32:24 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 7 Jun 2022 05:32:24 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating [v3] In-Reply-To: References: Message-ID: <1tsKwTfjXsFxdZyj4DP6MwshLRHBBLqSI1uRQ9rndlw=.bdf80734-f8ac-484c-b9ec-f9ae6001fe97@github.com> On Tue, 7 Jun 2022 05:30:08 GMT, Ioi Lam wrote: >> Added description of the new flag `-XX:+AutoCreateSharedArchive` to the `java` man page. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Use text suggested by David Looks good thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9024 From mbaesken at openjdk.java.net Tue Jun 7 07:39:09 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 7 Jun 2022 07:39:09 GMT Subject: RFR: JDK-8287011: Improve container information [v3] In-Reply-To: References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: On Mon, 6 Jun 2022 23:21:48 GMT, Ioi Lam wrote: > I think the issue title should be changed to "Improve container information", or maybe more specifically to "Improve container information in hs_err and logging". Thanks for the comment; I adjusted the title. ------------- PR: https://git.openjdk.java.net/jdk/pull/8991 From sgehwolf at openjdk.java.net Tue Jun 7 08:49:07 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 7 Jun 2022 08:49:07 GMT Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 09:18:38 GMT, Severin Gehwolf wrote: > Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated > buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue > of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read. > > While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From > a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be > there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is > meant to only use stringStream throughout the cgroups code. > > Testing: > - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2 > - [x] Added tests, which I've verified also pass before the stringStream change > > Thoughts? @iklam Would you have some cycles to review this, please? ------------- PR: https://git.openjdk.java.net/jdk/pull/8969 From sgehwolf at openjdk.java.net Tue Jun 7 08:49:58 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 7 Jun 2022 08:49:58 GMT Subject: RFR: 8287741: Fix of JDK-8287107 (unused cgv1 freezer controller) was incomplete [v2] In-Reply-To: References: Message-ID: <-CKx-n0SVtQYWjmoY8ISoAYiFNEoKCNJDdxhtCyUoeA=.8ea8c9bc-8aa6-41b9-919b-16cca0d3f315@github.com> > Please review this hotspot fix follow-up of JDK-8287107. The test which exercised this code was already added with JDK-8287107. I've now added an assert ensuring that we don't set the cgroup path multiple times. The fix is essentially the same as on the JDK side, skip setting the cgroup path when the hierarchy is non-zero which is equivalent to the empty string match that was done in the Java code. > > Testing: > - [x] `test/hotspot/jtreg/containers/cgroup/CgroupSubsystemFactory.java` with fastdebug on x86_64. Asserts before the code fix, passes after. > - [ ] GHA - still running. Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8287741: Fix of JDK-8287107 (unused cgv1 freezer controller) was incomplete Add a comment to re-trigger GHA tests. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/9001/files - new: https://git.openjdk.java.net/jdk/pull/9001/files/5c4cdc27..535f37b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9001&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9001&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/9001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9001/head:pull/9001 PR: https://git.openjdk.java.net/jdk/pull/9001 From duke at openjdk.java.net Tue Jun 7 08:49:58 2022 From: duke at openjdk.java.net (openjdk-notifier[bot]) Date: Tue, 7 Jun 2022 08:49:58 GMT Subject: RFR: 8287741: Fix of JDK-8287107 (unused cgv1 freezer controller) was incomplete [v2] In-Reply-To: <3NXr7cgkODq_VqNjiJN9Kc7kcv1_4hbPQtEk5R4QisI=.892fbfd2-71a1-46ae-b88c-7a86861109db@github.com> References: <3NXr7cgkODq_VqNjiJN9Kc7kcv1_4hbPQtEk5R4QisI=.892fbfd2-71a1-46ae-b88c-7a86861109db@github.com> Message-ID: On Fri, 3 Jun 2022 08:12:17 GMT, Severin Gehwolf wrote: >> LGTM! > >> LGTM! > > Thanks for the review, @iklam @jerboaa Please do not rebase or force-push to an active PR as it invalidates existing review comments. All changes will be squashed into a single commit automatically when integrating. See [OpenJDK Developers? Guide](https://openjdk.java.net/guide/#working-with-pull-requests) for more information. ------------- PR: https://git.openjdk.java.net/jdk/pull/9001 From yyang at openjdk.java.net Tue Jun 7 10:04:10 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 7 Jun 2022 10:04:10 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v2] In-Reply-To: References: Message-ID: <6qrVVa1ZWU8UCc0TeRYXYzQLGquO9_eNRzsQ6FUys-c=.979520bd-5ba6-4450-bb1d-34bb384d6305@github.com> > It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. > > Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` > > ==> CodeHeap 'non-nmethods' 1532544 (Used) > ==> CodeHeap 'profiled nmethods' 0 > ==> CodeHeap 'non-profiled nmethods' 13952 > ==> Metaspace 506696 > ==> Compressed Class Space 43312 > init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) > > In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`. Yi Yang has updated the pull request incrementally with one additional commit since the last revision: remove compressed class space pool ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8831/files - new: https://git.openjdk.java.net/jdk/pull/8831/files/4551c936..6b2f1be7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8831&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8831&range=00-01 Stats: 93 lines in 14 files changed: 3 ins; 76 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/8831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8831/head:pull/8831 PR: https://git.openjdk.java.net/jdk/pull/8831 From yyang at openjdk.java.net Tue Jun 7 10:07:08 2022 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 7 Jun 2022 10:07:08 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v3] In-Reply-To: References: Message-ID: > It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. > > Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` > > ==> CodeHeap 'non-nmethods' 1532544 (Used) > ==> CodeHeap 'profiled nmethods' 0 > ==> CodeHeap 'non-profiled nmethods' 13952 > ==> Metaspace 506696 > ==> Compressed Class Space 43312 > init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) > > In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`. Yi Yang has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8831/files - new: https://git.openjdk.java.net/jdk/pull/8831/files/6b2f1be7..54318474 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8831&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8831&range=01-02 Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8831/head:pull/8831 PR: https://git.openjdk.java.net/jdk/pull/8831 From sgehwolf at openjdk.java.net Tue Jun 7 12:28:13 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 7 Jun 2022 12:28:13 GMT Subject: RFR: 8287741: Fix of JDK-8287107 (unused cgv1 freezer controller) was incomplete [v2] In-Reply-To: <-CKx-n0SVtQYWjmoY8ISoAYiFNEoKCNJDdxhtCyUoeA=.8ea8c9bc-8aa6-41b9-919b-16cca0d3f315@github.com> References: <-CKx-n0SVtQYWjmoY8ISoAYiFNEoKCNJDdxhtCyUoeA=.8ea8c9bc-8aa6-41b9-919b-16cca0d3f315@github.com> Message-ID: On Tue, 7 Jun 2022 08:49:58 GMT, Severin Gehwolf wrote: >> Please review this hotspot fix follow-up of JDK-8287107. The test which exercised this code was already added with JDK-8287107. I've now added an assert ensuring that we don't set the cgroup path multiple times. The fix is essentially the same as on the JDK side, skip setting the cgroup path when the hierarchy is non-zero which is equivalent to the empty string match that was done in the Java code. >> >> Testing: >> - [x] `test/hotspot/jtreg/containers/cgroup/CgroupSubsystemFactory.java` with fastdebug on x86_64. Asserts before the code fix, passes after. >> - [x] GHA > > Severin Gehwolf has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8287741: Fix of JDK-8287107 (unused cgv1 freezer controller) was incomplete > > Add a comment to re-trigger GHA tests. It doesn't look like tier1 failures in GHA on x86 (32 bit) Linux are related to this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/9001 From sgehwolf at openjdk.java.net Tue Jun 7 12:31:13 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 7 Jun 2022 12:31:13 GMT Subject: Integrated: 8287741: Fix of JDK-8287107 (unused cgv1 freezer controller) was incomplete In-Reply-To: References: Message-ID: On Thu, 2 Jun 2022 18:30:38 GMT, Severin Gehwolf wrote: > Please review this hotspot fix follow-up of JDK-8287107. The test which exercised this code was already added with JDK-8287107. I've now added an assert ensuring that we don't set the cgroup path multiple times. The fix is essentially the same as on the JDK side, skip setting the cgroup path when the hierarchy is non-zero which is equivalent to the empty string match that was done in the Java code. > > Testing: > - [x] `test/hotspot/jtreg/containers/cgroup/CgroupSubsystemFactory.java` with fastdebug on x86_64. Asserts before the code fix, passes after. > - [x] GHA This pull request has now been integrated. Changeset: 8d28734e Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/8d28734ede0ed3922c92451a172d1fa676e484e9 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8287741: Fix of JDK-8287107 (unused cgv1 freezer controller) was incomplete Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/9001 From sgehwolf at openjdk.java.net Tue Jun 7 12:42:26 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 7 Jun 2022 12:42:26 GMT Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v2] In-Reply-To: References: Message-ID: > Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated > buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue > of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read. > > While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From > a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be > there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is > meant to only use stringStream throughout the cgroups code. > > Testing: > - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2 > - [x] Added tests, which I've verified also pass before the stringStream change > > Thoughts? Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into jdk-8287007-string-stream - Add cgroups v2 java test - use stringStream in cgroups v2 - Add gtest for cgroups v2 code path Also fixes the bug when cgroup path is '/'. - 8287007: [cgroups] Consistently use stringStream throughout parsing code - 8287007: [cgroups] Consistently use stringStream throughout parsing code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8969/files - new: https://git.openjdk.java.net/jdk/pull/8969/files/a7b156a4..8047fe37 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8969&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8969&range=00-01 Stats: 60055 lines in 839 files changed: 34126 ins; 19620 del; 6309 mod Patch: https://git.openjdk.java.net/jdk/pull/8969.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8969/head:pull/8969 PR: https://git.openjdk.java.net/jdk/pull/8969 From mbaesken at openjdk.java.net Tue Jun 7 13:15:08 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 7 Jun 2022 13:15:08 GMT Subject: RFR: JDK-8287011: Improve container information [v3] In-Reply-To: References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: On Fri, 3 Jun 2022 15:20:23 GMT, Severin Gehwolf wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> handle new cgroupv1 and v2 values in TestMisc > > src/hotspot/os/linux/os_linux.cpp line 2271: > >> 2269: // the kmem (kernel memory) values are only available in cgroupv1 >> 2270: if (p_ct != NULL && strcmp(p_ct, "cgroupv1") == 0) { >> 2271: print_container_helper(st, OSContainer::kernel_memory_usage_in_bytes(), "kernel_memory_usage_in_bytes"); > > We wouldn't need the extra version checking gymnastics if we'd call an `OSContainer::print_version_specific_info(st);` here instead. sounds like a good idea, but with the kmem stuff deprecated (Kernel commit adding the deprecation: https://github.com/torvalds/linux/commit/0158115f702b ) we should maybe wait first for a reply from Thomas why he is still interested in it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8991 From sgehwolf at openjdk.java.net Tue Jun 7 13:21:07 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 7 Jun 2022 13:21:07 GMT Subject: RFR: JDK-8287011: Improve container information [v3] In-Reply-To: References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: On Tue, 7 Jun 2022 13:11:49 GMT, Matthias Baesken wrote: >> src/hotspot/os/linux/os_linux.cpp line 2271: >> >>> 2269: // the kmem (kernel memory) values are only available in cgroupv1 >>> 2270: if (p_ct != NULL && strcmp(p_ct, "cgroupv1") == 0) { >>> 2271: print_container_helper(st, OSContainer::kernel_memory_usage_in_bytes(), "kernel_memory_usage_in_bytes"); >> >> We wouldn't need the extra version checking gymnastics if we'd call an `OSContainer::print_version_specific_info(st);` here instead. > > sounds like a good idea, but with the kmem stuff deprecated (Kernel commit adding the deprecation: > https://github.com/torvalds/linux/commit/0158115f702b ) we should maybe wait first for a reply from Thomas why he is still interested in it. OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8991 From stuefe at openjdk.java.net Tue Jun 7 15:07:11 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 7 Jun 2022 15:07:11 GMT Subject: RFR: JDK-8287011: Improve container information [v3] In-Reply-To: References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: <3BSe9cYH3VVel4mMFm9cE2G3qK8etS3hcw9BZjjmxbQ=.4076de86-d781-41d7-8140-e8ef6f7ee192@github.com> On Fri, 3 Jun 2022 14:05:27 GMT, Matthias Baesken wrote: >> The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > handle new cgroupv1 and v2 values in TestMisc Hi Severin, > * What's the use-case for those diagnostics? Usually on kubernetes swap is disabled so the swap info there is quite useless in that case. Why is the kernel memory info needed? The bug doesn't say _why_ it's important to have. Memory+swap (v1) or only swap (v2) limits are interesting to us since they may limit memory usage of a container the same way memory limit does. We are often confronted with unexplainable OOM kills or container kills; it makes sense to know the whole cgroup config, not only part of that. ------------- PR: https://git.openjdk.java.net/jdk/pull/8991 From stuefe at openjdk.java.net Tue Jun 7 15:07:16 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 7 Jun 2022 15:07:16 GMT Subject: RFR: JDK-8287011: Improve container information [v3] In-Reply-To: References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: On Fri, 3 Jun 2022 15:15:41 GMT, Severin Gehwolf wrote: > I'm really not fond of this increased API surface for properties which are only supported on one version, but not the other. The idea would be to use those for printing in `os_linux`, right? Could we not move the implementation detail to the version specific classes? I.e. define `virtual void print_version_specific_info(outputStream* st) = 0` here and in `osContainer_linux.hpp` then only call `OSContainer::print_version_specific_info(st)` in `os_linux` and be done with it? This would avoid the empty stub implementations in the version specific classes... We can do something much simpler. We can just expose the memory controller path and let `os::print_container_info()` read the files directly. Like we do e.g. with /proc/meminfo. The really useful thing OsContainer does is figuring out the controller path. Wrt to hs-err printing and VM.info, I am not so interested in its v1-v2-agnostic abstraction. I just want to know the values of the files in that directory, verbatim. If `os::print_container_info` were to access those files directly, we would not need to discuss which values are deemed useful or not. We just can print whatever we want without broadening the API surface. And I don't have to do the mental gymnastics to backtrace the v1-v2-abstraction numbers to their real platform meaning. In short, I think abstractions are useful to programmatically base decisions on hotspot and java code. But for error analysis, I prefer the raw values with their exact names. ------------- PR: https://git.openjdk.java.net/jdk/pull/8991 From ccheung at openjdk.java.net Tue Jun 7 16:02:26 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 7 Jun 2022 16:02:26 GMT Subject: RFR: 8287869: -XX:+AutoCreateSharedArchive doesn't work when JDK build is switched [v3] In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 04:56:18 GMT, Ioi Lam wrote: >> When you switch to a different build of the JDK (to a different version, or from product to debug), `-XX:+AutoCreateSharedArchive` should automatically regenerate the dynamic CDS archive. >> >> However, we have a bug where the information about the base archive is incorrectly stored in the dynamic archive. As a result, the new JDK will try to load the default base archive from the old JDK, causing CDS to be disabled, which means that the dynamic CDS archive cannot be generated at VM exit. >> >> The fix is to correctly set `GenericCDSFileMapHeader::__base_archive_name_{offset,size}` to zero when the default base archive is used. >> >> (Currently the fix can be validated only manually -- see JBS bug report. We are looking into a way to test this scenario automatically in the CI). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed trailing whitespace LGTM ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9046 From iklam at openjdk.java.net Tue Jun 7 16:58:17 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 7 Jun 2022 16:58:17 GMT Subject: RFR: 8273853: Update the Java manpage for automatic CDS archive updating [v2] In-Reply-To: References: Message-ID: On Mon, 6 Jun 2022 23:03:17 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @dholmes-ora comments > > Marked as reviewed by ccheung (Reviewer). Thanks @calvinccheung and @dholmes-ora for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/9024 From iklam at openjdk.java.net Tue Jun 7 17:01:08 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 7 Jun 2022 17:01:08 GMT Subject: Integrated: 8273853: Update the Java manpage for automatic CDS archive updating In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 20:45:24 GMT, Ioi Lam wrote: > Added description of the new flag `-XX:+AutoCreateSharedArchive` to the `java` man page. This pull request has now been integrated. Changeset: c41a283f Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/c41a283f527dcc4397707b8b19880f1b9aac6fb3 Stats: 39 lines in 1 file changed: 36 ins; 0 del; 3 mod 8273853: Update the Java manpage for automatic CDS archive updating Reviewed-by: ccheung, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/9024 From ccheung at openjdk.java.net Tue Jun 7 17:16:03 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 7 Jun 2022 17:16:03 GMT Subject: RFR: 8287872: Disable concurrent execution of hotspot docker tests In-Reply-To: References: Message-ID: On Mon, 6 Jun 2022 22:52:41 GMT, Ioi Lam wrote: > Please review this quick fix. > > Before the cause of [JDK-8287744](https://bugs.openjdk.org/browse/JDK-8287744) is known, let's disable concurrent execution of hotspot docker tests to avoid failures in CI. Looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9047 From dcubed at openjdk.java.net Tue Jun 7 17:29:11 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 7 Jun 2022 17:29:11 GMT Subject: Integrated: 8287919: ProblemList java/lang/CompressExpandTest.java Message-ID: A trivial fix to ProblemList java/lang/CompressExpandTest.java. ------------- Commit messages: - 8287919: ProblemList java/lang/CompressExpandTest.java Changes: https://git.openjdk.java.net/jdk/pull/9069/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9069&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287919 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/9069.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9069/head:pull/9069 PR: https://git.openjdk.java.net/jdk/pull/9069 From azvegint at openjdk.java.net Tue Jun 7 17:29:12 2022 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 7 Jun 2022 17:29:12 GMT Subject: Integrated: 8287919: ProblemList java/lang/CompressExpandTest.java In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 17:17:23 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/CompressExpandTest.java. Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/9069 From dcubed at openjdk.java.net Tue Jun 7 17:29:14 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 7 Jun 2022 17:29:14 GMT Subject: Integrated: 8287919: ProblemList java/lang/CompressExpandTest.java In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 17:18:33 GMT, Alexander Zvegintsev wrote: >> A trivial fix to ProblemList java/lang/CompressExpandTest.java. > > Marked as reviewed by azvegint (Reviewer). @azvegint - Thanks for the fast review! ------------- PR: https://git.openjdk.java.net/jdk/pull/9069 From dcubed at openjdk.java.net Tue Jun 7 17:29:15 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 7 Jun 2022 17:29:15 GMT Subject: Integrated: 8287919: ProblemList java/lang/CompressExpandTest.java In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 17:17:23 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/CompressExpandTest.java. This pull request has now been integrated. Changeset: 91e6bf67 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/91e6bf6791b7fc26db6f4288830091d812232dd8 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8287919: ProblemList java/lang/CompressExpandTest.java Reviewed-by: azvegint ------------- PR: https://git.openjdk.java.net/jdk/pull/9069 From iklam at openjdk.java.net Tue Jun 7 17:32:07 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 7 Jun 2022 17:32:07 GMT Subject: Integrated: 8287872: Disable concurrent execution of hotspot docker tests In-Reply-To: References: Message-ID: On Mon, 6 Jun 2022 22:52:41 GMT, Ioi Lam wrote: > Please review this quick fix. > > Before the cause of [JDK-8287744](https://bugs.openjdk.org/browse/JDK-8287744) is known, let's disable concurrent execution of hotspot docker tests to avoid failures in CI. This pull request has now been integrated. Changeset: 9ec27d0e Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/9ec27d0e9fff06d38d7541eb630867d412d9e4a6 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8287872: Disable concurrent execution of hotspot docker tests Reviewed-by: mseledtsov, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/9047 From rpressler at openjdk.java.net Tue Jun 7 18:49:35 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Tue, 7 Jun 2022 18:49:35 GMT Subject: RFR: 8287901: Loom: Failures with -XX:+VerifyStack Message-ID: Please review the following change. Debugging information added to `frame::describe` (used by `JavaThread::print_frame_layout`) was inaccurate, but proved fatal with `VerifyStack`, which uses the same information for verification. The location of a caller frame's return address and spilled fp, which are located in the callee, were recorded by the caller frame. In the case of the special frame `Continuation.enterSpecial`, those locations were recorded incorrectly. The fix is to record the information while describing the callee frame, rather than the caller. Passes tier1 ------------- Commit messages: - 8287901: Loom: Failures with -XX:+VerifyStack Changes: https://git.openjdk.java.net/jdk/pull/9066/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9066&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287901 Stats: 25 lines in 3 files changed: 11 ins; 2 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/9066.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9066/head:pull/9066 PR: https://git.openjdk.java.net/jdk/pull/9066 From stuefe at openjdk.java.net Tue Jun 7 19:44:33 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 7 Jun 2022 19:44:33 GMT Subject: RFR: JDK-8287011: Improve container information [v3] In-Reply-To: References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: <9uc6Fpc0xn-1oVpRwWw8qaTb6E2DJobApIMGAdhmdjE=.d117d3f4-5102-41f1-b6c0-08d94b2045dd@github.com> On Fri, 3 Jun 2022 14:05:27 GMT, Matthias Baesken wrote: >> The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > handle new cgroupv1 and v2 values in TestMisc As I wrote in a comment, if it is a problem expanding the OsContainer API and getting a good and useful v1-v2-abstraction, then let's not. All I really wanted was 1) have c-groups info in hs-err and Vm.Info and 2) have a clarification wrt different meaning of `memory_and_swap_limit_in_bytes()` for v1 vs v2. I can live without (2), and for 1), I can live with a solution where OsContainer just exposes the memory controller path and in os_linux.cpp we print out the various files we are interested in directly. I can also live with Matthias' patch as it is now, which I think is clean and looks good. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/8991 From dcubed at openjdk.java.net Tue Jun 7 20:42:52 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 7 Jun 2022 20:42:52 GMT Subject: RFR: 8287927: ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64 Message-ID: A trivial fix to ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64. What I'd really like to is to ProblemList this test on Mac_OS_X_12.4 and Mac_OS_X_12.5, but two digit release values (M.N) did not work when I tried them a month or so ago. ------------- Commit messages: - 8287927: ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/9071/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9071&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287927 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/9071.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9071/head:pull/9071 PR: https://git.openjdk.java.net/jdk/pull/9071 From aivanov at openjdk.java.net Tue Jun 7 21:11:52 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 7 Jun 2022 21:11:52 GMT Subject: RFR: 8287927: ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 20:33:43 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64. > > What I'd really like to is to ProblemList this test > on Mac_OS_X_12.4 and Mac_OS_X_12.5, but two digit release values > (M.N) did not work when I tried them a month or so ago. Marked as reviewed by aivanov (Reviewer). I'm unsure it belongs in *hotspot-runtime*? ------------- PR: https://git.openjdk.java.net/jdk/pull/9071 From dcubed at openjdk.java.net Tue Jun 7 21:11:52 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 7 Jun 2022 21:11:52 GMT Subject: RFR: 8287927: ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 20:33:43 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64. > > What I'd really like to is to ProblemList this test > on Mac_OS_X_12.4 and Mac_OS_X_12.5, but two digit release values > (M.N) did not work when I tried them a month or so ago. It doesn't belong in hotspot-runtime, but I include hotspot-runtime just in case one of my team is on-the-air and can give a quick review... @aivanov-jdk thanks for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/9071 From dcubed at openjdk.java.net Tue Jun 7 21:11:53 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 7 Jun 2022 21:11:53 GMT Subject: Integrated: 8287927: ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64 In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 20:33:43 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64. > > What I'd really like to is to ProblemList this test > on Mac_OS_X_12.4 and Mac_OS_X_12.5, but two digit release values > (M.N) did not work when I tried them a month or so ago. This pull request has now been integrated. Changeset: b7a34f72 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/b7a34f728d0653d55ef01da045c9aad4c0471143 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8287927: ProblemList java/awt/GraphicsDevice/DisplayModes/UnknownRefrshRateTest.java on macosx-aarch64 Reviewed-by: aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/9071 From dholmes at openjdk.java.net Tue Jun 7 21:13:41 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 7 Jun 2022 21:13:41 GMT Subject: RFR: 8287869: -XX:+AutoCreateSharedArchive doesn't work when JDK build is switched [v3] In-Reply-To: References: Message-ID: <-N258i5nzLAbI_VYSK9U66YDTdNIH5QZJU6sEQI6xSE=.84c5538c-5ea4-40bc-97d7-7f251311dbab@github.com> On Tue, 7 Jun 2022 04:56:18 GMT, Ioi Lam wrote: >> When you switch to a different build of the JDK (to a different version, or from product to debug), `-XX:+AutoCreateSharedArchive` should automatically regenerate the dynamic CDS archive. >> >> However, we have a bug where the information about the base archive is incorrectly stored in the dynamic archive. As a result, the new JDK will try to load the default base archive from the old JDK, causing CDS to be disabled, which means that the dynamic CDS archive cannot be generated at VM exit. >> >> The fix is to correctly set `GenericCDSFileMapHeader::__base_archive_name_{offset,size}` to zero when the default base archive is used. >> >> (Currently the fix can be validated only manually -- see JBS bug report. We are looking into a way to test this scenario automatically in the CI). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed trailing whitespace Seems okay. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9046 From iklam at openjdk.java.net Tue Jun 7 23:12:28 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 7 Jun 2022 23:12:28 GMT Subject: RFR: 8287869: -XX:+AutoCreateSharedArchive doesn't work when JDK build is switched [v3] In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 16:00:14 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed trailing whitespace > > LGTM Thanks @calvinccheung and @dholmes-ora for the review. Passed tiers 1-4. ------------- PR: https://git.openjdk.java.net/jdk/pull/9046 From iklam at openjdk.java.net Tue Jun 7 23:15:32 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 7 Jun 2022 23:15:32 GMT Subject: Integrated: 8287869: -XX:+AutoCreateSharedArchive doesn't work when JDK build is switched In-Reply-To: References: Message-ID: On Mon, 6 Jun 2022 22:30:13 GMT, Ioi Lam wrote: > When you switch to a different build of the JDK (to a different version, or from product to debug), `-XX:+AutoCreateSharedArchive` should automatically regenerate the dynamic CDS archive. > > However, we have a bug where the information about the base archive is incorrectly stored in the dynamic archive. As a result, the new JDK will try to load the default base archive from the old JDK, causing CDS to be disabled, which means that the dynamic CDS archive cannot be generated at VM exit. > > The fix is to correctly set `GenericCDSFileMapHeader::__base_archive_name_{offset,size}` to zero when the default base archive is used. > > (Currently the fix can be validated only manually -- see JBS bug report. We are looking into a way to test this scenario automatically in the CI). This pull request has now been integrated. Changeset: 68c5957b Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/68c5957b9e2306d96bec2d655ec743f13f250dae Stats: 27 lines in 4 files changed: 12 ins; 0 del; 15 mod 8287869: -XX:+AutoCreateSharedArchive doesn't work when JDK build is switched Reviewed-by: ccheung, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/9046 From hseigel at openjdk.java.net Wed Jun 8 00:01:57 2022 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 8 Jun 2022 00:01:57 GMT Subject: RFR: 8287854: Dangling reference in ClassVerifier::verify_class Message-ID: Please review this small change to fix JDK_8287854. The fix was tested with JCK lang and VM tests, Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows (in progress), and Mach5 tiers 3-5 on Linux x64. Thanks, Harold ------------- Commit messages: - 8287854: Dangling reference in ClassVerifier::verify_class Changes: https://git.openjdk.java.net/jdk/pull/9075/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9075&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287854 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/9075.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9075/head:pull/9075 PR: https://git.openjdk.java.net/jdk/pull/9075 From dholmes at openjdk.java.net Wed Jun 8 04:29:31 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 8 Jun 2022 04:29:31 GMT Subject: RFR: 8287854: Dangling reference in ClassVerifier::verify_class In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 23:52:52 GMT, Harold Seigel wrote: > Please review this small change to fix JDK_8287854. The fix was tested with JCK lang and VM tests, Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows (in progress), and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold The change is functionally correct, but this seems like a textbook case for a RAII helper class. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9075 From iklam at openjdk.java.net Wed Jun 8 06:03:25 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 8 Jun 2022 06:03:25 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v3] In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 10:07:08 GMT, Yi Yang wrote: >> It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. >> >> Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` >> >> ==> CodeHeap 'non-nmethods' 1532544 (Used) >> ==> CodeHeap 'profiled nmethods' 0 >> ==> CodeHeap 'non-profiled nmethods' 13952 >> ==> Metaspace 506696 >> ==> Compressed Class Space 43312 >> init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) >> >> In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`. > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > update @tstuefe could you take a look at the test changes. Since we can no longer query the compressed class space individually, I think the tests may become more lenient than before. For example, memoryUsageSmallComp/TestDescription.java uses `MemoryUsageTest::checkForNotGrowing()` which monitors the used bytes in `MetaspaceBaseGC::pool.getUsage().getUsed()` - Before this PR, it checks that the usage of the compressed klass space doesn't grow. - After this PR, it will allow the compresed klass space to grow, as long as the "other" meta space shrinks by a similar amount. Is this OK? Or should we add a new whitebox API to query the compressed vs meta space? src/hotspot/share/services/management.cpp line 743: > 741: } else { > 742: // Calculate the memory usage by summing up the pools. > 743: // NonHeapUsage = CodeHeaps + Metaspace I think the new comments in this file can be removed. test/hotspot/jtreg/vmTestbase/metaspace/gc/MemoryUsageTest.java line 141: > 139: System.err.println("Usage: "); > 140: System.err.println("java [-Xms..] [-XX:MetaspaceSize=..] [-XX:MaxMetaspaceSize=..] \\"); > 141: System.err.println(" " + MemoryUsageTest.class.getCanonicalName()); This method can be deleted since it's no longer used. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831 From iklam at openjdk.java.net Wed Jun 8 06:11:15 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 8 Jun 2022 06:11:15 GMT Subject: RFR: 8287854: Dangling reference in ClassVerifier::verify_class In-Reply-To: References: Message-ID: On Wed, 8 Jun 2022 04:26:07 GMT, David Holmes wrote: > The change is functionally correct, but this seems like a textbook case for a RAII helper class. I agree with David that RAII is needed here. There's one exit path that's not covered by the existing patch: void ClassVerifier::verify_class(TRAPS) { ... verify_method(methodHandle(THREAD, m), CHECK_VERIFY(this)); ... } ------------- PR: https://git.openjdk.java.net/jdk/pull/9075 From iklam at openjdk.java.net Wed Jun 8 07:21:34 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 8 Jun 2022 07:21:34 GMT Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v2] In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 12:42:26 GMT, Severin Gehwolf wrote: >> Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated >> buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue >> of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read. >> >> While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From >> a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be >> there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is >> meant to only use stringStream throughout the cgroups code. >> >> Testing: >> - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2 >> - [x] Added tests, which I've verified also pass before the stringStream change >> >> Thoughts? > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into jdk-8287007-string-stream > - Add cgroups v2 java test > - use stringStream in cgroups v2 > - Add gtest for cgroups v2 code path > > Also fixes the bug when cgroup path is '/'. > - 8287007: [cgroups] Consistently use stringStream throughout parsing code > - 8287007: [cgroups] Consistently use stringStream throughout parsing code Changes requested by iklam (Reviewer). src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 54: > 52: } else { > 53: char *p = strstr(cgroup_path, _root); > 54: if (p != NULL && p == cgroup_path) { I think this change should be done in a separate bug, because it will cause the `if` block to be executed. Previously the `if` block is never executed (unless `cgroup_path == _root` ??, but then it will just set `_path` to the same string as `_mount_point`) -- so we don't even know if this change of behavior might do something harmful. ------------- PR: https://git.openjdk.java.net/jdk/pull/8969 From sgehwolf at openjdk.java.net Wed Jun 8 08:28:28 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 8 Jun 2022 08:28:28 GMT Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v2] In-Reply-To: References: Message-ID: <0krw577dlrL32YtjeZSAyIncQF6ysf4lFl6q-NhCnP8=.b563344f-66db-4e8a-b725-92aab096e4c5@github.com> On Wed, 8 Jun 2022 07:13:30 GMT, Ioi Lam wrote: >> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'master' into jdk-8287007-string-stream >> - Add cgroups v2 java test >> - use stringStream in cgroups v2 >> - Add gtest for cgroups v2 code path >> >> Also fixes the bug when cgroup path is '/'. >> - 8287007: [cgroups] Consistently use stringStream throughout parsing code >> - 8287007: [cgroups] Consistently use stringStream throughout parsing code > > src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 54: > >> 52: } else { >> 53: char *p = strstr(cgroup_path, _root); >> 54: if (p != NULL && p == cgroup_path) { > > I think this change should be done in a separate bug, because it will cause the `if` block to be executed. Previously the `if` block is never executed (unless `cgroup_path == _root` ??, but then it will just set `_path` to the same string as `_mount_point`) -- so we don't even know if this change of behavior might do something harmful. OK. Then this will remain to be dead code and I'll remove the corresponding test case in the new `gtests` too (as they'd otherwise fail in contrast to the Java code). ------------- PR: https://git.openjdk.java.net/jdk/pull/8969 From ihse at openjdk.java.net Wed Jun 8 10:10:38 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 8 Jun 2022 10:10:38 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v5] In-Reply-To: References: Message-ID: On Thu, 2 Jun 2022 17:00:35 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > 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 40 additional commits since the last revision: > > - Update symbols for JDK 19 b25. > - Merge branch 'master' into JDK-8284858 > - Adjust deprecated options test. > - Merge branch 'master' into JDK-8284858 > - Update deprecated options test. > - Merge branch 'master' into JDK-8284858 > - Respond to review feedback. > - Update symbol information for JDK 19 b24. > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - ... and 30 more: https://git.openjdk.java.net/jdk/compare/6a77da51...e495a579 Build changes look good. Thanks for fixing the bug in `generate-symbol-data.sh`. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8236 From sgehwolf at openjdk.java.net Wed Jun 8 12:09:27 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 8 Jun 2022 12:09:27 GMT Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v3] In-Reply-To: References: Message-ID: > Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated > buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue > of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read. > > While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From > a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be > there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is > meant to only use stringStream throughout the cgroups code. > > Testing: > - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2 > - [x] Added tests, which I've verified also pass before the stringStream change > > Thoughts? Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Remove fix for substring match ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8969/files - new: https://git.openjdk.java.net/jdk/pull/8969/files/8047fe37..84d952b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8969&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8969&range=01-02 Stats: 10 lines in 2 files changed: 0 ins; 7 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8969.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8969/head:pull/8969 PR: https://git.openjdk.java.net/jdk/pull/8969 From sgehwolf at openjdk.java.net Wed Jun 8 12:12:36 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 8 Jun 2022 12:12:36 GMT Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v2] In-Reply-To: <0krw577dlrL32YtjeZSAyIncQF6ysf4lFl6q-NhCnP8=.b563344f-66db-4e8a-b725-92aab096e4c5@github.com> References: <0krw577dlrL32YtjeZSAyIncQF6ysf4lFl6q-NhCnP8=.b563344f-66db-4e8a-b725-92aab096e4c5@github.com> Message-ID: On Wed, 8 Jun 2022 08:25:21 GMT, Severin Gehwolf wrote: >> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 54: >> >>> 52: } else { >>> 53: char *p = strstr(cgroup_path, _root); >>> 54: if (p != NULL && p == cgroup_path) { >> >> I think this change should be done in a separate bug, because it will cause the `if` block to be executed. Previously the `if` block is never executed (unless `cgroup_path == _root` ??, but then it will just set `_path` to the same string as `_mount_point`) -- so we don't even know if this change of behavior might do something harmful. > > OK. Then this will remain to be dead code and I'll remove the corresponding test case in the new `gtests` too (as they'd otherwise fail in contrast to the Java code). Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8969 From coleenp at openjdk.java.net Wed Jun 8 13:31:31 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 8 Jun 2022 13:31:31 GMT Subject: RFR: 8287854: Dangling reference in ClassVerifier::verify_class In-Reply-To: References: Message-ID: <3cFTHdSECHUFWcZrCeEsSxND9RGV2Hf1Ry4c8vCbsBI=.26daeda7-af5f-4786-a648-1db38917a142@github.com> On Tue, 7 Jun 2022 23:52:52 GMT, Harold Seigel wrote: > Please review this small change to fix JDK_8287854. The fix was tested with JCK lang and VM tests, Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows (in progress), and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold I think this table should be created in the ClassVerifier constructor instead. Is there only this one caller of verify_class() ? ClassVerifier split_verifier(jt, klass); // We don't use CHECK here, or on inference_verify below, so that we can log any exception. split_verifier.verify_class(THREAD); ------------- PR: https://git.openjdk.java.net/jdk/pull/9075 From dholmes at openjdk.java.net Wed Jun 8 13:44:18 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 8 Jun 2022 13:44:18 GMT Subject: RFR: 8287854: Dangling reference in ClassVerifier::verify_class In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 23:52:52 GMT, Harold Seigel wrote: > Please review this small change to fix JDK_8287854. The fix was tested with JCK lang and VM tests, Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows (in progress), and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold Needs further work. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9075 From dholmes at openjdk.java.net Wed Jun 8 13:44:19 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 8 Jun 2022 13:44:19 GMT Subject: RFR: 8287854: Dangling reference in ClassVerifier::verify_class In-Reply-To: References: Message-ID: On Wed, 8 Jun 2022 06:08:00 GMT, Ioi Lam wrote: >> The change is functionally correct, but this seems like a textbook case for a RAII helper class. > >> The change is functionally correct, but this seems like a textbook case for a RAII helper class. > > I agree with David that RAII is needed here. There's one exit path that's not covered by the existing patch: > > > void ClassVerifier::verify_class(TRAPS) { > ... > verify_method(methodHandle(THREAD, m), CHECK_VERIFY(this)); > ... > } @iklam Good catch! I withdraw my approval. ------------- PR: https://git.openjdk.java.net/jdk/pull/9075 From rpressler at openjdk.java.net Wed Jun 8 16:30:37 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Wed, 8 Jun 2022 16:30:37 GMT Subject: RFR: 8287901: Loom: Failures with -XX:+VerifyStack [v2] In-Reply-To: References: Message-ID: > Please review the following change. > > Debugging information added to `frame::describe` (used by `JavaThread::print_frame_layout`) was inaccurate, but proved fatal with `VerifyStack`, which uses the same information for verification. > > The location of a caller frame's return address and spilled fp, which are located in the callee, were recorded by the caller frame. In the case of the special frame `Continuation.enterSpecial`, those locations were recorded incorrectly. The fix is to record the information while describing the callee frame, rather than the caller. > > Passes tier1 Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: Fix locations for interpreted frames ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/9066/files - new: https://git.openjdk.java.net/jdk/pull/9066/files/55108d8a..e6f306be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9066&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9066&range=00-01 Stats: 24 lines in 2 files changed: 18 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/9066.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9066/head:pull/9066 PR: https://git.openjdk.java.net/jdk/pull/9066 From pchilanomate at openjdk.java.net Wed Jun 8 16:53:32 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 8 Jun 2022 16:53:32 GMT Subject: RFR: 8287901: Loom: Failures with -XX:+VerifyStack [v2] In-Reply-To: References: Message-ID: On Wed, 8 Jun 2022 16:30:37 GMT, Ron Pressler wrote: >> Please review the following change. >> >> Debugging information added to `frame::describe` (used by `JavaThread::print_frame_layout`) was inaccurate, but proved fatal with `VerifyStack`, which uses the same information for verification. >> >> The location of a caller frame's return address and spilled fp, which are located in the callee, were recorded by the caller frame. In the case of the special frame `Continuation.enterSpecial`, those locations were recorded incorrectly. The fix is to record the information while describing the callee frame, rather than the caller. >> >> Passes tier1 > > Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: > > Fix locations for interpreted frames Looks good to me. ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9066 From sspitsyn at openjdk.java.net Wed Jun 8 17:33:32 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 8 Jun 2022 17:33:32 GMT Subject: RFR: 8231491: JDI tc02x004 failed again due to wrong # of breakpoints In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 17:02:44 GMT, Daniel D. Daugherty wrote: > A trivial fix that deletes an errant `debugee.resume()` call that causes a race > between the debugger and debuggee. I've also corrected incorrect line number > values mentioned in comments. > > This fix has been tested with the updated failing test both with and without the > debug code that makes the failure easy to reproduce. The real test will be seeing > if the failure stops reproducing in my stress testing runs on my M1 MacMini in > my lab. Looks good. Thank you for fixing! Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/9020 From coleenp at openjdk.java.net Wed Jun 8 18:01:32 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 8 Jun 2022 18:01:32 GMT Subject: RFR: 8287901: Loom: Failures with -XX:+VerifyStack [v2] In-Reply-To: References: Message-ID: <-Q5W_KtFmHug0r6r4qLN6oSUmLYrMzCBkysZTdTk9oY=.3e738c92-30ae-4faf-b0ad-130b053a372a@github.com> On Wed, 8 Jun 2022 16:30:37 GMT, Ron Pressler wrote: >> Please review the following change. >> >> Debugging information added to `frame::describe` (used by `JavaThread::print_frame_layout`) was inaccurate, but proved fatal with `VerifyStack`, which uses the same information for verification. >> >> The location of a caller frame's return address and spilled fp, which are located in the callee, were recorded by the caller frame. In the case of the special frame `Continuation.enterSpecial`, those locations were recorded incorrectly. The fix is to record the information while describing the callee frame, rather than the caller. >> >> Passes tier1 > > Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: > > Fix locations for interpreted frames I have one question about the test. test/jdk/jdk/internal/vm/Continuation/Basic.java line 50: > 48: * > 49: * @run testng/othervm --enable-preview -XX:+VerifyStack -Xint Basic > 50: * @run testng/othervm --enable-preview -XX:+VerifyStack -Xcomp -XX:TieredStopAtLevel=3 -XX:CompileOnly=jdk/internal/vm/Continuation,Basic Basic Why 3? Isn't C1 only equivalent to -XX:TieredStopAtLevel=1 ? ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9066 From rpressler at openjdk.java.net Wed Jun 8 18:30:34 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Wed, 8 Jun 2022 18:30:34 GMT Subject: RFR: 8287901: Loom: Failures with -XX:+VerifyStack [v2] In-Reply-To: <-Q5W_KtFmHug0r6r4qLN6oSUmLYrMzCBkysZTdTk9oY=.3e738c92-30ae-4faf-b0ad-130b053a372a@github.com> References: <-Q5W_KtFmHug0r6r4qLN6oSUmLYrMzCBkysZTdTk9oY=.3e738c92-30ae-4faf-b0ad-130b053a372a@github.com> Message-ID: On Wed, 8 Jun 2022 17:58:00 GMT, Coleen Phillimore wrote: >> Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix locations for interpreted frames > > test/jdk/jdk/internal/vm/Continuation/Basic.java line 50: > >> 48: * >> 49: * @run testng/othervm --enable-preview -XX:+VerifyStack -Xint Basic >> 50: * @run testng/othervm --enable-preview -XX:+VerifyStack -Xcomp -XX:TieredStopAtLevel=3 -XX:CompileOnly=jdk/internal/vm/Continuation,Basic Basic > > Why 3? Isn't C1 only equivalent to -XX:TieredStopAtLevel=1 ? It's C1 with profiling. Shouldn't matter here. ------------- PR: https://git.openjdk.java.net/jdk/pull/9066 From hseigel at openjdk.java.net Wed Jun 8 18:58:39 2022 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 8 Jun 2022 18:58:39 GMT Subject: RFR: 8287854: Dangling reference in ClassVerifier::verify_class [v2] In-Reply-To: References: Message-ID: <2K6I4Gsk0IJ9yNFzBx6Mtqq06eTCLaducyOFwTabAJA=.f9390995-fd7f-4284-a122-53a18f8bf4ad@github.com> > Please review this small change to fix JDK_8287854. The fix was tested with JCK lang and VM tests, Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows (in progress), and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: embed method_signatures_table inside ClassVerifier ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/9075/files - new: https://git.openjdk.java.net/jdk/pull/9075/files/4f147448..fe09cfe6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9075&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9075&range=00-01 Stats: 17 lines in 2 files changed: 0 ins; 12 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/9075.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9075/head:pull/9075 PR: https://git.openjdk.java.net/jdk/pull/9075 From hseigel at openjdk.java.net Wed Jun 8 18:58:40 2022 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 8 Jun 2022 18:58:40 GMT Subject: RFR: 8287854: Dangling reference in ClassVerifier::verify_class In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 23:52:52 GMT, Harold Seigel wrote: > Please review this small change to fix JDK_8287854. The fix was tested with JCK lang and VM tests, Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows (in progress), and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold Please review this new fix that uses Coleen's suggestion to embed the method_signatures_table in the ClassVerifier class. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/9075 From coleenp at openjdk.java.net Wed Jun 8 19:32:22 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 8 Jun 2022 19:32:22 GMT Subject: RFR: 8287854: Dangling reference in ClassVerifier::verify_class [v2] In-Reply-To: <2K6I4Gsk0IJ9yNFzBx6Mtqq06eTCLaducyOFwTabAJA=.f9390995-fd7f-4284-a122-53a18f8bf4ad@github.com> References: <2K6I4Gsk0IJ9yNFzBx6Mtqq06eTCLaducyOFwTabAJA=.f9390995-fd7f-4284-a122-53a18f8bf4ad@github.com> Message-ID: On Wed, 8 Jun 2022 18:58:39 GMT, Harold Seigel wrote: >> Please review this small change to fix JDK_8287854. The fix was tested with JCK lang and VM tests, Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows (in progress), and Mach5 tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > embed method_signatures_table inside ClassVerifier This looks really good. The lifetime of ClassVerifier and this method signature table match. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9075 From rpressler at openjdk.java.net Wed Jun 8 19:53:33 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Wed, 8 Jun 2022 19:53:33 GMT Subject: Integrated: 8287901: Loom: Failures with -XX:+VerifyStack In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 15:56:47 GMT, Ron Pressler wrote: > Please review the following change. > > Debugging information added to `frame::describe` (used by `JavaThread::print_frame_layout`) was inaccurate, but proved fatal with `VerifyStack`, which uses the same information for verification. > > The location of a caller frame's return address and spilled fp, which are located in the callee, were recorded by the caller frame. In the case of the special frame `Continuation.enterSpecial`, those locations were recorded incorrectly. The fix is to record the information while describing the callee frame, rather than the caller. > > Passes tier1 This pull request has now been integrated. Changeset: b6233985 Author: Ron Pressler Committer: Patricio Chilano Mateo URL: https://git.openjdk.java.net/jdk/commit/b62339855571b234979e2cf250c9251d1d063a06 Stats: 41 lines in 3 files changed: 27 ins; 0 del; 14 mod 8287901: Loom: Failures with -XX:+VerifyStack Reviewed-by: pchilanomate, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/9066 From darcy at openjdk.java.net Thu Jun 9 01:03:47 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 9 Jun 2022 01:03:47 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v6] In-Reply-To: References: Message-ID: > Time to start getting ready for JDK 20... 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 44 additional commits since the last revision: - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Update symbols for JDK 19 b25. - Merge branch 'master' into JDK-8284858 - Adjust deprecated options test. - Merge branch 'master' into JDK-8284858 - Update deprecated options test. - Merge branch 'master' into JDK-8284858 - ... and 34 more: https://git.openjdk.java.net/jdk/compare/530d16c1...1b29a17c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8236/files - new: https://git.openjdk.java.net/jdk/pull/8236/files/e495a579..1b29a17c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=04-05 Stats: 16423 lines in 539 files changed: 12382 ins; 2143 del; 1898 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236 From iris at openjdk.java.net Thu Jun 9 04:23:40 2022 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 9 Jun 2022 04:23:40 GMT Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v6] In-Reply-To: References: Message-ID: On Thu, 9 Jun 2022 01:03:47 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > 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 44 additional commits since the last revision: > > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Merge branch 'master' into JDK-8284858 > - Update symbols for JDK 19 b25. > - Merge branch 'master' into JDK-8284858 > - Adjust deprecated options test. > - Merge branch 'master' into JDK-8284858 > - Update deprecated options test. > - Merge branch 'master' into JDK-8284858 > - ... and 34 more: https://git.openjdk.java.net/jdk/compare/705cfa36...1b29a17c Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8236 From dholmes at openjdk.java.net Thu Jun 9 05:58:31 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 9 Jun 2022 05:58:31 GMT Subject: RFR: 8287854: Dangling reference in ClassVerifier::verify_class [v2] In-Reply-To: <2K6I4Gsk0IJ9yNFzBx6Mtqq06eTCLaducyOFwTabAJA=.f9390995-fd7f-4284-a122-53a18f8bf4ad@github.com> References: <2K6I4Gsk0IJ9yNFzBx6Mtqq06eTCLaducyOFwTabAJA=.f9390995-fd7f-4284-a122-53a18f8bf4ad@github.com> Message-ID: On Wed, 8 Jun 2022 18:58:39 GMT, Harold Seigel wrote: >> Please review this small change to fix JDK_8287854. The fix was tested with JCK lang and VM tests, Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows (in progress), and Mach5 tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > embed method_signatures_table inside ClassVerifier Much cleaner solution - thanks Harold and Coleen. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9075 From mbaesken at openjdk.java.net Thu Jun 9 07:58:58 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 9 Jun 2022 07:58:58 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload Message-ID: Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. ------------- Commit messages: - JDK-8288003 Changes: https://git.openjdk.java.net/jdk/pull/9101/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9101&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288003 Stats: 35 lines in 2 files changed: 33 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/9101.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9101/head:pull/9101 PR: https://git.openjdk.java.net/jdk/pull/9101 From hseigel at openjdk.java.net Thu Jun 9 12:06:36 2022 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 9 Jun 2022 12:06:36 GMT Subject: Integrated: 8287854: Dangling reference in ClassVerifier::verify_class In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 23:52:52 GMT, Harold Seigel wrote: > Please review this small change to fix JDK_8287854. The fix was tested with JCK lang and VM tests, Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows (in progress), and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: 3fa99844 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/3fa99844a69401f84677e7d512ffd937f7f16898 Stats: 13 lines in 2 files changed: 0 ins; 8 del; 5 mod 8287854: Dangling reference in ClassVerifier::verify_class Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/9075 From hseigel at openjdk.java.net Thu Jun 9 12:06:33 2022 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 9 Jun 2022 12:06:33 GMT Subject: RFR: 8287854: Dangling reference in ClassVerifier::verify_class [v2] In-Reply-To: <2K6I4Gsk0IJ9yNFzBx6Mtqq06eTCLaducyOFwTabAJA=.f9390995-fd7f-4284-a122-53a18f8bf4ad@github.com> References: <2K6I4Gsk0IJ9yNFzBx6Mtqq06eTCLaducyOFwTabAJA=.f9390995-fd7f-4284-a122-53a18f8bf4ad@github.com> Message-ID: On Wed, 8 Jun 2022 18:58:39 GMT, Harold Seigel wrote: >> Please review this small change to fix JDK_8287854. The fix was tested with JCK lang and VM tests, Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows (in progress), and Mach5 tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > embed method_signatures_table inside ClassVerifier Thanks Coleen, David, and Ioi for reviewing this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/9075 From dholmes at openjdk.java.net Thu Jun 9 13:43:17 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 9 Jun 2022 13:43:17 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload In-Reply-To: References: Message-ID: <_OV07DCq1GlAQYPJq8jCTkfSP52JvHC9HF9pn_kSdqE=.bc981661-a2d4-4171-bd89-230b1206ae85@github.com> On Thu, 9 Jun 2022 07:50:14 GMT, Matthias Baesken wrote: > Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. Generally okay but I'd like to minimise the conditional code. Thanks. src/hotspot/os/posix/os_posix.cpp line 718: > 716: if (res_dli == 0) { > 717: l_path = lmap->l_name; > 718: } Can we hide this in `os::Linux::dll_path` so that the code here would simply be: const char* l_path = LINUX_ONLY(os::Linux::dll_path(lib)) NOT_LINUX(""); src/hotspot/os/posix/os_posix.cpp line 726: > 724: > 725: if (res == 0) { > 726: Events::log_dll_message(NULL, "Unloaded shared library %s [" INTPTR_FORMAT "]", l_path, p2i(lib)); Shouldn't the %s be quoted here too? The output will look a bit odd: Unloaded shared library [0xbaadcafebaadcafe] vs. Unloaded shared library "" [0xbaadcafebaadcafe] ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9101 From tschatzl at openjdk.java.net Thu Jun 9 14:37:44 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 9 Jun 2022 14:37:44 GMT Subject: RFR: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark [v5] In-Reply-To: References: Message-ID: <3fRGN_Af-XQRo-gnWCmgKsua7k4FYyPK0xrXuzvvsjc=.bb9c053f-0026-4357-801e-f0f3251db481@github.com> > Hi all, > > can I have reviews for this change that makes a few CLDG iterations no-keepalive during GC pauses? > > This fixes a bug where the `VerifyDuringGC` verification otherwise kept alive all classes, effectively disabling class unloading during (g1) concurrent mark. > > Afaict this verification code is only every called during GC pauses, so the change should be fine. > > As for the change itself, I tried to avoid cluttering the code with `ClassLoaderDataGraphIterator<>` by using typedefs - unfortunately only C++ 17 allows omitting the `<>` if all template parameters are defaulted. > > There is also a new test case for just this. > > Testing: tier1-5 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Change Dictionary verification to use keep_alive peeking of the _class_loader ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8949/files - new: https://git.openjdk.org/jdk/pull/8949/files/59911eac..c67021eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8949&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8949&range=03-04 Stats: 8 lines in 3 files changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/8949.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8949/head:pull/8949 PR: https://git.openjdk.org/jdk/pull/8949 From mbaesken at openjdk.java.net Thu Jun 9 15:00:35 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 9 Jun 2022 15:00:35 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v2] In-Reply-To: References: Message-ID: > Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: introduce os::Linux::dll_path, add dlerror output, add some quoting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9101/files - new: https://git.openjdk.org/jdk/pull/9101/files/d48eaeac..1a0a7d6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9101&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9101&range=00-01 Stats: 38 lines in 4 files changed: 19 ins; 12 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9101.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9101/head:pull/9101 PR: https://git.openjdk.org/jdk/pull/9101 From mbaesken at openjdk.java.net Thu Jun 9 15:35:27 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 9 Jun 2022 15:35:27 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v3] In-Reply-To: References: Message-ID: <_DvR2-kvCv_WWBp7fVVadk5_nWI2mZ4pbdstFhhTr-g=.f1fd56c3-6726-4048-8cb0-fc4aac31f1cf@github.com> > Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: remove whitespace in os_linux.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9101/files - new: https://git.openjdk.org/jdk/pull/9101/files/1a0a7d6d..dbdca1ee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9101&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9101&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9101.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9101/head:pull/9101 PR: https://git.openjdk.org/jdk/pull/9101 From mbaesken at openjdk.java.net Thu Jun 9 15:35:29 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 9 Jun 2022 15:35:29 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v3] In-Reply-To: <_OV07DCq1GlAQYPJq8jCTkfSP52JvHC9HF9pn_kSdqE=.bc981661-a2d4-4171-bd89-230b1206ae85@github.com> References: <_OV07DCq1GlAQYPJq8jCTkfSP52JvHC9HF9pn_kSdqE=.bc981661-a2d4-4171-bd89-230b1206ae85@github.com> Message-ID: On Thu, 9 Jun 2022 13:34:52 GMT, David Holmes wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> remove whitespace in os_linux.hpp > > src/hotspot/os/posix/os_posix.cpp line 718: > >> 716: if (res_dli == 0) { >> 717: l_path = lmap->l_name; >> 718: } > > Can we hide this in `os::Linux::dll_path` so that the code here would simply be: > > > const char* l_path = LINUX_ONLY(os::Linux::dll_path(lib)) > NOT_LINUX(""); Hi David, thanks for the advice, done. I also added some more quoting and added the dlerror information to the error report (see os_posix.cpp). ------------- PR: https://git.openjdk.org/jdk/pull/9101 From darcy at openjdk.java.net Thu Jun 9 16:21:25 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 9 Jun 2022 16:21:25 GMT Subject: Integrated: JDK-8284858: Start of release updates for JDK 20 In-Reply-To: References: Message-ID: On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote: > Time to start getting ready for JDK 20... This pull request has now been integrated. Changeset: edff51e5 Author: Joe Darcy Committer: Erik Joelsson URL: https://git.openjdk.org/jdk/commit/edff51e5fdb5282830ecfb3792a88c7b28ca6557 Stats: 6453 lines in 69 files changed: 6403 ins; 5 del; 45 mod 8284858: Start of release updates for JDK 20 8286035: Add source 20 and target 20 to javac 8286034: Add SourceVersion.RELEASE_20 Reviewed-by: dholmes, kcr, iris, erikj, jjg, ihse ------------- PR: https://git.openjdk.org/jdk/pull/8236 From coleenp at openjdk.java.net Thu Jun 9 19:30:06 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 9 Jun 2022 19:30:06 GMT Subject: RFR: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark [v5] In-Reply-To: <3fRGN_Af-XQRo-gnWCmgKsua7k4FYyPK0xrXuzvvsjc=.bb9c053f-0026-4357-801e-f0f3251db481@github.com> References: <3fRGN_Af-XQRo-gnWCmgKsua7k4FYyPK0xrXuzvvsjc=.bb9c053f-0026-4357-801e-f0f3251db481@github.com> Message-ID: On Thu, 9 Jun 2022 14:37:44 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that makes a few CLDG iterations no-keepalive during GC pauses? >> >> This fixes a bug where the `VerifyDuringGC` verification otherwise kept alive all classes, effectively disabling class unloading during (g1) concurrent mark. >> >> Afaict this verification code is only every called during GC pauses, so the change should be fine. >> >> As for the change itself, I tried to avoid cluttering the code with `ClassLoaderDataGraphIterator<>` by using typedefs - unfortunately only C++ 17 allows omitting the `<>` if all template parameters are defaulted. >> >> There is also a new test case for just this. >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Change Dictionary verification to use keep_alive peeking of the _class_loader Looks good. Thank you for fixing this. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/8949 From dholmes at openjdk.java.net Fri Jun 10 00:00:07 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 10 Jun 2022 00:00:07 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v3] In-Reply-To: <_DvR2-kvCv_WWBp7fVVadk5_nWI2mZ4pbdstFhhTr-g=.f1fd56c3-6726-4048-8cb0-fc4aac31f1cf@github.com> References: <_DvR2-kvCv_WWBp7fVVadk5_nWI2mZ4pbdstFhhTr-g=.f1fd56c3-6726-4048-8cb0-fc4aac31f1cf@github.com> Message-ID: On Thu, 9 Jun 2022 15:35:27 GMT, Matthias Baesken wrote: >> Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove whitespace in os_linux.hpp Looks good - thanks for incorporating my requests. One minor item below. Thanks src/hotspot/os/linux/os_linux.cpp line 1792: > 1790: struct link_map *lmap; > 1791: int res_dli = ::dlinfo(lib, RTLD_DI_LINKMAP, &lmap); > 1792: const char* l_path = ""; Should this be "not available" to match the non-Linux case? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9101 From ysuenaga at openjdk.java.net Fri Jun 10 01:32:50 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 10 Jun 2022 01:32:50 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v3] In-Reply-To: <_DvR2-kvCv_WWBp7fVVadk5_nWI2mZ4pbdstFhhTr-g=.f1fd56c3-6726-4048-8cb0-fc4aac31f1cf@github.com> References: <_DvR2-kvCv_WWBp7fVVadk5_nWI2mZ4pbdstFhhTr-g=.f1fd56c3-6726-4048-8cb0-fc4aac31f1cf@github.com> Message-ID: On Thu, 9 Jun 2022 15:35:27 GMT, Matthias Baesken wrote: >> Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove whitespace in os_linux.hpp I think it is better to add null check to dll_unload() because it might be different behavior between Linux and Windows. GetModuleFileName() on Windows will return the path of executable if NULL is passed to hModule. https://docs.microsoft.com/ja-JP/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamea On the other hand, dlinfo() does not mention if NULL is passed in library handle. https://man7.org/linux/man-pages/man3/dlinfo.3.html I think dll_unload() is not expexted to unload executable... ------------- PR: https://git.openjdk.org/jdk/pull/9101 From stefank at openjdk.java.net Fri Jun 10 06:34:02 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 10 Jun 2022 06:34:02 GMT Subject: RFR: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark [v5] In-Reply-To: <3fRGN_Af-XQRo-gnWCmgKsua7k4FYyPK0xrXuzvvsjc=.bb9c053f-0026-4357-801e-f0f3251db481@github.com> References: <3fRGN_Af-XQRo-gnWCmgKsua7k4FYyPK0xrXuzvvsjc=.bb9c053f-0026-4357-801e-f0f3251db481@github.com> Message-ID: On Thu, 9 Jun 2022 14:37:44 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that makes a few CLDG iterations no-keepalive during GC pauses? >> >> This fixes a bug where the `VerifyDuringGC` verification otherwise kept alive all classes, effectively disabling class unloading during (g1) concurrent mark. >> >> Afaict this verification code is only every called during GC pauses, so the change should be fine. >> >> As for the change itself, I tried to avoid cluttering the code with `ClassLoaderDataGraphIterator<>` by using typedefs - unfortunately only C++ 17 allows omitting the `<>` if all template parameters are defaulted. >> >> There is also a new test case for just this. >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Change Dictionary verification to use keep_alive peeking of the _class_loader Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/8949 From mbaesken at openjdk.java.net Fri Jun 10 07:38:03 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 10 Jun 2022 07:38:03 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v4] In-Reply-To: References: Message-ID: > Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: dll_path on Linux - add NULL check, change special output to not available ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9101/files - new: https://git.openjdk.org/jdk/pull/9101/files/dbdca1ee..fa7b3b7b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9101&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9101&range=02-03 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9101.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9101/head:pull/9101 PR: https://git.openjdk.org/jdk/pull/9101 From mbaesken at openjdk.java.net Fri Jun 10 07:38:05 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 10 Jun 2022 07:38:05 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v3] In-Reply-To: <_DvR2-kvCv_WWBp7fVVadk5_nWI2mZ4pbdstFhhTr-g=.f1fd56c3-6726-4048-8cb0-fc4aac31f1cf@github.com> References: <_DvR2-kvCv_WWBp7fVVadk5_nWI2mZ4pbdstFhhTr-g=.f1fd56c3-6726-4048-8cb0-fc4aac31f1cf@github.com> Message-ID: <6fxZh5zesq1T4ghs3SIt5dhoDL5GvdCBa8xOtYNrUo8=.7edfc4e8-115d-4aec-b394-e033bc25802c@github.com> On Thu, 9 Jun 2022 15:35:27 GMT, Matthias Baesken wrote: >> Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > remove whitespace in os_linux.hpp Hello, I added a NULL check to os::Linux::dll_path. Additionally I adjusted l_path to "not available" to match the non-Linux case. ------------- PR: https://git.openjdk.org/jdk/pull/9101 From tschatzl at openjdk.java.net Fri Jun 10 08:00:27 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 10 Jun 2022 08:00:27 GMT Subject: Integrated: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark In-Reply-To: References: Message-ID: <5wNzFeCXPHTvJVwI8betnFvYKK4x4ph-cUngSZaKmvg=.6ded9d33-8dc3-412f-836b-72cef3886f2b@github.com> On Mon, 30 May 2022 17:09:35 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that makes a few CLDG iterations no-keepalive during GC pauses? > > This fixes a bug where the `VerifyDuringGC` verification otherwise kept alive all classes, effectively disabling class unloading during (g1) concurrent mark. > > Afaict this verification code is only every called during GC pauses, so the change should be fine. > > As for the change itself, I tried to avoid cluttering the code with `ClassLoaderDataGraphIterator<>` by using typedefs - unfortunately only C++ 17 allows omitting the `<>` if all template parameters are defaulted. > > There is also a new test case for just this. > > Testing: tier1-5 > > Thanks, > Thomas This pull request has now been integrated. Changeset: 94b473e4 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/94b473e4642a5a4626faeb73341b4aea128ccb31 Stats: 140 lines in 6 files changed: 123 ins; 5 del; 12 mod 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark Reviewed-by: stefank, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/8949 From tschatzl at openjdk.java.net Fri Jun 10 08:00:25 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 10 Jun 2022 08:00:25 GMT Subject: RFR: 8280454: G1: ClassLoaderData verification keeps CLDs live that causes problems with VerifyDuringGC during Remark [v5] In-Reply-To: References: <3fRGN_Af-XQRo-gnWCmgKsua7k4FYyPK0xrXuzvvsjc=.bb9c053f-0026-4357-801e-f0f3251db481@github.com> Message-ID: On Fri, 10 Jun 2022 06:30:35 GMT, Stefan Karlsson wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> Change Dictionary verification to use keep_alive peeking of the _class_loader > > Marked as reviewed by stefank (Reviewer). Thanks @stefank @coleenp for your reviews ------------- PR: https://git.openjdk.org/jdk/pull/8949 From duke at openjdk.java.net Fri Jun 10 10:30:24 2022 From: duke at openjdk.java.net (KIRIYAMA Takuya) Date: Fri, 10 Jun 2022 10:30:24 GMT Subject: RFR: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test Message-ID: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> I would like to fix 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test. FlightRecorder option has not been tested since JDK13. I think we should test it, because FlightRecorder option has not been obsolete in the latest JDK. Users would be in trouble if the option suddenly disappears without notice, so it's important to confirm the deprication message. Also we should add a test of ExtendedDTraceProbes option. The test was disabled in 8281675, because some jdk can't specify it. I modified the test to be able to verify ExtendedDTraceProbes in either case that DTRACE_ENABLED is enabled or not. ------------- Commit messages: - 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test Changes: https://git.openjdk.org/jdk/pull/9123/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9123&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8280235 Stats: 21 lines in 1 file changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9123.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9123/head:pull/9123 PR: https://git.openjdk.org/jdk/pull/9123 From jiefu at openjdk.java.net Fri Jun 10 11:24:50 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 10 Jun 2022 11:24:50 GMT Subject: RFR: 8288203: runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs Message-ID: Hi all, Please review this trivial patch. runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs due to 'VerifyDuringGC' is diagnostic. So let's move `-XX:+UnlockDiagnosticVMOptions` before 'VerifyDuringGC' to fix it. Thanks. Best regards, Jie ------------- Commit messages: - 8288203: runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs Changes: https://git.openjdk.org/jdk/pull/9125/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9125&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288203 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9125.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9125/head:pull/9125 PR: https://git.openjdk.org/jdk/pull/9125 From shade at openjdk.java.net Fri Jun 10 11:32:04 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 10 Jun 2022 11:32:04 GMT Subject: RFR: 8288203: runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs In-Reply-To: References: Message-ID: On Fri, 10 Jun 2022 11:14:22 GMT, Jie Fu wrote: > Hi all, > > Please review this trivial patch. > runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs due to 'VerifyDuringGC' is diagnostic. > So let's move `-XX:+UnlockDiagnosticVMOptions` before 'VerifyDuringGC' to fix it. > > Thanks. > Best regards, > Jie Looks fine and trivial. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9125 From jiefu at openjdk.java.net Fri Jun 10 11:43:09 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 10 Jun 2022 11:43:09 GMT Subject: RFR: 8288203: runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs In-Reply-To: References: Message-ID: <7Kypg7ucLM388RWW9YTcsUXMWYRbT4Ab0garYjdmJcE=.b772fb7d-0294-4d8c-bd40-03d04a4c4b07@github.com> On Fri, 10 Jun 2022 11:29:00 GMT, Aleksey Shipilev wrote: > Looks fine and trivial. Thanks @shipilev for your review. ------------- PR: https://git.openjdk.org/jdk/pull/9125 From jiefu at openjdk.java.net Fri Jun 10 11:43:10 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 10 Jun 2022 11:43:10 GMT Subject: Integrated: 8288203: runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs In-Reply-To: References: Message-ID: On Fri, 10 Jun 2022 11:14:22 GMT, Jie Fu wrote: > Hi all, > > Please review this trivial patch. > runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs due to 'VerifyDuringGC' is diagnostic. > So let's move `-XX:+UnlockDiagnosticVMOptions` before 'VerifyDuringGC' to fix it. > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: 5d0e8b69 Author: Jie Fu URL: https://git.openjdk.org/jdk/commit/5d0e8b698144a83025c6912520097f24128858f7 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8288203: runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs Reviewed-by: shade ------------- PR: https://git.openjdk.org/jdk/pull/9125 From dholmes at openjdk.java.net Fri Jun 10 13:31:37 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 10 Jun 2022 13:31:37 GMT Subject: RFR: 8279047: Remove expired flags in JDK 20 Message-ID: Expired Flags in 20: - FilterSpuriousWakeups - MinInliningThreshold - PrefetchFieldsAhead No remaining usages in code or tests. - UseHeavyMonitors (expired in PRODUCT ONLY) As this flag now only exists for debug builds it has to be a "develop" flag rather than product. There are then changes to two tests that use this flag, so that they only run on a debug VM. - test/jdk/java/lang/Thread/virtual/HoldsLock.java The second @run that uses UseHeavyMonitors is moved to a second test segment that only applies to the debug VM. - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java Change the test section that uses UseHeavyMonitors to only run on a debug VM and remove the IgnoreUnrecognizedOptions flag. Note that the existing test logic would run the same test twice on product builds. No documentation in the manpage exists for any of the newly expired flags. Obsoleted flags in 20: - ExtendedDTraceProbes Documented in manpage so moved from Deprecated section to Obsolete section. There is special handling for messages about use of this flag so that won't be updated until the flag is actually obsoleted (JDK-8279913). - UseContainerCpuShares - PreferContainerQuotaForCPUCount - AliasLevel Undocumented. Java manpage updates: - Updates Java version to 20 - Moved ExtendedDTraceProbe info as previously mentioned - Applied changes from the .1 file that had not been applied to the markdown source so that they were not lost (and note the .1 file was also missing changes from the markdown file that had not been propagated). - Removed an unrepresentable character (the section symbol) that was not being generated into either the html or nroff file correctly ------------- Commit messages: - Fix typo - 8279047: Remove expired flags in JDK 20 Changes: https://git.openjdk.org/jdk/pull/9127/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9127&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8279047 Stats: 69 lines in 5 files changed: 23 ins; 26 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/9127.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9127/head:pull/9127 PR: https://git.openjdk.org/jdk/pull/9127 From ysuenaga at openjdk.java.net Fri Jun 10 14:18:09 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 10 Jun 2022 14:18:09 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v4] In-Reply-To: References: Message-ID: On Fri, 10 Jun 2022 07:38:03 GMT, Matthias Baesken wrote: >> Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > dll_path on Linux - add NULL check, change special output to not available Why didn't you add NULL check to `os::dll_unload()` both os_windows and os_posix? If NULL is passed to `os::dll_unload()` at os_windows.cpp, it would be passed to `GetModuleFileName()`, then we would get executable path. I think we can add `assert` to the start of both `dll_load()` because NULL shouldn't be passed to them. ------------- PR: https://git.openjdk.org/jdk/pull/9101 From ysuenaga at openjdk.java.net Fri Jun 10 14:25:11 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 10 Jun 2022 14:25:11 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v4] In-Reply-To: References: Message-ID: <1O6oxOTv6AogyTockN_HBRTi5hTduAOb2c_aOEPMo28=.660d11bf-afb8-4adc-856d-8a8c5fbda3df@github.com> On Fri, 10 Jun 2022 07:38:03 GMT, Matthias Baesken wrote: >> Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > dll_path on Linux - add NULL check, change special output to not available src/hotspot/os/linux/os_linux.cpp line 1791: > 1789: const char* os::Linux::dll_path(void* lib) { > 1790: struct link_map *lmap; > 1791: const char* l_path = ""; To be honest, I prefer to return NULL if `dlinfo` is failed. IIUC the caller expects return dll path of `lib` - `` is not the path. I think it is better that alternative string would be set by the caller (`os::dll_unload()`) like a change of os_windows. But I do not stick my opinion. I'm ok if other reviewer approve your change. src/hotspot/os/windows/os_windows.cpp line 1241: > 1239: char name[MAX_PATH]; > 1240: if (::GetModuleFileName((HMODULE)lib, name, sizeof(name)) == 0) { > 1241: name[0] = '\0'; Should we set `` to `name` like a change for linux code? ------------- PR: https://git.openjdk.org/jdk/pull/9101 From stefan.reich.maker.of.eye at googlemail.com Fri Jun 10 14:25:42 2022 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Fri, 10 Jun 2022 16:25:42 +0200 Subject: The SUNWprivate_1.1 mystery Message-ID: Dear JDK devs, I hope this is the right list. The issue is this: Libraries such as jogamp.org's OpenGL Java binding have stopped working on Linux since JDK 18. To run an example, you can get https://botcompany.de:9898/x30.jar and run it with the parameter 1035520 (-jar x30.jar 1035520). It will download and run this program . This runs fine on JDK 17 on all platforms as well as on Windows on JDK 18. However, on JDK 18 on Linux Mint 19 it shows this error: java.lang.UnsatisfiedLinkError: /tmp/jogamp_0000/file_cache/jln13303489101580857037/jln7948171270029506087/natives/linux-amd64/libnativewindow_awt.so: /home/stefan/dev/jdk-18/lib/libjawt.so: version `SUNWprivate_1.1' not found (required by /tmp/jogamp_0000/file_cache/jln13303489101580857037/jln7948171270029506087/natives/linux-amd64/libnativewindow_awt.so) at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:395) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:234) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:176) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2394) at java.base/java.lang.Runtime.load0(Runtime.java:785) at java.base/java.lang.System.load(System.java:1979) at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:603) at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:63) at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:106) at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:487) at jogamp.nativewindow.NWJNILibLoader.access$000(NWJNILibLoader.java:39) at jogamp.nativewindow.NWJNILibLoader$1.run(NWJNILibLoader.java:49) at jogamp.nativewindow.NWJNILibLoader$1.run(NWJNILibLoader.java:41) at java.base/java.security.AccessController.doPrivileged(AccessController.java:318) at jogamp.nativewindow.NWJNILibLoader.loadNativeWindow(NWJNILibLoader.java:41) at jogamp.nativewindow.jawt.JAWTUtil.(JAWTUtil.java:336) What has changed in JDK 18? Many greetings and thanks in advance, Stefan -- == Gaz.AI == From dcubed at openjdk.java.net Fri Jun 10 15:29:36 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 10 Jun 2022 15:29:36 GMT Subject: RFR: 8288222: ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java Message-ID: A trivial fix to ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java. ------------- Commit messages: - 8288222: ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java Changes: https://git.openjdk.org/jdk19/pull/4/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk19&pr=4&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288222 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/4.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/4/head:pull/4 PR: https://git.openjdk.org/jdk19/pull/4 From alanb at openjdk.java.net Fri Jun 10 15:29:36 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 10 Jun 2022 15:29:36 GMT Subject: RFR: 8288222: ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java In-Reply-To: References: Message-ID: On Fri, 10 Jun 2022 15:21:34 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/4 From iklam at openjdk.java.net Fri Jun 10 15:34:25 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 10 Jun 2022 15:34:25 GMT Subject: RFR: 8288222: ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java In-Reply-To: References: Message-ID: On Fri, 10 Jun 2022 15:21:34 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/4 From dcubed at openjdk.java.net Fri Jun 10 15:34:27 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 10 Jun 2022 15:34:27 GMT Subject: RFR: 8288222: ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java In-Reply-To: References: Message-ID: On Fri, 10 Jun 2022 15:27:09 GMT, Alan Bateman wrote: >> A trivial fix to ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java. > > Marked as reviewed by alanb (Reviewer). @AlanBateman - Thanks for the fast review! ------------- PR: https://git.openjdk.org/jdk19/pull/4 From dcubed at openjdk.java.net Fri Jun 10 15:40:11 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 10 Jun 2022 15:40:11 GMT Subject: RFR: 8288222: ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java In-Reply-To: References: Message-ID: On Fri, 10 Jun 2022 15:30:41 GMT, Ioi Lam wrote: >> A trivial fix to ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java. > > Marked as reviewed by iklam (Reviewer). @iklam - Thanks for the fast review. I have got to learn to type! ------------- PR: https://git.openjdk.org/jdk19/pull/4 From dcubed at openjdk.java.net Fri Jun 10 15:40:12 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 10 Jun 2022 15:40:12 GMT Subject: Integrated: 8288222: ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java In-Reply-To: References: Message-ID: On Fri, 10 Jun 2022 15:21:34 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java. This pull request has now been integrated. Changeset: 0164145a Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk19/commit/0164145afc178b550313b80f5b5252b3bbff17a2 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8288222: ProblemList serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java Reviewed-by: alanb, iklam ------------- PR: https://git.openjdk.org/jdk19/pull/4 From kvn at openjdk.java.net Fri Jun 10 16:01:02 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 10 Jun 2022 16:01:02 GMT Subject: RFR: 8279047: Remove expired flags in JDK 20 In-Reply-To: References: Message-ID: <08vbjWK5DR3Ka73-cLos7Oxvsrte5Xdj_kn5E96LCc8=.7c9af12a-e737-47b6-98ab-e02229456ff2@github.com> On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes wrote: > Expired Flags in 20: > > - FilterSpuriousWakeups > - MinInliningThreshold > - PrefetchFieldsAhead > > No remaining usages in code or tests. > > - UseHeavyMonitors (expired in PRODUCT ONLY) > > As this flag now only exists for debug builds it has to be a "develop" flag rather than product. There are then changes to two tests that use this flag, so that they only run on a debug VM. > > - test/jdk/java/lang/Thread/virtual/HoldsLock.java > > The second @run that uses UseHeavyMonitors is moved to a second test segment that only applies to the debug VM. > > - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java > > Change the test section that uses UseHeavyMonitors to only run on a debug VM and remove the IgnoreUnrecognizedOptions flag. Note that the existing test logic would run the same test twice on product builds. > > No documentation in the manpage exists for any of the newly expired flags. > > Obsoleted flags in 20: > > - ExtendedDTraceProbes > > Documented in manpage so moved from Deprecated section to Obsolete section. There is special handling for messages about use of this flag so that won't be updated until the flag is actually obsoleted (JDK-8279913). > > - UseContainerCpuShares > - PreferContainerQuotaForCPUCount > - AliasLevel > > Undocumented. > > Java manpage updates: > - Updates Java version to 20 > - Moved ExtendedDTraceProbe info as previously mentioned > - Applied changes from the .1 file that had not been applied to the markdown source so that they were not lost (and note the .1 file was also missing changes from the markdown file that had not been propagated). > - Removed an unrepresentable character (the section symbol) that was not being generated into either the html or nroff file correctly Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9127 From kbarrett at openjdk.java.net Fri Jun 10 20:18:01 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 10 Jun 2022 20:18:01 GMT Subject: RFR: 8279047: Remove expired flags in JDK 20 In-Reply-To: References: Message-ID: On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes wrote: > Expired Flags in 20: > > - FilterSpuriousWakeups > - MinInliningThreshold > - PrefetchFieldsAhead > > No remaining usages in code or tests. > > - UseHeavyMonitors (expired in PRODUCT ONLY) > > As this flag now only exists for debug builds it has to be a "develop" flag rather than product. There are then changes to two tests that use this flag, so that they only run on a debug VM. > > - test/jdk/java/lang/Thread/virtual/HoldsLock.java > > The second @run that uses UseHeavyMonitors is moved to a second test segment that only applies to the debug VM. > > - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java > > Change the test section that uses UseHeavyMonitors to only run on a debug VM and remove the IgnoreUnrecognizedOptions flag. Note that the existing test logic would run the same test twice on product builds. > > No documentation in the manpage exists for any of the newly expired flags. > > Obsoleted flags in 20: > > - ExtendedDTraceProbes > > Documented in manpage so moved from Deprecated section to Obsolete section. There is special handling for messages about use of this flag so that won't be updated until the flag is actually obsoleted (JDK-8279913). > > - UseContainerCpuShares > - PreferContainerQuotaForCPUCount > - AliasLevel > > Undocumented. > > Java manpage updates: > - Updates Java version to 20 > - Moved ExtendedDTraceProbe info as previously mentioned > - Applied changes from the .1 file that had not been applied to the markdown source so that they were not lost (and note the .1 file was also missing changes from the markdown file that had not been propagated). > - Removed an unrepresentable character (the section symbol) that was not being generated into either the html or nroff file correctly Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9127 From dholmes at openjdk.java.net Sat Jun 11 05:41:49 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 11 Jun 2022 05:41:49 GMT Subject: RFR: 8279047: Remove expired flags in JDK 20 In-Reply-To: <08vbjWK5DR3Ka73-cLos7Oxvsrte5Xdj_kn5E96LCc8=.7c9af12a-e737-47b6-98ab-e02229456ff2@github.com> References: <08vbjWK5DR3Ka73-cLos7Oxvsrte5Xdj_kn5E96LCc8=.7c9af12a-e737-47b6-98ab-e02229456ff2@github.com> Message-ID: <6IscZJPdK1ScWseVs0-DD1Y9JE7sNVLf3Q2779d5MuA=.de292f85-bac4-48ad-8afb-b7e399d87cf4@github.com> On Fri, 10 Jun 2022 15:57:40 GMT, Vladimir Kozlov wrote: >> Expired Flags in 20: >> >> - FilterSpuriousWakeups >> - MinInliningThreshold >> - PrefetchFieldsAhead >> >> No remaining usages in code or tests. >> >> - UseHeavyMonitors (expired in PRODUCT ONLY) >> >> As this flag now only exists for debug builds it has to be a "develop" flag rather than product. There are then changes to two tests that use this flag, so that they only run on a debug VM. >> >> - test/jdk/java/lang/Thread/virtual/HoldsLock.java >> >> The second @run that uses UseHeavyMonitors is moved to a second test segment that only applies to the debug VM. >> >> - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java >> >> Change the test section that uses UseHeavyMonitors to only run on a debug VM and remove the IgnoreUnrecognizedOptions flag. Note that the existing test logic would run the same test twice on product builds. >> >> No documentation in the manpage exists for any of the newly expired flags. >> >> Obsoleted flags in 20: >> >> - ExtendedDTraceProbes >> >> Documented in manpage so moved from Deprecated section to Obsolete section. There is special handling for messages about use of this flag so that won't be updated until the flag is actually obsoleted (JDK-8279913). >> >> - UseContainerCpuShares >> - PreferContainerQuotaForCPUCount >> - AliasLevel >> >> Undocumented. >> >> Java manpage updates: >> - Updates Java version to 20 >> - Moved ExtendedDTraceProbe info as previously mentioned >> - Applied changes from the .1 file that had not been applied to the markdown source so that they were not lost (and note the .1 file was also missing changes from the markdown file that had not been propagated). >> - Removed an unrepresentable character (the section symbol) that was not being generated into either the html or nroff file correctly > > Looks good. Thanks for the reviews @vnkozlov and @kimbarrett ! ------------- PR: https://git.openjdk.org/jdk/pull/9127 From alanb at openjdk.java.net Sat Jun 11 05:50:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 11 Jun 2022 05:50:50 GMT Subject: RFR: 8279047: Remove expired flags in JDK 20 In-Reply-To: References: Message-ID: On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes wrote: > Expired Flags in 20: > > - FilterSpuriousWakeups > - MinInliningThreshold > - PrefetchFieldsAhead > > No remaining usages in code or tests. > > - UseHeavyMonitors (expired in PRODUCT ONLY) > > As this flag now only exists for debug builds it has to be a "develop" flag rather than product. There are then changes to two tests that use this flag, so that they only run on a debug VM. > > - test/jdk/java/lang/Thread/virtual/HoldsLock.java > > The second @run that uses UseHeavyMonitors is moved to a second test segment that only applies to the debug VM. > > - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java > > Change the test section that uses UseHeavyMonitors to only run on a debug VM and remove the IgnoreUnrecognizedOptions flag. Note that the existing test logic would run the same test twice on product builds. > > No documentation in the manpage exists for any of the newly expired flags. > > Obsoleted flags in 20: > > - ExtendedDTraceProbes > > Documented in manpage so moved from Deprecated section to Obsolete section. There is special handling for messages about use of this flag so that won't be updated until the flag is actually obsoleted (JDK-8279913). > > - UseContainerCpuShares > - PreferContainerQuotaForCPUCount > - AliasLevel > > Undocumented. > > Java manpage updates: > - Updates Java version to 20 > - Moved ExtendedDTraceProbe info as previously mentioned > - Applied changes from the .1 file that had not been applied to the markdown source so that they were not lost (and note the .1 file was also missing changes from the markdown file that had not been propagated). > - Removed an unrepresentable character (the section symbol) that was not being generated into either the html or nroff file correctly Marked as reviewed by alanb (Reviewer). test/jdk/java/lang/Thread/virtual/HoldsLock.java line 39: > 37: * @modules java.base/java.lang:+open > 38: * @compile --enable-preview -source ${jdk.version} HoldsLock.java > 39: * @run testng/othervm --enable-preview -XX:+UseHeavyMonitors HoldsLock The test updates look okay, probably don't need to duplicate the summary tag when it's unchanged but what you have is okay. ------------- PR: https://git.openjdk.org/jdk/pull/9127 From dholmes at openjdk.java.net Sat Jun 11 05:55:06 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 11 Jun 2022 05:55:06 GMT Subject: RFR: 8279047: Remove expired flags in JDK 20 In-Reply-To: References: Message-ID: On Sat, 11 Jun 2022 05:48:14 GMT, Alan Bateman wrote: >> Expired Flags in 20: >> >> - FilterSpuriousWakeups >> - MinInliningThreshold >> - PrefetchFieldsAhead >> >> No remaining usages in code or tests. >> >> - UseHeavyMonitors (expired in PRODUCT ONLY) >> >> As this flag now only exists for debug builds it has to be a "develop" flag rather than product. There are then changes to two tests that use this flag, so that they only run on a debug VM. >> >> - test/jdk/java/lang/Thread/virtual/HoldsLock.java >> >> The second @run that uses UseHeavyMonitors is moved to a second test segment that only applies to the debug VM. >> >> - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java >> >> Change the test section that uses UseHeavyMonitors to only run on a debug VM and remove the IgnoreUnrecognizedOptions flag. Note that the existing test logic would run the same test twice on product builds. >> >> No documentation in the manpage exists for any of the newly expired flags. >> >> Obsoleted flags in 20: >> >> - ExtendedDTraceProbes >> >> Documented in manpage so moved from Deprecated section to Obsolete section. There is special handling for messages about use of this flag so that won't be updated until the flag is actually obsoleted (JDK-8279913). >> >> - UseContainerCpuShares >> - PreferContainerQuotaForCPUCount >> - AliasLevel >> >> Undocumented. >> >> Java manpage updates: >> - Updates Java version to 20 >> - Moved ExtendedDTraceProbe info as previously mentioned >> - Applied changes from the .1 file that had not been applied to the markdown source so that they were not lost (and note the .1 file was also missing changes from the markdown file that had not been propagated). >> - Removed an unrepresentable character (the section symbol) that was not being generated into either the html or nroff file correctly > > Marked as reviewed by alanb (Reviewer). Thanks for the review @AlanBateman ! ------------- PR: https://git.openjdk.org/jdk/pull/9127 From dholmes at openjdk.java.net Sat Jun 11 05:55:08 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 11 Jun 2022 05:55:08 GMT Subject: Integrated: 8279047: Remove expired flags in JDK 20 In-Reply-To: References: Message-ID: <-GiViawovor61GE_0jy750oUVdzGjdVEwu3PZltgFnU=.401a110b-7a93-421d-a839-c928d96a324c@github.com> On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes wrote: > Expired Flags in 20: > > - FilterSpuriousWakeups > - MinInliningThreshold > - PrefetchFieldsAhead > > No remaining usages in code or tests. > > - UseHeavyMonitors (expired in PRODUCT ONLY) > > As this flag now only exists for debug builds it has to be a "develop" flag rather than product. There are then changes to two tests that use this flag, so that they only run on a debug VM. > > - test/jdk/java/lang/Thread/virtual/HoldsLock.java > > The second @run that uses UseHeavyMonitors is moved to a second test segment that only applies to the debug VM. > > - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java > > Change the test section that uses UseHeavyMonitors to only run on a debug VM and remove the IgnoreUnrecognizedOptions flag. Note that the existing test logic would run the same test twice on product builds. > > No documentation in the manpage exists for any of the newly expired flags. > > Obsoleted flags in 20: > > - ExtendedDTraceProbes > > Documented in manpage so moved from Deprecated section to Obsolete section. There is special handling for messages about use of this flag so that won't be updated until the flag is actually obsoleted (JDK-8279913). > > - UseContainerCpuShares > - PreferContainerQuotaForCPUCount > - AliasLevel > > Undocumented. > > Java manpage updates: > - Updates Java version to 20 > - Moved ExtendedDTraceProbe info as previously mentioned > - Applied changes from the .1 file that had not been applied to the markdown source so that they were not lost (and note the .1 file was also missing changes from the markdown file that had not been propagated). > - Removed an unrepresentable character (the section symbol) that was not being generated into either the html or nroff file correctly This pull request has now been integrated. Changeset: d46f404b Author: David Holmes URL: https://git.openjdk.org/jdk/commit/d46f404b3179c66e8e5775a9e2253c95238153c7 Stats: 69 lines in 5 files changed: 23 ins; 26 del; 20 mod 8279047: Remove expired flags in JDK 20 Reviewed-by: kvn, kbarrett, alanb ------------- PR: https://git.openjdk.org/jdk/pull/9127 From dholmes at openjdk.java.net Sat Jun 11 13:13:59 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 11 Jun 2022 13:13:59 GMT Subject: RFR: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test In-Reply-To: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> References: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> Message-ID: On Fri, 10 Jun 2022 10:20:38 GMT, KIRIYAMA Takuya wrote: > so it's important to confirm the deprication message. It has been confirmed, just not by a regression test. Adding this is harmless _but_ you can only test this on a JVM configured with JFR so now the test would have to `@require vm.jfr` as well. > Also we should add a test of ExtendedDTraceProbes option. That might be useful in 19 but this bug is being pushed to 20 and it incorrect for 20. At the start of every release we remove the options present in the VMDeprecatedOptions test that are obsoleted in that release as the error message changes and so would cause the test to fail. ------------- PR: https://git.openjdk.org/jdk/pull/9123 From dholmes at openjdk.java.net Sat Jun 11 13:51:59 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 11 Jun 2022 13:51:59 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v3] In-Reply-To: References: <_DvR2-kvCv_WWBp7fVVadk5_nWI2mZ4pbdstFhhTr-g=.f1fd56c3-6726-4048-8cb0-fc4aac31f1cf@github.com> Message-ID: On Fri, 10 Jun 2022 01:29:51 GMT, Yasumasa Suenaga wrote: > I think it is better to add null check to dll_unload() I would expect NULL checks to be present in the calling code somewhere; at most an assertion for NULL should be present in this lowest-level code. ------------- PR: https://git.openjdk.org/jdk/pull/9101 From iklam at openjdk.java.net Mon Jun 13 05:32:06 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 13 Jun 2022 05:32:06 GMT Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v3] In-Reply-To: References: Message-ID: On Wed, 8 Jun 2022 12:09:27 GMT, Severin Gehwolf wrote: >> Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated >> buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue >> of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read. >> >> While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From >> a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be >> there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is >> meant to only use stringStream throughout the cgroups code. >> >> Testing: >> - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2 >> - [x] Added tests, which I've verified also pass before the stringStream change >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Remove fix for substring match Just came back from vacation. LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/8969 From ioi.lam at oracle.com Mon Jun 13 06:01:15 2022 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 12 Jun 2022 23:01:15 -0700 Subject: The SUNWprivate_1.1 mystery In-Reply-To: References: Message-ID: <6797023f-2716-a82c-cc5b-a5c0aa8bcd37@oracle.com> I am not familiar with jogamp but found this discussion: https://forum.jogamp.org/Oracle-Java-13-Linux-version-SUNWprivate-1-1-not-found-td4040172.html Maybe you are using a very old build of jogamp? The symbol "SUNWprivate_1.1" has been removed from libjawt.so since JDK 11. I don't know why you only see the problem with JDK 18 but not JDK 17. Maybe you were not using JDK 17 but rather JDK 1.7? I would suggest contacting jogamp.org for further assistance on this issue. Thanks - Ioi On 6/10/2022 7:25 AM, Stefan Reich wrote: > Dear JDK devs, > > I hope this is the right list. The issue is this: Libraries such as > jogamp.org's OpenGL Java binding have stopped working on Linux since JDK 18. > > To run an example, you can get https://botcompany.de:9898/x30.jar and run > it with the parameter 1035520 (-jar x30.jar 1035520). It will download and > run this program . > > This runs fine on JDK 17 on all platforms as well as on Windows on JDK 18. > However, on JDK 18 on Linux Mint 19 it shows this error: > > java.lang.UnsatisfiedLinkError: > /tmp/jogamp_0000/file_cache/jln13303489101580857037/jln7948171270029506087/natives/linux-amd64/libnativewindow_awt.so: > /home/stefan/dev/jdk-18/lib/libjawt.so: version `SUNWprivate_1.1' not found > (required by > /tmp/jogamp_0000/file_cache/jln13303489101580857037/jln7948171270029506087/natives/linux-amd64/libnativewindow_awt.so) > at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) > at > java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:395) > at > java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:234) > at > java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:176) > at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2394) > at java.base/java.lang.Runtime.load0(Runtime.java:785) > at java.base/java.lang.System.load(System.java:1979) > at > com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:603) > at > com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:63) > at > com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:106) > at > com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:487) > at jogamp.nativewindow.NWJNILibLoader.access$000(NWJNILibLoader.java:39) > at jogamp.nativewindow.NWJNILibLoader$1.run(NWJNILibLoader.java:49) > at jogamp.nativewindow.NWJNILibLoader$1.run(NWJNILibLoader.java:41) > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:318) > at > jogamp.nativewindow.NWJNILibLoader.loadNativeWindow(NWJNILibLoader.java:41) > at jogamp.nativewindow.jawt.JAWTUtil.(JAWTUtil.java:336) > > What has changed in JDK 18? > > Many greetings and thanks in advance, > Stefan > From mbaesken at openjdk.java.net Mon Jun 13 08:26:53 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Mon, 13 Jun 2022 08:26:53 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v4] In-Reply-To: <1O6oxOTv6AogyTockN_HBRTi5hTduAOb2c_aOEPMo28=.660d11bf-afb8-4adc-856d-8a8c5fbda3df@github.com> References: <1O6oxOTv6AogyTockN_HBRTi5hTduAOb2c_aOEPMo28=.660d11bf-afb8-4adc-856d-8a8c5fbda3df@github.com> Message-ID: On Fri, 10 Jun 2022 14:22:26 GMT, Yasumasa Suenaga wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> dll_path on Linux - add NULL check, change special output to not available > > src/hotspot/os/linux/os_linux.cpp line 1791: > >> 1789: const char* os::Linux::dll_path(void* lib) { >> 1790: struct link_map *lmap; >> 1791: const char* l_path = ""; > > To be honest, I prefer to return NULL if `dlinfo` is failed. > IIUC the caller expects return dll path of `lib` - `` is not the path. > > I think it is better that alternative string would be set by the caller (`os::dll_unload()`) like a change of os_windows. But I do not stick my opinion. I'm ok if other reviewer approve your change. Adjusted dll_path, it returns now NULL in case of failure. > src/hotspot/os/windows/os_windows.cpp line 1241: > >> 1239: char name[MAX_PATH]; >> 1240: if (::GetModuleFileName((HMODULE)lib, name, sizeof(name)) == 0) { >> 1241: name[0] = '\0'; > > Should we set `` to `name` like a change for linux code? Yes, it is most likely better to have same output in failure case on Windows and other platforms. ------------- PR: https://git.openjdk.org/jdk/pull/9101 From mbaesken at openjdk.java.net Mon Jun 13 08:26:51 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Mon, 13 Jun 2022 08:26:51 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v5] In-Reply-To: References: Message-ID: > Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust dll_path ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9101/files - new: https://git.openjdk.org/jdk/pull/9101/files/fa7b3b7b..b255beb8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9101&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9101&range=03-04 Stats: 3 lines in 3 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9101.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9101/head:pull/9101 PR: https://git.openjdk.org/jdk/pull/9101 From sgehwolf at openjdk.java.net Mon Jun 13 09:45:52 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 13 Jun 2022 09:45:52 GMT Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v3] In-Reply-To: References: Message-ID: On Wed, 8 Jun 2022 12:09:27 GMT, Severin Gehwolf wrote: >> Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated >> buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue >> of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read. >> >> While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From >> a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be >> there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is >> meant to only use stringStream throughout the cgroups code. >> >> Testing: >> - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2 >> - [x] Added tests, which I've verified also pass before the stringStream change >> >> Thoughts? > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Remove fix for substring match @erikj79 Do you know why the SKARA bots didn't move this to `ready` by now? Is there an issue with the bots? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/8969 From stuefe at openjdk.java.net Mon Jun 13 10:42:10 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 13 Jun 2022 10:42:10 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v5] In-Reply-To: References: Message-ID: <12tO0v1NLeyFUy03yuA3dgRMIpjSQCDWemF5PipyyKY=.1f505e56-1de4-4629-8fe0-8be879b5fa38@github.com> On Mon, 13 Jun 2022 08:26:51 GMT, Matthias Baesken wrote: >> Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust dll_path Hi Matthias, this looks okay and is useful. I worried a bit about the thread safety of ::dlerror(), since it is specified as not threadsafe by [Posix](https://pubs.opengroup.org/onlinepubs/009696799/functions/dlerror.html): "The dlerror() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe." . However, the glibc variant (https://sources.debian.org/src/glibc/2.28-10/dlfcn/dlerror.c) seems to be thread-safe, using POSIX TLS to store the resulting error string. But interestingly enough, the string itself only lives as long as ::dlerror() is not called again. A second call to dlerror() will free() the string. So, one should use the string right away, for storing it should be strduped. I did not look if dlerror is threadsafe on Muslc. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/9101 From dholmes at openjdk.java.net Mon Jun 13 12:00:05 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 13 Jun 2022 12:00:05 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v5] In-Reply-To: <12tO0v1NLeyFUy03yuA3dgRMIpjSQCDWemF5PipyyKY=.1f505e56-1de4-4629-8fe0-8be879b5fa38@github.com> References: <12tO0v1NLeyFUy03yuA3dgRMIpjSQCDWemF5PipyyKY=.1f505e56-1de4-4629-8fe0-8be879b5fa38@github.com> Message-ID: On Mon, 13 Jun 2022 10:38:54 GMT, Thomas Stuefe wrote: > I worried a bit about the thread safety of ::dlerror() The usage here is no different to existing usages. ------------- PR: https://git.openjdk.org/jdk/pull/9101 From dholmes at openjdk.java.net Mon Jun 13 12:00:08 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 13 Jun 2022 12:00:08 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v5] In-Reply-To: References: Message-ID: <3gUh5SMoALh-J1X5IbJe3nE61L8Tb5aQ_dpMTwCigfc=.8275e957-7717-4106-80fe-11e1542c8f70@github.com> On Mon, 13 Jun 2022 08:26:51 GMT, Matthias Baesken wrote: >> Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust dll_path src/hotspot/os/linux/os_linux.cpp line 1792: > 1790: struct link_map *lmap; > 1791: const char* l_path = NULL; > 1792: if (lib != NULL) { I still say this can just be an assert - it is checked in the callers. ------------- PR: https://git.openjdk.org/jdk/pull/9101 From mbaesken at openjdk.java.net Mon Jun 13 12:27:11 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Mon, 13 Jun 2022 12:27:11 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v6] In-Reply-To: References: Message-ID: > Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: use assert in dll_path ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9101/files - new: https://git.openjdk.org/jdk/pull/9101/files/b255beb8..3cd592c0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9101&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9101&range=04-05 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9101.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9101/head:pull/9101 PR: https://git.openjdk.org/jdk/pull/9101 From mbaesken at openjdk.java.net Mon Jun 13 12:27:14 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Mon, 13 Jun 2022 12:27:14 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v5] In-Reply-To: <3gUh5SMoALh-J1X5IbJe3nE61L8Tb5aQ_dpMTwCigfc=.8275e957-7717-4106-80fe-11e1542c8f70@github.com> References: <3gUh5SMoALh-J1X5IbJe3nE61L8Tb5aQ_dpMTwCigfc=.8275e957-7717-4106-80fe-11e1542c8f70@github.com> Message-ID: On Mon, 13 Jun 2022 11:53:10 GMT, David Holmes wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust dll_path > > src/hotspot/os/linux/os_linux.cpp line 1792: > >> 1790: struct link_map *lmap; >> 1791: const char* l_path = NULL; >> 1792: if (lib != NULL) { > > I still say this can just be an assert - it is checked in the callers. I introduced an assert in dll_path. ------------- PR: https://git.openjdk.org/jdk/pull/9101 From stuefe at openjdk.java.net Mon Jun 13 12:31:58 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 13 Jun 2022 12:31:58 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v5] In-Reply-To: References: <12tO0v1NLeyFUy03yuA3dgRMIpjSQCDWemF5PipyyKY=.1f505e56-1de4-4629-8fe0-8be879b5fa38@github.com> Message-ID: <8u0y0h5mX4Klxkt1UGq41aLrkyuellwhdb6lCYnrCm8=.1e0bcdc3-fd05-46ab-810c-4beafbdaf3c7@github.com> On Mon, 13 Jun 2022 11:56:18 GMT, David Holmes wrote: > > I worried a bit about the thread safety of ::dlerror() > > The usage here is no different to existing usages. Sure, but they could have been existing errors :-) For proof that these thoughts are not completely unfounded see e.g. https://gitlab.gnome.org/GNOME/glib/-/issues/399, in that case pertaining to the now defunct eglibc. But older versions of glibc were not threadsafe either. ------------- PR: https://git.openjdk.org/jdk/pull/9101 From dholmes at openjdk.java.net Mon Jun 13 13:05:05 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 13 Jun 2022 13:05:05 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v5] In-Reply-To: <8u0y0h5mX4Klxkt1UGq41aLrkyuellwhdb6lCYnrCm8=.1e0bcdc3-fd05-46ab-810c-4beafbdaf3c7@github.com> References: <12tO0v1NLeyFUy03yuA3dgRMIpjSQCDWemF5PipyyKY=.1f505e56-1de4-4629-8fe0-8be879b5fa38@github.com> <8u0y0h5mX4Klxkt1UGq41aLrkyuellwhdb6lCYnrCm8=.1e0bcdc3-fd05-46ab-810c-4beafbdaf3c7@github.com> Message-ID: On Mon, 13 Jun 2022 12:27:22 GMT, Thomas Stuefe wrote: > Sure, but they could have been existing errors :-) Sure, but my point is that this fix is not introducing anything new. The potential for a broken dlerror has been discussed in the past. I don't think it is something we need to try to jump through hoops to anticipate. It is rare enough we will get an error, let alone concurrent ones. ------------- PR: https://git.openjdk.org/jdk/pull/9101 From alanb at openjdk.java.net Mon Jun 13 14:32:10 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 13 Jun 2022 14:32:10 GMT Subject: RFR: 8286176: Add JNI_VERSION_19 to jni.h and JNI spec Message-ID: <4gfI5vNdfsnz9LOqqQ_7c_MPtwUaP5CEkB4DOit9hCo=.0d24c1d1-ba43-4965-9043-741ced9c6ec0@github.com> JNI is updated in Java 19 so we need to define JNI_VERSION_19 and change GetVersion to return this version. test/hotspot/jtreg/native_sanity/JniVersion.java is updated to check that JNI_VERSION_19 is returned. The native library in the JMX agent, and several tests, define JNI_OnLoad that return JNI_VERSION_10 as the JNI version needed. These are updated to return JNI_VERSION_19 although these updates aren't strictly needed. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk19/pull/7/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk19&pr=7&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286176 Stats: 16 lines in 10 files changed: 2 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk19/pull/7.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/7/head:pull/7 PR: https://git.openjdk.org/jdk19/pull/7 From stuefe at openjdk.java.net Tue Jun 14 05:03:01 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 14 Jun 2022 05:03:01 GMT Subject: RFR: JDK-8288003: log events for os::dll_unload [v5] In-Reply-To: References: <12tO0v1NLeyFUy03yuA3dgRMIpjSQCDWemF5PipyyKY=.1f505e56-1de4-4629-8fe0-8be879b5fa38@github.com> <8u0y0h5mX4Klxkt1UGq41aLrkyuellwhdb6lCYnrCm8=.1e0bcdc3-fd05-46ab-810c-4beafbdaf3c7@github.com> Message-ID: On Mon, 13 Jun 2022 13:01:38 GMT, David Holmes wrote: > > Sure, but they could have been existing errors :-) > > Sure, but my point is that this fix is not introducing anything new. The potential for a broken dlerror has been discussed in the past. I don't think it is something we need to try to jump through hoops to anticipate. It is rare enough we will get an error, let alone concurrent ones. Of course, I agree. Thats why I approved the patch. ------------- PR: https://git.openjdk.org/jdk/pull/9101 From mbaesken at openjdk.java.net Tue Jun 14 07:21:45 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 14 Jun 2022 07:21:45 GMT Subject: Integrated: JDK-8288003: log events for os::dll_unload In-Reply-To: References: Message-ID: On Thu, 9 Jun 2022 07:50:14 GMT, Matthias Baesken wrote: > Currently we only log events for os::dll_load, but not for os::dll_unload, this patch adds it. On some platforms (Linux/Windows) we can use OS APIs (e.g. dlinfo on Linux) to log the path of the unloaded shared lib. This pull request has now been integrated. Changeset: c2ccf4ca Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/c2ccf4ca85b5375e08dce836acd6e86c851c3bd6 Stats: 46 lines in 4 files changed: 43 ins; 0 del; 3 mod 8288003: log events for os::dll_unload Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/9101 From ihse at openjdk.java.net Tue Jun 14 09:59:05 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 14 Jun 2022 09:59:05 GMT Subject: RFR: 8288396: Always create reproducible builds Message-ID: When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.) With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code. ------------- Commit messages: - 8288396: Always create reproducible builds Changes: https://git.openjdk.org/jdk/pull/9152/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9152&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288396 Stats: 94 lines in 15 files changed: 11 ins; 63 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/9152.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9152/head:pull/9152 PR: https://git.openjdk.org/jdk/pull/9152 From ihse at openjdk.java.net Tue Jun 14 09:59:06 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 14 Jun 2022 09:59:06 GMT Subject: RFR: 8288396: Always create reproducible builds In-Reply-To: References: Message-ID: On Tue, 14 Jun 2022 09:48:25 GMT, Magnus Ihse Bursie wrote: > When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.) > > With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code. This PR also include a more "radical" version of JDK-8287894, which probably should have been adopted by JDK-8287894 in the first place. There is no need to include the build date in the assert strings for shmem on Windows. ------------- PR: https://git.openjdk.org/jdk/pull/9152 From ihse at openjdk.java.net Tue Jun 14 10:09:37 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 14 Jun 2022 10:09:37 GMT Subject: RFR: 8288396: Always create reproducible builds [v2] In-Reply-To: References: Message-ID: > When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.) > > With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix exitTransportWithError signature ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9152/files - new: https://git.openjdk.org/jdk/pull/9152/files/8bc40ddb..e2f5fc05 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9152&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9152&range=00-01 Stats: 33 lines in 5 files changed: 0 ins; 27 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9152.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9152/head:pull/9152 PR: https://git.openjdk.org/jdk/pull/9152 From ihse at openjdk.java.net Tue Jun 14 10:37:49 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 14 Jun 2022 10:37:49 GMT Subject: RFR: 8288396: Always create reproducible builds [v2] In-Reply-To: References: Message-ID: On Tue, 14 Jun 2022 10:09:37 GMT, Magnus Ihse Bursie wrote: >> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.) >> >> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix exitTransportWithError signature I made some additional cleanup associated with shmem. I think that `sysAssert` can (and probably should) be replaced with `SHMEM_ASSERT`. I can fix that as well, if someone from serviceability says that I should do it. ------------- PR: https://git.openjdk.org/jdk/pull/9152 From mbaesken at openjdk.java.net Tue Jun 14 11:34:45 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 14 Jun 2022 11:34:45 GMT Subject: RFR: JDK-8284977: MetricsTesterCgroupV2.getLongValueEntryFromFile fails when named value doesn't exist Message-ID: When running test/jdk/jdk/internal/platform/cgroup/TestCgroupMetrics.java on ubuntu 21.10 or 22 , this test looks for a named value "nr_periods" in the file /sys/fs/cgroup/..../cpu.stat . However this metric is not always present, which leads to an AIOOB exception. ------------- Commit messages: - JDK-8284977 Changes: https://git.openjdk.org/jdk/pull/9153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9153&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8284977 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9153.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9153/head:pull/9153 PR: https://git.openjdk.org/jdk/pull/9153 From sgehwolf at openjdk.java.net Tue Jun 14 11:55:03 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 14 Jun 2022 11:55:03 GMT Subject: RFR: JDK-8284977: MetricsTesterCgroupV2.getLongValueEntryFromFile fails when named value doesn't exist In-Reply-To: References: Message-ID: <6DUrNbK3CCTviBhnAmm5MC9BDG5zoatrVn4Ez_dgdeI=.599ec6fe-5bae-4799-809a-46023914e2c5@github.com> On Tue, 14 Jun 2022 11:26:17 GMT, Matthias Baesken wrote: > When running test/jdk/jdk/internal/platform/cgroup/TestCgroupMetrics.java on ubuntu 21.10 or 22 , this test looks for a named value "nr_periods" in the file /sys/fs/cgroup/..../cpu.stat . However this metric is not always present, which leads to an AIOOB exception. LGTM ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.org/jdk/pull/9153 From erikj at openjdk.java.net Tue Jun 14 12:02:01 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 14 Jun 2022 12:02:01 GMT Subject: RFR: 8288396: Always create reproducible builds [v2] In-Reply-To: References: Message-ID: On Tue, 14 Jun 2022 10:09:37 GMT, Magnus Ihse Bursie wrote: >> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.) >> >> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix exitTransportWithError signature make/autoconf/flags-ldflags.m4 line 132: > 130: > 131: if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then > 132: REPRODUCIBLE_LDFLAGS="-experimental:deterministic" For the cflag, we check that the compiler supports it, but for the linker flag you are just setting it without a check. Before this patch, if we got here and ENABLE_REPRODUCIBLE_BUILD was true, it meant that the test had passed for the compiler, from which we could assume it would also work for the linker, but that is no longer the case. ------------- PR: https://git.openjdk.org/jdk/pull/9152 From dholmes at openjdk.java.net Tue Jun 14 12:23:02 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 14 Jun 2022 12:23:02 GMT Subject: RFR: 8286176: Add JNI_VERSION_19 to jni.h and JNI spec In-Reply-To: <4gfI5vNdfsnz9LOqqQ_7c_MPtwUaP5CEkB4DOit9hCo=.0d24c1d1-ba43-4965-9043-741ced9c6ec0@github.com> References: <4gfI5vNdfsnz9LOqqQ_7c_MPtwUaP5CEkB4DOit9hCo=.0d24c1d1-ba43-4965-9043-741ced9c6ec0@github.com> Message-ID: <3Wz6m66_gkZ4-u268K-AuVrVuInw7FtydqIugurCUbE=.96082836-2ab5-461c-a640-9f22c6a0b136@github.com> On Sat, 11 Jun 2022 15:42:34 GMT, Alan Bateman wrote: > JNI is updated in Java 19 so we need to define JNI_VERSION_19 and change GetVersion to return this version. > > test/hotspot/jtreg/native_sanity/JniVersion.java is updated to check that JNI_VERSION_19 is returned. The native library in the JMX agent, and several tests, define JNI_OnLoad that return JNI_VERSION_10 as the JNI version needed. These are updated to return JNI_VERSION_19 although these updates aren't strictly needed. @AlanBateman sorry I missed your statement "although these updates aren't strictly needed". ------------- PR: https://git.openjdk.org/jdk19/pull/7 From rpressler at openjdk.java.net Tue Jun 14 12:24:55 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Tue, 14 Jun 2022 12:24:55 GMT Subject: RFR: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp Message-ID: Please review the following fix. When JVM TI puts a thread's state in `interp_only_mode`, thaw takes the slow path and deoptimizes frames as they're thawed in `recurse_thaw_compiled_frame`. However, thawing a deoptimized frame's callee will override the frame's patched pc (to the deopt handler), essentially reverting the deoptimization. This fix patches the deoptimized return address after thawing the callee. Passes loom tiers 1-5 ------------- Commit messages: - Clarify comment - Remove tests from exclude list - Patch caller pc Changes: https://git.openjdk.org/jdk19/pull/12/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk19&pr=12&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8278053 Stats: 6 lines in 2 files changed: 3 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/12.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/12/head:pull/12 PR: https://git.openjdk.org/jdk19/pull/12 From alanb at openjdk.java.net Tue Jun 14 12:24:56 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 14 Jun 2022 12:24:56 GMT Subject: RFR: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp In-Reply-To: References: Message-ID: On Tue, 14 Jun 2022 08:02:21 GMT, Ron Pressler wrote: > Please review the following fix. > > When JVM TI puts a thread's state in `interp_only_mode`, thaw takes the slow path and deoptimizes frames as they're thawed in `recurse_thaw_compiled_frame`. However, thawing a deoptimized frame's callee will override the frame's patched pc (to the deopt handler), essentially reverting the deoptimization. This fix patches the deoptimized return address after thawing the callee. > > Passes loom tiers 1-5 Are you going to remove the test from test/hotspot/jtreg/ProblemList-Xcomp.txt? ------------- PR: https://git.openjdk.org/jdk19/pull/12 From rpressler at openjdk.java.net Tue Jun 14 12:24:57 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Tue, 14 Jun 2022 12:24:57 GMT Subject: RFR: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp In-Reply-To: References: Message-ID: On Tue, 14 Jun 2022 08:36:19 GMT, Alan Bateman wrote: >> Please review the following fix. >> >> When JVM TI puts a thread's state in `interp_only_mode`, thaw takes the slow path and deoptimizes frames as they're thawed in `recurse_thaw_compiled_frame`. However, thawing a deoptimized frame's callee will override the frame's patched pc (to the deopt handler), essentially reverting the deoptimization. This fix patches the deoptimized return address after thawing the callee. >> >> Passes loom tiers 1-5 > > Are you going to remove the test from test/hotspot/jtreg/ProblemList-Xcomp.txt? @AlanBateman done. ------------- PR: https://git.openjdk.org/jdk19/pull/12 From ihse at openjdk.java.net Tue Jun 14 12:31:04 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 14 Jun 2022 12:31:04 GMT Subject: RFR: 8288396: Always create reproducible builds [v2] In-Reply-To: References: Message-ID: On Tue, 14 Jun 2022 11:54:40 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix exitTransportWithError signature > > make/autoconf/flags-ldflags.m4 line 132: > >> 130: >> 131: if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then >> 132: REPRODUCIBLE_LDFLAGS="-experimental:deterministic" > > For the cflag, we check that the compiler supports it, but for the linker flag you are just setting it without a check. Before this patch, if we got here and ENABLE_REPRODUCIBLE_BUILD was true, it meant that the test had passed for the compiler, from which we could assume it would also work for the linker, but that is no longer the case. Good point. ------------- PR: https://git.openjdk.org/jdk/pull/9152 From hseigel at openjdk.java.net Tue Jun 14 15:19:05 2022 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 14 Jun 2022 15:19:05 GMT Subject: RFR: 8288134: Super class names don't have envelopes In-Reply-To: References: Message-ID: On Mon, 13 Jun 2022 18:44:24 GMT, Coleen Phillimore wrote: > SystemDictionary::resolve_super_or_null() calls resolve_instance_class_or_null_helper() which strips off the L; envelope for class names then calls resolve_instance_class_or_null(). > Super class names come from the constant pool or an existing InstanceKlass in the CDS path, so is already verified by the format checker, if the name has L; and it will already get a class format error. > > Removed this helper and call resolve_instance_class_or_null() directly, and inlined the helper function into resolve_or_null(). > > Tested by tier1-4 on Oracle supported platforms. Looks good! Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.org/jdk/pull/9144 From coleenp at openjdk.java.net Tue Jun 14 16:16:54 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 14 Jun 2022 16:16:54 GMT Subject: RFR: 8288134: Super class names don't have envelopes In-Reply-To: References: Message-ID: On Mon, 13 Jun 2022 18:44:24 GMT, Coleen Phillimore wrote: > SystemDictionary::resolve_super_or_null() calls resolve_instance_class_or_null_helper() which strips off the L; envelope for class names then calls resolve_instance_class_or_null(). > Super class names come from the constant pool or an existing InstanceKlass in the CDS path, so is already verified by the format checker, if the name has L; and it will already get a class format error. > > Removed this helper and call resolve_instance_class_or_null() directly, and inlined the helper function into resolve_or_null(). > > Tested by tier1-4 on Oracle supported platforms. Thanks Harold! ------------- PR: https://git.openjdk.org/jdk/pull/9144 From iklam at openjdk.java.net Tue Jun 14 18:57:39 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 14 Jun 2022 18:57:39 GMT Subject: RFR: 8288443: Simplify vmClasses::resolve_all() Message-ID: <7AAtR7ty4p7IzqrVh1pGWO0DUyfyNKXLVDqL9Q2A3GI=.b6cf12b5-8db3-413d-9cd5-b43dba381744@github.com> Please review this simple clean up: - There's no need to initialize the JSR 292 classes separately (the `-XX:+EnableInvokeDynamic` option has been removed long time ago). - Separate initialization of the reference classes is not necessary when CDS is enabled. ------------- Commit messages: - 8288443: Simplify vmClasses::resolve_all() Changes: https://git.openjdk.org/jdk/pull/9157/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9157&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288443 Stats: 31 lines in 1 file changed: 5 ins; 0 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/9157.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9157/head:pull/9157 PR: https://git.openjdk.org/jdk/pull/9157 From fparain at openjdk.java.net Tue Jun 14 18:59:57 2022 From: fparain at openjdk.java.net (Frederic Parain) Date: Tue, 14 Jun 2022 18:59:57 GMT Subject: RFR: 8288134: Super class names don't have envelopes In-Reply-To: References: Message-ID: On Mon, 13 Jun 2022 18:44:24 GMT, Coleen Phillimore wrote: > SystemDictionary::resolve_super_or_null() calls resolve_instance_class_or_null_helper() which strips off the L; envelope for class names then calls resolve_instance_class_or_null(). > Super class names come from the constant pool or an existing InstanceKlass in the CDS path, so is already verified by the format checker, if the name has L; and it will already get a class format error. > > Removed this helper and call resolve_instance_class_or_null() directly, and inlined the helper function into resolve_or_null(). > > Tested by tier1-4 on Oracle supported platforms. LGTM Fred ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.org/jdk/pull/9144 From coleenp at openjdk.java.net Tue Jun 14 19:33:52 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 14 Jun 2022 19:33:52 GMT Subject: RFR: 8288134: Super class names don't have envelopes In-Reply-To: References: Message-ID: On Mon, 13 Jun 2022 18:44:24 GMT, Coleen Phillimore wrote: > SystemDictionary::resolve_super_or_null() calls resolve_instance_class_or_null_helper() which strips off the L; envelope for class names then calls resolve_instance_class_or_null(). > Super class names come from the constant pool or an existing InstanceKlass in the CDS path, so is already verified by the format checker, if the name has L; and it will already get a class format error. > > Removed this helper and call resolve_instance_class_or_null() directly, and inlined the helper function into resolve_or_null(). > > Tested by tier1-4 on Oracle supported platforms. Thanks Fred! ------------- PR: https://git.openjdk.org/jdk/pull/9144 From coleenp at openjdk.java.net Tue Jun 14 19:33:53 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 14 Jun 2022 19:33:53 GMT Subject: Integrated: 8288134: Super class names don't have envelopes In-Reply-To: References: Message-ID: On Mon, 13 Jun 2022 18:44:24 GMT, Coleen Phillimore wrote: > SystemDictionary::resolve_super_or_null() calls resolve_instance_class_or_null_helper() which strips off the L; envelope for class names then calls resolve_instance_class_or_null(). > Super class names come from the constant pool or an existing InstanceKlass in the CDS path, so is already verified by the format checker, if the name has L; and it will already get a class format error. > > Removed this helper and call resolve_instance_class_or_null() directly, and inlined the helper function into resolve_or_null(). > > Tested by tier1-4 on Oracle supported platforms. This pull request has now been integrated. Changeset: 0f580974 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/0f580974a606cf9df293dbaebf72ab86cd01b774 Stats: 26 lines in 2 files changed: 0 ins; 12 del; 14 mod 8288134: Super class names don't have envelopes Reviewed-by: iklam, hseigel, fparain ------------- PR: https://git.openjdk.org/jdk/pull/9144 From mdoerr at openjdk.java.net Tue Jun 14 19:49:41 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 14 Jun 2022 19:49:41 GMT Subject: RFR: JDK-8284977: MetricsTesterCgroupV2.getLongValueEntryFromFile fails when named value doesn't exist In-Reply-To: References: Message-ID: On Tue, 14 Jun 2022 11:26:17 GMT, Matthias Baesken wrote: > When running test/jdk/jdk/internal/platform/cgroup/TestCgroupMetrics.java on ubuntu 21.10 or 22 , this test looks for a named value "nr_periods" in the file /sys/fs/cgroup/..../cpu.stat . However this metric is not always present, which leads to an AIOOB exception. Marked as reviewed by mdoerr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9153 From mdoerr at openjdk.java.net Tue Jun 14 20:12:41 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 14 Jun 2022 20:12:41 GMT Subject: RFR: JDK-8284977: MetricsTesterCgroupV2.getLongValueEntryFromFile fails when named value doesn't exist In-Reply-To: References: Message-ID: On Tue, 14 Jun 2022 11:26:17 GMT, Matthias Baesken wrote: > When running test/jdk/jdk/internal/platform/cgroup/TestCgroupMetrics.java on ubuntu 21.10 or 22 , this test looks for a named value "nr_periods" in the file /sys/fs/cgroup/..../cpu.stat . However this metric is not always present, which leads to an AIOOB exception. Do we want to fix it in JDK20 only (not 19)? "Bugs of any priority whose fixes only affect tests, or test-problem lists, or documentation may be fixed in RDP 1 and RDP 2." https://openjdk.org/jeps/3#rdp-1 ------------- PR: https://git.openjdk.org/jdk/pull/9153 From amenkov at openjdk.java.net Tue Jun 14 23:06:37 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 14 Jun 2022 23:06:37 GMT Subject: RFR: 8288396: Always create reproducible builds [v2] In-Reply-To: References: Message-ID: <8c8eYBUKp4-nZsS7eIxdbBohIOd0BRzRchSfHL8wE5s=.883d27bd-7e38-4829-80a4-71a8378876c8@github.com> On Tue, 14 Jun 2022 12:27:06 GMT, Magnus Ihse Bursie wrote: >> make/autoconf/flags-ldflags.m4 line 132: >> >>> 130: >>> 131: if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then >>> 132: REPRODUCIBLE_LDFLAGS="-experimental:deterministic" >> >> For the cflag, we check that the compiler supports it, but for the linker flag you are just setting it without a check. Before this patch, if we got here and ENABLE_REPRODUCIBLE_BUILD was true, it meant that the test had passed for the compiler, from which we could assume it would also work for the linker, but that is no longer the case. > > Good point. > I made some additional cleanup associated with shmem. I think that sysAssert can (and probably should) > be replaced with SHMEM_ASSERT. I can fix that as well, if someone from serviceability says that I should do it. Please do it. There is no reason to keep 2 identical defines. ------------- PR: https://git.openjdk.org/jdk/pull/9152 From ccheung at openjdk.java.net Tue Jun 14 23:37:52 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 14 Jun 2022 23:37:52 GMT Subject: RFR: 8288443: Simplify vmClasses::resolve_all() In-Reply-To: <7AAtR7ty4p7IzqrVh1pGWO0DUyfyNKXLVDqL9Q2A3GI=.b6cf12b5-8db3-413d-9cd5-b43dba381744@github.com> References: <7AAtR7ty4p7IzqrVh1pGWO0DUyfyNKXLVDqL9Q2A3GI=.b6cf12b5-8db3-413d-9cd5-b43dba381744@github.com> Message-ID: On Tue, 14 Jun 2022 17:54:25 GMT, Ioi Lam wrote: > Please review this simple clean up: > > - There's no need to initialize the JSR 292 classes separately (the `-XX:+EnableInvokeDynamic` option has been removed long time ago). > - Separate initialization of the reference classes is not necessary when CDS is enabled. Looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk/pull/9157 From mbaesken at openjdk.java.net Wed Jun 15 06:42:42 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 15 Jun 2022 06:42:42 GMT Subject: Integrated: JDK-8284977: MetricsTesterCgroupV2.getLongValueEntryFromFile fails when named value doesn't exist In-Reply-To: References: Message-ID: On Tue, 14 Jun 2022 11:26:17 GMT, Matthias Baesken wrote: > When running test/jdk/jdk/internal/platform/cgroup/TestCgroupMetrics.java on ubuntu 21.10 or 22 , this test looks for a named value "nr_periods" in the file /sys/fs/cgroup/..../cpu.stat . However this metric is not always present, which leads to an AIOOB exception. This pull request has now been integrated. Changeset: 444a0d98 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/444a0d98ac06ab043e3b11281234fd515abff302 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8284977: MetricsTesterCgroupV2.getLongValueEntryFromFile fails when named value doesn't exist Reviewed-by: sgehwolf, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/9153 From mbaesken at openjdk.java.net Wed Jun 15 06:42:40 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 15 Jun 2022 06:42:40 GMT Subject: RFR: JDK-8284977: MetricsTesterCgroupV2.getLongValueEntryFromFile fails when named value doesn't exist In-Reply-To: References: Message-ID: On Tue, 14 Jun 2022 20:07:13 GMT, Martin Doerr wrote: > Do we want to fix it in JDK20 only (not 19)? "Bugs of any priority whose fixes only affect tests, or test-problem lists, or documentation may be fixed in RDP 1 and RDP 2." https://openjdk.org/jeps/3#rdp-1 I think we can backport it if needed. ------------- PR: https://git.openjdk.org/jdk/pull/9153 From mbaesken at openjdk.java.net Wed Jun 15 07:38:40 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 15 Jun 2022 07:38:40 GMT Subject: RFR: JDK-8287011: Improve container information [v4] In-Reply-To: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: > The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8287011 - handle new cgroupv1 and v2 values in TestMisc - adjust output in os_linux.cpp - JDK-8287011 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8991/files - new: https://git.openjdk.org/jdk/pull/8991/files/e90a3046..cbcf985b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8991&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8991&range=02-03 Stats: 115099 lines in 1797 files changed: 56370 ins; 48550 del; 10179 mod Patch: https://git.openjdk.org/jdk/pull/8991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8991/head:pull/8991 PR: https://git.openjdk.org/jdk/pull/8991 From mbaesken at openjdk.java.net Wed Jun 15 08:21:49 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 15 Jun 2022 08:21:49 GMT Subject: RFR: JDK-8287011: Improve container information [v3] In-Reply-To: References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: On Tue, 7 Jun 2022 13:17:06 GMT, Severin Gehwolf wrote: >> sounds like a good idea, but with the kmem stuff deprecated (Kernel commit adding the deprecation: >> https://github.com/torvalds/linux/commit/0158115f702b ) we should maybe wait first for a reply from Thomas why he is still interested in it. > > OK. Hi Severin, I think the OSContainer::print_version_specific_info(st) sounds like a good idea. It would mean that we keep the API smaller and do not overload it with stuff that is in fact only available in v1 (or only available in v2). ------------- PR: https://git.openjdk.org/jdk/pull/8991 From mbaesken at openjdk.java.net Wed Jun 15 11:37:36 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 15 Jun 2022 11:37:36 GMT Subject: RFR: JDK-8287011: Improve container information [v5] In-Reply-To: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: <4n2ej21Q2mTKnTNSPZ87PuCWEfYILveN8MXOp9uZoi4=.999d5182-efc0-463a-9131-fa5644ed5bbc@github.com> > The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Introduce print_version_specific_info ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8991/files - new: https://git.openjdk.org/jdk/pull/8991/files/cbcf985b..77c52cdf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8991&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8991&range=03-04 Stats: 142 lines in 8 files changed: 22 ins; 98 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/8991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8991/head:pull/8991 PR: https://git.openjdk.org/jdk/pull/8991 From mbaesken at openjdk.java.net Wed Jun 15 11:37:41 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 15 Jun 2022 11:37:41 GMT Subject: RFR: JDK-8287011: Improve container information [v4] In-Reply-To: References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: <91Cg2BwtyztjX1fqxXz9tZ0XnuAxPJhIUczSJ0oEPJs=.881b65c2-86bf-456b-ab00-19b822449ae9@github.com> On Wed, 15 Jun 2022 07:38:40 GMT, Matthias Baesken wrote: >> The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. > > Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8287011 > - handle new cgroupv1 and v2 values in TestMisc > - adjust output in os_linux.cpp > - JDK-8287011 I introduced a method OSContainer::print_version_specific_info, this avoids putting (in some version) unavailable metrics (like the kernel-memory functions) into all cgroups (v1 and v2). ------------- PR: https://git.openjdk.org/jdk/pull/8991 From sgehwolf at openjdk.java.net Wed Jun 15 11:59:37 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 15 Jun 2022 11:59:37 GMT Subject: RFR: JDK-8287011: Improve container information [v5] In-Reply-To: <4n2ej21Q2mTKnTNSPZ87PuCWEfYILveN8MXOp9uZoi4=.999d5182-efc0-463a-9131-fa5644ed5bbc@github.com> References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> <4n2ej21Q2mTKnTNSPZ87PuCWEfYILveN8MXOp9uZoi4=.999d5182-efc0-463a-9131-fa5644ed5bbc@github.com> Message-ID: <-M9De6LyJimEST5NYRwmiQD2JOxbwCe9etL2hWK1pRg=.33443195-012d-4b02-ba85-455b633ffe8a@github.com> On Wed, 15 Jun 2022 11:37:36 GMT, Matthias Baesken wrote: >> The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Introduce print_version_specific_info OK ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.org/jdk/pull/8991 From dholmes at openjdk.java.net Wed Jun 15 13:00:00 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 15 Jun 2022 13:00:00 GMT Subject: RFR: 8288443: Simplify vmClasses::resolve_all() In-Reply-To: <7AAtR7ty4p7IzqrVh1pGWO0DUyfyNKXLVDqL9Q2A3GI=.b6cf12b5-8db3-413d-9cd5-b43dba381744@github.com> References: <7AAtR7ty4p7IzqrVh1pGWO0DUyfyNKXLVDqL9Q2A3GI=.b6cf12b5-8db3-413d-9cd5-b43dba381744@github.com> Message-ID: On Tue, 14 Jun 2022 17:54:25 GMT, Ioi Lam wrote: > Please review this simple clean up: > > - There's no need to initialize the JSR 292 classes separately (the `-XX:+EnableInvokeDynamic` option has been removed long time ago). > - Separate initialization of the reference classes is not necessary when CDS is enabled. Seems fine. There are related comments about ordering and 1.4 JDKs in vmClassMacros.hpp that should also be cleaned up. I find it interesting it says /* Note: MethodHandle must be first, and VolatileCallSite last in group */ when DirectMethodHandle is actually first. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9157 From coleenp at openjdk.java.net Wed Jun 15 13:36:00 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 15 Jun 2022 13:36:00 GMT Subject: RFR: 8288443: Simplify vmClasses::resolve_all() In-Reply-To: <7AAtR7ty4p7IzqrVh1pGWO0DUyfyNKXLVDqL9Q2A3GI=.b6cf12b5-8db3-413d-9cd5-b43dba381744@github.com> References: <7AAtR7ty4p7IzqrVh1pGWO0DUyfyNKXLVDqL9Q2A3GI=.b6cf12b5-8db3-413d-9cd5-b43dba381744@github.com> Message-ID: On Tue, 14 Jun 2022 17:54:25 GMT, Ioi Lam wrote: > Please review this simple clean up: > > - There's no need to initialize the JSR 292 classes separately (the `-XX:+EnableInvokeDynamic` option has been removed long time ago). > - Separate initialization of the reference classes is not necessary when CDS is enabled. Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9157 From ihse at openjdk.java.net Wed Jun 15 14:13:43 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 15 Jun 2022 14:13:43 GMT Subject: RFR: 8288396: Always create reproducible builds [v3] In-Reply-To: References: Message-ID: > When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.) > > With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Replace sysAssert with SHMEM_ASSERT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9152/files - new: https://git.openjdk.org/jdk/pull/9152/files/e2f5fc05..0421abc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9152&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9152&range=01-02 Stats: 30 lines in 1 file changed: 0 ins; 12 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/9152.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9152/head:pull/9152 PR: https://git.openjdk.org/jdk/pull/9152 From ihse at openjdk.java.net Wed Jun 15 14:19:34 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 15 Jun 2022 14:19:34 GMT Subject: RFR: 8288396: Always create reproducible builds [v4] In-Reply-To: References: Message-ID: <7PVfQ1OxfSkOxdkxxNH9NrakgUCXHjhzLpY0mwHh-F0=.a793fa2f-7115-4f04-9d60-8409989d802b@github.com> > When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.) > > With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into full-reproducibility - Replace sysAssert with SHMEM_ASSERT - Fix exitTransportWithError signature - 8288396: Always create reproducible builds ------------- Changes: https://git.openjdk.org/jdk/pull/9152/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9152&range=03 Stats: 155 lines in 18 files changed: 11 ins; 102 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/9152.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9152/head:pull/9152 PR: https://git.openjdk.org/jdk/pull/9152 From ihse at openjdk.java.net Wed Jun 15 15:18:04 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 15 Jun 2022 15:18:04 GMT Subject: RFR: 8288396: Always create reproducible builds [v5] In-Reply-To: References: Message-ID: > When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.) > > With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Remove incorrect argument - Test if linker can accept the flag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9152/files - new: https://git.openjdk.org/jdk/pull/9152/files/adc0bbcb..6c45fa5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9152&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9152&range=03-04 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9152.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9152/head:pull/9152 PR: https://git.openjdk.org/jdk/pull/9152 From dcubed at openjdk.java.net Wed Jun 15 16:17:44 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 16:17:44 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() Message-ID: A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows us to add checks to detect failures like: JDK-8288139 JavaThread touches oop after GC barrier is detached https://bugs.openjdk.org/browse/JDK-8288139 This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. ------------- Commit messages: - 8288497: add support for JavaThread::is_gc_barrier_detached() Changes: https://git.openjdk.org/jdk19/pull/20/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=20&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288497 Stats: 31 lines in 4 files changed: 22 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk19/pull/20.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/20/head:pull/20 PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.java.net Wed Jun 15 16:17:56 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 16:17:56 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 15:44:21 GMT, Daniel D. Daugherty wrote: > A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows > us to add checks to detect failures like: > > JDK-8288139 JavaThread touches oop after GC barrier is detached > https://bugs.openjdk.org/browse/JDK-8288139 > > This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. src/hotspot/share/runtime/thread.inline.hpp line 264: > 262: inline bool JavaThread::is_exiting() const { > 263: // Use load-acquire so that setting of _terminated by > 264: // JavaThread::set_terminated() is seen more quickly. This comment should have been updated when the code in JavaThread::exit() was refactored into JavaThread::set_terminated(). I'm doing it as part of this fix for clarity. src/hotspot/share/runtime/thread.inline.hpp line 281: > 279: inline bool JavaThread::is_terminated() const { > 280: // Use load-acquire so that setting of _terminated by > 281: // JavaThread::set_terminated() is seen more quickly. This comment should have been updated when the code in JavaThread::exit() was refactored into JavaThread::set_terminated(). I'm doing it as part of this fix for clarity. src/hotspot/share/services/threadService.cpp line 167: > 165: if (!thread->is_exiting()) { > 166: // We did not get here via JavaThread::exit() so current_thread_exiting() > 167: // was not called, e.g., JavaThread::cleanup_failed_attach_current_thread(). [JDK-8286830](https://bugs.openjdk.org/browse/JDK-8286830) ~HandshakeState should not touch oops changed JavaThread::exit() so we no longer had a path that called current_thread_exiting() and another path that did not call current_thread_exiting() so this comment should have been clarified with that fix. I'm doing it as part of this fix for clarity. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From iklam at openjdk.java.net Wed Jun 15 16:24:45 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 15 Jun 2022 16:24:45 GMT Subject: RFR: 8288443: Simplify vmClasses::resolve_all() [v2] In-Reply-To: <7AAtR7ty4p7IzqrVh1pGWO0DUyfyNKXLVDqL9Q2A3GI=.b6cf12b5-8db3-413d-9cd5-b43dba381744@github.com> References: <7AAtR7ty4p7IzqrVh1pGWO0DUyfyNKXLVDqL9Q2A3GI=.b6cf12b5-8db3-413d-9cd5-b43dba381744@github.com> Message-ID: > Please review this simple clean up: > > - There's no need to initialize the JSR 292 classes separately (the `-XX:+EnableInvokeDynamic` option has been removed long time ago). > - Separate initialization of the reference classes is not necessary when CDS is enabled. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: removed out-dated comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9157/files - new: https://git.openjdk.org/jdk/pull/9157/files/e802861c..ccdf46c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9157&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9157&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9157.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9157/head:pull/9157 PR: https://git.openjdk.org/jdk/pull/9157 From iklam at openjdk.java.net Wed Jun 15 16:26:37 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 15 Jun 2022 16:26:37 GMT Subject: RFR: 8288443: Simplify vmClasses::resolve_all() [v2] In-Reply-To: References: <7AAtR7ty4p7IzqrVh1pGWO0DUyfyNKXLVDqL9Q2A3GI=.b6cf12b5-8db3-413d-9cd5-b43dba381744@github.com> Message-ID: On Wed, 15 Jun 2022 12:56:31 GMT, David Holmes wrote: > Seems fine. > > There are related comments about ordering and 1.4 JDKs in vmClassMacros.hpp that should also be cleaned up. I find it interesting it says > > /* Note: MethodHandle must be first, and VolatileCallSite last in group */ > > when DirectMethodHandle is actually first. > > Thanks. I removed the out-dated comments about supporting earlier JDKs. Also removed the info about the ordering of the `MethodHandle` classes. I have no idea whether or why the ordering is important, but this mystery should be covered by the comment about the `VM_CLASSES_DO` macro definition. // The order of these definitions is significant: the classes are // resolved by vmClasses::resolve_all() in this order. Changing the // order may require careful restructuring of the VM start-up sequence. ------------- PR: https://git.openjdk.org/jdk/pull/9157 From dcubed at openjdk.java.net Wed Jun 15 16:45:53 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 16:45:53 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached Message-ID: Update SharedRuntime::get_java_tid() to verify that the calling thread is safely accessing its own threadObj(). This check uses the new is_gc_barrier_detached() function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). The above check was used to reproduce the failure mode without Shenandoah and the remainder of the fix relocates the offending code from ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of removed the 'tid' entry from the ThreadIdTable is still done under the protection of the Threads_lock. This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. ------------- Depends on: https://git.openjdk.org/jdk19/pull/20 Commit messages: - 8288139: JavaThread touches oop after GC barrier is detached Changes: https://git.openjdk.org/jdk19/pull/21/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=21&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288139 Stats: 22 lines in 4 files changed: 9 ins; 6 del; 7 mod Patch: https://git.openjdk.org/jdk19/pull/21.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/21/head:pull/21 PR: https://git.openjdk.org/jdk19/pull/21 From dcubed at openjdk.java.net Wed Jun 15 18:27:06 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 18:27:06 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 15:44:21 GMT, Daniel D. Daugherty wrote: > A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows > us to add checks to detect failures like: > > JDK-8288139 JavaThread touches oop after GC barrier is detached > https://bugs.openjdk.org/browse/JDK-8288139 > > This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. @dholmes-ora, @patricio and @robehn - Pinging you guys since we were all involved with [JDK-8286830](https://bugs.openjdk.org/browse/JDK-8286830) ~HandshakeState should not touch oops @fisk - Pinging you since you are interested in GC barriers. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.java.net Wed Jun 15 18:28:07 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 18:28:07 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 16:06:08 GMT, Daniel D. Daugherty wrote: > Update SharedRuntime::get_java_tid() to verify that the calling thread is safely > accessing its own threadObj(). This check uses the new is_gc_barrier_detached() > function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). > > The above check was used to reproduce the failure mode without Shenandoah > and the remainder of the fix relocates the offending code from > ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of > removed the 'tid' entry from the ThreadIdTable is still done under the > protection of the Threads_lock. > > This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. @dholmes-ora, @Patricio and @robehn - Pinging you guys since we were all involved with [JDK-8286830](https://bugs.openjdk.org/browse/JDK-8286830) ~HandshakeState should not touch oops @fisk - Pinging you since you are interested in GC barriers. ------------- PR: https://git.openjdk.org/jdk19/pull/21 From pchilanomate at openjdk.java.net Wed Jun 15 18:53:09 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 15 Jun 2022 18:53:09 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 16:06:08 GMT, Daniel D. Daugherty wrote: > Update SharedRuntime::get_java_tid() to verify that the calling thread is safely > accessing its own threadObj(). This check uses the new is_gc_barrier_detached() > function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). > > The above check was used to reproduce the failure mode without Shenandoah > and the remainder of the fix relocates the offending code from > ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of > removed the 'tid' entry from the ThreadIdTable is still done under the > protection of the Threads_lock. > > This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. Looks good to me! I only have one comment but made it in 8288497 because it applies more to that change. Thanks, Patricio ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.org/jdk19/pull/21 From pchilanomate at openjdk.java.net Wed Jun 15 18:56:02 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 15 Jun 2022 18:56:02 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 15:44:21 GMT, Daniel D. Daugherty wrote: > A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows > us to add checks to detect failures like: > > JDK-8288139 JavaThread touches oop after GC barrier is detached > https://bugs.openjdk.org/browse/JDK-8288139 > > This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. I think I would just use the _thread_terminated state rather than introducing a new _thread_gc_barrier_detached state just to detect failures. So the only extra things covered by _thread_gc_barrier_detached and not by _thread_terminated would be ThreadService::remove_thread() which just updates some counters, and ThreadsSMRSupport::remove_thread() which we overlooked before but now by inspection I don't see any other place where we touch oops there. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.java.net Wed Jun 15 19:05:57 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 19:05:57 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 18:51:05 GMT, Patricio Chilano Mateo wrote: >> Update SharedRuntime::get_java_tid() to verify that the calling thread is safely >> accessing its own threadObj(). This check uses the new is_gc_barrier_detached() >> function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). >> >> The above check was used to reproduce the failure mode without Shenandoah >> and the remainder of the fix relocates the offending code from >> ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of >> removed the 'tid' entry from the ThreadIdTable is still done under the >> protection of the Threads_lock. >> >> This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Looks good to me! I only have one comment but made it in 8288497 because it applies more to that change. > > Thanks, > Patricio @pchilano - Thanks for the review! ------------- PR: https://git.openjdk.org/jdk19/pull/21 From alanb at openjdk.java.net Wed Jun 15 19:10:04 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 15 Jun 2022 19:10:04 GMT Subject: RFR: 8286176: Add JNI_VERSION_19 to jni.h and JNI spec In-Reply-To: <3Wz6m66_gkZ4-u268K-AuVrVuInw7FtydqIugurCUbE=.96082836-2ab5-461c-a640-9f22c6a0b136@github.com> References: <4gfI5vNdfsnz9LOqqQ_7c_MPtwUaP5CEkB4DOit9hCo=.0d24c1d1-ba43-4965-9043-741ced9c6ec0@github.com> <3Wz6m66_gkZ4-u268K-AuVrVuInw7FtydqIugurCUbE=.96082836-2ab5-461c-a640-9f22c6a0b136@github.com> Message-ID: On Tue, 14 Jun 2022 12:19:29 GMT, David Holmes wrote: > @AlanBateman sorry I missed your statement "although these updates aren't strictly needed". Right, I decided it would be better to just update them rather than leaving them at _10. For the management agent then JNI_OnLoad returning any supported version will do as we build/test is separating to the rest of the JDK. Same thing for the tests. Someone back porting changes might have to adjust of course but the isn't important here. ------------- PR: https://git.openjdk.org/jdk19/pull/7 From dcubed at openjdk.java.net Wed Jun 15 19:14:09 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 19:14:09 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 18:52:30 GMT, Patricio Chilano Mateo wrote: >> A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows >> us to add checks to detect failures like: >> >> JDK-8288139 JavaThread touches oop after GC barrier is detached >> https://bugs.openjdk.org/browse/JDK-8288139 >> >> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > I think I would just use the _thread_terminated state rather than introducing a new _thread_gc_barrier_detached state just to detect failures. So the only extra things covered by _thread_gc_barrier_detached and not by _thread_terminated would be ThreadService::remove_thread() which just updates some counters, and ThreadsSMRSupport::remove_thread() which we overlooked before but now by inspection I don't see any other place where we touch oops there. @pchilano - Thanks for the review! Since we've been having issues with oop usage after the GC barrier is detached in several bugs, I was going for the more precise control of adding the new TerminatedTypes value. There is quite a bit of code from: old L3600: `BarrierSet::barrier_set()->on_thread_detach(p);` to old L3623: `p->set_terminated(JavaThread::_thread_terminated);` so rather than have to reason about the code over and over again, I would rather do these sanity checks with targeted code. To paraphrase @robehn: Why do with code inspection what you can do with code? ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.java.net Wed Jun 15 19:46:53 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 19:46:53 GMT Subject: Integrated: 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64 Message-ID: A trivial fix to ProblemList gc/stress/TestStressG1Humongous.java on windows-x64. ------------- Commit messages: - 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64 Changes: https://git.openjdk.org/jdk19/pull/23/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=23&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288526 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/23.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/23/head:pull/23 PR: https://git.openjdk.org/jdk19/pull/23 From psandoz at openjdk.java.net Wed Jun 15 19:46:53 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 15 Jun 2022 19:46:53 GMT Subject: Integrated: 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64 In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 19:34:59 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList gc/stress/TestStressG1Humongous.java on windows-x64. Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/23 From dcubed at openjdk.java.net Wed Jun 15 19:46:53 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 19:46:53 GMT Subject: Integrated: 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64 In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 19:41:07 GMT, Paul Sandoz wrote: >> A trivial fix to ProblemList gc/stress/TestStressG1Humongous.java on windows-x64. > > Marked as reviewed by psandoz (Reviewer). @PaulSandoz - Thanks for the fast review! ------------- PR: https://git.openjdk.org/jdk19/pull/23 From dcubed at openjdk.java.net Wed Jun 15 19:46:54 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 19:46:54 GMT Subject: Integrated: 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64 In-Reply-To: References: Message-ID: <2BRPmO9tZGXyA4HBWTy9IjxX8ulM706IQzt3ET5NjEI=.9b6ef0d7-a78c-478c-b020-0918ecc9e64b@github.com> On Wed, 15 Jun 2022 19:34:59 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList gc/stress/TestStressG1Humongous.java on windows-x64. This pull request has now been integrated. Changeset: 9254e129 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk19/commit/9254e1299374b772c2ea12176a145fb0e91c7fbc Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64 Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/jdk19/pull/23 From rpressler at openjdk.java.net Wed Jun 15 19:57:48 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Wed, 15 Jun 2022 19:57:48 GMT Subject: RFR: 8286103: VThreadMonitorTest fails "assert(!current->cont_fastpath() || (current->cont_fastpath_thread_state() && !interpreted_native_or_deoptimized_on_stack(current))) failed" Message-ID: <9c6zeRBtbGjRpSGqN81OIRPUyLu-ceV-1gRwA1fWs-U=.87df7fc0-ac51-4742-8dd1-8f8d536a7bb8@github.com> Please review the following fix. Detection of a deoptimized frame in thaw was incorrect, as it tested the deoptimization state of a frame object constructed without relevant data. Passes loom tiers 1-5. ------------- Commit messages: - Comment typo - Add comment - Fix detection of deoptimized frame in thaw Changes: https://git.openjdk.org/jdk19/pull/18/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=18&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286103 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/18.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/18/head:pull/18 PR: https://git.openjdk.org/jdk19/pull/18 From sspitsyn at openjdk.java.net Wed Jun 15 19:57:48 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 15 Jun 2022 19:57:48 GMT Subject: RFR: 8286103: VThreadMonitorTest fails "assert(!current->cont_fastpath() || (current->cont_fastpath_thread_state() && !interpreted_native_or_deoptimized_on_stack(current))) failed" In-Reply-To: <9c6zeRBtbGjRpSGqN81OIRPUyLu-ceV-1gRwA1fWs-U=.87df7fc0-ac51-4742-8dd1-8f8d536a7bb8@github.com> References: <9c6zeRBtbGjRpSGqN81OIRPUyLu-ceV-1gRwA1fWs-U=.87df7fc0-ac51-4742-8dd1-8f8d536a7bb8@github.com> Message-ID: <70us5FFEycI7nxOmdkG5oZlz5valvxgA90oUCkc5jso=.6c0a8790-a0d9-416d-8536-7e53faac5af6@github.com> On Wed, 15 Jun 2022 11:00:14 GMT, Ron Pressler wrote: > Please review the following fix. > > Detection of a deoptimized frame in thaw was incorrect, as it tested the deoptimization state of a frame object constructed without relevant data. > > Passes loom tiers 1-5. Nice discovery! It looks good to me. I hope, the test does not fail with this fix anymore. Thanks, Serguei Marked as reviewed by sspitsyn (Reviewer). ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk19/pull/18 From dcubed at openjdk.java.net Wed Jun 15 20:26:47 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 20:26:47 GMT Subject: RFR: 8288530: ProblemList serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java in -Xcomp mode Message-ID: A trivial fix to ProblemList serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java in -Xcomp mode. Humor note: The product bug ID and ProblemList bug ID differ by exactly 100. ------------- Commit messages: - 8288530: ProblemList serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java in -Xcomp mode Changes: https://git.openjdk.org/jdk/pull/9173/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9173&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288530 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9173.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9173/head:pull/9173 PR: https://git.openjdk.org/jdk/pull/9173 From amenkov at openjdk.java.net Wed Jun 15 21:18:02 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 15 Jun 2022 21:18:02 GMT Subject: RFR: 8288530: ProblemList serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java in -Xcomp mode In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 20:18:12 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java in -Xcomp mode. > > Humor note: The product bug ID and ProblemList bug ID differ by exactly 100. Marked as reviewed by amenkov (Reviewer). I agree the fix is trivial ------------- PR: https://git.openjdk.org/jdk/pull/9173 From dcubed at openjdk.java.net Wed Jun 15 21:20:14 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 21:20:14 GMT Subject: RFR: 8288530: ProblemList serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java in -Xcomp mode In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 21:16:00 GMT, Alex Menkov wrote: >> A trivial fix to ProblemList serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java in -Xcomp mode. >> >> Humor note: The product bug ID and ProblemList bug ID differ by exactly 100. > > I agree the fix is trivial @alexmenkov - Thanks for the review! ------------- PR: https://git.openjdk.org/jdk/pull/9173 From dcubed at openjdk.java.net Wed Jun 15 21:22:04 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 21:22:04 GMT Subject: Integrated: 8288530: ProblemList serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java in -Xcomp mode In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 20:18:12 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java in -Xcomp mode. > > Humor note: The product bug ID and ProblemList bug ID differ by exactly 100. This pull request has now been integrated. Changeset: 9ff40346 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/9ff40346dd45ae1607785bb242d9db10562fb99a Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8288530: ProblemList serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java in -Xcomp mode Reviewed-by: amenkov ------------- PR: https://git.openjdk.org/jdk/pull/9173 From amenkov at openjdk.java.net Wed Jun 15 21:23:04 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 15 Jun 2022 21:23:04 GMT Subject: RFR: 8288396: Always create reproducible builds [v5] In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 15:18:04 GMT, Magnus Ihse Bursie wrote: >> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.) >> >> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove incorrect argument > - Test if linker can accept the flag JDI changes look good ------------- Marked as reviewed by amenkov (Reviewer). PR: https://git.openjdk.org/jdk/pull/9152 From dholmes at openjdk.java.net Wed Jun 15 22:25:10 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 15 Jun 2022 22:25:10 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 16:06:08 GMT, Daniel D. Daugherty wrote: > Update SharedRuntime::get_java_tid() to verify that the calling thread is safely > accessing its own threadObj(). This check uses the new is_gc_barrier_detached() > function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). > > The above check was used to reproduce the failure mode without Shenandoah > and the remainder of the fix relocates the offending code from > ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of > removed the 'tid' entry from the ThreadIdTable is still done under the > protection of the Threads_lock. > > This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. src/hotspot/share/runtime/sharedRuntime.cpp line 998: > 996: JRT_END > 997: > 998: jlong SharedRuntime::get_java_tid(Thread* thread) { Additional RFE: can we not declare this to take JavaThread and so avoid the checks and casts below? src/hotspot/share/runtime/thread.cpp line 3603: > 3601: ThreadIdTable::remove_thread(tid); > 3602: } > 3603: I don't like exposing `ThreadSMR` internal details like this. Can we at least make this a little `ThreadSMRSupport` method that we call from here. Or ... can we just move `ThreadsSMRSupport::remove_thread(p);` to before `on_thread_detach`? Or can we grab the pid before `on_thread_detach` and pass it to `ThreadsSMRSupport::remove_thread`? ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dholmes at openjdk.java.net Wed Jun 15 22:33:02 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 15 Jun 2022 22:33:02 GMT Subject: RFR: 8288443: Simplify vmClasses::resolve_all() [v2] In-Reply-To: References: <7AAtR7ty4p7IzqrVh1pGWO0DUyfyNKXLVDqL9Q2A3GI=.b6cf12b5-8db3-413d-9cd5-b43dba381744@github.com> Message-ID: On Wed, 15 Jun 2022 16:24:45 GMT, Ioi Lam wrote: >> Please review this simple clean up: >> >> - There's no need to initialize the JSR 292 classes separately (the `-XX:+EnableInvokeDynamic` option has been removed long time ago). >> - Separate initialization of the reference classes is not necessary when CDS is enabled. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > removed out-dated comments Thanks for the update ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9157 From dholmes at openjdk.java.net Wed Jun 15 22:42:12 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 15 Jun 2022 22:42:12 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 19:12:08 GMT, Daniel D. Daugherty wrote: >> I think I would just use the _thread_terminated state rather than introducing a new _thread_gc_barrier_detached state just to detect failures. So the only extra things covered by _thread_gc_barrier_detached and not by _thread_terminated would be ThreadService::remove_thread() which just updates some counters, and ThreadsSMRSupport::remove_thread() which we overlooked before but now by inspection I don't see any other place where we touch oops there. > > @pchilano - Thanks for the review! > > Since we've been having issues with oop usage after the GC barrier is detached > in several bugs, I was going for the more precise control of adding the new > TerminatedTypes value. There is quite a bit of code from: > > old L3600: `BarrierSet::barrier_set()->on_thread_detach(p);` > > to > > old L3623: `p->set_terminated(JavaThread::_thread_terminated);` > > so rather than have to reason about the code over and over again, > I would rather do these sanity checks with targeted code. To paraphrase > @robehn: Why do with code inspection what you can do with code? @dcubed-ojdk I must admit I'm also not a fan of adding this very specialized interim state into the thread termination states. I would have expected the barrier code itself to be able to detect when `on_thread_detach` had been called, instead of the `JavaThread` having to track that for itself. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dholmes at openjdk.java.net Wed Jun 15 22:43:03 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 15 Jun 2022 22:43:03 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 16:06:08 GMT, Daniel D. Daugherty wrote: > Update SharedRuntime::get_java_tid() to verify that the calling thread is safely > accessing its own threadObj(). This check uses the new is_gc_barrier_detached() > function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). > > The above check was used to reproduce the failure mode without Shenandoah > and the remainder of the fix relocates the offending code from > ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of > removed the 'tid' entry from the ThreadIdTable is still done under the > protection of the Threads_lock. > > This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. src/hotspot/share/runtime/sharedRuntime.cpp line 1003: > 1001: guarantee(current != thread || !JavaThread::cast(thread)->is_gc_barrier_detached(), > 1002: "current cannot touch oops after its GC barrier is detached."); > 1003: oop obj = JavaThread::cast(thread)->threadObj(); I think the oop-touching-safety check should be done in `threadObj()` itself so that all callers are protected. ------------- PR: https://git.openjdk.org/jdk19/pull/21 From iklam at openjdk.java.net Wed Jun 15 22:43:13 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 15 Jun 2022 22:43:13 GMT Subject: RFR: 8288443: Simplify vmClasses::resolve_all() [v2] In-Reply-To: References: <7AAtR7ty4p7IzqrVh1pGWO0DUyfyNKXLVDqL9Q2A3GI=.b6cf12b5-8db3-413d-9cd5-b43dba381744@github.com> Message-ID: On Tue, 14 Jun 2022 23:34:29 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> removed out-dated comments > > Looks good. Thanks @calvinccheung @dholmes-ora @coleenp for the review. Passed tiers 1-4. ------------- PR: https://git.openjdk.org/jdk/pull/9157 From iklam at openjdk.java.net Wed Jun 15 22:43:16 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 15 Jun 2022 22:43:16 GMT Subject: Integrated: 8288443: Simplify vmClasses::resolve_all() In-Reply-To: <7AAtR7ty4p7IzqrVh1pGWO0DUyfyNKXLVDqL9Q2A3GI=.b6cf12b5-8db3-413d-9cd5-b43dba381744@github.com> References: <7AAtR7ty4p7IzqrVh1pGWO0DUyfyNKXLVDqL9Q2A3GI=.b6cf12b5-8db3-413d-9cd5-b43dba381744@github.com> Message-ID: On Tue, 14 Jun 2022 17:54:25 GMT, Ioi Lam wrote: > Please review this simple clean up: > > - There's no need to initialize the JSR 292 classes separately (the `-XX:+EnableInvokeDynamic` option has been removed long time ago). > - Separate initialization of the reference classes is not necessary when CDS is enabled. This pull request has now been integrated. Changeset: 07612281 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/07612281b084de62b6fb9e682184f93316130f41 Stats: 36 lines in 2 files changed: 5 ins; 4 del; 27 mod 8288443: Simplify vmClasses::resolve_all() Reviewed-by: ccheung, dholmes, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/9157 From dcubed at openjdk.java.net Wed Jun 15 23:58:07 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 23:58:07 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 15:44:21 GMT, Daniel D. Daugherty wrote: > A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows > us to add checks to detect failures like: > > JDK-8288139 JavaThread touches oop after GC barrier is detached > https://bugs.openjdk.org/browse/JDK-8288139 > > This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. If the folks that own the barrier code add detection checks there, then this code can be removed in the future. For now, I would like to get this code in so that I can continue to search for additional instances of this type of failure. As for the addition of the _thread_gc_barrier_detached TerminatedTypes value and the location of when that state goes active, it is that new state and it's placement that verified that the code in ThreadsSMRSupport::remove_thread() was in the wrong place (fixed in JDK-8288139). Depending on the _thread_terminated TerminatedTypes value did not and would not have verified that problem. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.java.net Thu Jun 16 00:04:07 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 16 Jun 2022 00:04:07 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 22:12:45 GMT, David Holmes wrote: >> Update SharedRuntime::get_java_tid() to verify that the calling thread is safely >> accessing its own threadObj(). This check uses the new is_gc_barrier_detached() >> function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). >> >> The above check was used to reproduce the failure mode without Shenandoah >> and the remainder of the fix relocates the offending code from >> ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of >> removed the 'tid' entry from the ThreadIdTable is still done under the >> protection of the Threads_lock. >> >> This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > src/hotspot/share/runtime/sharedRuntime.cpp line 998: > >> 996: JRT_END >> 997: >> 998: jlong SharedRuntime::get_java_tid(Thread* thread) { > > Additional RFE: can we not declare this to take JavaThread and so avoid the checks and casts below? I can research that and file a follow up RFE if necessary. > src/hotspot/share/runtime/thread.cpp line 3603: > >> 3601: ThreadIdTable::remove_thread(tid); >> 3602: } >> 3603: > > I don't like exposing `ThreadSMR` internal details like this. Can we at least make this a little `ThreadSMRSupport` method that we call from here. > > Or ... can we just move `ThreadsSMRSupport::remove_thread(p);` to before `on_thread_detach`? > > Or can we grab the pid before `on_thread_detach` and pass it to `ThreadsSMRSupport::remove_thread`? Ummmm... The code that I moved is not a TheadSMR internal detail. That code is part of the M&M support that was added by Daniil in: JDK-8185005 Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) https://bugs.openjdk.org/browse/JDK-8185005 I don't remember why Daniil put that code in ThreadsSMRSupport::remove_thread(p), but it is just as appropriate to put it in Threads::remove(). That M&M cleanup code is part of the cleanup necessary when a JavaThread is removed. The important part is to call that code after the Threads_lock is grabbed. ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dholmes at openjdk.java.net Thu Jun 16 00:06:06 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 16 Jun 2022 00:06:06 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 15:44:21 GMT, Daniel D. Daugherty wrote: > A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows > us to add checks to detect failures like: > > JDK-8288139 JavaThread touches oop after GC barrier is detached > https://bugs.openjdk.org/browse/JDK-8288139 > > This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. Hi Dan, After looking at the barrier code I'm warming up to the proposal you have made, but with a couple of suggestions below. Thanks. src/hotspot/share/runtime/thread.cpp line 3601: > 3599: // requiring the GC state to be alive. > 3600: BarrierSet::barrier_set()->on_thread_detach(p); > 3601: if (p->is_exiting()) { I don't understand why this needs to be conditional? src/hotspot/share/runtime/thread.hpp line 1180: > 1178: bool is_exiting() const; > 1179: // thread's GC barrier is detached or thread is terminated > 1180: bool is_gc_barrier_detached() const; Can we name this based on what it allows (access to oops) rather than what it relates to deep down? e.g. `can_access_oops_safely` or `is_oop_safe` ? src/hotspot/share/runtime/thread.hpp line 1186: > 1184: bool check_is_terminated(TerminatedTypes l_terminated) const { > 1185: return l_terminated != _not_terminated && l_terminated != _thread_exiting && > 1186: l_terminated != _thread_gc_barrier_detached; Existing: I don't think I buy this argument that we need to check all the states we don't want to see rather than the one we do. If the JavaThread has been freed we could see anything - and we should never be executing this code in the first place. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dholmes at openjdk.java.net Thu Jun 16 00:06:09 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 16 Jun 2022 00:06:09 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 15:50:18 GMT, Daniel D. Daugherty wrote: >> A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows >> us to add checks to detect failures like: >> >> JDK-8288139 JavaThread touches oop after GC barrier is detached >> https://bugs.openjdk.org/browse/JDK-8288139 >> >> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > src/hotspot/share/runtime/thread.inline.hpp line 264: > >> 262: inline bool JavaThread::is_exiting() const { >> 263: // Use load-acquire so that setting of _terminated by >> 264: // JavaThread::set_terminated() is seen more quickly. > > This comment should have been updated when the code in > JavaThread::exit() was refactored into JavaThread::set_terminated(). > I'm doing it as part of this fix for clarity. It is a bogus comment - acquire semantics has nothing to do with seeing things more quickly. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.java.net Thu Jun 16 00:08:03 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 16 Jun 2022 00:08:03 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 16:06:08 GMT, Daniel D. Daugherty wrote: > Update SharedRuntime::get_java_tid() to verify that the calling thread is safely > accessing its own threadObj(). This check uses the new is_gc_barrier_detached() > function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). > > The above check was used to reproduce the failure mode without Shenandoah > and the remainder of the fix relocates the offending code from > ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of > removed the 'tid' entry from the ThreadIdTable is still done under the > protection of the Threads_lock. > > This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. @dholmes-ora - Thanks for the review! I think I've replied to everything. Please let me know if I missed something... ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dcubed at openjdk.java.net Thu Jun 16 00:08:06 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 16 Jun 2022 00:08:06 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 22:39:42 GMT, David Holmes wrote: >> Update SharedRuntime::get_java_tid() to verify that the calling thread is safely >> accessing its own threadObj(). This check uses the new is_gc_barrier_detached() >> function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). >> >> The above check was used to reproduce the failure mode without Shenandoah >> and the remainder of the fix relocates the offending code from >> ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of >> removed the 'tid' entry from the ThreadIdTable is still done under the >> protection of the Threads_lock. >> >> This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > src/hotspot/share/runtime/sharedRuntime.cpp line 1003: > >> 1001: guarantee(current != thread || !JavaThread::cast(thread)->is_gc_barrier_detached(), >> 1002: "current cannot touch oops after its GC barrier is detached."); >> 1003: oop obj = JavaThread::cast(thread)->threadObj(); > > I think the oop-touching-safety check should be done in `threadObj()` itself so that all callers are protected. The placement in SharedRuntime::get_java_tid() is because that is the failure mode that this bug is about. My next stress testing experiment will be to put a similar guarantee() in threadObj(), but I expect there to be more fan-out from that placement. This fix is tightly focued on the bug as it is reported because I plan to fix it in JDK19. ------------- PR: https://git.openjdk.org/jdk19/pull/21 From stuefe at openjdk.java.net Thu Jun 16 05:57:04 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 16 Jun 2022 05:57:04 GMT Subject: RFR: JDK-8287011: Improve container information [v5] In-Reply-To: <4n2ej21Q2mTKnTNSPZ87PuCWEfYILveN8MXOp9uZoi4=.999d5182-efc0-463a-9131-fa5644ed5bbc@github.com> References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> <4n2ej21Q2mTKnTNSPZ87PuCWEfYILveN8MXOp9uZoi4=.999d5182-efc0-463a-9131-fa5644ed5bbc@github.com> Message-ID: On Wed, 15 Jun 2022 11:37:36 GMT, Matthias Baesken wrote: >> The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Introduce print_version_specific_info src/hotspot/os/linux/osContainer_linux.hpp line 48: > 46: static void print_version_specific_info(outputStream* st); > 47: static void print_container_helper(outputStream* st, jlong j, const char* metrics); > 48: hpp file needs forward declaration of outputStream now, or include ostream.hpp, otherwise you break files that include this header but not ostream. ------------- PR: https://git.openjdk.org/jdk/pull/8991 From duke at openjdk.java.net Thu Jun 16 06:56:39 2022 From: duke at openjdk.java.net (Dmitry Kulikov) Date: Thu, 16 Jun 2022 06:56:39 GMT Subject: RFR: 8288005: HotSpot build with disabled PCH fails for Windows AArch64 Message-ID: Added a header file include that fixes HotSpot build with disabled PCH for Windows AArch64. Build successfully tested on Windows 10 x86_64 machine: * with Visual Studio 2019 for AArch64 cross-compile, * with Visual Studio 2017 & 2019 for x86_64 build. Running tests on Windows and other platforms showed no regression after this patch. ------------- Commit messages: - 8288005: HotSpot build with disabled PCH fails for Windows AArch64 Changes: https://git.openjdk.org/jdk/pull/9178/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9178&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288005 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9178.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9178/head:pull/9178 PR: https://git.openjdk.org/jdk/pull/9178 From shade at openjdk.java.net Thu Jun 16 07:14:01 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 16 Jun 2022 07:14:01 GMT Subject: RFR: 8288005: HotSpot build with disabled PCH fails for Windows AArch64 In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 06:50:15 GMT, Dmitry Kulikov wrote: > Added a header file include that fixes HotSpot build with disabled PCH for Windows AArch64. > Build successfully tested on Windows 10 x86_64 machine: > * with Visual Studio 2019 for AArch64 cross-compile, > * with Visual Studio 2017 & 2019 for x86_64 build. > > Running tests on Windows and other platforms showed no regression after this patch. Looks fine and trivial. I wonder if we should switch Windows AArch64 GHA to disabled PCH... ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9178 From stuefe at openjdk.java.net Thu Jun 16 07:19:07 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 16 Jun 2022 07:19:07 GMT Subject: RFR: 8288005: HotSpot build with disabled PCH fails for Windows AArch64 In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 07:09:18 GMT, Aleksey Shipilev wrote: > I wonder if we should switch Windows AArch64 GHA to disabled PCH... I'm for it, but IIRC the argument was that it takes too long. Do we do the Intel builds without pch? ------------- PR: https://git.openjdk.org/jdk/pull/9178 From shade at openjdk.java.net Thu Jun 16 07:19:07 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 16 Jun 2022 07:19:07 GMT Subject: RFR: 8288005: HotSpot build with disabled PCH fails for Windows AArch64 In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 07:15:32 GMT, Thomas Stuefe wrote: > I'm for it, but IIRC the argument was that it takes too long. Do we do the Intel builds without pch? Ah yes, I remember this, MSVC without PCH has a large hit. We build Linux no-pch hotspot only. ------------- PR: https://git.openjdk.org/jdk/pull/9178 From eosterlund at openjdk.java.net Thu Jun 16 07:20:07 2022 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 16 Jun 2022 07:20:07 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 15:44:21 GMT, Daniel D. Daugherty wrote: > A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows > us to add checks to detect failures like: > > JDK-8288139 JavaThread touches oop after GC barrier is detached > https://bugs.openjdk.org/browse/JDK-8288139 > > This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. I have also been bitten before by oops being touched at the boundaries of the thread life cycle, so I understand why we would want to be more precise about modelling this in the thread life cycle. The only thing I don't understand with the patch is why there are two alternative state machines now. One that goes through the new state and one that does not go through the new state. There might be a good reason for that, but I would like to understand why that is. And probably have that written in a comment where the two state machines are described. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From kbarrett at openjdk.java.net Thu Jun 16 07:25:01 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 16 Jun 2022 07:25:01 GMT Subject: RFR: 8288005: HotSpot build with disabled PCH fails for Windows AArch64 In-Reply-To: References: Message-ID: <-CR3bA4SlRqYA9GmPlmIvIfavrDYBgaQaN550uM_2QA=.029d1a52-037b-44ac-bed8-d5267d2463ed@github.com> On Thu, 16 Jun 2022 06:50:15 GMT, Dmitry Kulikov wrote: > Added a header file include that fixes HotSpot build with disabled PCH for Windows AArch64. > Build successfully tested on Windows 10 x86_64 machine: > * with Visual Studio 2019 for AArch64 cross-compile, > * with Visual Studio 2017 & 2019 for x86_64 build. > > Running tests on Windows and other platforms showed no regression after this patch. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9178 From rehn at openjdk.java.net Thu Jun 16 07:33:03 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 16 Jun 2022 07:33:03 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 15:44:21 GMT, Daniel D. Daugherty wrote: > A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows > us to add checks to detect failures like: > > JDK-8288139 JavaThread touches oop after GC barrier is detached > https://bugs.openjdk.org/browse/JDK-8288139 > > This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. Hi, Except for the few lines of code between: BarrierSet::barrier_set()->on_thread_detach(p) and ThreadsSMRSupport::remove(); This new state is identical to the result of "ThreadsSMRSupport::get_java_thread_list()->includes(p)". The JavaThread is attached to the barrier set when we add it to the ThreadsList and detached when we remove it. If we have a safepoint poll between (done with Threads_lock held): BarrierSet::barrier_set()->on_thread_detach(p); -> p->set_terminated(JavaThread::_thread_terminated); We have a bug. This means that this new state is not even possible to observe from another thread (with target safe). So for any other thread there is no difference, which means we have new global state just for a few lines of code while we are terminating with Threads_lock held. So I don't think this one place needs a new global state. Note that for a safe target thread the terminated flag gives the same result as: "ThreadsSMRSupport::get_java_thread_list()->includes(p)" So jt->is_terminated() can be implemented with "ThreadsSMRSupport::get_java_thread_list()->includes(p)". (again assuming we are not doing some racy, and only asking for threads that are safe/stable) ------------- PR: https://git.openjdk.org/jdk19/pull/20 From rehn at openjdk.java.net Thu Jun 16 07:51:07 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 16 Jun 2022 07:51:07 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 16:06:08 GMT, Daniel D. Daugherty wrote: > Update SharedRuntime::get_java_tid() to verify that the calling thread is safely > accessing its own threadObj(). This check uses the new is_gc_barrier_detached() > function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). > > The above check was used to reproduce the failure mode without Shenandoah > and the remainder of the fix relocates the offending code from > ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of > removed the 'tid' entry from the ThreadIdTable is still done under the > protection of the Threads_lock. > > This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. Hi After we have done: if (JvmtiEnv::environments_might_exist()) { JvmtiExport::cleanup_thread(this); } I don't think there is any valid use case of ThreadIdTable. So can't we just remove the thread from the table here instead: I.e. if (JvmtiEnv::environments_might_exist()) { JvmtiExport::cleanup_thread(this); } if (ThreadIdTable::is_initialized()) { jlong tid = SharedRuntime::get_java_tid(thread); ThreadIdTable::remove_thread(tid); } ? ------------- PR: https://git.openjdk.org/jdk19/pull/21 From stuefe at openjdk.java.net Thu Jun 16 07:57:28 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 16 Jun 2022 07:57:28 GMT Subject: RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside Message-ID: The VM uses SIGUSR2 (can be overridden via _JAVA_SR_SIGNUM) to implement suspend/resume on java threads. It sends, via pthread_kill, SIGUSR2 to targeted threads to interrupt them. It knows the target thread, and the target thread is always a VM-attached thread. However, if SIGUSR2 gets sent from outside, any thread may receive the signal, and if the target thread is not attached to the VM (e.g. primordial), it is unable to handle it. The result is an assert (debug VM) or a crash (release VM). On my box, this can be reliably reproduced by sending SIGUSR2 to any VM. This has been discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2022-June/091450.html The proposed solutions range from "works as designed" (on the ground that sending arbitrary signals to the JVM is an error in itself, and we should rather crash hard and fast) to "lets catch and ignore the signal". ---- In this patch I opt for: - Debug: keep asserting, but make the message more helpful by including signal info for the stray SR signal. Includes sender pid and signal number (in case SR signal had been overridden). # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/shared/projects/openjdk/jdk-jdk/source/src/hotspot/os/posix/signals_posix.cpp:1611), pid=139712, tid=139712 # assert(thread != __null) failed: Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 6681, si_uid: 1027).. - Release: write a message to tty about this signal, including sender pid and signal name. Otherwise, ignore the signal, dont crash. Repeated signals will generate repeated output: thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -cp $REPROS_JAR de.stuefe.repros.Simple Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239773, si_uid: 1027). Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239774, si_uid: 1027). Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239775, si_uid: 1027). Notes: - In release builds, we also could quit the VM instead of continuing. I prefer gracefully ignoring the signal, because in our experience quitting - regardless of how good the diagnostic message is - often just leads to frustrated users complaining about VMs mysteriously vanishing. Same goes for crashes, it just pools into the general "java is unstable" notion. I'm open for discussing this. - I use tty for the diagnostic message, which goes to stdout. I really dislike that, error output should go to stderr. But since the rest of the VM handles diagnostic output the same way, I use tty here too. Thanks, Thomas ------------- Commit messages: - small corrections - SIGUSR2 crash Changes: https://git.openjdk.org/jdk/pull/9181/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9181&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288556 Stats: 16 lines in 1 file changed: 15 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9181.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9181/head:pull/9181 PR: https://git.openjdk.org/jdk/pull/9181 From duke at openjdk.java.net Thu Jun 16 08:15:13 2022 From: duke at openjdk.java.net (Dmitry Kulikov) Date: Thu, 16 Jun 2022 08:15:13 GMT Subject: RFR: 8288005: HotSpot build with disabled PCH fails for Windows AArch64 In-Reply-To: References: Message-ID: <0ZGDtIi3m5C1-yvYZGmVcmwqBtPTTsehS75oazYuVHI=.efeacdea-7c03-4637-abd5-9663d3869e9c@github.com> On Thu, 16 Jun 2022 06:50:15 GMT, Dmitry Kulikov wrote: > Added a header file include that fixes HotSpot build with disabled PCH for Windows AArch64. > Build successfully tested on Windows 10 x86_64 machine: > * with Visual Studio 2019 for AArch64 cross-compile, > * with Visual Studio 2017 & 2019 for x86_64 build. > > Running tests on Windows and other platforms showed no regression after this patch. Thank you for the review! ------------- PR: https://git.openjdk.org/jdk/pull/9178 From duke at openjdk.java.net Thu Jun 16 08:15:15 2022 From: duke at openjdk.java.net (Dmitry Kulikov) Date: Thu, 16 Jun 2022 08:15:15 GMT Subject: RFR: 8288005: HotSpot build with disabled PCH fails for Windows AArch64 In-Reply-To: References: Message-ID: <4tNmU8XHdXQZUbZnitLKMu6aCLQ09DVp9neR2hFrIvw=.826c222e-b9d0-4d4c-b8a4-f958c4c00646@github.com> On Thu, 16 Jun 2022 07:17:05 GMT, Aleksey Shipilev wrote: >>> I wonder if we should switch Windows AArch64 GHA to disabled PCH... >> >> I'm for it, but IIRC the argument was that it takes too long. Do we do the Intel builds without pch? > >> I'm for it, but IIRC the argument was that it takes too long. Do we do the Intel builds without pch? > > Ah yes, I remember this, MSVC without PCH has a large hit. We build Linux no-pch hotspot only. @shipilev @kimbarrett could you please sponsor this PR? ------------- PR: https://git.openjdk.org/jdk/pull/9178 From shade at openjdk.java.net Thu Jun 16 08:15:16 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 16 Jun 2022 08:15:16 GMT Subject: RFR: 8288005: HotSpot build with disabled PCH fails for Windows AArch64 In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 06:50:15 GMT, Dmitry Kulikov wrote: > Added a header file include that fixes HotSpot build with disabled PCH for Windows AArch64. > Build successfully tested on Windows 10 x86_64 machine: > * with Visual Studio 2019 for AArch64 cross-compile, > * with Visual Studio 2017 & 2019 for x86_64 build. > > Running tests on Windows and other platforms showed no regression after this patch. Well, GHA is a bit misbehaving this morning, and I would have liked to see a clean run there. But I think it is going to be fine, as many targets have actually completed the build. ------------- PR: https://git.openjdk.org/jdk/pull/9178 From duke at openjdk.java.net Thu Jun 16 08:15:17 2022 From: duke at openjdk.java.net (Dmitry Kulikov) Date: Thu, 16 Jun 2022 08:15:17 GMT Subject: Integrated: 8288005: HotSpot build with disabled PCH fails for Windows AArch64 In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 06:50:15 GMT, Dmitry Kulikov wrote: > Added a header file include that fixes HotSpot build with disabled PCH for Windows AArch64. > Build successfully tested on Windows 10 x86_64 machine: > * with Visual Studio 2019 for AArch64 cross-compile, > * with Visual Studio 2017 & 2019 for x86_64 build. > > Running tests on Windows and other platforms showed no regression after this patch. This pull request has now been integrated. Changeset: b2a58bec Author: Dmitry Kulikov Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/b2a58bec4a4f70a06b23013cc4c351b36a413521 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8288005: HotSpot build with disabled PCH fails for Windows AArch64 Reviewed-by: shade, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/9178 From zgu at openjdk.org Thu Jun 16 12:31:19 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 16 Jun 2022 12:31:19 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 15:44:21 GMT, Daniel D. Daugherty wrote: > A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows > us to add checks to detect failures like: > > JDK-8288139 JavaThread touches oop after GC barrier is detached > https://bugs.openjdk.org/browse/JDK-8288139 > > This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. Just a suggestion: I believe adding thread state check in Thread::gc_data() method helps to catch this problem in the future, as the gc_data is usually accessed by GC barrier ... ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dholmes at openjdk.org Thu Jun 16 12:49:19 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 16 Jun 2022 12:49:19 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 00:04:04 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/sharedRuntime.cpp line 1003: >> >>> 1001: guarantee(current != thread || !JavaThread::cast(thread)->is_gc_barrier_detached(), >>> 1002: "current cannot touch oops after its GC barrier is detached."); >>> 1003: oop obj = JavaThread::cast(thread)->threadObj(); >> >> I think the oop-touching-safety check should be done in `threadObj()` itself so that all callers are protected. > > The placement in SharedRuntime::get_java_tid() is because that is the failure > mode that this bug is about. My next stress testing experiment will be to put > a similar guarantee() in threadObj(), but I expect there to be more fan-out > from that placement. > > This fix is tightly focued on the bug as it is reported because I plan to fix > it in JDK19. Yeah ... hmmm ... threadObj is still the better place for any safety check ... arguably it should be even deeper in OopHandle. I'm not sure what fanout you are concerned about. If we find there are other invalid oop accesses then we would want to fix them in 19 - no? >> src/hotspot/share/runtime/thread.cpp line 3603: >> >>> 3601: ThreadIdTable::remove_thread(tid); >>> 3602: } >>> 3603: >> >> I don't like exposing `ThreadSMR` internal details like this. Can we at least make this a little `ThreadSMRSupport` method that we call from here. >> >> Or ... can we just move `ThreadsSMRSupport::remove_thread(p);` to before `on_thread_detach`? >> >> Or can we grab the pid before `on_thread_detach` and pass it to `ThreadsSMRSupport::remove_thread`? > > Ummmm... The code that I moved is not a TheadSMR internal detail. That code > is part of the M&M support that was added by Daniil in: > > JDK-8185005 Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) > https://bugs.openjdk.org/browse/JDK-8185005 > > I don't remember why Daniil put that code in ThreadsSMRSupport::remove_thread(p), > but it is just as appropriate to put it in Threads::remove(). That M&M cleanup code > is part of the cleanup necessary when a JavaThread is removed. The important part > is to call that code after the Threads_lock is grabbed. Thanks Dan, I had forgotten about that and just assumed it was ThreadSMR related. Moving it as you did is now not a concern. ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dcubed at openjdk.org Thu Jun 16 15:55:47 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 16 Jun 2022 15:55:47 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 15:44:21 GMT, Daniel D. Daugherty wrote: > A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows > us to add checks to detect failures like: > > JDK-8288139 JavaThread touches oop after GC barrier is detached > https://bugs.openjdk.org/browse/JDK-8288139 > > This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. Wow! Okay I'm no longer considering this to be a trivial fix. I'll update the description in a second... @dholmes-ora, @fisk, @robehn and @zhengyu123 - Thanks for chiming in on this review. Obviously it will take me a bit of time to navigate this variety of comments and figure out a way forward. On the plus side, My Mach5 Tier8 is down to 11 of the usual 48 24H tasks and so far there are no failures. So the testing on this fix (JDK-8288497) and JDK-8288139 is look just dandy! ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Thu Jun 16 16:16:59 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 16 Jun 2022 16:16:59 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 23:48:44 GMT, David Holmes wrote: >> A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows >> us to add checks to detect failures like: >> >> JDK-8288139 JavaThread touches oop after GC barrier is detached >> https://bugs.openjdk.org/browse/JDK-8288139 >> >> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > src/hotspot/share/runtime/thread.cpp line 3601: > >> 3599: // requiring the GC state to be alive. >> 3600: BarrierSet::barrier_set()->on_thread_detach(p); >> 3601: if (p->is_exiting()) { > > I don't understand why this needs to be conditional? The "normal" transitions for a JavaThread's _terminated field are: _not_terminated => _thread_exiting => _thread_gc_barrier_detached => _thread_terminated The transitions for a JavaThread that failed to attach are: _not_terminated => _thread_terminated because that JavaThread does not calls JavaThread::exit(). If we try to take the attach failing JavaThread thru _thread_gc_barrier_detached, then some of the counter code will be unhappy and we'll see assertion failures. > src/hotspot/share/runtime/thread.hpp line 1180: > >> 1178: bool is_exiting() const; >> 1179: // thread's GC barrier is detached or thread is terminated >> 1180: bool is_gc_barrier_detached() const; > > Can we name this based on what it allows (access to oops) rather than what it relates to deep down? e.g. `can_access_oops_safely` or `is_oop_safe` ? We can definitely rename, but naming is hard... :-) Those names you proposed are inversions of the current name and would require that the logic of the function be inverted. The other names I came up before I settled on is_gc_barrier_detached(): can_no_longer_access_oops() oops_are_no_longer_safe() cannot_safely_access_oops() The closest match between your proposed names and mine are: `can_access_oops_safely` and `cannot_safely_access_oops` Other opinions are welcome. > src/hotspot/share/runtime/thread.hpp line 1186: > >> 1184: bool check_is_terminated(TerminatedTypes l_terminated) const { >> 1185: return l_terminated != _not_terminated && l_terminated != _thread_exiting && >> 1186: l_terminated != _thread_gc_barrier_detached; > > Existing: I don't think I buy this argument that we need to check all the states we don't want to see rather than the one we do. If the JavaThread has been freed we could see anything - and we should never be executing this code in the first place. The logic style of this function is a carry over from before we had Thread-SMR and we tried to detect a freed JavaThread. With Thread-SMR, we don't need to do the check this way at all. Do we really want to change that as part of this fix for JDK19? ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Thu Jun 16 16:17:00 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 16 Jun 2022 16:17:00 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 15:55:21 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/thread.cpp line 3601: >> >>> 3599: // requiring the GC state to be alive. >>> 3600: BarrierSet::barrier_set()->on_thread_detach(p); >>> 3601: if (p->is_exiting()) { >> >> I don't understand why this needs to be conditional? > > The "normal" transitions for a JavaThread's _terminated field are: > > _not_terminated => _thread_exiting => _thread_gc_barrier_detached => _thread_terminated > > The transitions for a JavaThread that failed to attach are: > > _not_terminated => _thread_terminated > > because that JavaThread does not calls JavaThread::exit(). If we try to take > the attach failing JavaThread thru _thread_gc_barrier_detached, then some > of the counter code will be unhappy and we'll see assertion failures. I just dug up my testing notes: gc/g1/ihop/TestIHOPStatic.java fails in fastdebug and slowdebug: # Internal Error (/System/Volumes/Data/work/shared/bug_hunt/8288139_for_jdk19.git/open/src/hotspot/share/services/threadService.cpp:177), pid=3359, tid=5891 # assert(_live_threads_count->get_value() > count) failed: thread count mismatch 6 : 6 So the purpose of the condition is so that an attach failing JavaThread has the same transitions that it always had. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Thu Jun 16 16:17:03 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 16 Jun 2022 16:17:03 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 23:59:50 GMT, David Holmes wrote: >> src/hotspot/share/runtime/thread.inline.hpp line 264: >> >>> 262: inline bool JavaThread::is_exiting() const { >>> 263: // Use load-acquire so that setting of _terminated by >>> 264: // JavaThread::set_terminated() is seen more quickly. >> >> This comment should have been updated when the code in >> JavaThread::exit() was refactored into JavaThread::set_terminated(). >> I'm doing it as part of this fix for clarity. > > It is a bogus comment - acquire semantics has nothing to do with seeing things more quickly. I'm pretty sure that I wrote the original comment and you were one of my reviewers way, way back then. When we were trying to match up the load-acquires in the accessors with the in-line release-store code in JavaThread::exit(), the comment was needed (ignoring the part about "seeing things more quickly"). Now that we have load-acquires in the accessors and a release-store in the setter, i.e., no more in-line code in JavaThread::exit(), I no longer think we need a comment to coordinate. I'm in favor of dropping all instances of this comment. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Thu Jun 16 16:17:05 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 16 Jun 2022 16:17:05 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: <41JGpwkhvtvgmHOf-DKZUwGL8nm7tsjneLoSKMh7V5U=.caa82313-aa29-44ac-a1ce-c036890feec1@github.com> On Wed, 15 Jun 2022 15:51:13 GMT, Daniel D. Daugherty wrote: >> A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows >> us to add checks to detect failures like: >> >> JDK-8288139 JavaThread touches oop after GC barrier is detached >> https://bugs.openjdk.org/browse/JDK-8288139 >> >> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > src/hotspot/share/runtime/thread.inline.hpp line 281: > >> 279: inline bool JavaThread::is_terminated() const { >> 280: // Use load-acquire so that setting of _terminated by >> 281: // JavaThread::set_terminated() is seen more quickly. > > This comment should have been updated when the code in > JavaThread::exit() was refactored into JavaThread::set_terminated(). > I'm doing it as part of this fix for clarity. See above discussion about this comment. I'm in favor of dropping this comment. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Thu Jun 16 16:33:46 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 16 Jun 2022 16:33:46 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 07:16:18 GMT, Erik ?sterlund wrote: >> A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows >> us to add checks to detect failures like: >> >> JDK-8288139 JavaThread touches oop after GC barrier is detached >> https://bugs.openjdk.org/browse/JDK-8288139 >> >> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > I have also been bitten before by oops being touched at the boundaries of the thread life cycle, so I understand why we would want to be more precise about modelling this in the thread life cycle. The only thing I don't understand with the patch is why there are two alternative state machines now. One that goes through the new state and one that does not go through the new state. There might be a good reason for that, but I would like to understand why that is. And probably have that written in a comment where the two state machines are described. @fisk's comment from above: > The only thing I don't understand with the patch is why there are two alternative > state machines now. One that goes through the new state and one that does not > go through the new state. There might be a good reason for that, but I would like > to understand why that is. And probably have that written in a comment where > the two state machines are described. There used to be (at least) three alternative state machines. There were two in JavaThread::exit() and the failing JNI attach is the third. There might be more, but I haven't found them yet. [JDK-8286830](https://bugs.openjdk.org/browse/JDK-8286830) ~HandshakeState should not touch oops changed JavaThread::exit() so we no longer had a path that called current_thread_exiting() and another path that did not call current_thread_exiting(). Currently we only document the one state machine. I should probably fix that. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Thu Jun 16 16:36:53 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 16 Jun 2022 16:36:53 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 12:29:13 GMT, Zhengyu Gu wrote: >> A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows >> us to add checks to detect failures like: >> >> JDK-8288139 JavaThread touches oop after GC barrier is detached >> https://bugs.openjdk.org/browse/JDK-8288139 >> >> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Just a suggestion: I believe adding thread state check in Thread::gc_data() method helps to catch this problem in the future, as the gc_data is usually accessed by GC barrier ... @zhengyu123's comment from above: > Just a suggestion: I believe adding thread state check in Thread::gc_data() > method helps to catch this problem in the future, as the gc_data is usually > accessed by GC barrier ... I think we (Runtime) are hoping that the GC folks add something specific that is intended to catch these kind of problems. If that happens, then this hack that I'm doing now can be retired. Adding a "thread state" check to Thread::gc_data() might be the solution, but I would feel more comfortable if that change was made by GC folks that know this barrier stuff. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Thu Jun 16 16:44:45 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 16 Jun 2022 16:44:45 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 12:45:21 GMT, David Holmes wrote: >> The placement in SharedRuntime::get_java_tid() is because that is the failure >> mode that this bug is about. My next stress testing experiment will be to put >> a similar guarantee() in threadObj(), but I expect there to be more fan-out >> from that placement. >> >> This fix is tightly focued on the bug as it is reported because I plan to fix >> it in JDK19. > > Yeah ... hmmm ... threadObj is still the better place for any safety check ... arguably it should be even deeper in OopHandle. > > I'm not sure what fanout you are concerned about. If we find there are other invalid oop accesses then we would want to fix them in 19 - no? I want to fix this bug in JDK19 since it is a blocker for @zhengyu123. I want to keep this fix small and focused on the exact crash associated with the bug. Yes, threadObj() or deeper is a better place. No argument, but I plan to do that as a new hunt and I expect there to be many problems and I don't want to hold up this fix for additional hunting. If I find more issues, then we'll determine how to get them fixed in JDK19. ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dcubed at openjdk.org Thu Jun 16 16:49:46 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 16 Jun 2022 16:49:46 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 16:06:08 GMT, Daniel D. Daugherty wrote: > Update SharedRuntime::get_java_tid() to verify that the calling thread is safely > accessing its own threadObj(). This check uses the new is_gc_barrier_detached() > function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). > > The above check was used to reproduce the failure mode without Shenandoah > and the remainder of the fix relocates the offending code from > ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of > removed the 'tid' entry from the ThreadIdTable is still done under the > protection of the Threads_lock. > > This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. The ThreadIdTable::remove_thread() call has to be done under the protection of the Threads_lock if I remember correctly and the Threads_lock is not held at that point in the code. There's some race condition with the other code where I updated the comments. ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dcubed at openjdk.org Thu Jun 16 17:06:48 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 16 Jun 2022 17:06:48 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 07:29:34 GMT, Robbin Ehn wrote: >> A trivial fix to add support for JavaThread::is_gc_barrier_detached() which allows >> us to add checks to detect failures like: >> >> JDK-8288139 JavaThread touches oop after GC barrier is detached >> https://bugs.openjdk.org/browse/JDK-8288139 >> >> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Hi, > > Except for the few lines of code between: > BarrierSet::barrier_set()->on_thread_detach(p) and ThreadsSMRSupport::remove(); > > This new state is identical to the result of "ThreadsSMRSupport::get_java_thread_list()->includes(p)". > The JavaThread is attached to the barrier set when we add it to the ThreadsList and detached when we remove it. > > If we have a safepoint poll between (done with Threads_lock held): > BarrierSet::barrier_set()->on_thread_detach(p); > -> > p->set_terminated(JavaThread::_thread_terminated); > > We have a bug. This means that this new state is not even possible to observe from another thread (with target safe). > So for any other thread there is no difference, which means we have new global state just for a few lines of code while we are terminating with Threads_lock held. > > So I don't think this one place needs a new global state. > > Note that for a safe target thread the terminated flag gives the same result as: > "ThreadsSMRSupport::get_java_thread_list()->includes(p)" > > So jt->is_terminated() can be implemented with "ThreadsSMRSupport::get_java_thread_list()->includes(p)". (again assuming we are not doing some racy, and only asking for threads that are safe/stable) @robehn's comment from above: > Except for the few lines of code between: > BarrierSet::barrier_set()->on_thread_detach(p) and ThreadsSMRSupport::remove(); > > This new state is identical to the result of "ThreadsSMRSupport::get_java_thread_list()->includes(p)". No it's not equivalent. If I replace is_gc_barrier_attached()'s implementation with your check, then it would NOT catch the code that's in the wrong place and is being fixed by JDK-8288139. Setting the new _terminated field state exactly where I do so in this fix is what allowed me to prove that the code that I moved in JDK-8288139 is in the wrong place. > This means that this new state is not even possible to observe from another thread (with target safe). This new state is NOT for another thread to use. This new state is for the calling thread to use to make sure that it doesn't use oops after the GC barrier is detached. > So I don't think this one place needs a new global state. Not for the long term. @dholmes-ora and I are hoping that the GC folks eventually add some logic in the GC subsystem that catches this condition. If that is done, then the this is_gc_barrier_detached() support code can all be removed. > Note that for a safe target thread the terminated flag gives the same result as: > "ThreadsSMRSupport::get_java_thread_list()->includes(p)" > > So jt->is_terminated() can be implemented with "ThreadsSMRSupport::get_java_thread_list()->includes(p)". > (again assuming we are not doing some racy, and only asking for threads that are safe/stable) I don't think we want to retire the _terminated field in this bug fix. And the replacement code is much more expensive as the ThreadsList grows due to the search time. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From iklam at openjdk.org Thu Jun 16 19:14:21 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 16 Jun 2022 19:14:21 GMT Subject: RFR: 8288601: Consolidate static/dynamic archive tables Message-ID: Please review this small clean-up of almost identical code that handles the tables for the static and dynamic archives. ------------- Commit messages: - 8288601: Consolidate static/dynamic archive tables Changes: https://git.openjdk.org/jdk/pull/9190/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9190&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288601 Stats: 115 lines in 5 files changed: 35 ins; 42 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/9190.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9190/head:pull/9190 PR: https://git.openjdk.org/jdk/pull/9190 From dcubed at openjdk.org Thu Jun 16 20:30:51 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 16 Jun 2022 20:30:51 GMT Subject: RFR: 8288497: add support for JavaThread::is_gc_barrier_detached() [v2] In-Reply-To: References: Message-ID: <1E0lM4hNfMhCJh0QnpniURqMIFd3XgI2mUdFMFTrDF0=.8d3b7f2a-ef78-4f89-aa13-d56a2d8c0029@github.com> > A fix to add support for JavaThread::is_gc_barrier_detached() which allows > us to add checks to detect failures like: > > JDK-8288139 JavaThread touches oop after GC barrier is detached > https://bugs.openjdk.org/browse/JDK-8288139 > > This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Resolve some code review comments on v00. - Merge branch 'master' into JDK-8288497 - 8288497: add support for JavaThread::is_gc_barrier_detached() ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/20/files - new: https://git.openjdk.org/jdk19/pull/20/files/fb181ab4..24ecdea4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=20&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=20&range=00-01 Stats: 362 lines in 27 files changed: 230 ins; 59 del; 73 mod Patch: https://git.openjdk.org/jdk19/pull/20.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/20/head:pull/20 PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Thu Jun 16 21:11:00 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 16 Jun 2022 21:11:00 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v2] In-Reply-To: References: Message-ID: > Update SharedRuntime::get_java_tid() to verify that the calling thread is safely > accessing its own threadObj(). This check uses the new is_gc_barrier_detached() > function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). > > The above check was used to reproduce the failure mode without Shenandoah > and the remainder of the fix relocates the offending code from > ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of > removed the 'tid' entry from the ThreadIdTable is still done under the > protection of the Threads_lock. > > This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - update after 8288497 v00 code review changes - Merge branch 'JDK-8288497' into JDK-8288139 - 8288139: JavaThread touches oop after GC barrier is detached ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/21/files - new: https://git.openjdk.org/jdk19/pull/21/files/515b381e..1811bc14 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=21&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=21&range=00-01 Stats: 363 lines in 28 files changed: 230 ins; 59 del; 74 mod Patch: https://git.openjdk.org/jdk19/pull/21.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/21/head:pull/21 PR: https://git.openjdk.org/jdk19/pull/21 From dholmes at openjdk.org Fri Jun 17 00:56:55 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Jun 2022 00:56:55 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v2] In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 21:11:00 GMT, Daniel D. Daugherty wrote: >> Update SharedRuntime::get_java_tid() to verify that the calling thread is safely >> accessing its own threadObj(). This check uses the new is_gc_barrier_detached() >> function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). >> >> The above check was used to reproduce the failure mode without Shenandoah >> and the remainder of the fix relocates the offending code from >> ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of >> removed the 'tid' entry from the ThreadIdTable is still done under the >> protection of the Threads_lock. >> >> This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - update after 8288497 v00 code review changes > - Merge branch 'JDK-8288497' into JDK-8288139 > - 8288139: JavaThread touches oop after GC barrier is detached Thanks Dan. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk19/pull/21 From dholmes at openjdk.org Fri Jun 17 00:56:56 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Jun 2022 00:56:56 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v2] In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 16:40:31 GMT, Daniel D. Daugherty wrote: >> Yeah ... hmmm ... threadObj is still the better place for any safety check ... arguably it should be even deeper in OopHandle. >> >> I'm not sure what fanout you are concerned about. If we find there are other invalid oop accesses then we would want to fix them in 19 - no? > > I want to fix this bug in JDK19 since it is a blocker for @zhengyu123. I want to > keep this fix small and focused on the exact crash associated with the bug. > > Yes, threadObj() or deeper is a better place. No argument, but I plan to do that > as a new hunt and I expect there to be many problems and I don't want to hold > up this fix for additional hunting. If I find more issues, then we'll determine how > to get them fixed in JDK19. Okay ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dholmes at openjdk.org Fri Jun 17 01:05:47 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 17 Jun 2022 01:05:47 GMT Subject: RFR: 8288497: add support for JavaThread::cannot_access_oops_safely() [v2] In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 16:03:53 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/thread.hpp line 1180: >> >>> 1178: bool is_exiting() const; >>> 1179: // thread's GC barrier is detached or thread is terminated >>> 1180: bool is_gc_barrier_detached() const; >> >> Can we name this based on what it allows (access to oops) rather than what it relates to deep down? e.g. `can_access_oops_safely` or `is_oop_safe` ? > > We can definitely rename, but naming is hard... :-) > > Those names you proposed are inversions of the current name and would > require that the logic of the function be inverted. > > The other names I came up before I settled on is_gc_barrier_detached(): > > > can_no_longer_access_oops() > oops_are_no_longer_safe() > cannot_safely_access_oops() > > > The closest match between your proposed names and mine are: > > `can_access_oops_safely` and `cannot_safely_access_oops` > > Other opinions are welcome. I think the style guide for naming is to use positive names to avoid double negatives when you have to negate the function - so `is_safe_for_x` rather than `is_not_safe_for_x`. I like `thread->is_oop_safe()` - short and clear. >> src/hotspot/share/runtime/thread.hpp line 1186: >> >>> 1184: bool check_is_terminated(TerminatedTypes l_terminated) const { >>> 1185: return l_terminated != _not_terminated && l_terminated != _thread_exiting && >>> 1186: l_terminated != _thread_gc_barrier_detached; >> >> Existing: I don't think I buy this argument that we need to check all the states we don't want to see rather than the one we do. If the JavaThread has been freed we could see anything - and we should never be executing this code in the first place. > > The logic style of this function is a carry over from before we had Thread-SMR > and we tried to detect a freed JavaThread. With Thread-SMR, we don't need to > do the check this way at all. > > Do we really want to change that as part of this fix for JDK19? No it can be cleaned up later. This fix just highlighted the badness of that piece of code. :) ------------- PR: https://git.openjdk.org/jdk19/pull/20 From ccheung at openjdk.org Fri Jun 17 05:41:45 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 17 Jun 2022 05:41:45 GMT Subject: RFR: 8288601: Consolidate static/dynamic archive tables In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 17:48:09 GMT, Ioi Lam wrote: > Please review this small clean-up of almost identical code that handles the tables for the static and dynamic archives. Nice cleanup. Has this changeset gone through any tier(s) testing? src/hotspot/share/cds/dumpTimeClassInfo.hpp line 28: > 26: #define SHARED_CDS_DUMPTIMESHAREDCLASSINFO_HPP > 27: > 28: #include "cds/archiveBuilder.hpp" Only a blank line was added. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk/pull/9190 From alanb at openjdk.org Fri Jun 17 06:00:06 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 17 Jun 2022 06:00:06 GMT Subject: Integrated: 8286176: Add JNI_VERSION_19 to jni.h and JNI spec In-Reply-To: <4gfI5vNdfsnz9LOqqQ_7c_MPtwUaP5CEkB4DOit9hCo=.0d24c1d1-ba43-4965-9043-741ced9c6ec0@github.com> References: <4gfI5vNdfsnz9LOqqQ_7c_MPtwUaP5CEkB4DOit9hCo=.0d24c1d1-ba43-4965-9043-741ced9c6ec0@github.com> Message-ID: On Sat, 11 Jun 2022 15:42:34 GMT, Alan Bateman wrote: > JNI is updated in Java 19 so we need to define JNI_VERSION_19 and change GetVersion to return this version. > > test/hotspot/jtreg/native_sanity/JniVersion.java is updated to check that JNI_VERSION_19 is returned. The native library in the JMX agent, and several tests, define JNI_OnLoad that return JNI_VERSION_10 as the JNI version needed. These are updated to return JNI_VERSION_19 although these updates aren't strictly needed. This pull request has now been integrated. Changeset: 53bf1bfd Author: Alan Bateman URL: https://git.openjdk.org/jdk19/commit/53bf1bfdabb79b37afedd09051d057f9eea620f2 Stats: 16 lines in 10 files changed: 2 ins; 0 del; 14 mod 8286176: Add JNI_VERSION_19 to jni.h and JNI spec Reviewed-by: dcubed, iris, mchung, dholmes ------------- PR: https://git.openjdk.org/jdk19/pull/7 From duke at openjdk.org Fri Jun 17 06:51:51 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Fri, 17 Jun 2022 06:51:51 GMT Subject: RFR: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test [v2] In-Reply-To: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> References: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> Message-ID: <2EuSSI9VbYx4SqmIjiecMHJhLFwlHEt46NRpspQF0Jk=.7f12155f-f347-4f88-8d0e-048c0dc817d8@github.com> > I would like to fix 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test. > > FlightRecorder option has not been tested since JDK13. > I think we should test it, because FlightRecorder option has not been obsolete in the latest JDK. > Users would be in trouble if the option suddenly disappears without notice, > so it's important to confirm the deprication message. > > Also we should add a test of ExtendedDTraceProbes option. > The test was disabled in 8281675, because some jdk can't specify it. > I modified the test to be able to verify ExtendedDTraceProbes in either case that DTRACE_ENABLED is enabled or not. KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9123/files - new: https://git.openjdk.org/jdk/pull/9123/files/7b04c325..6f69d020 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9123&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9123&range=00-01 Stats: 23 lines in 1 file changed: 5 ins; 11 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/9123.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9123/head:pull/9123 PR: https://git.openjdk.org/jdk/pull/9123 From duke at openjdk.org Fri Jun 17 06:51:53 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Fri, 17 Jun 2022 06:51:53 GMT Subject: RFR: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test In-Reply-To: References: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> Message-ID: On Sat, 11 Jun 2022 13:10:18 GMT, David Holmes wrote: >> I would like to fix 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test. >> >> FlightRecorder option has not been tested since JDK13. >> I think we should test it, because FlightRecorder option has not been obsolete in the latest JDK. >> Users would be in trouble if the option suddenly disappears without notice, >> so it's important to confirm the deprication message. >> >> Also we should add a test of ExtendedDTraceProbes option. >> The test was disabled in 8281675, because some jdk can't specify it. >> I modified the test to be able to verify ExtendedDTraceProbes in either case that DTRACE_ENABLED is enabled or not. > >> so it's important to confirm the deprication message. > > It has been confirmed, just not by a regression test. Adding this is harmless _but_ you can only test this on a JVM configured with JFR so you'd need to selectively add the FlightRecorder flag after programmatically checking whether JFR is present or not (I hope we have a WhiteBox or Platform check for that). > >> Also we should add a test of ExtendedDTraceProbes option. > > That might be useful in 19 but this bug is being pushed to 20 and it is incorrect for 20. At the start of every release we remove the options present in the VMDeprecatedOptions test that are obsoleted in that release as the error message changes and so would cause the test to fail. @dholmes-ora Thank you for your review. I modified the test to check whether JFR is present or not, and deleted the test of ExtendedDTraceProbes option. Could you please review the fix. ------------- PR: https://git.openjdk.org/jdk/pull/9123 From yyang at openjdk.org Fri Jun 17 07:02:47 2022 From: yyang at openjdk.org (Yi Yang) Date: Fri, 17 Jun 2022 07:02:47 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v4] In-Reply-To: References: Message-ID: > It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. > > Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` > > ==> CodeHeap 'non-nmethods' 1532544 (Used) > ==> CodeHeap 'profiled nmethods' 0 > ==> CodeHeap 'non-profiled nmethods' 13952 > ==> Metaspace 506696 > ==> Compressed Class Space 43312 > init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) > > In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`. Yi Yang has updated the pull request incrementally with one additional commit since the last revision: address Ioi's comments; fix LowMemoryTest2.sh failure ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8831/files - new: https://git.openjdk.org/jdk/pull/8831/files/54318474..c3f02b8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8831&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8831&range=02-03 Stats: 29 lines in 5 files changed: 10 ins; 16 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/8831.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8831/head:pull/8831 PR: https://git.openjdk.org/jdk/pull/8831 From yyang at openjdk.org Fri Jun 17 07:02:49 2022 From: yyang at openjdk.org (Yi Yang) Date: Fri, 17 Jun 2022 07:02:49 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Fri, 27 May 2022 07:22:11 GMT, Thomas Stuefe wrote: >>> I think the right fix is to just convert the MetaspacePool into NonClassMetaspacePool and only report the non-class values. >> >> Yes, it's okay for me. But I have another concern. >> >> The compressed class pool is not directly used by other VM components. However, memory pools are exposed via java management APIs. At JDK level, users could obtain memory pools and choose a specified pool by name. If adapting the first solution, I guess it's somewhat strange for users to understand what is `Non Class Space`: >> >> private static MemoryPoolMXBean getMemoryPool(String name) { >> List pools = ManagementFactory.getMemoryPoolMXBeans(); >> for (MemoryPoolMXBean pool : pools) { >> if (pool.getName().equals(name)) { >> return pool; >> } >> } >> >> throw new RuntimeException("Expected to find a memory pool with name " + name); >> } >> public static void foo() { >> MemoryPoolMXBean a = getMemoryPool("Compressed Class Space"); >> MemoryPoolMXBean a = getMemoryPool("Non Class Space"); >> } >> >> If we remove `CompressedClassSpace`, we can only `getMemoryPool("Metaspace")`. Although metaspace is not baked in the specification, IMHO it's easier for developers to understand what is `metaspace` compared to the concepts of `Non Class Space` and `Compressed Class Space`. > >> >> If we remove `CompressedClassSpace`, we can only `getMemoryPool("Metaspace")`. Although metaspace is not baked in the specification, IMHO it's easier for developers to understand what is `metaspace` compared to the concepts of `Non Class Space` and `Compressed Class Space`. > > I personally think that would be totally fine. @tstuefe Can you please take a look at test changes? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/8831 From yyang at openjdk.org Fri Jun 17 07:02:52 2022 From: yyang at openjdk.org (Yi Yang) Date: Fri, 17 Jun 2022 07:02:52 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v3] In-Reply-To: References: Message-ID: On Wed, 8 Jun 2022 05:25:28 GMT, Ioi Lam wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> update > > src/hotspot/share/services/management.cpp line 743: > >> 741: } else { >> 742: // Calculate the memory usage by summing up the pools. >> 743: // NonHeapUsage = CodeHeaps + Metaspace > > I think the new comments in this file can be removed. Thank you @iklam for review! All your comments have been addressed. I also fixed another jtreg failure(LowMemoryTest2.sh) ------------- PR: https://git.openjdk.org/jdk/pull/8831 From rehn at openjdk.org Fri Jun 17 07:05:52 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 17 Jun 2022 07:05:52 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v2] In-Reply-To: References: Message-ID: <4v8Se1opo6asvmxLPK-vey-uC-mgAGKV45QJTl8vHh4=.f95d92b2-133e-47ac-9596-ea09a23af5f9@github.com> On Thu, 16 Jun 2022 21:11:00 GMT, Daniel D. Daugherty wrote: >> Update SharedRuntime::get_java_tid() to verify that the calling thread is safely >> accessing its own threadObj(). This check uses the new is_gc_barrier_detached() >> function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). >> >> The above check was used to reproduce the failure mode without Shenandoah >> and the remainder of the fix relocates the offending code from >> ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of >> removed the 'tid' entry from the ThreadIdTable is still done under the >> protection of the Threads_lock. >> >> This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - update after 8288497 v00 code review changes > - Merge branch 'JDK-8288497' into JDK-8288139 > - 8288139: JavaThread touches oop after GC barrier is detached Marked as reviewed by rehn (Reviewer). Ok, seems fine, thanks. ------------- PR: https://git.openjdk.org/jdk19/pull/21 From rehn at openjdk.org Fri Jun 17 07:13:55 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 17 Jun 2022 07:13:55 GMT Subject: RFR: 8288497: add support for JavaThread::cannot_access_oops_safely() [v2] In-Reply-To: <1E0lM4hNfMhCJh0QnpniURqMIFd3XgI2mUdFMFTrDF0=.8d3b7f2a-ef78-4f89-aa13-d56a2d8c0029@github.com> References: <1E0lM4hNfMhCJh0QnpniURqMIFd3XgI2mUdFMFTrDF0=.8d3b7f2a-ef78-4f89-aa13-d56a2d8c0029@github.com> Message-ID: <5iqKYS2NJdLYVqq6QtimkbERP9EAeyOXZkp-dRVRN2M=.5fbc7b90-ba9e-47ae-85e8-2e92190bacd4@github.com> On Thu, 16 Jun 2022 20:30:51 GMT, Daniel D. Daugherty wrote: >> A fix to add support for JavaThread::is_gc_barrier_detached() which allows >> us to add checks to detect failures like: >> >> JDK-8288139 JavaThread touches oop after GC barrier is detached >> https://bugs.openjdk.org/browse/JDK-8288139 >> >> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Resolve some code review comments on v00. > - Merge branch 'master' into JDK-8288497 > - 8288497: add support for JavaThread::is_gc_barrier_detached() Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/20 From rehn at openjdk.org Fri Jun 17 07:13:57 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 17 Jun 2022 07:13:57 GMT Subject: RFR: 8288497: add support for JavaThread::cannot_access_oops_safely() In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 07:29:34 GMT, Robbin Ehn wrote: >> A fix to add support for JavaThread::is_gc_barrier_detached() which allows >> us to add checks to detect failures like: >> >> JDK-8288139 JavaThread touches oop after GC barrier is detached >> https://bugs.openjdk.org/browse/JDK-8288139 >> >> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Hi, > > Except for the few lines of code between: > BarrierSet::barrier_set()->on_thread_detach(p) and ThreadsSMRSupport::remove(); > > This new state is identical to the result of "ThreadsSMRSupport::get_java_thread_list()->includes(p)". > The JavaThread is attached to the barrier set when we add it to the ThreadsList and detached when we remove it. > > If we have a safepoint poll between (done with Threads_lock held): > BarrierSet::barrier_set()->on_thread_detach(p); > -> > p->set_terminated(JavaThread::_thread_terminated); > > We have a bug. This means that this new state is not even possible to observe from another thread (with target safe). > So for any other thread there is no difference, which means we have new global state just for a few lines of code while we are terminating with Threads_lock held. > > So I don't think this one place needs a new global state. > > Note that for a safe target thread the terminated flag gives the same result as: > "ThreadsSMRSupport::get_java_thread_list()->includes(p)" > > So jt->is_terminated() can be implemented with "ThreadsSMRSupport::get_java_thread_list()->includes(p)". (again assuming we are not doing some racy, and only asking for threads that are safe/stable) > @robehn's comment from above: > > > Except for the few lines of code between: > > BarrierSet::barrier_set()->on_thread_detach(p) and ThreadsSMRSupport::remove(); > > This new state is identical to the result of "ThreadsSMRSupport::get_java_thread_list()->includes(p)". > > No it's not equivalent. If I replace is_gc_barrier_attached()'s implementation with your check, then it would NOT catch the code that's in the wrong place and is being fixed by JDK-8288139. Setting the new _terminated field state exactly where I do so in this fix is what allowed me to prove that the code that I moved in JDK-8288139 is in the wrong place. That's why I said except between these lines :) If you say this is the correct way to handle it for now, then it is. Looks fine, thanks! ------------- PR: https://git.openjdk.org/jdk19/pull/20 From stuefe at openjdk.org Fri Jun 17 08:04:50 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 17 Jun 2022 08:04:50 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v4] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 07:02:47 GMT, Yi Yang wrote: >> It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. >> >> Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` >> >> ==> CodeHeap 'non-nmethods' 1532544 (Used) >> ==> CodeHeap 'profiled nmethods' 0 >> ==> CodeHeap 'non-profiled nmethods' 13952 >> ==> Metaspace 506696 >> ==> Compressed Class Space 43312 >> init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) >> >> In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`. > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > address Ioi's comments; fix LowMemoryTest2.sh failure Looks good, but see inline question. test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.sh line 74: > 72: # we would have committed the space right away and therefore the MemoryMXBean "committed" trigger > 73: # would have fired. In the new Metaspace, we don't commit, so the MemoryMXBean does not fire. > 74: go -noclassgc -XX:MaxMetaspaceSize=4m LowMemoryTest2 Why did you reduce the MaxMetaspaceSize? (Should probably be okay post JEP-387, but how does it relate to your change?) ------------- PR: https://git.openjdk.org/jdk/pull/8831 From yyang at openjdk.org Fri Jun 17 08:24:51 2022 From: yyang at openjdk.org (Yi Yang) Date: Fri, 17 Jun 2022 08:24:51 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v4] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 08:00:44 GMT, Thomas Stuefe wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> address Ioi's comments; fix LowMemoryTest2.sh failure > > test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.sh line 74: > >> 72: # we would have committed the space right away and therefore the MemoryMXBean "committed" trigger >> 73: # would have fired. In the new Metaspace, we don't commit, so the MemoryMXBean does not fire. >> 74: go -noclassgc -XX:MaxMetaspaceSize=4m LowMemoryTest2 > > Why did you reduce the MaxMetaspaceSize? (Should probably be okay post JEP-387, but how does it relate to your change?) Maybe I misunderstand the purpose of LowMemoryTest2? I thought the original test case go -noclassgc -XX:MaxMetaspaceSize=16m -XX:CompressedClassSpaceSize=4m LowMemoryTest2 is used to check if low memory ratio(20% remaining) of compressed class pool could be detected instead of throwing Compressed Class Space OOM. Since we don't have compressed class pool anymore, I thought metaspace should be reduced to adapt original purpose of that test case. ------------- PR: https://git.openjdk.org/jdk/pull/8831 From sspitsyn at openjdk.org Fri Jun 17 08:32:49 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 17 Jun 2022 08:32:49 GMT Subject: RFR: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp In-Reply-To: References: Message-ID: On Tue, 14 Jun 2022 08:02:21 GMT, Ron Pressler wrote: > Please review the following fix. > > When JVM TI puts a thread's state in `interp_only_mode`, thaw takes the slow path and deoptimizes frames as they're thawed in `recurse_thaw_compiled_frame`. However, thawing a deoptimized frame's callee will override the frame's patched pc (to the deopt handler), essentially reverting the deoptimization. This fix patches the deoptimized return address after thawing the callee. > > Passes loom tiers 1-5 Looks good. Thank you for investigating and fixing! Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk19/pull/12 From eosterlund at openjdk.org Fri Jun 17 13:35:58 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 17 Jun 2022 13:35:58 GMT Subject: RFR: 8288497: add support for JavaThread::cannot_access_oops_safely() [v2] In-Reply-To: <1E0lM4hNfMhCJh0QnpniURqMIFd3XgI2mUdFMFTrDF0=.8d3b7f2a-ef78-4f89-aa13-d56a2d8c0029@github.com> References: <1E0lM4hNfMhCJh0QnpniURqMIFd3XgI2mUdFMFTrDF0=.8d3b7f2a-ef78-4f89-aa13-d56a2d8c0029@github.com> Message-ID: On Thu, 16 Jun 2022 20:30:51 GMT, Daniel D. Daugherty wrote: >> A fix to add support for JavaThread::is_gc_barrier_detached() which allows >> us to add checks to detect failures like: >> >> JDK-8288139 JavaThread touches oop after GC barrier is detached >> https://bugs.openjdk.org/browse/JDK-8288139 >> >> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Resolve some code review comments on v00. > - Merge branch 'master' into JDK-8288497 > - 8288497: add support for JavaThread::is_gc_barrier_detached() Thank you for the explanation, @dcubed-ojdk. This looks good to me. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk19/pull/20 From eosterlund at openjdk.org Fri Jun 17 13:37:59 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 17 Jun 2022 13:37:59 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v2] In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 21:11:00 GMT, Daniel D. Daugherty wrote: >> Update SharedRuntime::get_java_tid() to verify that the calling thread is safely >> accessing its own threadObj(). This check uses the new is_gc_barrier_detached() >> function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). >> >> The above check was used to reproduce the failure mode without Shenandoah >> and the remainder of the fix relocates the offending code from >> ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of >> removed the 'tid' entry from the ThreadIdTable is still done under the >> protection of the Threads_lock. >> >> This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - update after 8288497 v00 code review changes > - Merge branch 'JDK-8288497' into JDK-8288139 > - 8288139: JavaThread touches oop after GC barrier is detached Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk19/pull/21 From ihse at openjdk.org Fri Jun 17 13:59:09 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 17 Jun 2022 13:59:09 GMT Subject: RFR: 8288396: Always create reproducible builds [v5] In-Reply-To: References: Message-ID: <5dvZCp5zW56RrXU6QPhglJP2dT0fk3g71L8peDgELiY=.857d2783-3a5e-442b-9921-29c8074c3c2b@github.com> On Wed, 15 Jun 2022 15:18:04 GMT, Magnus Ihse Bursie wrote: >> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.) >> >> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove incorrect argument > - Test if linker can accept the flag Anyone from Hotspot caring to review the Hotspot changes? ------------- PR: https://git.openjdk.org/jdk/pull/9152 From pchilanomate at openjdk.org Fri Jun 17 15:03:57 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 17 Jun 2022 15:03:57 GMT Subject: RFR: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp In-Reply-To: References: Message-ID: <073U5O_ydGK7VB1jFi0700cMFvBTp2g0tX3Gm2-pUOY=.a4243989-2292-43ad-aee9-3e82ae16a2d1@github.com> On Tue, 14 Jun 2022 08:02:21 GMT, Ron Pressler wrote: > Please review the following fix. > > When JVM TI puts a thread's state in `interp_only_mode`, thaw takes the slow path and deoptimizes frames as they're thawed in `recurse_thaw_compiled_frame`. However, thawing a deoptimized frame's callee will override the frame's patched pc (to the deopt handler), essentially reverting the deoptimization. This fix patches the deoptimized return address after thawing the callee. > > Passes loom tiers 1-5 LGTM. ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.org/jdk19/pull/12 From dcubed at openjdk.org Fri Jun 17 15:08:08 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 17 Jun 2022 15:08:08 GMT Subject: RFR: 8288497: add support for JavaThread::cannot_access_oops_safely() [v2] In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 22:38:31 GMT, David Holmes wrote: >> @pchilano - Thanks for the review! >> >> Since we've been having issues with oop usage after the GC barrier is detached >> in several bugs, I was going for the more precise control of adding the new >> TerminatedTypes value. There is quite a bit of code from: >> >> old L3600: `BarrierSet::barrier_set()->on_thread_detach(p);` >> >> to >> >> old L3623: `p->set_terminated(JavaThread::_thread_terminated);` >> >> so rather than have to reason about the code over and over again, >> I would rather do these sanity checks with targeted code. To paraphrase >> @robehn: Why do with code inspection what you can do with code? > > @dcubed-ojdk I must admit I'm also not a fan of adding this very specialized interim state into the thread termination states. I would have expected the barrier code itself to be able to detect when `on_thread_detach` had been called, instead of the `JavaThread` having to track that for itself. @dholmes-ora, @robehn and @fisk - Thanks for the re-reviews! I'm going to do the rename that @dholmes-ora suggested and then retest again... ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Fri Jun 17 15:08:10 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 17 Jun 2022 15:08:10 GMT Subject: RFR: 8288497: add support for JavaThread::cannot_access_oops_safely() [v2] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 01:00:57 GMT, David Holmes wrote: >> We can definitely rename, but naming is hard... :-) >> >> Those names you proposed are inversions of the current name and would >> require that the logic of the function be inverted. >> >> The other names I came up before I settled on is_gc_barrier_detached(): >> >> >> can_no_longer_access_oops() >> oops_are_no_longer_safe() >> cannot_safely_access_oops() >> >> >> The closest match between your proposed names and mine are: >> >> `can_access_oops_safely` and `cannot_safely_access_oops` >> >> Other opinions are welcome. > > I think the style guide for naming is to use positive names to avoid double negatives when you have to negate the function - so `is_safe_for_x` rather than `is_not_safe_for_x`. I like `thread->is_oop_safe()` - short and clear. I do one more rename of the bug, the PR and the function name... ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Fri Jun 17 15:19:03 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 17 Jun 2022 15:19:03 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v2] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 00:54:14 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - update after 8288497 v00 code review changes >> - Merge branch 'JDK-8288497' into JDK-8288139 >> - 8288139: JavaThread touches oop after GC barrier is detached > > Thanks Dan. @dholmes-ora, @robehn and @fisk - Thanks for the re-review. I'm doing another rename in JDK-8288497 so that will ripple into here... ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dcubed at openjdk.org Fri Jun 17 15:21:01 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 17 Jun 2022 15:21:01 GMT Subject: RFR: 8288497: add support for JavaThread::cannot_access_oops_safely() [v3] In-Reply-To: References: Message-ID: > A fix to add support for JavaThread::is_gc_barrier_detached() which allows > us to add checks to detect failures like: > > JDK-8288139 JavaThread touches oop after GC barrier is detached > https://bugs.openjdk.org/browse/JDK-8288139 > > This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Rename cannot_access_oops_safely to is_oop_safe and invert the function's logic. ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/20/files - new: https://git.openjdk.org/jdk19/pull/20/files/24ecdea4..3f526bee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=20&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=20&range=01-02 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk19/pull/20.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/20/head:pull/20 PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Fri Jun 17 15:39:10 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 17 Jun 2022 15:39:10 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v3] In-Reply-To: References: Message-ID: > Update SharedRuntime::get_java_tid() to verify that the calling thread is safely > accessing its own threadObj(). This check uses the new is_gc_barrier_detached() > function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). > > The above check was used to reproduce the failure mode without Shenandoah > and the remainder of the fix relocates the offending code from > ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of > removed the 'tid' entry from the ThreadIdTable is still done under the > protection of the Threads_lock. > > This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - update after 8288497 v01 code review changes - Merge branch 'JDK-8288497' into JDK-8288139 - update after 8288497 v00 code review changes - Merge branch 'JDK-8288497' into JDK-8288139 - 8288139: JavaThread touches oop after GC barrier is detached ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/21/files - new: https://git.openjdk.org/jdk19/pull/21/files/1811bc14..a7302d19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=21&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=21&range=01-02 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk19/pull/21.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/21/head:pull/21 PR: https://git.openjdk.org/jdk19/pull/21 From coleenp at openjdk.org Fri Jun 17 15:45:56 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 17 Jun 2022 15:45:56 GMT Subject: RFR: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp In-Reply-To: References: Message-ID: <1_wM3INQnOEU_wSH3pyxg7mTfA5ohn7xqkzbQKR6IDI=.0706d9ee-1a6b-4589-b060-82c363395618@github.com> On Tue, 14 Jun 2022 08:02:21 GMT, Ron Pressler wrote: > Please review the following fix. > > When JVM TI puts a thread's state in `interp_only_mode`, thaw takes the slow path and deoptimizes frames as they're thawed in `recurse_thaw_compiled_frame`. However, thawing a deoptimized frame's callee will override the frame's patched pc (to the deopt handler), essentially reverting the deoptimization. This fix patches the deoptimized return address after thawing the callee. > > Passes loom tiers 1-5 src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1970: > 1968: } else { > 1969: // caller might have been deoptimized during thaw but we've overwritten the return address when copying f > 1970: ContinuationHelper::Frame::patch_pc(caller, caller.raw_pc()); What is raw_pc() vs pc() ? why? is _cont.is_empty() true here? ie. a bit more explanation would be useful here. ------------- PR: https://git.openjdk.org/jdk19/pull/12 From rpressler at openjdk.org Fri Jun 17 15:51:03 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Fri, 17 Jun 2022 15:51:03 GMT Subject: RFR: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp In-Reply-To: <1_wM3INQnOEU_wSH3pyxg7mTfA5ohn7xqkzbQKR6IDI=.0706d9ee-1a6b-4589-b060-82c363395618@github.com> References: <1_wM3INQnOEU_wSH3pyxg7mTfA5ohn7xqkzbQKR6IDI=.0706d9ee-1a6b-4589-b060-82c363395618@github.com> Message-ID: On Fri, 17 Jun 2022 15:41:24 GMT, Coleen Phillimore wrote: >> Please review the following fix. >> >> When JVM TI puts a thread's state in `interp_only_mode`, thaw takes the slow path and deoptimizes frames as they're thawed in `recurse_thaw_compiled_frame`. However, thawing a deoptimized frame's callee will override the frame's patched pc (to the deopt handler), essentially reverting the deoptimization. This fix patches the deoptimized return address after thawing the callee. >> >> Passes loom tiers 1-5 > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1970: > >> 1968: } else { >> 1969: // caller might have been deoptimized during thaw but we've overwritten the return address when copying f >> 1970: ContinuationHelper::Frame::patch_pc(caller, caller.raw_pc()); > > What is raw_pc() vs pc() ? why? is _cont.is_empty() true here? ie. a bit more explanation would be useful here. raw_pc is the "physical" return pc, and could point to the deopt handler; pc is the original caller address whether or not the caller is deoptimized. So raw_pc and pc are different iff the frame is deoptimized. The relevant background is in the (pre-Loom) deoptimization-related frame methods, raw_pc and patch_pc (e.g. they say that deoptimizing stores the original pc in the frame). ------------- PR: https://git.openjdk.org/jdk19/pull/12 From stuefe at openjdk.org Fri Jun 17 16:03:02 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 17 Jun 2022 16:03:02 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong In-Reply-To: References: Message-ID: On Fri, 27 May 2022 07:22:11 GMT, Thomas Stuefe wrote: >>> I think the right fix is to just convert the MetaspacePool into NonClassMetaspacePool and only report the non-class values. >> >> Yes, it's okay for me. But I have another concern. >> >> The compressed class pool is not directly used by other VM components. However, memory pools are exposed via java management APIs. At JDK level, users could obtain memory pools and choose a specified pool by name. If adapting the first solution, I guess it's somewhat strange for users to understand what is `Non Class Space`: >> >> private static MemoryPoolMXBean getMemoryPool(String name) { >> List pools = ManagementFactory.getMemoryPoolMXBeans(); >> for (MemoryPoolMXBean pool : pools) { >> if (pool.getName().equals(name)) { >> return pool; >> } >> } >> >> throw new RuntimeException("Expected to find a memory pool with name " + name); >> } >> public static void foo() { >> MemoryPoolMXBean a = getMemoryPool("Compressed Class Space"); >> MemoryPoolMXBean a = getMemoryPool("Non Class Space"); >> } >> >> If we remove `CompressedClassSpace`, we can only `getMemoryPool("Metaspace")`. Although metaspace is not baked in the specification, IMHO it's easier for developers to understand what is `metaspace` compared to the concepts of `Non Class Space` and `Compressed Class Space`. > >> >> If we remove `CompressedClassSpace`, we can only `getMemoryPool("Metaspace")`. Although metaspace is not baked in the specification, IMHO it's easier for developers to understand what is `metaspace` compared to the concepts of `Non Class Space` and `Compressed Class Space`. > > I personally think that would be totally fine. > @tstuefe could you take a look at the test changes. Since we can no longer query the compressed class space individually, I think the tests may become more lenient than before. For example, memoryUsageSmallComp/TestDescription.java uses `MemoryUsageTest::checkForNotGrowing()` which monitors the used bytes in `MetaspaceBaseGC::pool.getUsage().getUsed()` > > * Before this PR, it checks that the usage of the compressed klass space doesn't grow. > * After this PR, it will allow the compresed klass space to grow, as long as the "other" meta space shrinks by a similar amount. > > Is this OK? Or should we add a new whitebox API to query the compressed vs meta space? Sorry for the long delay, I was not at work. I think you may be right, we need a replacement for the old memory bean for these tests. Whitebox seems easiest. ------------- PR: https://git.openjdk.org/jdk/pull/8831 From stuefe at openjdk.org Fri Jun 17 16:03:05 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 17 Jun 2022 16:03:05 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v4] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 08:22:42 GMT, Yi Yang wrote: >> test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.sh line 74: >> >>> 72: # we would have committed the space right away and therefore the MemoryMXBean "committed" trigger >>> 73: # would have fired. In the new Metaspace, we don't commit, so the MemoryMXBean does not fire. >>> 74: go -noclassgc -XX:MaxMetaspaceSize=4m LowMemoryTest2 >> >> Why did you reduce the MaxMetaspaceSize? (Should probably be okay post JEP-387, but how does it relate to your change?) > > Maybe I misunderstand the purpose of LowMemoryTest2? > > I thought the original test case > > go -noclassgc -XX:MaxMetaspaceSize=16m -XX:CompressedClassSpaceSize=4m LowMemoryTest2 > > is used to check if low memory ratio(20% remaining) of compressed class pool could be detected instead of throwing Compressed Class Space OOM. Since we don't have compressed class pool anymore, I thought metaspace should be reduced to adapt original purpose of that test case. I would have thought that since we don't have the pool anymore, we can just remove this test line. The lines above already test against MaxMetaspaceSize. ------------- PR: https://git.openjdk.org/jdk/pull/8831 From coleenp at openjdk.org Fri Jun 17 16:28:03 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 17 Jun 2022 16:28:03 GMT Subject: RFR: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp In-Reply-To: References: Message-ID: <2fG0qoJH_8U5W4AAQst6DlxQuESG1QW7c33D4Aw88NU=.bcab6d0e-e951-46fa-ab42-fd00329a136a@github.com> On Tue, 14 Jun 2022 08:02:21 GMT, Ron Pressler wrote: > Please review the following fix. > > When JVM TI puts a thread's state in `interp_only_mode`, thaw takes the slow path and deoptimizes frames as they're thawed in `recurse_thaw_compiled_frame`. However, thawing a deoptimized frame's callee will override the frame's patched pc (to the deopt handler), essentially reverting the deoptimization. This fix patches the deoptimized return address after thawing the callee. > > Passes loom tiers 1-5 Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/12 From coleenp at openjdk.org Fri Jun 17 16:28:07 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 17 Jun 2022 16:28:07 GMT Subject: RFR: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp In-Reply-To: References: <1_wM3INQnOEU_wSH3pyxg7mTfA5ohn7xqkzbQKR6IDI=.0706d9ee-1a6b-4589-b060-82c363395618@github.com> Message-ID: <3vahfwOFZzoTwQNDiplNObO-f71dgkJ0z99uUcD6VEg=.e613cd17-a4f5-4627-94f0-0354e0556ac2@github.com> On Fri, 17 Jun 2022 15:47:02 GMT, Ron Pressler wrote: >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1970: >> >>> 1968: } else { >>> 1969: // caller might have been deoptimized during thaw but we've overwritten the return address when copying f >>> 1970: ContinuationHelper::Frame::patch_pc(caller, caller.raw_pc()); >> >> What is raw_pc() vs pc() ? why? is _cont.is_empty() true here? ie. a bit more explanation would be useful here. > > raw_pc is the "physical" return pc, and could point to the deopt handler; pc is the original caller address whether or not the caller is deoptimized. So raw_pc and pc are different iff the frame is deoptimized. > The relevant background is in the (pre-Loom) deoptimization-related frame methods, raw_pc and patch_pc (e.g. they say that deoptimizing stores the original pc in the frame). Looking at JDK 18 runtime code for raw_pc() (should probably change the comment since it's not only used by deoptimization anymore): I'm told pc_return_offset is zero so the 'else' clause doesn't change the caller.pc if the frame isn't deoptimized. Thanks to @pchilano also for explanation. Can you change the comment to: s/when copying f/\nwhen copying the caller frame from the heap. The caller.pc is unchanged otherwise./ ------------- PR: https://git.openjdk.org/jdk19/pull/12 From dcubed at openjdk.org Fri Jun 17 16:28:18 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 17 Jun 2022 16:28:18 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 Message-ID: Update a couple of tests that were modified by JDK-8286830. Now the tests properly honor any specified time limit by splitting the time between both sub-tests. Also pick up a sanity check based on JDK-8288497 that I've been using in recent stress testing. ------------- Depends on: https://git.openjdk.org/jdk19/pull/21 Commit messages: - update after 8288497 v01 code review changes - Merge branch 'JDK-8288139' into JDK-8288532 - update after 8288497 v00 code review changes - Merge branch 'JDK-8288139' into JDK-8288532 - 8288532: additional review changes for JDK-8286830 Changes: https://git.openjdk.org/jdk19/pull/32/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=32&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288532 Stats: 12 lines in 3 files changed: 9 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk19/pull/32.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/32/head:pull/32 PR: https://git.openjdk.org/jdk19/pull/32 From rpressler at openjdk.org Fri Jun 17 16:40:09 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Fri, 17 Jun 2022 16:40:09 GMT Subject: RFR: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp [v2] In-Reply-To: References: Message-ID: > Please review the following fix. > > When JVM TI puts a thread's state in `interp_only_mode`, thaw takes the slow path and deoptimizes frames as they're thawed in `recurse_thaw_compiled_frame`. However, thawing a deoptimized frame's callee will override the frame's patched pc (to the deopt handler), essentially reverting the deoptimization. This fix patches the deoptimized return address after thawing the callee. > > Passes loom tiers 1-5 Ron Pressler has updated the pull request incrementally with two additional commits since the last revision: - Change comment. - Change comment ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/12/files - new: https://git.openjdk.org/jdk19/pull/12/files/c34a25ac..af57e33b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=12&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=12&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/12.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/12/head:pull/12 PR: https://git.openjdk.org/jdk19/pull/12 From coleenp at openjdk.org Fri Jun 17 16:40:11 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 17 Jun 2022 16:40:11 GMT Subject: RFR: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp [v2] In-Reply-To: <3vahfwOFZzoTwQNDiplNObO-f71dgkJ0z99uUcD6VEg=.e613cd17-a4f5-4627-94f0-0354e0556ac2@github.com> References: <1_wM3INQnOEU_wSH3pyxg7mTfA5ohn7xqkzbQKR6IDI=.0706d9ee-1a6b-4589-b060-82c363395618@github.com> <3vahfwOFZzoTwQNDiplNObO-f71dgkJ0z99uUcD6VEg=.e613cd17-a4f5-4627-94f0-0354e0556ac2@github.com> Message-ID: On Fri, 17 Jun 2022 16:24:53 GMT, Coleen Phillimore wrote: >> raw_pc is the "physical" return pc, and could point to the deopt handler; pc is the original caller address whether or not the caller is deoptimized. So raw_pc and pc are different iff the frame is deoptimized. >> The relevant background is in the (pre-Loom) deoptimization-related frame methods, raw_pc and patch_pc (e.g. they say that deoptimizing stores the original pc in the frame). > > Looking at JDK 18 runtime code for raw_pc() (should probably change the comment since it's not only used by deoptimization anymore): I'm told pc_return_offset is zero so the 'else' clause doesn't change the caller.pc if the frame isn't deoptimized. > Thanks to @pchilano also for explanation. > Can you change the comment to: > s/when copying f/\nwhen copying the caller frame from the heap. The caller.pc is unchanged otherwise./ it's not 'f'. ------------- PR: https://git.openjdk.org/jdk19/pull/12 From rpressler at openjdk.org Fri Jun 17 16:40:12 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Fri, 17 Jun 2022 16:40:12 GMT Subject: RFR: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp [v2] In-Reply-To: References: <1_wM3INQnOEU_wSH3pyxg7mTfA5ohn7xqkzbQKR6IDI=.0706d9ee-1a6b-4589-b060-82c363395618@github.com> <3vahfwOFZzoTwQNDiplNObO-f71dgkJ0z99uUcD6VEg=.e613cd17-a4f5-4627-94f0-0354e0556ac2@github.com> Message-ID: On Fri, 17 Jun 2022 16:32:47 GMT, Coleen Phillimore wrote: >> Looking at JDK 18 runtime code for raw_pc() (should probably change the comment since it's not only used by deoptimization anymore): I'm told pc_return_offset is zero so the 'else' clause doesn't change the caller.pc if the frame isn't deoptimized. >> Thanks to @pchilano also for explanation. >> Can you change the comment to: >> s/when copying f/\nwhen copying the caller frame from the heap. The caller.pc is unchanged otherwise./ > > it's not 'f'. Changed to say "when copying f from the heap. The caller.pc is unchanged otherwise" because it's copying f, the callee, that's the issue, as the return address to the caller is in the callee frame. ------------- PR: https://git.openjdk.org/jdk19/pull/12 From coleenp at openjdk.org Fri Jun 17 16:40:13 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 17 Jun 2022 16:40:13 GMT Subject: RFR: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp [v2] In-Reply-To: References: <1_wM3INQnOEU_wSH3pyxg7mTfA5ohn7xqkzbQKR6IDI=.0706d9ee-1a6b-4589-b060-82c363395618@github.com> <3vahfwOFZzoTwQNDiplNObO-f71dgkJ0z99uUcD6VEg=.e613cd17-a4f5-4627-94f0-0354e0556ac2@github.com> Message-ID: On Fri, 17 Jun 2022 16:33:09 GMT, Ron Pressler wrote: >> it's not 'f'. > > Changed to say "when copying f from the heap. The caller.pc is unchanged otherwise" because it's copying f, the callee, that's the issue, as the return address to the caller is in the callee frame. Ok. didn't see 'f' in the diffs. ------------- PR: https://git.openjdk.org/jdk19/pull/12 From pchilanomate at openjdk.org Fri Jun 17 16:52:56 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 17 Jun 2022 16:52:56 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v3] In-Reply-To: References: Message-ID: <9SvTYjsua7NJ3UzSvFUZgghWHEBeUdPNJ8PRgvJMZ8s=.678ba88a-2aed-42c1-91de-13418677a297@github.com> On Fri, 17 Jun 2022 15:39:10 GMT, Daniel D. Daugherty wrote: >> Update SharedRuntime::get_java_tid() to verify that the calling thread is safely >> accessing its own threadObj(). This check uses the new is_gc_barrier_detached() >> function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). >> >> The above check was used to reproduce the failure mode without Shenandoah >> and the remainder of the fix relocates the offending code from >> ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of >> removed the 'tid' entry from the ThreadIdTable is still done under the >> protection of the Threads_lock. >> >> This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - update after 8288497 v01 code review changes > - Merge branch 'JDK-8288497' into JDK-8288139 > - update after 8288497 v00 code review changes > - Merge branch 'JDK-8288497' into JDK-8288139 > - 8288139: JavaThread touches oop after GC barrier is detached Still good. ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.org/jdk19/pull/21 From pchilanomate at openjdk.org Fri Jun 17 17:37:55 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 17 Jun 2022 17:37:55 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 21:54:56 GMT, Daniel D. Daugherty wrote: > Update a couple of tests that were modified by JDK-8286830. Now the tests properly > honor any specified time limit by splitting the time between both sub-tests. > Also pick up a sanity check based on JDK-8288497 that I've been using in recent > stress testing. Hi Dan, Some comments below. Thanks, Patricio src/hotspot/share/runtime/thread.inline.hpp line 151: > 149: ~AsyncExceptionHandshake() { > 150: Thread* current = Thread::current(); > 151: if (current->is_Java_thread()) { Why verify if this is a JavaThread? The target is always a JavaThread, and the sender of the exception is also a JavaThread(JVM_StopThread and JvmtiEnv::StopThread). Even the handshake operation will assert if the handshaker is not a JT. test/hotspot/jtreg/runtime/Thread/StopAtExit.java line 75: > 73: } > 74: } > 75: timeMax /= 2; // Split time between the two sub-tests. Maybe bump DEF_TIME_MAX to 60 seconds now so both subtests run the original 30 seconds? My intention was to run the same test again(same time) but with the addition of threadCreator. test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 81: > 79: } > 80: } > 81: timeMax /= 2; // Split time between the two sub-tests. Same thing about DEF_TIME_MAX. ------------- PR: https://git.openjdk.org/jdk19/pull/32 From dcubed at openjdk.org Fri Jun 17 19:00:00 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 17 Jun 2022 19:00:00 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v3] In-Reply-To: <9SvTYjsua7NJ3UzSvFUZgghWHEBeUdPNJ8PRgvJMZ8s=.678ba88a-2aed-42c1-91de-13418677a297@github.com> References: <9SvTYjsua7NJ3UzSvFUZgghWHEBeUdPNJ8PRgvJMZ8s=.678ba88a-2aed-42c1-91de-13418677a297@github.com> Message-ID: On Fri, 17 Jun 2022 16:49:32 GMT, Patricio Chilano Mateo wrote: >> Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - update after 8288497 v01 code review changes >> - Merge branch 'JDK-8288497' into JDK-8288139 >> - update after 8288497 v00 code review changes >> - Merge branch 'JDK-8288497' into JDK-8288139 >> - 8288139: JavaThread touches oop after GC barrier is detached > > Still good. @pchilano - Thanks for the re-review! ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dcubed at openjdk.org Fri Jun 17 19:01:54 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 17 Jun 2022 19:01:54 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 17:33:58 GMT, Patricio Chilano Mateo wrote: >> Update a couple of tests that were modified by JDK-8286830. Now the tests properly >> honor any specified time limit by splitting the time between both sub-tests. >> Also pick up a sanity check based on JDK-8288497 that I've been using in recent >> stress testing. > > Hi Dan, > > Some comments below. > > Thanks, > Patricio @pchilano - Thanks for the review! > test/hotspot/jtreg/runtime/Thread/SuspendAtExit.java line 81: > >> 79: } >> 80: } >> 81: timeMax /= 2; // Split time between the two sub-tests. > > Same thing about DEF_TIME_MAX. I try not to have the default config for a stress test run longer that 30 seconds total. 15 seconds per sub-test is fine. ------------- PR: https://git.openjdk.org/jdk19/pull/32 From dcubed at openjdk.org Fri Jun 17 19:08:57 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 17 Jun 2022 19:08:57 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 17:25:00 GMT, Patricio Chilano Mateo wrote: >> Update a couple of tests that were modified by JDK-8286830. Now the tests properly >> honor any specified time limit by splitting the time between both sub-tests. >> Also pick up a sanity check based on JDK-8288497 that I've been using in recent >> stress testing. > > src/hotspot/share/runtime/thread.inline.hpp line 151: > >> 149: ~AsyncExceptionHandshake() { >> 150: Thread* current = Thread::current(); >> 151: if (current->is_Java_thread()) { > > Why verify if this is a JavaThread? The target is always a JavaThread, and the sender of the exception is also a JavaThread(JVM_StopThread and JvmtiEnv::StopThread). Even the handshake operation will assert if the handshaker is not a JT. Will investigate. > test/hotspot/jtreg/runtime/Thread/StopAtExit.java line 75: > >> 73: } >> 74: } >> 75: timeMax /= 2; // Split time between the two sub-tests. > > Maybe bump DEF_TIME_MAX to 60 seconds now so both subtests run the original 30 seconds? My intention was to run the same test again(same time) but with the addition of threadCreator. I try not to have the default config for a stress test run longer that 30 seconds total. 15 seconds per sub-test is fine. ------------- PR: https://git.openjdk.org/jdk19/pull/32 From dcubed at openjdk.org Fri Jun 17 19:17:56 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 17 Jun 2022 19:17:56 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 In-Reply-To: References: Message-ID: <8OCwr3eCdbC24Ff1-7UUJgAS2VQzvOLrF8qSCarsyxc=.0e072e91-d0a5-4f6d-8118-f4b70647b33b@github.com> On Fri, 17 Jun 2022 19:05:08 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/thread.inline.hpp line 151: >> >>> 149: ~AsyncExceptionHandshake() { >>> 150: Thread* current = Thread::current(); >>> 151: if (current->is_Java_thread()) { >> >> Why verify if this is a JavaThread? The target is always a JavaThread, and the sender of the exception is also a JavaThread(JVM_StopThread and JvmtiEnv::StopThread). Even the handshake operation will assert if the handshaker is not a JT. > > Will investigate. JavaThread::send_async_exception() creates a new AsyncExceptionHandshake. JavaThread::send_async_exception() is called by JVM_StopThread() and JvmtiEnv::StopThread(). The InstallAsyncExceptionHandshake which wraps the AsyncExceptionHandshake is installed via Handshake::execute() which calls " JavaThread* self = JavaThread::current()" first thing so send_async_exception() will fire an assert() if not called by a JavaThread. Will fix. ------------- PR: https://git.openjdk.org/jdk19/pull/32 From pchilanomate at openjdk.org Fri Jun 17 19:22:59 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 17 Jun 2022 19:22:59 GMT Subject: RFR: 8288497: add support for JavaThread::is_oop_safe() [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 15:21:01 GMT, Daniel D. Daugherty wrote: >> A fix to add support for JavaThread::is_gc_barrier_detached() which allows >> us to add checks to detect failures like: >> >> JDK-8288139 JavaThread touches oop after GC barrier is detached >> https://bugs.openjdk.org/browse/JDK-8288139 >> >> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Rename cannot_access_oops_safely to is_oop_safe and invert the function's logic. Thanks Dan, looks good. ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Fri Jun 17 19:22:59 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 17 Jun 2022 19:22:59 GMT Subject: RFR: 8288497: add support for JavaThread::is_oop_safe() [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 19:18:19 GMT, Patricio Chilano Mateo wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename cannot_access_oops_safely to is_oop_safe and invert the function's logic. > > Thanks Dan, looks good. @pchilano - Thanks for the re-review! ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Fri Jun 17 19:32:46 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 17 Jun 2022 19:32:46 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 [v2] In-Reply-To: References: Message-ID: > Update a couple of tests that were modified by JDK-8286830. Now the tests properly > honor any specified time limit by splitting the time between both sub-tests. > Also pick up a sanity check based on JDK-8288497 that I've been using in recent > stress testing. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Check in AsyncExceptionHandshake() dtr can assume the caller is a JavaThread. ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/32/files - new: https://git.openjdk.org/jdk19/pull/32/files/6bb82594..6cd771a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=32&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=32&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk19/pull/32.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/32/head:pull/32 PR: https://git.openjdk.org/jdk19/pull/32 From pchilanomate at openjdk.org Fri Jun 17 20:56:00 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 17 Jun 2022 20:56:00 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 [v2] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 19:32:46 GMT, Daniel D. Daugherty wrote: >> Update a couple of tests that were modified by JDK-8286830. Now the tests properly >> honor any specified time limit by splitting the time between both sub-tests. >> Also pick up a sanity check based on JDK-8288497 that I've been using in recent >> stress testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Check in AsyncExceptionHandshake() dtr can assume the caller is a JavaThread. Thanks for the fix. Looks good. ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.org/jdk19/pull/32 From dcubed at openjdk.org Fri Jun 17 21:28:01 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 17 Jun 2022 21:28:01 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 [v2] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 19:32:46 GMT, Daniel D. Daugherty wrote: >> Update a couple of tests that were modified by JDK-8286830. Now the tests properly >> honor any specified time limit by splitting the time between both sub-tests. >> Also pick up a sanity check based on JDK-8288497 that I've been using in recent >> stress testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Check in AsyncExceptionHandshake() dtr can assume the caller is a JavaThread. I forgot that install_async_exception() can delete the AsyncExceptionHandshake which calls the AsyncExceptionHandshake dtr: ```--------------- T H R E A D --------------- Current thread (0x0000ffff001bab70): VMThread "VM Thread" [stack: 0x0000fffee8110000,0x0000fffee8310000] [id=661857] _threads_hazard_ptr=0x0000fffc8021f770, _nested_threads_hazard_ptr_cnt=0 Stack: [0x0000fffee8110000,0x0000fffee8310000], sp=0x0000fffee830e030, free space=2040k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1909960] AsyncExceptionHandshake::~AsyncExceptionHandshake()+0x230 V [libjvm.so+0x1908a7c] JavaThread::install_async_exception(AsyncExceptionHandshake*)+0x4c V [libjvm.so+0x190ace8] InstallAsyncExceptionHandshake::do_thread(Thread*)+0x38 V [libjvm.so+0xe67d20] HandshakeOperation::do_handshake(JavaThread*)+0x13c V [libjvm.so+0xe68cec] HandshakeState::try_process(HandshakeOperation*)+0x23c V [libjvm.so+0xe6b384] VM_HandshakeAllThreads::doit()+0x1f4 V [libjvm.so+0x19f2788] VM_Operation::evaluate()+0x168 V [libjvm.so+0x1a1c9d4] VMThread::evaluate_operation(VM_Operation*)+0x154 V [libjvm.so+0x1a1e1bc] VMThread::inner_execute(VM_Operation*)+0x45c V [libjvm.so+0x1a1e374] VMThread::loop()+0xc4 V [libjvm.so+0x1a1e4a0] VMThread::run()+0xcc V [libjvm.so+0x1907bb8] Thread::call_run()+0xf8 V [libjvm.so+0x16033a4] thread_native_entry(Thread*)+0x104 C [libpthread.so.0+0x78f8] start_thread+0x188 Gotta back out last change... and restart all the testing... sigh... ------------- PR: https://git.openjdk.org/jdk19/pull/32 From dcubed at openjdk.org Fri Jun 17 21:43:50 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 17 Jun 2022 21:43:50 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 [v3] In-Reply-To: References: Message-ID: > Update a couple of tests that were modified by JDK-8286830. Now the tests properly > honor any specified time limit by splitting the time between both sub-tests. > Also pick up a sanity check based on JDK-8288497 that I've been using in recent > stress testing. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: VMThread can get to check in AsyncExceptionHandshake() dtr via a bailout. ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/32/files - new: https://git.openjdk.org/jdk19/pull/32/files/6cd771a0..f2baf0b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=32&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=32&range=01-02 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk19/pull/32.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/32/head:pull/32 PR: https://git.openjdk.org/jdk19/pull/32 From iklam at openjdk.org Sat Jun 18 00:59:52 2022 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 18 Jun 2022 00:59:52 GMT Subject: RFR: 8288601: Consolidate static/dynamic archive tables [v2] In-Reply-To: References: Message-ID: > Please review this small clean-up of almost identical code that handles the tables for the static and dynamic archives. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: reverted blank line change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9190/files - new: https://git.openjdk.org/jdk/pull/9190/files/1d15341b..c2626245 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9190&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9190&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9190.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9190/head:pull/9190 PR: https://git.openjdk.org/jdk/pull/9190 From iklam at openjdk.org Sat Jun 18 00:59:54 2022 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 18 Jun 2022 00:59:54 GMT Subject: RFR: 8288601: Consolidate static/dynamic archive tables [v2] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 05:37:33 GMT, Calvin Cheung wrote: > Nice cleanup. Has this changeset gone through any tier(s) testing? Hi Calvin, Thanks for the review. This changeset has passed tiers 1-4. I also removed the blank line change you found. ------------- PR: https://git.openjdk.org/jdk/pull/9190 From sspitsyn at openjdk.org Sat Jun 18 01:27:53 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 18 Jun 2022 01:27:53 GMT Subject: RFR: 8286103: VThreadMonitorTest fails "assert(!current->cont_fastpath() || (current->cont_fastpath_thread_state() && !interpreted_native_or_deoptimized_on_stack(current))) failed" In-Reply-To: <9c6zeRBtbGjRpSGqN81OIRPUyLu-ceV-1gRwA1fWs-U=.87df7fc0-ac51-4742-8dd1-8f8d536a7bb8@github.com> References: <9c6zeRBtbGjRpSGqN81OIRPUyLu-ceV-1gRwA1fWs-U=.87df7fc0-ac51-4742-8dd1-8f8d536a7bb8@github.com> Message-ID: <2yqrdT5UeEqltbbU0xcLAFESJtP_fAnp6qNpdB6J12E=.43c46480-815f-44f4-9caf-92b55324dec9@github.com> On Wed, 15 Jun 2022 11:00:14 GMT, Ron Pressler wrote: > Please review the following fix. > > Detection of a deoptimized frame in thaw was incorrect, as it tested the deoptimization state of a frame object constructed without relevant data. > > Passes loom tiers 1-5. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/18 From duke at openjdk.org Sat Jun 18 01:53:53 2022 From: duke at openjdk.org (kristylee88) Date: Sat, 18 Jun 2022 01:53:53 GMT Subject: RFR: 8288601: Consolidate static/dynamic archive tables [v2] In-Reply-To: References: Message-ID: <5VK8gVfBi0tx7OeCP6gAdLw_TMFIvN1aPezQ4bI2N50=.c5a8953c-1e57-46d6-983a-d1a8338f1c23@github.com> On Sat, 18 Jun 2022 00:59:52 GMT, Ioi Lam wrote: >> Please review this small clean-up of almost identical code that handles the tables for the static and dynamic archives. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > reverted blank line change Marked as reviewed by kristylee88 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/9190 From dcubed at openjdk.org Sat Jun 18 14:05:53 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 18 Jun 2022 14:05:53 GMT Subject: RFR: 8288497: add support for JavaThread::is_oop_safe() [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 15:21:01 GMT, Daniel D. Daugherty wrote: >> A fix to add support for JavaThread::is_gc_barrier_detached() which allows >> us to add checks to detect failures like: >> >> JDK-8288139 JavaThread touches oop after GC barrier is detached >> https://bugs.openjdk.org/browse/JDK-8288139 >> >> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Rename cannot_access_oops_safely to is_oop_safe and invert the function's logic. The latest version's Mach5 Tier[1-7] looks good. Mach5 Tier8 was just started. @dholmes-ora - please re-review when you get the chance. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Sat Jun 18 14:06:57 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 18 Jun 2022 14:06:57 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 15:39:10 GMT, Daniel D. Daugherty wrote: >> Update SharedRuntime::get_java_tid() to verify that the calling thread is safely >> accessing its own threadObj(). This check uses the new is_gc_barrier_detached() >> function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). >> >> The above check was used to reproduce the failure mode without Shenandoah >> and the remainder of the fix relocates the offending code from >> ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of >> removed the 'tid' entry from the ThreadIdTable is still done under the >> protection of the Threads_lock. >> >> This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - update after 8288497 v01 code review changes > - Merge branch 'JDK-8288497' into JDK-8288139 > - update after 8288497 v00 code review changes > - Merge branch 'JDK-8288497' into JDK-8288139 > - 8288139: JavaThread touches oop after GC barrier is detached The latest version's Mach5 Tier[1-7] looks good. Mach5 Tier8 was just started. ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dcubed at openjdk.org Sat Jun 18 14:06:59 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 18 Jun 2022 14:06:59 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 21:43:50 GMT, Daniel D. Daugherty wrote: >> Update a couple of tests that were modified by JDK-8286830. Now the tests properly >> honor any specified time limit by splitting the time between both sub-tests. >> Also pick up a sanity check based on JDK-8288497 that I've been using in recent >> stress testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > VMThread can get to check in AsyncExceptionHandshake() dtr via a bailout. The latest version's Mach5 Tier[1-7] looks good. Mach5 Tier8 was just started. @pchilano - please re-review when you get the chance. ------------- PR: https://git.openjdk.org/jdk19/pull/32 From dholmes at openjdk.org Mon Jun 20 00:11:46 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Jun 2022 00:11:46 GMT Subject: RFR: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test [v2] In-Reply-To: <2EuSSI9VbYx4SqmIjiecMHJhLFwlHEt46NRpspQF0Jk=.7f12155f-f347-4f88-8d0e-048c0dc817d8@github.com> References: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> <2EuSSI9VbYx4SqmIjiecMHJhLFwlHEt46NRpspQF0Jk=.7f12155f-f347-4f88-8d0e-048c0dc817d8@github.com> Message-ID: On Fri, 17 Jun 2022 06:51:51 GMT, KIRIYAMA Takuya wrote: >> I would like to fix 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test. >> >> FlightRecorder option has not been tested since JDK13. >> I think we should test it, because FlightRecorder option has not been obsolete in the latest JDK. >> Users would be in trouble if the option suddenly disappears without notice, >> so it's important to confirm the deprication message. >> >> Also we should add a test of ExtendedDTraceProbes option. >> The test was disabled in 8281675, because some jdk can't specify it. >> I modified the test to be able to verify ExtendedDTraceProbes in either case that DTRACE_ENABLED is enabled or not. > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test Changes requested by dholmes (Reviewer). test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 103: > 101: String match = getDeprecationString(jfrOptionNames[0]); > 102: output.shouldMatch(match); > 103: } This is not the way to handle this. In the static block that initializes the set of flags to test you should do something like: if (wb.isJFRIncluded()) { deprecated.add("FlightRecorder", false); } before line 70. ------------- PR: https://git.openjdk.org/jdk/pull/9123 From dholmes at openjdk.org Mon Jun 20 00:54:52 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Jun 2022 00:54:52 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v3] In-Reply-To: References: Message-ID: <50MGGIvqUupuM9a4tIl3pZuceR5bWlmaPGoAYM3ZDdM=.785d5f52-6ede-4f14-9fac-03ef28be38cb@github.com> On Fri, 17 Jun 2022 15:39:10 GMT, Daniel D. Daugherty wrote: >> Update SharedRuntime::get_java_tid() to verify that the calling thread is safely >> accessing its own threadObj(). This check uses the new is_gc_barrier_detached() >> function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). >> >> The above check was used to reproduce the failure mode without Shenandoah >> and the remainder of the fix relocates the offending code from >> ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of >> removed the 'tid' entry from the ThreadIdTable is still done under the >> protection of the Threads_lock. >> >> This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - update after 8288497 v01 code review changes > - Merge branch 'JDK-8288497' into JDK-8288139 > - update after 8288497 v00 code review changes > - Merge branch 'JDK-8288497' into JDK-8288139 > - 8288139: JavaThread touches oop after GC barrier is detached Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dholmes at openjdk.org Mon Jun 20 01:41:53 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Jun 2022 01:41:53 GMT Subject: RFR: 8288497: add support for JavaThread::is_oop_safe() [v3] In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 16:10:55 GMT, Daniel D. Daugherty wrote: >> It is a bogus comment - acquire semantics has nothing to do with seeing things more quickly. > > I'm pretty sure that I wrote the original comment and you were one of my > reviewers way, way back then. > > When we were trying to match up the load-acquires in the accessors with > the in-line release-store code in JavaThread::exit(), the comment was needed > (ignoring the part about "seeing things more quickly"). Now that we have > load-acquires in the accessors and a release-store in the setter, i.e., no more > in-line code in JavaThread::exit(), I no longer think we need a comment to > coordinate. > > I'm in favor of dropping all instances of this comment. Sounds good. FTR this came in with the Thread-SMR changes which were reviewed over a period of many months with some "vigorous" discussion. :) I think by the time this particular code appeared the focus was on bigger issues. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dholmes at openjdk.org Mon Jun 20 01:50:46 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Jun 2022 01:50:46 GMT Subject: RFR: 8288497: add support for JavaThread::is_oop_safe() [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 15:21:01 GMT, Daniel D. Daugherty wrote: >> A fix to add support for JavaThread::is_gc_barrier_detached() which allows >> us to add checks to detect failures like: >> >> JDK-8288139 JavaThread touches oop after GC barrier is detached >> https://bugs.openjdk.org/browse/JDK-8288139 >> >> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Rename cannot_access_oops_safely to is_oop_safe and invert the function's logic. Thanks for the updates Dan and your patience. One minor query/suggestion below, but this is good as-is. Thanks. src/hotspot/share/runtime/thread.inline.hpp line 269: > 267: } > 268: > 269: inline bool JavaThread::is_oop_safe() const { Do we want to document, and assert, that this is only intended for use by the current thread on itself? I can't imagine any scenario where we would need to ask whether an arbitrary thread is oop-safe. ?? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk19/pull/20 From dholmes at openjdk.org Mon Jun 20 01:58:56 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Jun 2022 01:58:56 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 21:43:50 GMT, Daniel D. Daugherty wrote: >> Update a couple of tests that were modified by JDK-8286830. Now the tests properly >> honor any specified time limit by splitting the time between both sub-tests. >> Also pick up a sanity check based on JDK-8288497 that I've been using in recent >> stress testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > VMThread can get to check in AsyncExceptionHandshake() dtr via a bailout. Changes seem fine. It will be nice when the oop-safety check can be handled in OopHandler::release. Thanks, David test/hotspot/jtreg/runtime/Thread/StopAtExit.java line 79: > 77: test(timeMax); > 78: > 79: // Fire-up deamon that just creates new threads. This generates contention on Existing typo: s/deamon/daemon/ ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk19/pull/32 From dholmes at openjdk.org Mon Jun 20 02:09:53 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Jun 2022 02:09:53 GMT Subject: RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 07:47:02 GMT, Thomas Stuefe wrote: > The VM uses SIGUSR2 (can be overridden via _JAVA_SR_SIGNUM) to implement suspend/resume on java threads. It sends, via pthread_kill, SIGUSR2 to targeted threads to interrupt them. It knows the target thread, and the target thread is always a VM-attached thread. > > However, if SIGUSR2 gets sent from outside, any thread may receive the signal, and if the target thread is not attached to the VM (e.g. primordial), it is unable to handle it. The result is an assert (debug VM) or a crash (release VM). On my box, this can be reliably reproduced by sending SIGUSR2 to any VM. > > This has been discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2022-June/091450.html > > The proposed solutions range from "works as designed" (on the ground that sending arbitrary signals to the JVM is an error in itself, and we should rather crash hard and fast) to "lets catch and ignore the signal". > > ---- > > In this patch I opt for: > > - Debug: keep asserting, but make the message more helpful by including signal info for the stray SR signal. Includes sender pid and signal number (in case SR signal had been overridden). > > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/shared/projects/openjdk/jdk-jdk/source/src/hotspot/os/posix/signals_posix.cpp:1611), pid=139712, tid=139712 > # assert(thread != __null) failed: Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 6681, si_uid: 1027).. > > - Release: write a message to tty about this signal, including sender pid and signal name. Otherwise, ignore the signal, dont crash. Repeated signals will generate repeated output: > > > thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -cp $REPROS_JAR de.stuefe.repros.Simple > > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239773, si_uid: 1027). > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239774, si_uid: 1027). > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239775, si_uid: 1027). > > > Notes: > - In release builds, we also could quit the VM instead of continuing. I prefer gracefully ignoring the signal, because in our experience quitting - regardless of how good the diagnostic message is - often just leads to frustrated users complaining about VMs mysteriously vanishing. Same goes for crashes, it just pools into the general "java is unstable" notion. I'm open for discussing this. > - I use tty for the diagnostic message, which goes to stdout. I really dislike that, error output should go to stderr. But since the rest of the VM handles diagnostic output the same way, I use tty here too. > > Thanks, Thomas As per the discussion this is a much broader problem as it could apply to a range of signals and can be wrong even if the thread is not attached. Even if you want to restrict this to SR_SIGNUM the current proposal only handles one case. src/hotspot/os/posix/signals_posix.cpp line 1613: > 1611: ss.print_raw(")."); > 1612: assert(thread != NULL, "%s.", ss.base()); > 1613: tty->print_cr("%s", ss.base()); Surely this should be a regular VM warning not a raw write to tty - neither of which are signal-safe. ------------- PR: https://git.openjdk.org/jdk/pull/9181 From stuefe at openjdk.org Mon Jun 20 05:29:53 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 20 Jun 2022 05:29:53 GMT Subject: RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 07:47:02 GMT, Thomas Stuefe wrote: > The VM uses SIGUSR2 (can be overridden via _JAVA_SR_SIGNUM) to implement suspend/resume on java threads. It sends, via pthread_kill, SIGUSR2 to targeted threads to interrupt them. It knows the target thread, and the target thread is always a VM-attached thread. > > However, if SIGUSR2 gets sent from outside, any thread may receive the signal, and if the target thread is not attached to the VM (e.g. primordial), it is unable to handle it. The result is an assert (debug VM) or a crash (release VM). On my box, this can be reliably reproduced by sending SIGUSR2 to any VM. > > This has been discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2022-June/091450.html > > The proposed solutions range from "works as designed" (on the ground that sending arbitrary signals to the JVM is an error in itself, and we should rather crash hard and fast) to "lets catch and ignore the signal". > > ---- > > In this patch I opt for: > > - Debug: keep asserting, but make the message more helpful by including signal info for the stray SR signal. Includes sender pid and signal number (in case SR signal had been overridden). > > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/shared/projects/openjdk/jdk-jdk/source/src/hotspot/os/posix/signals_posix.cpp:1611), pid=139712, tid=139712 > # assert(thread != __null) failed: Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 6681, si_uid: 1027).. > > - Release: write a message to tty about this signal, including sender pid and signal name. Otherwise, ignore the signal, dont crash. Repeated signals will generate repeated output: > > > thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -cp $REPROS_JAR de.stuefe.repros.Simple > > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239773, si_uid: 1027). > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239774, si_uid: 1027). > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239775, si_uid: 1027). > > > Notes: > - In release builds, we also could quit the VM instead of continuing. I prefer gracefully ignoring the signal, because in our experience quitting - regardless of how good the diagnostic message is - often just leads to frustrated users complaining about VMs mysteriously vanishing. Same goes for crashes, it just pools into the general "java is unstable" notion. I'm open for discussing this. > - I use tty for the diagnostic message, which goes to stdout. I really dislike that, error output should go to stderr. But since the rest of the VM handles diagnostic output the same way, I use tty here too. > > Thanks, Thomas Hi David, > As per the discussion this is a much broader problem as it could apply to a range of signals and can be wrong even if the thread is not attached. Even if you want to restrict this to SR_SIGNUM the current proposal only handles one case. I disagree about this being a large issue. Quoting https://mail.openjdk.org/pipermail/core-libs-dev/2022-June/091577.html *I'd say we limit this to* *1) signal for which we registered handlers: the handlers should at least not crash or vanish the VM without a trace* *2) signals which may conceivably be sent to the VM in the normal course of events: if the default action is to terminate the VM, we should handle them* The (1) set is rather small and contains: - SEGV, ILL, FPE, BUS: These should crash, so crashing out the VM if the signal is sent manually is reasonable (in fact, I use this sometimes). - TRAP (power only): Used by the compiler; relies not on Thread::current, just on the pc from the context. Sending it from outside should be benign. - PIPE, XFSZ: As I wrote in the mail thread, we already gracefully ignore these signals when receiving them, for both debug and release builds. - QUIT (BREAK_SIGNAL): We assert !ReduceSignalUsage in debug. In Release, we gracefully ignore this signal. - HUP, SIGTERM (SHUTDOWN1_SIGNAL, SHUTDOWN3_SIGNAL): End the VM immediately as expected. - QUIT (SHUTDOWN2_SIGNAL): Prints thread dump. Does not shutdown the VM. All of these signals are already handled correctly. Note that with several of them (PIPE, XFSZ) we already established the pattern of ignoring signals instead of vanishing the VM. The set (2) is atm unknown to me. Are there any more? SIGCHILD is ignored by default. SIGUSR1 exists and exits the VM; this may be another case, but atm we don't handle it and I would not add a handler to it since user apps may use this signal. Any others? ---- The way I see it, my patch would introduce the same handling for SIGUSR2 we already have established for SIGPIPE, SIGXFSZ, and arguably for SIGINT. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/9181 From dholmes at openjdk.org Mon Jun 20 07:37:05 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Jun 2022 07:37:05 GMT Subject: RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside In-Reply-To: References: Message-ID: <7aW_f0wY3yOQQHqCnbuXEFRqrQVUbXIY0yvMH4ZV1gE=.404eee0b-bce3-41b0-9747-ea8ebfd3125e@github.com> On Thu, 16 Jun 2022 07:47:02 GMT, Thomas Stuefe wrote: > The VM uses SIGUSR2 (can be overridden via _JAVA_SR_SIGNUM) to implement suspend/resume on java threads. It sends, via pthread_kill, SIGUSR2 to targeted threads to interrupt them. It knows the target thread, and the target thread is always a VM-attached thread. > > However, if SIGUSR2 gets sent from outside, any thread may receive the signal, and if the target thread is not attached to the VM (e.g. primordial), it is unable to handle it. The result is an assert (debug VM) or a crash (release VM). On my box, this can be reliably reproduced by sending SIGUSR2 to any VM. > > This has been discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2022-June/091450.html > > The proposed solutions range from "works as designed" (on the ground that sending arbitrary signals to the JVM is an error in itself, and we should rather crash hard and fast) to "lets catch and ignore the signal". > > ---- > > In this patch I opt for: > > - Debug: keep asserting, but make the message more helpful by including signal info for the stray SR signal. Includes sender pid and signal number (in case SR signal had been overridden). > > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/shared/projects/openjdk/jdk-jdk/source/src/hotspot/os/posix/signals_posix.cpp:1611), pid=139712, tid=139712 > # assert(thread != __null) failed: Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 6681, si_uid: 1027).. > > - Release: write a message to tty about this signal, including sender pid and signal name. Otherwise, ignore the signal, dont crash. Repeated signals will generate repeated output: > > > thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -cp $REPROS_JAR de.stuefe.repros.Simple > > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239773, si_uid: 1027). > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239774, si_uid: 1027). > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239775, si_uid: 1027). > > > Notes: > - In release builds, we also could quit the VM instead of continuing. I prefer gracefully ignoring the signal, because in our experience quitting - regardless of how good the diagnostic message is - often just leads to frustrated users complaining about VMs mysteriously vanishing. Same goes for crashes, it just pools into the general "java is unstable" notion. I'm open for discussing this. > - I use tty for the diagnostic message, which goes to stdout. I really dislike that, error output should go to stderr. But since the rest of the VM handles diagnostic output the same way, I use tty here too. > > Thanks, Thomas Hi Thomas, Okay I see SIGUSR2 (or more generally SR_SIGNUM) is special in that regard: it is an internal-use-only non-terminating signal. But any external sending of SIGUSR2 is invalid regardless of whether an attached or not-attached thread handles it. ------------- PR: https://git.openjdk.org/jdk/pull/9181 From stuefe at openjdk.org Mon Jun 20 08:05:55 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 20 Jun 2022 08:05:55 GMT Subject: RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside In-Reply-To: <7aW_f0wY3yOQQHqCnbuXEFRqrQVUbXIY0yvMH4ZV1gE=.404eee0b-bce3-41b0-9747-ea8ebfd3125e@github.com> References: <7aW_f0wY3yOQQHqCnbuXEFRqrQVUbXIY0yvMH4ZV1gE=.404eee0b-bce3-41b0-9747-ea8ebfd3125e@github.com> Message-ID: <0netpkNph4rKWn46Z2ktX3gA77N8GVyMfK-XvXWgZwc=.62c6253d-c58c-4381-850e-d4c180589910@github.com> On Mon, 20 Jun 2022 07:35:04 GMT, David Holmes wrote: > Hi Thomas, > > Okay I see SIGUSR2 (or more generally SR_SIGNUM) is special in that regard: it is an internal-use-only non-terminating signal. But any external sending of SIGUSR2 is invalid regardless of whether an attached or not-attached thread handles it. So, should I fail if si_pid!=getpid? As I wrote, I was a bit worried that some OSes may not deliver the correct pid in si_pid - either deliver the kernel thread id or leave it empty. I have dim recollections of such errors on AIX or HPUX. So far, we use si_pid only for displaying purposes and don't really rely on it being correct. Another issue, I tried the patch with redefining SR_SIGNUM and found that I could not use SIGUSR1 on Linux because its numerical value (10) is below SIGSEGV(11) on my box and we have this code: https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/0a5f5770612cd8523ff0c16b240faf8498b94043/src/hotspot/os/posix/signals_posix.cpp*L1684-L1689__;Iw!!ACWV5N9M2RV99hQ!Ihm8CFH8kEeicajmh-yt1SPmh_STLxiHXl56_91fA1VbTrPX3W9vlyxoKEiXJL0HY_JEKkCo5plteewO5PmRc3NerXYz$ Do you think this is fix-worthy? SIGUSR1 seems an obvious choice for an alternate SR signal, but OTOH nobody complained in 20+ years. ------------- PR: https://git.openjdk.org/jdk/pull/9181 From stuefe at openjdk.org Mon Jun 20 08:21:57 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 20 Jun 2022 08:21:57 GMT Subject: RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside In-Reply-To: <0netpkNph4rKWn46Z2ktX3gA77N8GVyMfK-XvXWgZwc=.62c6253d-c58c-4381-850e-d4c180589910@github.com> References: <7aW_f0wY3yOQQHqCnbuXEFRqrQVUbXIY0yvMH4ZV1gE=.404eee0b-bce3-41b0-9747-ea8ebfd3125e@github.com> <0netpkNph4rKWn46Z2ktX3gA77N8GVyMfK-XvXWgZwc=.62c6253d-c58c-4381-850e-d4c180589910@github.com> Message-ID: On Mon, 20 Jun 2022 08:02:36 GMT, Thomas Stuefe wrote: > Another issue, I tried the patch with redefining SR_SIGNUM and found that I could not use SIGUSR1 on Linux because its numerical value (10) is below SIGSEGV(11) on my box and we have this code: > > https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/0a5f5770612cd8523ff0c16b240faf8498b94043/src/hotspot/os/posix/signals_posix.cpp*L1684-L1689__;Iw!!ACWV5N9M2RV99hQ!Ndl79VsW_OfatocPfBl3W4JtFwX05nUiQiF5X9ovSXN8OcN9CYDFM0WV-Zv-BZ6FWbQeLgffH2UKn8FQefxdsk3QCjmw$ > > Do you think this is fix-worthy? SIGUSR1 seems an obvious choice for an alternate SR signal, but OTOH nobody complained in 20+ years. I read up on this in the very good analysis at: https://bugs.openjdk.org/browse/JDK-4355769?focusedCommentId=12425929&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-12425929 . This was a wild read :) I continue to be impressed by the quality of bug reports in JBS. Seems more complicated than I thought. I am not sure how much of this is till valid today. This was 21 years ago. I'm surprised by the described behaviour though, that SIGUSR2 can interrupt delivery of error signals; I would have naively thought that signal delivery is on a strict first come first deliver base. ------------- PR: https://git.openjdk.org/jdk/pull/9181 From stuefe at openjdk.org Mon Jun 20 10:37:11 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 20 Jun 2022 10:37:11 GMT Subject: RFR: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes random crashes Message-ID: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com> After [JDK-8284997](https://bugs.openjdk.org/browse/JDK-8284997) delivered just a bandaid, this is hopefully the real fix. JDK-8283326 re-implemented SafeFetch as static assembler functions. This broke arm: the VM would crash at random points, usually in Atomic::add(), usually right at startup. In most cases the VM could not even be built correctly, see JDK-8284997. This was only reproducible if the VM was built natively, on a Raspberry Pi, inside an Ubuntu18-derived container. Buiding natively on Raspberry Pi OS was fine. Cross-building was fine too. The difference is the default instruction set the toolchain uses. We don't explicitly specify `-mthumb` or `-marm`, so we use the toolchain's default. That default seems to depend on how GCC itself was built. Ubuntu ships a GCC that has been built in thumb mode, thus defaulting to `-mthumb`, whereas Raspberry Pi OS and Fedora ship GCCs that default to `-marm`. So, the VM proper is compiled either to arm or thumb code. The `SafeFetch32` assembly function itself uses arm code always. Why this is I don't know for sure, I assume if I wanted thumb I need to specify `.thumb_func` in the assembly. If the VM uses thumb, it needs to call SafeFetch32 with a switching branch instruction (BX). But the compiler-generated BL. The instruction set was not switched upon entering SafeFetch32 and garbage thumb code was executed. VM crashes soon after. This seems to be a common problem when writing arm assembly by hand, the solution is specify `.type function`. See also [1]: "As of GCC 4.7, the .type directive is pretty much required for functions. Or, rather, it is required if you want ARM and Thumb interworking to work." A remaining question is whether we should specify the instruction set explicitly when building on arm32, to prevent surprises like this. Preferably with a configure option. ---- Testing: - GHAs are green, but that does not say much: they just do the usual cross building without running the executables. Even if they would run, they would be compiled with -marm and not show the default - Both @marchof and me tested the fix with a native build on Raspberry Pi. I confirmed that the patch fixes the problem. I ran gtests, which also tests SafeFetch ------------- Commit messages: - Use real static safefetch on linux arm Changes: https://git.openjdk.org/jdk/pull/9213/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9213&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288719 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9213.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9213/head:pull/9213 PR: https://git.openjdk.org/jdk/pull/9213 From dholmes at openjdk.org Mon Jun 20 12:52:59 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 20 Jun 2022 12:52:59 GMT Subject: RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 07:47:02 GMT, Thomas Stuefe wrote: > The VM uses SIGUSR2 (can be overridden via _JAVA_SR_SIGNUM) to implement suspend/resume on java threads. It sends, via pthread_kill, SIGUSR2 to targeted threads to interrupt them. It knows the target thread, and the target thread is always a VM-attached thread. > > However, if SIGUSR2 gets sent from outside, any thread may receive the signal, and if the target thread is not attached to the VM (e.g. primordial), it is unable to handle it. The result is an assert (debug VM) or a crash (release VM). On my box, this can be reliably reproduced by sending SIGUSR2 to any VM. > > This has been discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2022-June/091450.html > > The proposed solutions range from "works as designed" (on the ground that sending arbitrary signals to the JVM is an error in itself, and we should rather crash hard and fast) to "lets catch and ignore the signal". > > ---- > > In this patch I opt for: > > - Debug: keep asserting, but make the message more helpful by including signal info for the stray SR signal. Includes sender pid and signal number (in case SR signal had been overridden). > > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/shared/projects/openjdk/jdk-jdk/source/src/hotspot/os/posix/signals_posix.cpp:1611), pid=139712, tid=139712 > # assert(thread != __null) failed: Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 6681, si_uid: 1027).. > > - Release: write a message to tty about this signal, including sender pid and signal name. Otherwise, ignore the signal, dont crash. Repeated signals will generate repeated output: > > > thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -cp $REPROS_JAR de.stuefe.repros.Simple > > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239773, si_uid: 1027). > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239774, si_uid: 1027). > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239775, si_uid: 1027). > > > Notes: > - In release builds, we also could quit the VM instead of continuing. I prefer gracefully ignoring the signal, because in our experience quitting - regardless of how good the diagnostic message is - often just leads to frustrated users complaining about VMs mysteriously vanishing. Same goes for crashes, it just pools into the general "java is unstable" notion. I'm open for discussing this. > - I use tty for the diagnostic message, which goes to stdout. I really dislike that, error output should go to stderr. But since the rest of the VM handles diagnostic output the same way, I use tty here too. > > Thanks, Thomas As the saying goes "it's complicated". Whether Linux signal delivery has the same properties today I have no idea. I'm somewhat bemused that SIGUSR1 and SIGUSR2 are not adjacent signals - weird design to say the least. I also don't understand how you can possibly get two signals pending like that at the same time when one is synchronous and the other asynchronous. 4355769 is an interesting read but I'm not sure I can really agree with the analysis (and note that one comment seems to contradict an earlier one, so exactly what happened is unclear). So yeah setting an alternative SR_SIGNUM is problematic. On the si_pid part ... I have no prior knowledge of this (didn't even know it existed), so have no idea whether it is reliable or not. Seems to me we have far greater risk of breaking something unexpectedly with changing this code than we potentially benefit from making the change. So I'd vote for doing nothing. ------------- PR: https://git.openjdk.org/jdk/pull/9181 From stuefe at openjdk.org Mon Jun 20 13:07:51 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 20 Jun 2022 13:07:51 GMT Subject: RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside In-Reply-To: References: Message-ID: On Mon, 20 Jun 2022 12:48:49 GMT, David Holmes wrote: > > On the si_pid part ... I have no prior knowledge of this (didn't even know it existed), so have no idea whether it is reliable or not. > > Seems to me we have far greater risk of breaking something unexpectedly with changing this code than we potentially benefit from making the change. > > So I'd vote for doing nothing. "Nothing" as in I should withdraw this patch? Surely not? The behavioral difference my patch brings would be: debug: assert with useless information -> assert with useful information release: crash with useless report -> print useful information, continue As I wrote, I can compromise the second part to: release: crash with useless report -> print useful information, exit VM ------------- PR: https://git.openjdk.org/jdk/pull/9181 From snazarki at openjdk.org Mon Jun 20 18:54:46 2022 From: snazarki at openjdk.org (Sergey Nazarkin) Date: Mon, 20 Jun 2022 18:54:46 GMT Subject: RFR: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes random crashes In-Reply-To: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com> References: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com> Message-ID: On Mon, 20 Jun 2022 08:24:49 GMT, Thomas Stuefe wrote: > After [JDK-8284997](https://bugs.openjdk.org/browse/JDK-8284997) delivered just a bandaid, this is hopefully the real fix. > > JDK-8283326 re-implemented SafeFetch as static assembler functions. This broke arm: the VM would crash at random points, usually in Atomic::add(), usually right at startup. In most cases the VM could not even be built correctly, see JDK-8284997. > > This was only reproducible if the VM was built natively, on a Raspberry Pi, inside an Ubuntu18-derived container. Buiding natively on Raspberry Pi OS was fine. Cross-building was fine too. The difference is the default instruction set the toolchain uses. We don't explicitly specify `-mthumb` or `-marm`, so we use the toolchain's default. That default seems to depend on how GCC itself was built. Ubuntu ships a GCC that has been built in thumb mode, thus defaulting to `-mthumb`, whereas Raspberry Pi OS and Fedora ship GCCs that default to `-marm`. > > So, the VM proper is compiled either to arm or thumb code. The `SafeFetch32` assembly function itself uses arm code always. Why this is I don't know for sure, I assume if I wanted thumb I need to specify `.thumb_func` in the assembly. > > If the VM uses thumb, it needs to call SafeFetch32 with a switching branch instruction (BX). But the compiler-generated BL. The instruction set was not switched upon entering SafeFetch32 and garbage thumb code was executed. VM crashes soon after. > > This seems to be a common problem when writing arm assembly by hand, the solution is specify `.type function`. See also [1]: "As of GCC 4.7, the .type directive is pretty much required for functions. Or, rather, it is required if you want ARM and Thumb interworking to work." > > A remaining question is whether we should specify the instruction set explicitly when building on arm32, to prevent surprises like this. Preferably with a configure option. > > ---- > > Testing: > - GHAs are green, but that does not say much: they just do the usual cross building without running the executables. Even if they would run, they would be compiled with -marm and not show the default > - Both @marchof and me tested the fix with a native build on Raspberry Pi. I confirmed that the patch fixes the problem. I ran gtests, which also tests SafeFetch Marked as reviewed by snazarki (no project role). Now I remember jdk8 aarch32 port marks assembly functions specially to handle thumb interworking. AFAIK the bug can be reproduced with overridden C(XX)FLAGS=-mthumb even with crossbuilds. LGTM ------------- PR: https://git.openjdk.org/jdk/pull/9213 From dholmes at openjdk.org Tue Jun 21 00:15:58 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Jun 2022 00:15:58 GMT Subject: RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside In-Reply-To: References: Message-ID: <71npL3Y3iHODd-awkdpKhU1jh0ZXFh19iN2RVuYRtcI=.43400e70-57bd-4da6-9f52-4138f9bfefb0@github.com> On Thu, 16 Jun 2022 07:47:02 GMT, Thomas Stuefe wrote: > The VM uses SIGUSR2 (can be overridden via _JAVA_SR_SIGNUM) to implement suspend/resume on java threads. It sends, via pthread_kill, SIGUSR2 to targeted threads to interrupt them. It knows the target thread, and the target thread is always a VM-attached thread. > > However, if SIGUSR2 gets sent from outside, any thread may receive the signal, and if the target thread is not attached to the VM (e.g. primordial), it is unable to handle it. The result is an assert (debug VM) or a crash (release VM). On my box, this can be reliably reproduced by sending SIGUSR2 to any VM. > > This has been discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2022-June/091450.html > > The proposed solutions range from "works as designed" (on the ground that sending arbitrary signals to the JVM is an error in itself, and we should rather crash hard and fast) to "lets catch and ignore the signal". > > ---- > > In this patch I opt for: > > - Debug: keep asserting, but make the message more helpful by including signal info for the stray SR signal. Includes sender pid and signal number (in case SR signal had been overridden). > > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/shared/projects/openjdk/jdk-jdk/source/src/hotspot/os/posix/signals_posix.cpp:1611), pid=139712, tid=139712 > # assert(thread != __null) failed: Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 6681, si_uid: 1027).. > > - Release: write a message to tty about this signal, including sender pid and signal name. Otherwise, ignore the signal, dont crash. Repeated signals will generate repeated output: > > > thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -cp $REPROS_JAR de.stuefe.repros.Simple > > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239773, si_uid: 1027). > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239774, si_uid: 1027). > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239775, si_uid: 1027). > > > Notes: > - In release builds, we also could quit the VM instead of continuing. I prefer gracefully ignoring the signal, because in our experience quitting - regardless of how good the diagnostic message is - often just leads to frustrated users complaining about VMs mysteriously vanishing. Same goes for crashes, it just pools into the general "java is unstable" notion. I'm open for discussing this. > - I use tty for the diagnostic message, which goes to stdout. I really dislike that, error output should go to stderr. But since the rest of the VM handles diagnostic output the same way, I use tty here too. > > Thanks, Thomas Given you have done the work I can review the patch - we just need to resolve the tty vs. VM warning issue. But I don't see a need to make any actual changes here. ------------- PR: https://git.openjdk.org/jdk/pull/9181 From yyang at openjdk.org Tue Jun 21 02:44:53 2022 From: yyang at openjdk.org (Yi Yang) Date: Tue, 21 Jun 2022 02:44:53 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v4] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 07:02:47 GMT, Yi Yang wrote: >> It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. >> >> Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` >> >> ==> CodeHeap 'non-nmethods' 1532544 (Used) >> ==> CodeHeap 'profiled nmethods' 0 >> ==> CodeHeap 'non-profiled nmethods' 13952 >> ==> Metaspace 506696 >> ==> Compressed Class Space 43312 >> init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) >> >> In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`. > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > address Ioi's comments; fix LowMemoryTest2.sh failure > I would have thought that since we don't have the pool anymore, we can just remove this test line. The lines above already test against MaxMetaspaceSize. Okay. > I think you may be right, we need a replacement for the old memory bean for these tests. Whitebox seems easiest. So should we keep tests as it is or add a new whitebox API and discard existing test changes? I prefer to keep tests as it is rather than adding whitebox API since I've made a lot of test changes. But I also want to hear your expert suggestions as final conclusion. ------------- PR: https://git.openjdk.org/jdk/pull/8831 From stuefe at openjdk.org Tue Jun 21 05:20:47 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 21 Jun 2022 05:20:47 GMT Subject: RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside [v2] In-Reply-To: References: Message-ID: On Mon, 20 Jun 2022 02:04:18 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> use log_warning(os) instead of tty printing > > src/hotspot/os/posix/signals_posix.cpp line 1613: > >> 1611: ss.print_raw(")."); >> 1612: assert(thread != NULL, "%s.", ss.base()); >> 1613: tty->print_cr("%s", ss.base()); > > Surely this should be a regular VM warning not a raw write to tty - neither of which are signal-safe. Okay, I changed this to log_warning(os). ------------- PR: https://git.openjdk.org/jdk/pull/9181 From stuefe at openjdk.org Tue Jun 21 05:20:46 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 21 Jun 2022 05:20:46 GMT Subject: RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside [v2] In-Reply-To: References: Message-ID: > The VM uses SIGUSR2 (can be overridden via _JAVA_SR_SIGNUM) to implement suspend/resume on java threads. It sends, via pthread_kill, SIGUSR2 to targeted threads to interrupt them. It knows the target thread, and the target thread is always a VM-attached thread. > > However, if SIGUSR2 gets sent from outside, any thread may receive the signal, and if the target thread is not attached to the VM (e.g. primordial), it is unable to handle it. The result is an assert (debug VM) or a crash (release VM). On my box, this can be reliably reproduced by sending SIGUSR2 to any VM. > > This has been discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2022-June/091450.html > > The proposed solutions range from "works as designed" (on the ground that sending arbitrary signals to the JVM is an error in itself, and we should rather crash hard and fast) to "lets catch and ignore the signal". > > ---- > > In this patch I opt for: > > - Debug: keep asserting, but make the message more helpful by including signal info for the stray SR signal. Includes sender pid and signal number (in case SR signal had been overridden). > > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/shared/projects/openjdk/jdk-jdk/source/src/hotspot/os/posix/signals_posix.cpp:1611), pid=139712, tid=139712 > # assert(thread != __null) failed: Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 6681, si_uid: 1027).. > > - Release: write a message to tty about this signal, including sender pid and signal name. Otherwise, ignore the signal, dont crash. Repeated signals will generate repeated output: > > > thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -cp $REPROS_JAR de.stuefe.repros.Simple > > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239773, si_uid: 1027). > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239774, si_uid: 1027). > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239775, si_uid: 1027). > > > Notes: > - In release builds, we also could quit the VM instead of continuing. I prefer gracefully ignoring the signal, because in our experience quitting - regardless of how good the diagnostic message is - often just leads to frustrated users complaining about VMs mysteriously vanishing. Same goes for crashes, it just pools into the general "java is unstable" notion. I'm open for discussing this. > - I use tty for the diagnostic message, which goes to stdout. I really dislike that, error output should go to stderr. But since the rest of the VM handles diagnostic output the same way, I use tty here too. > > Thanks, Thomas Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: use log_warning(os) instead of tty printing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9181/files - new: https://git.openjdk.org/jdk/pull/9181/files/0a5f5770..1679a419 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9181&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9181&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9181.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9181/head:pull/9181 PR: https://git.openjdk.org/jdk/pull/9181 From iklam at openjdk.org Tue Jun 21 05:24:55 2022 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 21 Jun 2022 05:24:55 GMT Subject: Integrated: 8288601: Consolidate static/dynamic archive tables In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 17:48:09 GMT, Ioi Lam wrote: > Please review this small clean-up of almost identical code that handles the tables for the static and dynamic archives. This pull request has now been integrated. Changeset: ad891461 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/ad8914616bd63f628e5b6472f1f48315dacfbc94 Stats: 114 lines in 4 files changed: 34 ins; 42 del; 38 mod 8288601: Consolidate static/dynamic archive tables Reviewed-by: ccheung ------------- PR: https://git.openjdk.org/jdk/pull/9190 From stuefe at openjdk.org Tue Jun 21 05:27:54 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 21 Jun 2022 05:27:54 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v4] In-Reply-To: References: Message-ID: On Tue, 21 Jun 2022 02:41:35 GMT, Yi Yang wrote: > > I would have thought that since we don't have the pool anymore, we can just remove this test line. The lines above already > > test against MaxMetaspaceSize. > > Okay. > > > I think you may be right, we need a replacement for the old memory bean for these tests. Whitebox seems easiest. > > So should we keep test changes as it is or discard existing test changes and then rewrite related tests via new compressed class space query whitebox API? I prefer to keep tests as it is rather than adding whitebox API since I've made a lot of test changes. But I also want to hear your expert suggestions as final conclusion. I think the easier way would be actually to add a whitebox API for class space use, as @iklam suggested, and just replace the memory pool usage calls with that one. That would be a purely mechanical change if a bit onerous. But since the metaspace itself did not change, the numbers are the same, so the tests test the same. Still easier than trying to think through the changed semantics for each test. Sorry that this seems to have exploded in complexity :-( ------------- PR: https://git.openjdk.org/jdk/pull/8831 From dholmes at openjdk.org Tue Jun 21 05:29:52 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Jun 2022 05:29:52 GMT Subject: RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside [v2] In-Reply-To: References: Message-ID: On Tue, 21 Jun 2022 05:20:46 GMT, Thomas Stuefe wrote: >> The VM uses SIGUSR2 (can be overridden via _JAVA_SR_SIGNUM) to implement suspend/resume on java threads. It sends, via pthread_kill, SIGUSR2 to targeted threads to interrupt them. It knows the target thread, and the target thread is always a VM-attached thread. >> >> However, if SIGUSR2 gets sent from outside, any thread may receive the signal, and if the target thread is not attached to the VM (e.g. primordial), it is unable to handle it. The result is an assert (debug VM) or a crash (release VM). On my box, this can be reliably reproduced by sending SIGUSR2 to any VM. >> >> This has been discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2022-June/091450.html >> >> The proposed solutions range from "works as designed" (on the ground that sending arbitrary signals to the JVM is an error in itself, and we should rather crash hard and fast) to "lets catch and ignore the signal". >> >> ---- >> >> In this patch I opt for: >> >> - Debug: keep asserting, but make the message more helpful by including signal info for the stray SR signal. Includes sender pid and signal number (in case SR signal had been overridden). >> >> >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/shared/projects/openjdk/jdk-jdk/source/src/hotspot/os/posix/signals_posix.cpp:1611), pid=139712, tid=139712 >> # assert(thread != __null) failed: Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 6681, si_uid: 1027).. >> >> - Release: write a message to tty about this signal, including sender pid and signal name. Otherwise, ignore the signal, dont crash. Repeated signals will generate repeated output: >> >> >> thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -cp $REPROS_JAR de.stuefe.repros.Simple >> >> Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239773, si_uid: 1027). >> Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239774, si_uid: 1027). >> Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239775, si_uid: 1027). >> >> >> Notes: >> - In release builds, we also could quit the VM instead of continuing. I prefer gracefully ignoring the signal, because in our experience quitting - regardless of how good the diagnostic message is - often just leads to frustrated users complaining about VMs mysteriously vanishing. Same goes for crashes, it just pools into the general "java is unstable" notion. I'm open for discussing this. >> - I use tty for the diagnostic message, which goes to stdout. I really dislike that, error output should go to stderr. But since the rest of the VM handles diagnostic output the same way, I use tty here too. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > use log_warning(os) instead of tty printing Thanks Thomas! ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9181 From alanb at openjdk.org Tue Jun 21 06:39:18 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 21 Jun 2022 06:39:18 GMT Subject: RFR: 8287982: Concurrent implicit attach from native threads crashes VM Message-ID: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com> If several native threads attach to the VM at around the same time, and before any threads get an automatically generated name are created, then the VM may crash attempting to access the thread status. The issue exists for native threads that attach explicitly with JNI AttachCurrentThread without a thread name, or native threads that attach implicitly by using a function pointer to do an up call. The issue that raises its head periodically is that native threads that JNI attach do the initializaiton of the Thread object in the context of the attaching thread. Great care must be taken because Java code is executing in the context of a Thread that is not fully initialized. The right thing is probably to create the Thread object in another thread, using the service thread has been mentioned. The issue at this time arises when two or more native threads attempt to attach without thread names at around the same time. The first thread that needs an automatically generated name triggers the loading and initialization of a helper class. If there are other threads attaching at the same time then they may have to wait on the monitor which can trigger the crash because the field holder with the thread status is not created at this time. Crashes in monitor enter and notify have been observed. Coleen has changed this code so that linking and initialization uses a mutex (JDK-8288064) so t his specific crash doesn't duplicate in the main line. The short term fix for openjdk/jdk19 is to reorder the initialization so that field holder with the thread status is created before setting the name. Creating a jtreg test with the conditions to duplicate this issue is complicated. The jtreg main wrapper creates the main thread with an automatically generated thread name before it runs the test main method. This is the reason that the test needs to launch a new VM with the right setup to exercise both explicit and implicit attach. ------------- Commit messages: - Move -ljvm to LIBS - Swap link options - Update test - Cleanup - Merge - Initial version Changes: https://git.openjdk.org/jdk19/pull/28/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=28&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287982 Stats: 402 lines in 7 files changed: 364 ins; 21 del; 17 mod Patch: https://git.openjdk.org/jdk19/pull/28.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/28/head:pull/28 PR: https://git.openjdk.org/jdk19/pull/28 From dholmes at openjdk.org Tue Jun 21 07:13:41 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 21 Jun 2022 07:13:41 GMT Subject: RFR: 8287982: Concurrent implicit attach from native threads crashes VM In-Reply-To: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com> References: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com> Message-ID: On Thu, 16 Jun 2022 13:34:18 GMT, Alan Bateman wrote: > If several native threads attach to the VM at around the same time, and before any threads get an automatically generated name are created, then the VM may crash attempting to access the thread status. The issue exists for native threads that attach explicitly with JNI AttachCurrentThread without a thread name, or native threads that attach implicitly by using a function pointer to do an up call. > > The issue that raises its head periodically is that native threads that JNI attach do the initializaiton of the Thread object in the context of the attaching thread. Great care must be taken because Java code is executing in the context of a Thread that is not fully initialized. The right thing is probably to create the Thread object in another thread, using the service thread has been mentioned. The issue at this time arises when two or more native threads attempt to attach without thread names at around the same time. The first thread that needs an automatically generated name triggers the loading and initialization of a helper class. If there are other threads attaching at the same time then they may have to wait on the monitor which can trigger the crash because the field holder with the thread status is not created at this time. Crashes in monitor enter and notify have been observed. Coleen has changed this code so that linking and initialization uses a mutex (JDK-8288064) so this specific crash doesn't duplicate in the main line. The short term fix for openjdk/jdk19 is to reorder the initialization so that field holder with the thread status is created before setting the name. > > Creating a jtreg test with the conditions to duplicate this issue is complicated. The jtreg main wrapper creates the main thread with an automatically generated thread name before it runs the test main method. This is the reason that the test needs to launch a new VM with the right setup to exercise both explicit and implicit attach. Looks good. And I confirmed that the VM code will correctly handle a null name from the current Java thread. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk19/pull/28 From lucy at openjdk.org Tue Jun 21 07:52:59 2022 From: lucy at openjdk.org (Lutz Schmidt) Date: Tue, 21 Jun 2022 07:52:59 GMT Subject: RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside [v2] In-Reply-To: References: Message-ID: On Tue, 21 Jun 2022 05:20:46 GMT, Thomas Stuefe wrote: >> The VM uses SIGUSR2 (can be overridden via _JAVA_SR_SIGNUM) to implement suspend/resume on java threads. It sends, via pthread_kill, SIGUSR2 to targeted threads to interrupt them. It knows the target thread, and the target thread is always a VM-attached thread. >> >> However, if SIGUSR2 gets sent from outside, any thread may receive the signal, and if the target thread is not attached to the VM (e.g. primordial), it is unable to handle it. The result is an assert (debug VM) or a crash (release VM). On my box, this can be reliably reproduced by sending SIGUSR2 to any VM. >> >> This has been discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2022-June/091450.html >> >> The proposed solutions range from "works as designed" (on the ground that sending arbitrary signals to the JVM is an error in itself, and we should rather crash hard and fast) to "lets catch and ignore the signal". >> >> ---- >> >> In this patch I opt for: >> >> - Debug: keep asserting, but make the message more helpful by including signal info for the stray SR signal. Includes sender pid and signal number (in case SR signal had been overridden). >> >> >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/shared/projects/openjdk/jdk-jdk/source/src/hotspot/os/posix/signals_posix.cpp:1611), pid=139712, tid=139712 >> # assert(thread != __null) failed: Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 6681, si_uid: 1027).. >> >> - Release: write a message to tty about this signal, including sender pid and signal name. Otherwise, ignore the signal, dont crash. Repeated signals will generate repeated output: >> >> >> thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -cp $REPROS_JAR de.stuefe.repros.Simple >> >> Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239773, si_uid: 1027). >> Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239774, si_uid: 1027). >> Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239775, si_uid: 1027). >> >> >> Notes: >> - In release builds, we also could quit the VM instead of continuing. I prefer gracefully ignoring the signal, because in our experience quitting - regardless of how good the diagnostic message is - often just leads to frustrated users complaining about VMs mysteriously vanishing. Same goes for crashes, it just pools into the general "java is unstable" notion. I'm open for discussing this. >> - I use tty for the diagnostic message, which goes to stdout. I really dislike that, error output should go to stderr. But since the rest of the VM handles diagnostic output the same way, I use tty here too. >> >> Thanks, Thomas > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > use log_warning(os) instead of tty printing Changes look good to me. PRODUCT code should not abort but continue running if safely possible. In the case considered here, nothing is wrong in the VM. It just receives a signal it doesn't know what to do about. Therefore, "ignore and continue" is the right strategy. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.org/jdk/pull/9181 From stuefe at openjdk.org Tue Jun 21 07:58:58 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 21 Jun 2022 07:58:58 GMT Subject: RFR: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside In-Reply-To: <71npL3Y3iHODd-awkdpKhU1jh0ZXFh19iN2RVuYRtcI=.43400e70-57bd-4da6-9f52-4138f9bfefb0@github.com> References: <71npL3Y3iHODd-awkdpKhU1jh0ZXFh19iN2RVuYRtcI=.43400e70-57bd-4da6-9f52-4138f9bfefb0@github.com> Message-ID: On Tue, 21 Jun 2022 00:12:23 GMT, David Holmes wrote: >> The VM uses SIGUSR2 (can be overridden via _JAVA_SR_SIGNUM) to implement suspend/resume on java threads. It sends, via pthread_kill, SIGUSR2 to targeted threads to interrupt them. It knows the target thread, and the target thread is always a VM-attached thread. >> >> However, if SIGUSR2 gets sent from outside, any thread may receive the signal, and if the target thread is not attached to the VM (e.g. primordial), it is unable to handle it. The result is an assert (debug VM) or a crash (release VM). On my box, this can be reliably reproduced by sending SIGUSR2 to any VM. >> >> This has been discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2022-June/091450.html >> >> The proposed solutions range from "works as designed" (on the ground that sending arbitrary signals to the JVM is an error in itself, and we should rather crash hard and fast) to "lets catch and ignore the signal". >> >> ---- >> >> In this patch I opt for: >> >> - Debug: keep asserting, but make the message more helpful by including signal info for the stray SR signal. Includes sender pid and signal number (in case SR signal had been overridden). >> >> >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/shared/projects/openjdk/jdk-jdk/source/src/hotspot/os/posix/signals_posix.cpp:1611), pid=139712, tid=139712 >> # assert(thread != __null) failed: Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 6681, si_uid: 1027).. >> >> - Release: write a message to tty about this signal, including sender pid and signal name. Otherwise, ignore the signal, dont crash. Repeated signals will generate repeated output: >> >> >> thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -cp $REPROS_JAR de.stuefe.repros.Simple >> >> Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239773, si_uid: 1027). >> Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239774, si_uid: 1027). >> Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239775, si_uid: 1027). >> >> >> Notes: >> - In release builds, we also could quit the VM instead of continuing. I prefer gracefully ignoring the signal, because in our experience quitting - regardless of how good the diagnostic message is - often just leads to frustrated users complaining about VMs mysteriously vanishing. Same goes for crashes, it just pools into the general "java is unstable" notion. I'm open for discussing this. >> - I use tty for the diagnostic message, which goes to stdout. I really dislike that, error output should go to stderr. But since the rest of the VM handles diagnostic output the same way, I use tty here too. >> >> Thanks, Thomas > > Given you have done the work I can review the patch - we just need to resolve the tty vs. VM warning issue. But I don't see a need to make any actual changes here. Thanks a lot, @dholmes-ora and @RealLucy ! ------------- PR: https://git.openjdk.org/jdk/pull/9181 From stuefe at openjdk.org Tue Jun 21 07:59:00 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 21 Jun 2022 07:59:00 GMT Subject: Integrated: JDK-8288556: VM crashes if it gets sent SIGUSR2 from outside In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 07:47:02 GMT, Thomas Stuefe wrote: > The VM uses SIGUSR2 (can be overridden via _JAVA_SR_SIGNUM) to implement suspend/resume on java threads. It sends, via pthread_kill, SIGUSR2 to targeted threads to interrupt them. It knows the target thread, and the target thread is always a VM-attached thread. > > However, if SIGUSR2 gets sent from outside, any thread may receive the signal, and if the target thread is not attached to the VM (e.g. primordial), it is unable to handle it. The result is an assert (debug VM) or a crash (release VM). On my box, this can be reliably reproduced by sending SIGUSR2 to any VM. > > This has been discussed here: https://mail.openjdk.org/pipermail/core-libs-dev/2022-June/091450.html > > The proposed solutions range from "works as designed" (on the ground that sending arbitrary signals to the JVM is an error in itself, and we should rather crash hard and fast) to "lets catch and ignore the signal". > > ---- > > In this patch I opt for: > > - Debug: keep asserting, but make the message more helpful by including signal info for the stray SR signal. Includes sender pid and signal number (in case SR signal had been overridden). > > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/shared/projects/openjdk/jdk-jdk/source/src/hotspot/os/posix/signals_posix.cpp:1611), pid=139712, tid=139712 > # assert(thread != __null) failed: Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 6681, si_uid: 1027).. > > - Release: write a message to tty about this signal, including sender pid and signal name. Otherwise, ignore the signal, dont crash. Repeated signals will generate repeated output: > > > thomas at starfish:/shared/projects/openjdk/jdk-jdk/output-release$ ./images/jdk/bin/java -cp $REPROS_JAR de.stuefe.repros.Simple > > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239773, si_uid: 1027). > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239774, si_uid: 1027). > Non-attached thread received stray SR signal (siginfo: si_signo: 12 (SIGUSR2), si_code: 0 (SI_USER), si_pid: 239775, si_uid: 1027). > > > Notes: > - In release builds, we also could quit the VM instead of continuing. I prefer gracefully ignoring the signal, because in our experience quitting - regardless of how good the diagnostic message is - often just leads to frustrated users complaining about VMs mysteriously vanishing. Same goes for crashes, it just pools into the general "java is unstable" notion. I'm open for discussing this. > - I use tty for the diagnostic message, which goes to stdout. I really dislike that, error output should go to stderr. But since the rest of the VM handles diagnostic output the same way, I use tty here too. > > Thanks, Thomas This pull request has now been integrated. Changeset: 701ea3be Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/701ea3beaaef1acda2d2e041cfdb7d75549cf95c Stats: 16 lines in 1 file changed: 15 ins; 0 del; 1 mod 8288556: VM crashes if it gets sent SIGUSR2 from outside Reviewed-by: dholmes, lucy ------------- PR: https://git.openjdk.org/jdk/pull/9181 From alanb at openjdk.org Tue Jun 21 08:16:41 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 21 Jun 2022 08:16:41 GMT Subject: RFR: 8287982: Concurrent implicit attach from native threads crashes VM In-Reply-To: References: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com> Message-ID: On Tue, 21 Jun 2022 07:09:50 GMT, David Holmes wrote: > And I confirmed that the VM code will correctly handle a null name from the current Java thread. Thanks, I checked that one. One thing that I'm wondering for the test is whether to move it to test/hotspot/jtreg/runtime/jni/ so it lives with the other tests for JNI. I had expected to find other tests for AttachCurrentThread in that location but we don't. ------------- PR: https://git.openjdk.org/jdk19/pull/28 From stuefe at openjdk.org Tue Jun 21 08:33:33 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 21 Jun 2022 08:33:33 GMT Subject: RFR: JDK-8288824: [arm32] Display isetstate in register output Message-ID: <-LhYaNgj5nQi6L-w7rb7kkB1NVn4UrTgoBkmzdA7Ebw=.77d037a3-e3c3-4bfe-a756-3a7125f1a21c@github.com> When analyzing [JDK-8288719](https://bugs.openjdk.org/browse/JDK-8288719), to know the current isetstate was useful. It would be nice if that were printed clearly in the register output to save some mental cycles parsing CPSR. Looks like this: Registers: r0 = 0x00000000 r1 = 0xbe9e7fb8 r2 = 0x00000000 r3 = 0xb6f860ac r4 = 0xbe9e7fb8 r5 = 0xb6f864e0 r6 = 0xbe9e8060 r7 = 0xbe9e7fb0 r8 = 0xb6da8798 r9 = 0x00000000 r10 = 0x00000000 fp = 0x00000001 r12 = 0xb6da87ec sp = 0xbe9e7fb0 lr = 0xb6bc7dfb pc = 0xb6bc7dfa cpsr = 0x800e0030 isetstate: Thumb Registers: r0 = 0xb6be3664 r1 = 0xbe947c70 r2 = 0x00000058 r3 = 0xb6f3e000 r4 = 0xbe947c70 r5 = 0xb6f3f510 r6 = 0xb6c95bdc r7 = 0xbe947d18 r8 = 0xbe947d98 r9 = 0x00000000 r10 = 0x00000000 fp = 0xbe947d14 r12 = 0xb6c95f84 sp = 0xbe947c68 lr = 0xb6e97218 pc = 0xb6793f3c cpsr = 0x60000010 isetstate: ARM I refrained from parsing more information from the CPSR because I did not want to blow up the patch. ISETSTATE proved to be useful. More information can be added if needed. ------------- Commit messages: - Display isetstate Changes: https://git.openjdk.org/jdk/pull/9223/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9223&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288824 Stats: 14 lines in 1 file changed: 13 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9223.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9223/head:pull/9223 PR: https://git.openjdk.org/jdk/pull/9223 From sgehwolf at openjdk.org Tue Jun 21 08:40:04 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 21 Jun 2022 08:40:04 GMT Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems [v3] In-Reply-To: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> References: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com> Message-ID: On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf wrote: >> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). >> >> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. >> >> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). >> >> Testing: >> - [x] Added unit tests >> - [x] GHA >> - [x] Container tests on cgroups v1 Linux. Continue to pass > > Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision: > > - Refactor hotspot gtest > - Separate into function. Fix comment. Don't close this yet please, bot. ------------- PR: https://git.openjdk.org/jdk/pull/8629 From stuefe at openjdk.org Tue Jun 21 08:54:53 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 21 Jun 2022 08:54:53 GMT Subject: RFR: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes random crashes In-Reply-To: References: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com> Message-ID: On Mon, 20 Jun 2022 18:50:26 GMT, Sergey Nazarkin wrote: > Now I remember jdk8 aarch32 port marks assembly functions specially to handle thumb interworking. AFAIK the bug can be reproduced with overridden C(XX)FLAGS=-mthumb even with crossbuilds. LGTM Thank you, Sergey! I tried to reproduce this with -mthumb with a crossbuild, but was not able to pass --with-extra-cflags to a devkit crossbuild. I opened https://bugs.openjdk.org/browse/JDK-8288797 to track that. ------------- PR: https://git.openjdk.org/jdk/pull/9213 From yyang at openjdk.org Tue Jun 21 11:35:52 2022 From: yyang at openjdk.org (Yi Yang) Date: Tue, 21 Jun 2022 11:35:52 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v4] In-Reply-To: References: Message-ID: On Tue, 21 Jun 2022 05:23:58 GMT, Thomas Stuefe wrote: > > > I would have thought that since we don't have the pool anymore, we can just remove this test line. The lines above already > > > test against MaxMetaspaceSize. > > > > > > Okay. > > > I think you may be right, we need a replacement for the old memory bean for these tests. Whitebox seems easiest. > > > > > > So should we keep test changes as it is or discard existing test changes and then rewrite related tests via new compressed class space query whitebox API? I prefer to keep tests as it is rather than adding whitebox API since I've made a lot of test changes. But I also want to hear your expert suggestions as final conclusion. > > I think the easier way would be actually to add a whitebox API for class space use, as @iklam suggested, and just replace the memory pool usage calls with that one. That would be a purely mechanical change if a bit onerous. But since the metaspace itself did not change, the numbers are the same, so the tests test the same. Still easier than trying to think through the changed semantics for each test. > > Sorry that this seems to have exploded in complexity :-( Never mind:) I did a closer look at these test changes, it seems that many changes are still necessary even if we provide a WhiteBox.getCompressedClassSpaceMemoryUsage(). In particular, tests other than test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/gc/lotsOfCallSites/Test.java need to be tweaked. Can you please confirm it? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/8831 From pchilanomate at openjdk.org Tue Jun 21 13:44:08 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 21 Jun 2022 13:44:08 GMT Subject: RFR: 8286103: VThreadMonitorTest fails "assert(!current->cont_fastpath() || (current->cont_fastpath_thread_state() && !interpreted_native_or_deoptimized_on_stack(current))) failed" In-Reply-To: <9c6zeRBtbGjRpSGqN81OIRPUyLu-ceV-1gRwA1fWs-U=.87df7fc0-ac51-4742-8dd1-8f8d536a7bb8@github.com> References: <9c6zeRBtbGjRpSGqN81OIRPUyLu-ceV-1gRwA1fWs-U=.87df7fc0-ac51-4742-8dd1-8f8d536a7bb8@github.com> Message-ID: <0kNw4a3BgXEki-o0VK7rmF4QS-r_DVL422b-mDZHubA=.05c796f1-5cd3-4ce7-b9a9-09819ca35cd8@github.com> On Wed, 15 Jun 2022 11:00:14 GMT, Ron Pressler wrote: > Please review the following fix. > > Detection of a deoptimized frame in thaw was incorrect, as it tested the deoptimization state of a frame object constructed without relevant data. > > Passes loom tiers 1-5. LGTM. ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.org/jdk19/pull/18 From stuefe at openjdk.org Tue Jun 21 13:47:53 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 21 Jun 2022 13:47:53 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v4] In-Reply-To: References: Message-ID: On Tue, 21 Jun 2022 11:30:49 GMT, Yi Yang wrote: > > > > I would have thought that since we don't have the pool anymore, we can just remove this test line. The lines above already > > > > test against MaxMetaspaceSize. > > > > > > > > > Okay. > > > > I think you may be right, we need a replacement for the old memory bean for these tests. Whitebox seems easiest. > > > > > > > > > So should we keep test changes as it is or discard existing test changes and then rewrite related tests via new compressed class space query whitebox API? I prefer to keep tests as it is rather than adding whitebox API since I've made a lot of test changes. But I also want to hear your expert suggestions as final conclusion. > > > > > > I think the easier way would be actually to add a whitebox API for class space use, as @iklam suggested, and just replace the memory pool usage calls with that one. That would be a purely mechanical change if a bit onerous. But since the metaspace itself did not change, the numbers are the same, so the tests test the same. Still easier than trying to think through the changed semantics for each test. > > Sorry that this seems to have exploded in complexity :-( > > Never mind:) I did a closer look at these test changes, it seems that many changes are still necessary even if we provide a WhiteBox.getCompressedClassSpaceMemoryUsage(). In particular, tests other than test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/gc/lotsOfCallSites/Test.java need to be tweaked. Can you please confirm it? Why, what changes do you have in mind? ------------- PR: https://git.openjdk.org/jdk/pull/8831 From rehn at openjdk.org Tue Jun 21 15:08:02 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 21 Jun 2022 15:08:02 GMT Subject: RFR: 8287982: Concurrent implicit attach from native threads crashes VM In-Reply-To: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com> References: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com> Message-ID: On Thu, 16 Jun 2022 13:34:18 GMT, Alan Bateman wrote: > If several native threads attach to the VM at around the same time, and before any threads get an automatically generated name are created, then the VM may crash attempting to access the thread status. The issue exists for native threads that attach explicitly with JNI AttachCurrentThread without a thread name, or native threads that attach implicitly by using a function pointer to do an up call. > > The issue that raises its head periodically is that native threads that JNI attach do the initializaiton of the Thread object in the context of the attaching thread. Great care must be taken because Java code is executing in the context of a Thread that is not fully initialized. The right thing is probably to create the Thread object in another thread, using the service thread has been mentioned. The issue at this time arises when two or more native threads attempt to attach without thread names at around the same time. The first thread that needs an automatically generated name triggers the loading and initialization of a helper class. If there are other threads attaching at the same time then they may have to wait on the monitor which can trigger the crash because the field holder with the thread status is not created at this time. Crashes in monitor enter and notify have been observed. Coleen has changed this code so that linking and initialization uses a mutex (JDK-8288064) so this specific crash doesn't duplicate in the main line. The short term fix for openjdk/jdk19 is to reorder the initialization so that field holder with the thread status is created before setting the name. > > Creating a jtreg test with the conditions to duplicate this issue is complicated. The jtreg main wrapper creates the main thread with an automatically generated thread name before it runs the test main method. This is the reason that the test needs to launch a new VM with the right setup to exercise both explicit and implicit attach. Looks good. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk19/pull/28 From pchilanomate at openjdk.org Tue Jun 21 15:49:54 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 21 Jun 2022 15:49:54 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 21:43:50 GMT, Daniel D. Daugherty wrote: >> Update a couple of tests that were modified by JDK-8286830. Now the tests properly >> honor any specified time limit by splitting the time between both sub-tests. >> Also pick up a sanity check based on JDK-8288497 that I've been using in recent >> stress testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > VMThread can get to check in AsyncExceptionHandshake() dtr via a bailout. Marked as reviewed by pchilanomate (Reviewer). > I forgot that install_async_exception() can delete the AsyncExceptionHandshake which calls the AsyncExceptionHandshake dtr: > > ``` > > Current thread (0x0000ffff001bab70): VMThread "VM Thread" [stack: 0x0000fffee8110000,0x0000fffee8310000] [id=661857] _threads_hazard_ptr=0x0000fffc8021f770, _nested_threads_hazard_ptr_cnt=0 > > Stack: [0x0000fffee8110000,0x0000fffee8310000], sp=0x0000fffee830e030, free space=2040k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x1909960] AsyncExceptionHandshake::~AsyncExceptionHandshake()+0x230 > V [libjvm.so+0x1908a7c] JavaThread::install_async_exception(AsyncExceptionHandshake*)+0x4c > V [libjvm.so+0x190ace8] InstallAsyncExceptionHandshake::do_thread(Thread*)+0x38 > V [libjvm.so+0xe67d20] HandshakeOperation::do_handshake(JavaThread*)+0x13c > V [libjvm.so+0xe68cec] HandshakeState::try_process(HandshakeOperation*)+0x23c > V [libjvm.so+0xe6b384] VM_HandshakeAllThreads::doit()+0x1f4 > V [libjvm.so+0x19f2788] VM_Operation::evaluate()+0x168 > V [libjvm.so+0x1a1c9d4] VMThread::evaluate_operation(VM_Operation*)+0x154 > V [libjvm.so+0x1a1e1bc] VMThread::inner_execute(VM_Operation*)+0x45c > V [libjvm.so+0x1a1e374] VMThread::loop()+0xc4 > V [libjvm.so+0x1a1e4a0] VMThread::run()+0xcc > V [libjvm.so+0x1907bb8] Thread::call_run()+0xf8 > V [libjvm.so+0x16033a4] thread_native_entry(Thread*)+0x104 > C [libpthread.so.0+0x78f8] start_thread+0x188 > ``` Ah right, the VMThread could take over that synchronous handshake! Thanks for the investigation Dan. The last update looks good. ------------- PR: https://git.openjdk.org/jdk19/pull/32 From dcubed at openjdk.org Tue Jun 21 16:09:42 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 21 Jun 2022 16:09:42 GMT Subject: RFR: 8288497: add support for JavaThread::is_oop_safe() [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 15:21:01 GMT, Daniel D. Daugherty wrote: >> A fix to add support for JavaThread::is_gc_barrier_detached() which allows >> us to add checks to detect failures like: >> >> JDK-8288139 JavaThread touches oop after GC barrier is detached >> https://bugs.openjdk.org/browse/JDK-8288139 >> >> This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Rename cannot_access_oops_safely to is_oop_safe and invert the function's logic. The Mach5 Tier8 run had no failures. All testing looks great. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Tue Jun 21 16:09:44 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 21 Jun 2022 16:09:44 GMT Subject: RFR: 8288497: add support for JavaThread::is_oop_safe() [v3] In-Reply-To: References: Message-ID: <1mU1WN_ZTVXowc1DQzHfTmnTFnof1CUKcBLfTxjFvBo=.8570c8a3-27f8-4303-b9ce-a32178e4b71f@github.com> On Mon, 20 Jun 2022 01:46:03 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename cannot_access_oops_safely to is_oop_safe and invert the function's logic. > > src/hotspot/share/runtime/thread.inline.hpp line 269: > >> 267: } >> 268: >> 269: inline bool JavaThread::is_oop_safe() const { > > Do we want to document, and assert, that this is only intended for use by the current thread on itself? I can't imagine any scenario where we would need to ask whether an arbitrary thread is oop-safe. ?? @dholmes-ora - Thanks very much for the re-review. I'll accept your "good as-is" and proceed with integration. I think I've tweaked this fix enough at this point. Especially if we end up replacing it with support in the GC subsystems instead. ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Tue Jun 21 16:11:11 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 21 Jun 2022 16:11:11 GMT Subject: Integrated: 8288497: add support for JavaThread::is_oop_safe() In-Reply-To: References: Message-ID: <_qZowOhbZlROkpk2RQ2IJTqkbX8VTy5HUC50FXWZero=.b17afeec-5b5d-4f42-bd09-f9a0e47b15cb@github.com> On Wed, 15 Jun 2022 15:44:21 GMT, Daniel D. Daugherty wrote: > A fix to add support for JavaThread::is_gc_barrier_detached() which allows > us to add checks to detect failures like: > > JDK-8288139 JavaThread touches oop after GC barrier is detached > https://bugs.openjdk.org/browse/JDK-8288139 > > This fix along with the fix for JDK-8288139 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. This pull request has now been integrated. Changeset: e26d3b3c Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk19/commit/e26d3b3c01a06f250344d0afdaa9fadd1fdae33b Stats: 36 lines in 4 files changed: 24 ins; 5 del; 7 mod 8288497: add support for JavaThread::is_oop_safe() Reviewed-by: pchilanomate, dholmes, rehn, eosterlund ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Tue Jun 21 16:12:51 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 21 Jun 2022 16:12:51 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 15:39:10 GMT, Daniel D. Daugherty wrote: >> Update SharedRuntime::get_java_tid() to verify that the calling thread is safely >> accessing its own threadObj(). This check uses the new is_gc_barrier_detached() >> function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). >> >> The above check was used to reproduce the failure mode without Shenandoah >> and the remainder of the fix relocates the offending code from >> ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of >> removed the 'tid' entry from the ThreadIdTable is still done under the >> protection of the Threads_lock. >> >> This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. >> There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. > > Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - update after 8288497 v01 code review changes > - Merge branch 'JDK-8288497' into JDK-8288139 > - update after 8288497 v00 code review changes > - Merge branch 'JDK-8288497' into JDK-8288139 > - 8288139: JavaThread touches oop after GC barrier is detached The Mach5 Tier8 run had no failures. All testing looks great. ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dcubed at openjdk.org Tue Jun 21 16:19:08 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 21 Jun 2022 16:19:08 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v4] In-Reply-To: References: Message-ID: <43QMacJvtDdB3RSGNrG6axGPDzOk0c6zZvBATm5h1P8=.8e3b66a3-f594-4fa5-a4f2-ec6c323d3ce8@github.com> > Update SharedRuntime::get_java_tid() to verify that the calling thread is safely > accessing its own threadObj(). This check uses the new is_gc_barrier_detached() > function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). > > The above check was used to reproduce the failure mode without Shenandoah > and the remainder of the fix relocates the offending code from > ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of > removed the 'tid' entry from the ThreadIdTable is still done under the > protection of the Threads_lock. > > This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'master' into JDK-8288139 - update after 8288497 v01 code review changes - Merge branch 'JDK-8288497' into JDK-8288139 - Rename cannot_access_oops_safely to is_oop_safe and invert the function's logic. - update after 8288497 v00 code review changes - Merge branch 'JDK-8288497' into JDK-8288139 - Resolve some code review comments on v00. - Merge branch 'master' into JDK-8288497 - 8288139: JavaThread touches oop after GC barrier is detached - 8288497: add support for JavaThread::is_gc_barrier_detached() ------------- Changes: https://git.openjdk.org/jdk19/pull/21/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=21&range=03 Stats: 22 lines in 4 files changed: 9 ins; 6 del; 7 mod Patch: https://git.openjdk.org/jdk19/pull/21.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/21/head:pull/21 PR: https://git.openjdk.org/jdk19/pull/21 From dcubed at openjdk.org Tue Jun 21 16:22:59 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 21 Jun 2022 16:22:59 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v3] In-Reply-To: <50MGGIvqUupuM9a4tIl3pZuceR5bWlmaPGoAYM3ZDdM=.785d5f52-6ede-4f14-9fac-03ef28be38cb@github.com> References: <50MGGIvqUupuM9a4tIl3pZuceR5bWlmaPGoAYM3ZDdM=.785d5f52-6ede-4f14-9fac-03ef28be38cb@github.com> Message-ID: <4jKzUI5UcEtdUl1uaGOiDLQfSxaGT3RZezqpJdL5P_0=.957b980c-8b4c-4096-ada2-d49e02b985c6@github.com> On Mon, 20 Jun 2022 00:50:56 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - update after 8288497 v01 code review changes >> - Merge branch 'JDK-8288497' into JDK-8288139 >> - update after 8288497 v00 code review changes >> - Merge branch 'JDK-8288497' into JDK-8288139 >> - 8288139: JavaThread touches oop after GC barrier is detached > > Marked as reviewed by dholmes (Reviewer). @dholmes-ora - Thanks for the re-review! ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dcubed at openjdk.org Tue Jun 21 16:24:26 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 21 Jun 2022 16:24:26 GMT Subject: Integrated: 8288139: JavaThread touches oop after GC barrier is detached In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 16:06:08 GMT, Daniel D. Daugherty wrote: > Update SharedRuntime::get_java_tid() to verify that the calling thread is safely > accessing its own threadObj(). This check uses the new is_gc_barrier_detached() > function added by [JDK-8288497](https://bugs.openjdk.org/browse/JDK-8288497) add support for JavaThread::is_gc_barrier_detached(). > > The above check was used to reproduce the failure mode without Shenandoah > and the remainder of the fix relocates the offending code from > ThreadsSMRSupport::remove_thread() to Threads::remove(). The work of > removed the 'tid' entry from the ThreadIdTable is still done under the > protection of the Threads_lock. > > This fix along with the fix for JDK-8288497 has been tested in Mach5 Tier[1-8]. > There are no related failures in Mach5 Tier[1-7]; Mach5 Tier8 is still running. This pull request has now been integrated. Changeset: a1449886 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk19/commit/a1449886004b2f0a70f1413bb19ce3ba5c914fdf Stats: 22 lines in 4 files changed: 9 ins; 6 del; 7 mod 8288139: JavaThread touches oop after GC barrier is detached Reviewed-by: pchilanomate, dholmes, rehn, eosterlund ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dcubed at openjdk.org Tue Jun 21 16:25:09 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 21 Jun 2022 16:25:09 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 [v3] In-Reply-To: References: Message-ID: On Tue, 21 Jun 2022 15:46:09 GMT, Patricio Chilano Mateo wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> VMThread can get to check in AsyncExceptionHandshake() dtr via a bailout. > >> I forgot that install_async_exception() can delete the AsyncExceptionHandshake which calls the AsyncExceptionHandshake dtr: >> >> ``` >> >> Current thread (0x0000ffff001bab70): VMThread "VM Thread" [stack: 0x0000fffee8110000,0x0000fffee8310000] [id=661857] _threads_hazard_ptr=0x0000fffc8021f770, _nested_threads_hazard_ptr_cnt=0 >> >> Stack: [0x0000fffee8110000,0x0000fffee8310000], sp=0x0000fffee830e030, free space=2040k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x1909960] AsyncExceptionHandshake::~AsyncExceptionHandshake()+0x230 >> V [libjvm.so+0x1908a7c] JavaThread::install_async_exception(AsyncExceptionHandshake*)+0x4c >> V [libjvm.so+0x190ace8] InstallAsyncExceptionHandshake::do_thread(Thread*)+0x38 >> V [libjvm.so+0xe67d20] HandshakeOperation::do_handshake(JavaThread*)+0x13c >> V [libjvm.so+0xe68cec] HandshakeState::try_process(HandshakeOperation*)+0x23c >> V [libjvm.so+0xe6b384] VM_HandshakeAllThreads::doit()+0x1f4 >> V [libjvm.so+0x19f2788] VM_Operation::evaluate()+0x168 >> V [libjvm.so+0x1a1c9d4] VMThread::evaluate_operation(VM_Operation*)+0x154 >> V [libjvm.so+0x1a1e1bc] VMThread::inner_execute(VM_Operation*)+0x45c >> V [libjvm.so+0x1a1e374] VMThread::loop()+0xc4 >> V [libjvm.so+0x1a1e4a0] VMThread::run()+0xcc >> V [libjvm.so+0x1907bb8] Thread::call_run()+0xf8 >> V [libjvm.so+0x16033a4] thread_native_entry(Thread*)+0x104 >> C [libpthread.so.0+0x78f8] start_thread+0x188 >> ``` > Ah right, the VMThread could take over that synchronous handshake! Thanks for the investigation Dan. The last update looks good. @pchilano - Thanks for the re-review. @dholmes-ora - Thanks for the review. ------------- PR: https://git.openjdk.org/jdk19/pull/32 From dcubed at openjdk.org Tue Jun 21 16:25:11 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 21 Jun 2022 16:25:11 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 21:43:50 GMT, Daniel D. Daugherty wrote: >> Update a couple of tests that were modified by JDK-8286830. Now the tests properly >> honor any specified time limit by splitting the time between both sub-tests. >> Also pick up a sanity check based on JDK-8288497 that I've been using in recent >> stress testing. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > VMThread can get to check in AsyncExceptionHandshake() dtr via a bailout. The Mach5 Tier8 run had no failures. All testing looks great. ------------- PR: https://git.openjdk.org/jdk19/pull/32 From dcubed at openjdk.org Tue Jun 21 16:35:40 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 21 Jun 2022 16:35:40 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 [v4] In-Reply-To: References: Message-ID: > Update a couple of tests that were modified by JDK-8286830. Now the tests properly > honor any specified time limit by splitting the time between both sub-tests. > Also pick up a sanity check based on JDK-8288497 that I've been using in recent > stress testing. Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge branch 'master' into JDK-8288532 - VMThread can get to check in AsyncExceptionHandshake() dtr via a bailout. - Check in AsyncExceptionHandshake() dtr can assume the caller is a JavaThread. - update after 8288497 v01 code review changes - Merge branch 'JDK-8288139' into JDK-8288532 - update after 8288497 v01 code review changes - Merge branch 'JDK-8288497' into JDK-8288139 - Rename cannot_access_oops_safely to is_oop_safe and invert the function's logic. - update after 8288497 v00 code review changes - Merge branch 'JDK-8288139' into JDK-8288532 - ... and 7 more: https://git.openjdk.org/jdk19/compare/a1449886...9fa9d1d6 ------------- Changes: https://git.openjdk.org/jdk19/pull/32/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=32&range=03 Stats: 13 lines in 3 files changed: 10 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk19/pull/32.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/32/head:pull/32 PR: https://git.openjdk.org/jdk19/pull/32 From dcubed at openjdk.org Tue Jun 21 16:39:29 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 21 Jun 2022 16:39:29 GMT Subject: Integrated: 8288532: additional review changes for JDK-8286830 In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 21:54:56 GMT, Daniel D. Daugherty wrote: > Update a couple of tests that were modified by JDK-8286830. Now the tests properly > honor any specified time limit by splitting the time between both sub-tests. > Also pick up a sanity check based on JDK-8288497 that I've been using in recent > stress testing. This pull request has now been integrated. Changeset: 31d981e5 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk19/commit/31d981e5ea0fa4108da5ef94272794a8fed4a363 Stats: 13 lines in 3 files changed: 10 ins; 0 del; 3 mod 8288532: additional review changes for JDK-8286830 Reviewed-by: pchilanomate, dholmes ------------- PR: https://git.openjdk.org/jdk19/pull/32 From rpressler at openjdk.org Tue Jun 21 16:53:09 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Tue, 21 Jun 2022 16:53:09 GMT Subject: Integrated: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp In-Reply-To: References: Message-ID: <9BshgTXvwPZxnbeGG1eSSxXgIuo8syoI8eqfu9gxeLY=.57460693-36a2-4ecc-853e-e6d5a355e7d4@github.com> On Tue, 14 Jun 2022 08:02:21 GMT, Ron Pressler wrote: > Please review the following fix. > > When JVM TI puts a thread's state in `interp_only_mode`, thaw takes the slow path and deoptimizes frames as they're thawed in `recurse_thaw_compiled_frame`. However, thawing a deoptimized frame's callee will override the frame's patched pc (to the deopt handler), essentially reverting the deoptimization. This fix patches the deoptimized return address after thawing the callee. > > Passes loom tiers 1-5 This pull request has now been integrated. Changeset: 97200a78 Author: Ron Pressler Committer: Serguei Spitsyn URL: https://git.openjdk.org/jdk19/commit/97200a78b176ccc8781acb67db2af2f62572d46a Stats: 7 lines in 2 files changed: 4 ins; 3 del; 0 mod 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp Reviewed-by: sspitsyn, pchilanomate, coleenp ------------- PR: https://git.openjdk.org/jdk19/pull/12 From rpressler at openjdk.org Tue Jun 21 17:01:22 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Tue, 21 Jun 2022 17:01:22 GMT Subject: Integrated: 8286103: VThreadMonitorTest fails "assert(!current->cont_fastpath() || (current->cont_fastpath_thread_state() && !interpreted_native_or_deoptimized_on_stack(current))) failed" In-Reply-To: <9c6zeRBtbGjRpSGqN81OIRPUyLu-ceV-1gRwA1fWs-U=.87df7fc0-ac51-4742-8dd1-8f8d536a7bb8@github.com> References: <9c6zeRBtbGjRpSGqN81OIRPUyLu-ceV-1gRwA1fWs-U=.87df7fc0-ac51-4742-8dd1-8f8d536a7bb8@github.com> Message-ID: <5QN14MgBRsV8CSM7_JlSjDWJh4Hg4DVIqmPM6150Ex0=.863a359f-c4e8-45ee-8f58-f6b530b271fd@github.com> On Wed, 15 Jun 2022 11:00:14 GMT, Ron Pressler wrote: > Please review the following fix. > > Detection of a deoptimized frame in thaw was incorrect, as it tested the deoptimization state of a frame object constructed without relevant data. > > Passes loom tiers 1-5. This pull request has now been integrated. Changeset: 198cec9e Author: Ron Pressler Committer: Serguei Spitsyn URL: https://git.openjdk.org/jdk19/commit/198cec9e1b7e8f77a619335dbc569c8def21670c Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8286103: VThreadMonitorTest fails "assert(!current->cont_fastpath() || (current->cont_fastpath_thread_state() && !interpreted_native_or_deoptimized_on_stack(current))) failed" Reviewed-by: sspitsyn, pchilanomate ------------- PR: https://git.openjdk.org/jdk19/pull/18 From duke at openjdk.org Tue Jun 21 19:22:15 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Tue, 21 Jun 2022 19:22:15 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL Message-ID: Please review this fix for JDK-8288904, thank you. Currently running tier1-3 tests. ------------- Commit messages: - Add memory barrier and atomic load Changes: https://git.openjdk.org/jdk/pull/9225/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9225&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288904 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9225.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9225/head:pull/9225 PR: https://git.openjdk.org/jdk/pull/9225 From xliu at openjdk.org Tue Jun 21 23:21:14 2022 From: xliu at openjdk.org (Xin Liu) Date: Tue, 21 Jun 2022 23:21:14 GMT Subject: RFR: 8288926: make runtime/logging/DeoptStats.java more reliable Message-ID: 8288926: make runtime/logging/DeoptStats.java more reliable ------------- Commit messages: - 8288926: make runtime/logging/DeoptStats.java more reliable Changes: https://git.openjdk.org/jdk/pull/9228/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9228&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288926 Stats: 16 lines in 1 file changed: 9 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9228.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9228/head:pull/9228 PR: https://git.openjdk.org/jdk/pull/9228 From eosterlund at openjdk.org Wed Jun 22 05:20:51 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 22 Jun 2022 05:20:51 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL In-Reply-To: References: Message-ID: On Tue, 21 Jun 2022 19:12:55 GMT, Johan Sj?l?n wrote: > Please review this fix for JDK-8288904, thank you. > > Currently running tier1-3 tests. Might want to add a comment explaining the reason for the fence to be there. ------------- Changes requested by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/9225 From duke at openjdk.org Wed Jun 22 06:50:42 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Wed, 22 Jun 2022 06:50:42 GMT Subject: RFR: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test [v3] In-Reply-To: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> References: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> Message-ID: > I would like to fix 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test. > > FlightRecorder option has not been tested since JDK13. > I think we should test it, because FlightRecorder option has not been obsolete in the latest JDK. > Users would be in trouble if the option suddenly disappears without notice, > so it's important to confirm the deprication message. > > Also we should add a test of ExtendedDTraceProbes option. > The test was disabled in 8281675, because some jdk can't specify it. > I modified the test to be able to verify ExtendedDTraceProbes in either case that DTRACE_ENABLED is enabled or not. KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9123/files - new: https://git.openjdk.org/jdk/pull/9123/files/6f69d020..5e4b17c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9123&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9123&range=01-02 Stats: 13 lines in 1 file changed: 3 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9123.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9123/head:pull/9123 PR: https://git.openjdk.org/jdk/pull/9123 From duke at openjdk.org Wed Jun 22 06:50:42 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Wed, 22 Jun 2022 06:50:42 GMT Subject: RFR: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test [v2] In-Reply-To: References: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> <2EuSSI9VbYx4SqmIjiecMHJhLFwlHEt46NRpspQF0Jk=.7f12155f-f347-4f88-8d0e-048c0dc817d8@github.com> Message-ID: <0yT_2RB_RNUblR--tRkviZuygZz2ao2_cV3anYTFXdM=.e32f782c-040d-4b63-894c-e54aba50c017@github.com> On Mon, 20 Jun 2022 00:07:07 GMT, David Holmes wrote: >> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: >> >> 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test > > test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 103: > >> 101: String match = getDeprecationString(jfrOptionNames[0]); >> 102: output.shouldMatch(match); >> 103: } > > This is not the way to handle this. In the static block that initializes the set of flags to test you should do something like: > > > if (wb.isJFRIncluded()) { > deprecated.add("FlightRecorder", false); > } > > before line 70. Thank you for your comment. I fixed the test. Could you please review it again? ------------- PR: https://git.openjdk.org/jdk/pull/9123 From dholmes at openjdk.org Wed Jun 22 07:03:49 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Jun 2022 07:03:49 GMT Subject: RFR: 8287982: Concurrent implicit attach from native threads crashes VM In-Reply-To: References: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com> Message-ID: On Tue, 21 Jun 2022 08:13:29 GMT, Alan Bateman wrote: > One thing that I'm wondering for the test is whether to move it to test/hotspot/jtreg/runtime/jni/ so it lives with the other tests for JNI. I had expected to find other tests for AttachCurrentThread in that location but we don't. As this doesn't change hotspot code it seems more appropriate to have the regression test where it is. We have a number of tests that use AttachCurrentThread but very few actual regression tests for it. Thanks. ------------- PR: https://git.openjdk.org/jdk19/pull/28 From duke at openjdk.org Wed Jun 22 07:45:26 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 22 Jun 2022 07:45:26 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: > Please review this fix for JDK-8288904, thank you. > > Currently running tier1-3 tests. Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Comment the loadstore ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9225/files - new: https://git.openjdk.org/jdk/pull/9225/files/b13a0fbe..31417665 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9225&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9225&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9225.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9225/head:pull/9225 PR: https://git.openjdk.org/jdk/pull/9225 From duke at openjdk.org Wed Jun 22 07:45:26 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 22 Jun 2022 07:45:26 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 05:17:04 GMT, Erik ?sterlund wrote: >> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment the loadstore > > Might want to add a comment explaining the reason for the fence to be there. @fisk , sure, something like this? ------------- PR: https://git.openjdk.org/jdk/pull/9225 From rehn at openjdk.org Wed Jun 22 07:48:51 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 22 Jun 2022 07:48:51 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: <6F7S0pkXV3KO6oqoOzQkqxO67CiFIyJqCFW9JsXBdqo=.a4a16f73-3695-4465-837a-5e95330e3bb8@github.com> On Wed, 22 Jun 2022 07:45:26 GMT, Johan Sj?l?n wrote: >> Please review this fix for JDK-8288904, thank you. >> >> Currently running tier1-3 tests. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Comment the loadstore Thanks, looks good. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/9225 From alanb at openjdk.org Wed Jun 22 07:51:58 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 22 Jun 2022 07:51:58 GMT Subject: Integrated: 8287982: Concurrent implicit attach from native threads crashes VM In-Reply-To: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com> References: <0xsDtg-r8VMuRWnnOqwutfHMaIo2yb-YBD0WBAyrwXY=.f498852b-f012-4517-b640-fb0d98c4b6b9@github.com> Message-ID: On Thu, 16 Jun 2022 13:34:18 GMT, Alan Bateman wrote: > If several native threads attach to the VM at around the same time, and before any threads get an automatically generated name are created, then the VM may crash attempting to access the thread status. The issue exists for native threads that attach explicitly with JNI AttachCurrentThread without a thread name, or native threads that attach implicitly by using a function pointer to do an up call. > > The issue that raises its head periodically is that native threads that JNI attach do the initializaiton of the Thread object in the context of the attaching thread. Great care must be taken because Java code is executing in the context of a Thread that is not fully initialized. The right thing is probably to create the Thread object in another thread, using the service thread has been mentioned. The issue at this time arises when two or more native threads attempt to attach without thread names at around the same time. The first thread that needs an automatically generated name triggers the loading and initialization of a helper class. If there are other threads attaching at the same time then they may have to wait on the monitor which can trigger the crash because the field holder with the thread status is not created at this time. Crashes in monitor enter and notify have been observed. Coleen has changed this code so that linking and initialization uses a mutex (JDK-8288064) so this specific crash doesn't duplicate in the main line. The short term fix for openjdk/jdk19 is to reorder the initialization so that field holder with the thread status is created before setting the name. > > Creating a jtreg test with the conditions to duplicate this issue is complicated. The jtreg main wrapper creates the main thread with an automatically generated thread name before it runs the test main method. This is the reason that the test needs to launch a new VM with the right setup to exercise both explicit and implicit attach. This pull request has now been integrated. Changeset: 7cf71bc2 Author: Alan Bateman URL: https://git.openjdk.org/jdk19/commit/7cf71bc2d3ae3d84552f06358e70204dc65552fc Stats: 402 lines in 7 files changed: 364 ins; 21 del; 17 mod 8287982: Concurrent implicit attach from native threads crashes VM Reviewed-by: dholmes, rehn ------------- PR: https://git.openjdk.org/jdk19/pull/28 From mbaesken at openjdk.org Wed Jun 22 08:20:50 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Jun 2022 08:20:50 GMT Subject: RFR: JDK-8287011: Improve container information [v6] In-Reply-To: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: <3sKyZmnRqYNFue4wdDEcFtBWoUUDSYFXyDCkAwZoCS4=.e94191c1-7ea8-499e-bfbe-bb1b7926af81@github.com> > The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Add inclusion of ostream.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8991/files - new: https://git.openjdk.org/jdk/pull/8991/files/77c52cdf..9f95a892 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8991&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8991&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/8991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8991/head:pull/8991 PR: https://git.openjdk.org/jdk/pull/8991 From mbaesken at openjdk.org Wed Jun 22 08:20:53 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Jun 2022 08:20:53 GMT Subject: RFR: JDK-8287011: Improve container information [v5] In-Reply-To: References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> <4n2ej21Q2mTKnTNSPZ87PuCWEfYILveN8MXOp9uZoi4=.999d5182-efc0-463a-9131-fa5644ed5bbc@github.com> Message-ID: On Thu, 16 Jun 2022 05:53:54 GMT, Thomas Stuefe wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Introduce print_version_specific_info > > src/hotspot/os/linux/osContainer_linux.hpp line 48: > >> 46: static void print_version_specific_info(outputStream* st); >> 47: static void print_container_helper(outputStream* st, jlong j, const char* metrics); >> 48: > > hpp file needs forward declaration of outputStream now, or include ostream.hpp, otherwise you break files that include this header but not ostream. Hi Thomas, I added the inclusion of ostream.hpp . Thanks, Matthias ------------- PR: https://git.openjdk.org/jdk/pull/8991 From stuefe at openjdk.org Wed Jun 22 08:29:43 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 22 Jun 2022 08:29:43 GMT Subject: RFR: JDK-8287011: Improve container information [v6] In-Reply-To: <3sKyZmnRqYNFue4wdDEcFtBWoUUDSYFXyDCkAwZoCS4=.e94191c1-7ea8-499e-bfbe-bb1b7926af81@github.com> References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> <3sKyZmnRqYNFue4wdDEcFtBWoUUDSYFXyDCkAwZoCS4=.e94191c1-7ea8-499e-bfbe-bb1b7926af81@github.com> Message-ID: On Wed, 22 Jun 2022 08:20:50 GMT, Matthias Baesken wrote: >> The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add inclusion of ostream.hpp Thank you Matthias. This looks good to me now. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/8991 From simonis at openjdk.org Wed Jun 22 09:40:43 2022 From: simonis at openjdk.org (Volker Simonis) Date: Wed, 22 Jun 2022 09:40:43 GMT Subject: RFR: 8288926: make runtime/logging/DeoptStats.java more reliable In-Reply-To: References: Message-ID: On Tue, 21 Jun 2022 23:11:43 GMT, Xin Liu wrote: > Currently, the test only triggers one deoptimization and it is not the test itself. In [JDK-8287385](https://bugs.openjdk.org/browse/JDK-8287385), we suppress the superficial unstable_if traps and then we can't pass this test. We would like to make sure the test triggers a deoptimization itself and is not subject to external environment. > > Before this change, vmOutput.log has the following information. > > > Deoptimization traps recorded: > 1 (100.0%) total > unstable_if/reinterpret/if_icmpeq: 1 (100.0%) > > > > After this change, it contains 2 deoptimizations. The null-check deopt comes from the test itself. > > > Deoptimization traps recorded: > 2 (100.0%) total > null_check/maybe_recompile/getfield: 1 (50.0%) > unstable_if/reinterpret/if_icmpeq: 1 (50.0%) > > > > Test: > ``` > $make test TEST="runtime/logging/DeoptStats.java" CONF=linux-x86_64-server-release LOG=info Change looks good. Thanks for catching this! ------------- Marked as reviewed by simonis (Reviewer). PR: https://git.openjdk.org/jdk/pull/9228 From mbaesken at openjdk.org Wed Jun 22 10:39:59 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 22 Jun 2022 10:39:59 GMT Subject: Integrated: JDK-8287011: Improve container information In-Reply-To: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> References: <3vdIVfAmMzGoWc2nlHsB4WFcIR5V47byRxzx9ZqiLGc=.b587c9ab-e247-4299-8549-5bd128b40554@github.com> Message-ID: On Thu, 2 Jun 2022 13:03:31 GMT, Matthias Baesken wrote: > The change adds some potentially interesting cgroup v1 and v2 metrics to hs_err / hs_info files. This pull request has now been integrated. Changeset: d51f4f47 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/d51f4f471f3941294a987dcb68ee264fe27f018a Stats: 125 lines in 9 files changed: 104 ins; 13 del; 8 mod 8287011: Improve container information Reviewed-by: sgehwolf, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/8991 From dholmes at openjdk.org Wed Jun 22 12:34:53 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Jun 2022 12:34:53 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 07:45:26 GMT, Johan Sj?l?n wrote: >> Please review this fix for JDK-8288904, thank you. >> >> Currently running tier1-3 tests. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Comment the loadstore This fix in itself looks good. But it raises a lot of questions for me about how concurrent access is actual controlled here. I can't see what stops a new reader from becoming active after we see _active_readers go to zero? Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9225 From dholmes at openjdk.org Wed Jun 22 12:43:59 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Jun 2022 12:43:59 GMT Subject: RFR: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test [v3] In-Reply-To: References: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> Message-ID: On Wed, 22 Jun 2022 06:50:42 GMT, KIRIYAMA Takuya wrote: >> I would like to fix 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test. >> >> FlightRecorder option has not been tested since JDK13. >> I think we should test it, because FlightRecorder option has not been obsolete in the latest JDK. >> Users would be in trouble if the option suddenly disappears without notice, >> so it's important to confirm the deprication message. >> >> Also we should add a test of ExtendedDTraceProbes option. >> The test was disabled in 8281675, because some jdk can't specify it. >> I modified the test to be able to verify ExtendedDTraceProbes in either case that DTRACE_ENABLED is enabled or not. > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test Thanks for the update. Small style nit but otherwise good. Thanks. test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 71: > 69: )); > 70: if (wb.isJFRIncluded()) { > 71: deprecated.add(new String[] {"FlightRecorder", "false"}); No need for all the extra whitespace after the comma - just a single space please. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9123 From duke at openjdk.org Wed Jun 22 13:57:11 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 22 Jun 2022 13:57:11 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 12:31:31 GMT, David Holmes wrote: >> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment the loadstore > > This fix in itself looks good. > > But it raises a lot of questions for me about how concurrent access is actual controlled here. I can't see what stops a new reader from becoming active after we see _active_readers go to zero? > > Thanks. @dholmes-ora, The implementation is lock-free and uses RCU. This is approximately how it works in pseudo-code: class LogOutputList { LogOutputNode* entry; // All threads gain entry to the linked list through this pointer } void LogOutputList::mutate_output_list() { // Save the entry pointer LogOutputNode* cur = entry; // Remove the entry pointer, now no new readers can access this list entry = NULL; // OK, we can now wait for all readers to exit wait_until_no_readers(); // ... Do things we need to do to cur ... // Restore pointer, new readers can occur. entry = cur; } There are some details here which I have omitted, but this is the gist of it. ------------- PR: https://git.openjdk.org/jdk/pull/9225 From duke at openjdk.org Wed Jun 22 13:57:13 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 22 Jun 2022 13:57:13 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 07:45:26 GMT, Johan Sj?l?n wrote: >> Please review this fix for JDK-8288904, thank you. >> >> Currently running tier1-3 tests. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Comment the loadstore Please sponsor this, thank you :-). ------------- PR: https://git.openjdk.org/jdk/pull/9225 From phh at openjdk.org Wed Jun 22 14:34:39 2022 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 22 Jun 2022 14:34:39 GMT Subject: RFR: 8288926: make runtime/logging/DeoptStats.java more reliable In-Reply-To: References: Message-ID: <4FrjLH3UXWASYbuwCpAlg-2Qw3fQ6-Opi2OYKIuP5ek=.8650d0b9-49ed-4f19-a60d-8ed9a824cbdc@github.com> On Tue, 21 Jun 2022 23:11:43 GMT, Xin Liu wrote: > Currently, the test only triggers one deoptimization and it is not the test itself. In [JDK-8287385](https://bugs.openjdk.org/browse/JDK-8287385), we suppress the superficial unstable_if traps and then we can't pass this test. We would like to make sure the test triggers a deoptimization itself and is not subject to external environment. > > Before this change, vmOutput.log has the following information. > > > Deoptimization traps recorded: > 1 (100.0%) total > unstable_if/reinterpret/if_icmpeq: 1 (100.0%) > > > > After this change, it contains 2 deoptimizations. The null-check deopt comes from the test itself. > > > Deoptimization traps recorded: > 2 (100.0%) total > null_check/maybe_recompile/getfield: 1 (50.0%) > unstable_if/reinterpret/if_icmpeq: 1 (50.0%) > > > > Test: > ``` > $make test TEST="runtime/logging/DeoptStats.java" CONF=linux-x86_64-server-release LOG=info Lgtm. ------------- Marked as reviewed by phh (Reviewer). PR: https://git.openjdk.org/jdk/pull/9228 From xliu at openjdk.org Wed Jun 22 16:01:57 2022 From: xliu at openjdk.org (Xin Liu) Date: Wed, 22 Jun 2022 16:01:57 GMT Subject: Integrated: 8288926: make runtime/logging/DeoptStats.java more reliable In-Reply-To: References: Message-ID: <65sCvhWs7iZ_941UhYMGufC6-2q4KPVwz_hRppwmEFc=.353e2219-f823-49fe-a736-11a64d42d2d8@github.com> On Tue, 21 Jun 2022 23:11:43 GMT, Xin Liu wrote: > Currently, the test only triggers one deoptimization and it is not the test itself. In [JDK-8287385](https://bugs.openjdk.org/browse/JDK-8287385), we suppress the superficial unstable_if traps and then we can't pass this test. We would like to make sure the test triggers a deoptimization itself and is not subject to external environment. > > Before this change, vmOutput.log has the following information. > > > Deoptimization traps recorded: > 1 (100.0%) total > unstable_if/reinterpret/if_icmpeq: 1 (100.0%) > > > > After this change, it contains 2 deoptimizations. The null-check deopt comes from the test itself. > > > Deoptimization traps recorded: > 2 (100.0%) total > null_check/maybe_recompile/getfield: 1 (50.0%) > unstable_if/reinterpret/if_icmpeq: 1 (50.0%) > > > > Test: > ``` > $make test TEST="runtime/logging/DeoptStats.java" CONF=linux-x86_64-server-release LOG=info This pull request has now been integrated. Changeset: 82c77ca8 Author: Xin Liu URL: https://git.openjdk.org/jdk/commit/82c77ca807d62c25b9605c6c8164e42af6c3ce6e Stats: 16 lines in 1 file changed: 9 ins; 5 del; 2 mod 8288926: make runtime/logging/DeoptStats.java more reliable Reviewed-by: simonis, phh ------------- PR: https://git.openjdk.org/jdk/pull/9228 From dcubed at openjdk.org Wed Jun 22 16:23:59 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 22 Jun 2022 16:23:59 GMT Subject: Integrated: 8288988: ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode Message-ID: A trivial fix to ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode. ------------- Commit messages: - 8288988: ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode Changes: https://git.openjdk.org/jdk19/pull/58/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=58&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288988 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/58.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/58/head:pull/58 PR: https://git.openjdk.org/jdk19/pull/58 From alanb at openjdk.org Wed Jun 22 16:24:00 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 22 Jun 2022 16:24:00 GMT Subject: Integrated: 8288988: ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 16:12:06 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/58 From azvegint at openjdk.org Wed Jun 22 16:24:02 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 22 Jun 2022 16:24:02 GMT Subject: Integrated: 8288988: ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 16:12:06 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode. Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/58 From dcubed at openjdk.org Wed Jun 22 16:24:04 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 22 Jun 2022 16:24:04 GMT Subject: Integrated: 8288988: ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 16:12:58 GMT, Alan Bateman wrote: >> A trivial fix to ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode. > > Marked as reviewed by alanb (Reviewer). @AlanBateman - Thanks for the lightning fast review! ------------- PR: https://git.openjdk.org/jdk19/pull/58 From dcubed at openjdk.org Wed Jun 22 16:24:05 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 22 Jun 2022 16:24:05 GMT Subject: Integrated: 8288988: ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 16:12:59 GMT, Alexander Zvegintsev wrote: >> A trivial fix to ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode. > > Marked as reviewed by azvegint (Reviewer). @azvegint - Thanks for the lightning fast review! ------------- PR: https://git.openjdk.org/jdk19/pull/58 From dcubed at openjdk.org Wed Jun 22 16:24:07 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 22 Jun 2022 16:24:07 GMT Subject: Integrated: 8288988: ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 16:12:06 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode. This pull request has now been integrated. Changeset: 6458ebc8 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk19/commit/6458ebc8e4cb11d99f7447e01f890ba36ad41664 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8288988: ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode Reviewed-by: alanb, azvegint ------------- PR: https://git.openjdk.org/jdk19/pull/58 From xliu at openjdk.org Wed Jun 22 16:53:03 2022 From: xliu at openjdk.org (Xin Liu) Date: Wed, 22 Jun 2022 16:53:03 GMT Subject: RFR: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes random crashes In-Reply-To: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com> References: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com> Message-ID: On Mon, 20 Jun 2022 08:24:49 GMT, Thomas Stuefe wrote: > After [JDK-8284997](https://bugs.openjdk.org/browse/JDK-8284997) delivered just a bandaid, this is hopefully the real fix. > > JDK-8283326 re-implemented SafeFetch as static assembler functions. This broke arm: the VM would crash at random points, usually in Atomic::add(), usually right at startup. In most cases the VM could not even be built correctly, see JDK-8284997. > > This was only reproducible if the VM was built natively, on a Raspberry Pi, inside an Ubuntu18-derived container. Buiding natively on Raspberry Pi OS was fine. Cross-building was fine too. The difference is the default instruction set the toolchain uses. We don't explicitly specify `-mthumb` or `-marm`, so we use the toolchain's default. That default seems to depend on how GCC itself was built. Ubuntu ships a GCC that has been built in thumb mode, thus defaulting to `-mthumb`, whereas Raspberry Pi OS and Fedora ship GCCs that default to `-marm`. > > So, the VM proper is compiled either to arm or thumb code. The `SafeFetch32` assembly function itself uses arm code always. Why this is I don't know for sure, I assume if I wanted thumb I need to specify `.thumb_func` in the assembly. > > If the VM uses thumb, it needs to call SafeFetch32 with a switching branch instruction (BX). But the compiler-generated BL. The instruction set was not switched upon entering SafeFetch32 and garbage thumb code was executed. VM crashes soon after. > > This seems to be a common problem when writing arm assembly by hand, the solution is specify `.type function`. See also [1]: "As of GCC 4.7, the .type directive is pretty much required for functions. Or, rather, it is required if you want ARM and Thumb interworking to work." > > A remaining question is whether we should specify the instruction set explicitly when building on arm32, to prevent surprises like this. Preferably with a configure option. > > ---- > > Testing: > - GHAs are green, but that does not say much: they just do the usual cross building without running the executables. Even if they would run, they would be compiled with -marm and not show the default > - Both @marchof and me tested the fix with a native build on Raspberry Pi. I confirmed that the patch fixes the problem. I ran gtests, which also tests SafeFetch I take a look at linux_arm directory. All functions come in pair(.global and .type function). so it's reasonable. LGTM. I am not a reviewer. we still need other reviewer to approve it. src/hotspot/os_cpu/linux_arm/safefetch_linux_arm.S line 29: > 27: .globl _SafeFetch32_fault > 28: .globl _SafeFetch32_continuation > 29: .type SafeFetch32_impl, %function By adding this .type directive, the compiler knows that SafeFetch32_impl is a function. When static linker resolves it, it will update the correct branch instruction according to its target. In this case, it will use BX on Ubuntu18.04. Is my understanding correct? ------------- Marked as reviewed by xliu (Committer). PR: https://git.openjdk.org/jdk/pull/9213 From rriggs at openjdk.org Wed Jun 22 18:31:40 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 22 Jun 2022 18:31:40 GMT Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more informative Message-ID: The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values. The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value. The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr. Including both expected and actual values in the exception makes it easier to understand. Exception messages should not include newlines. ------------- Commit messages: - 8288495: [test] Make OutputAnalyzer exception more informative Changes: https://git.openjdk.org/jdk/pull/9247/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9247&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288495 Stats: 46 lines in 2 files changed: 27 ins; 1 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/9247.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9247/head:pull/9247 PR: https://git.openjdk.org/jdk/pull/9247 From pchilanomate at openjdk.org Wed Jun 22 19:01:53 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 22 Jun 2022 19:01:53 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 07:45:26 GMT, Johan Sj?l?n wrote: >> Please review this fix for JDK-8288904, thank you. >> >> Passed tier1-tier3 tests, excluding faulty tests. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Comment the loadstore src/hotspot/share/logging/logOutputList.cpp line 51: > 49: // Prevent mutations to the output list to float above the active reader check. > 50: // Such a reordering would lead to readers loading faulty data. > 51: OrderAccess::loadstore(); Just got curious about this memory ordering problem. How can a write after the while loop be executed(and be seen by other threads) without even knowing if we can bail out of the while loop. So I'm thinking that otherwise this program would crash: volatile int never_touched_variable = 0; int* address = (int*)0xBADC0FEE; int main() { while(never_touched_variable == 0) {} *address = 1; return 0; } ------------- PR: https://git.openjdk.org/jdk/pull/9225 From duke at openjdk.org Wed Jun 22 19:54:45 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 22 Jun 2022 19:54:45 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 18:58:37 GMT, Patricio Chilano Mateo wrote: >> Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment the loadstore > > src/hotspot/share/logging/logOutputList.cpp line 51: > >> 49: // Prevent mutations to the output list to float above the active reader check. >> 50: // Such a reordering would lead to readers loading faulty data. >> 51: OrderAccess::loadstore(); > > Just got curious about this memory ordering problem. How can a write after the while loop be executed(and be seen by other threads) without even knowing if we can bail out of the while loop. So I'm thinking that otherwise this program would crash: > > > volatile int never_touched_variable = 0; > int* address = (int*)0xBADC0FEE; > > int main() { > while(never_touched_variable == 0) {} > *address = 1; > return 0; > > } I'm going by ARM's memory model, which is understood by me as something like: "Any nondependent loads and stores may be observed in a different order than program order". Dependency here means register or address dependency. I think your program is allowed to crash, because I think you're invoking UB by making and dereferencing a pointer to random memory. ------------- PR: https://git.openjdk.org/jdk/pull/9225 From eosterlund at openjdk.org Wed Jun 22 20:19:53 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 22 Jun 2022 20:19:53 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 19:51:34 GMT, Johan Sj?l?n wrote: >> src/hotspot/share/logging/logOutputList.cpp line 51: >> >>> 49: // Prevent mutations to the output list to float above the active reader check. >>> 50: // Such a reordering would lead to readers loading faulty data. >>> 51: OrderAccess::loadstore(); >> >> Just got curious about this memory ordering problem. How can a write after the while loop be executed(and be seen by other threads) without even knowing if we can bail out of the while loop. So I'm thinking that otherwise this program would crash: >> >> >> volatile int never_touched_variable = 0; >> int* address = (int*)0xBADC0FEE; >> >> int main() { >> while(never_touched_variable == 0) {} >> *address = 1; >> return 0; >> >> } > > I'm going by ARM's memory model, which is understood by me as something like: "Any nondependent loads and stores may be observed in a different order than program order". Dependency here means register or address dependency. > > I think your program is allowed to crash, because I think you're invoking UB by making and dereferencing a pointer to random memory. I suppose the memory state change due to calling free on a node can reorder to before the load checking there are no readers. The. The memory can appear to be free memory and get allocated to random other memory that changes state arbitrarily, while there is still a concurrent reader. ------------- PR: https://git.openjdk.org/jdk/pull/9225 From eosterlund at openjdk.org Wed Jun 22 20:42:34 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 22 Jun 2022 20:42:34 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 07:45:26 GMT, Johan Sj?l?n wrote: >> Please review this fix for JDK-8288904, thank you. >> >> Passed tier1-tier3 tests, excluding faulty tests. > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Comment the loadstore Talked to Johan and StefanK earlier today. In general this data structure is very poorly synchronized. Nodes are injected without release store even though there are concurrent readers, there is no fencing or atomics around basically any of the heads or next pointer accesses, despite reading and writing to them concurrently. Not sure how much of it we want to rewrite in this particular patch, but it does need major reworking I think. Maybe the most reasonable option is writing a new data structure entirely. Or maybe this is one of those times where having any form of readers writer lock would make this code way easier to reason about. We already mark where the reader vs writer sections are, but with unnecessarily relaxed and fragile synchronization for what it is. We have other places where we really want a readers writer lock and end up inventing the wheel again. Not sure if fixing this properly should be done in this patch or a follow up patch. ------------- PR: https://git.openjdk.org/jdk/pull/9225 From pchilanomate at openjdk.org Wed Jun 22 20:42:34 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 22 Jun 2022 20:42:34 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 20:17:48 GMT, Erik ?sterlund wrote: >> I'm going by ARM's memory model, which is understood by me as something like: "Any nondependent loads and stores may be observed in a different order than program order". Dependency here means register or address dependency. >> >> I think your program is allowed to crash, because I think you're invoking UB by making and dereferencing a pointer to random memory. > > I suppose the memory state change due to calling free on a node can reorder to before the load checking there are no readers. The. The memory can appear to be free memory and get allocated to random other memory that changes state arbitrarily, while there is still a concurrent reader. Right but isn't there a control dependency that the hardware will still obey? Or can the hardware write to memory even if that path is never taken? Regarding UB, I could paste the assembly of that instead (maybe I should have done that). My question was whether the cpu can execute that write instruction before even knowing if that branch will be taken. Note: I found this interesting article about control dependencies (https://urldefense.com/v3/__https://lwn.net/Articles/860037/__;!!ACWV5N9M2RV99hQ!ONppXCB70bV7ccOwZEwlx-8yzEYb9NeIOdBFO6jpAxIJ-UUqDpaa9ySnJuhOrdFotRUvhQ_fpdyies-UqGWnrtmKxxqCFxa4A3IB$ ). It mentions that the hardware will respect that dependency but there could be some aggressive compiler optimizations on some cases. I don't think that applies here though. @fisk sorry, not sure I understood the example. ------------- PR: https://git.openjdk.org/jdk/pull/9225 From dcubed at openjdk.org Wed Jun 22 20:46:53 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 22 Jun 2022 20:46:53 GMT Subject: RFR: 8288497: add support for JavaThread::is_oop_safe() [v3] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 01:01:52 GMT, David Holmes wrote: >> The logic style of this function is a carry over from before we had Thread-SMR >> and we tried to detect a freed JavaThread. With Thread-SMR, we don't need to >> do the check this way at all. >> >> Do we really want to change that as part of this fix for JDK19? > > No it can be cleaned up later. This fix just highlighted the badness of that piece of code. :) New RFE filed: [JDK-8289003](https://bugs.openjdk.org/browse/JDK-8289003) JavaThread::check_is_terminated() implementation should rely on Thread-SMR ------------- PR: https://git.openjdk.org/jdk19/pull/20 From dcubed at openjdk.org Wed Jun 22 21:01:05 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 22 Jun 2022 21:01:05 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v4] In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 00:00:32 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/sharedRuntime.cpp line 998: >> >>> 996: JRT_END >>> 997: >>> 998: jlong SharedRuntime::get_java_tid(Thread* thread) { >> >> Additional RFE: can we not declare this to take JavaThread and so avoid the checks and casts below? > > I can research that and file a follow up RFE if necessary. New RFE: [JDK-8289004](https://bugs.openjdk.org/browse/JDK-8289004) investigate if SharedRuntime::get_java_tid parameter should be a JavaThread* ------------- PR: https://git.openjdk.org/jdk19/pull/21 From dcubed at openjdk.org Wed Jun 22 21:04:54 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 22 Jun 2022 21:04:54 GMT Subject: RFR: 8288532: additional review changes for JDK-8286830 [v3] In-Reply-To: References: Message-ID: <1YFKo2MWO_SqP1YD2UmqGdPg-tGvIGFS7BzzAWmr4Uo=.c455ec19-58b5-45c0-a69c-e7eab8cb44f7@github.com> On Mon, 20 Jun 2022 01:54:20 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> VMThread can get to check in AsyncExceptionHandshake() dtr via a bailout. > > test/hotspot/jtreg/runtime/Thread/StopAtExit.java line 79: > >> 77: test(timeMax); >> 78: >> 79: // Fire-up deamon that just creates new threads. This generates contention on > > Existing typo: s/deamon/daemon/ I missed fixing this typo. Sorry about that. ------------- PR: https://git.openjdk.org/jdk19/pull/32 From duke at openjdk.org Wed Jun 22 21:32:45 2022 From: duke at openjdk.org (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Wed, 22 Jun 2022 21:32:45 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 20:36:48 GMT, Patricio Chilano Mateo wrote: >> I suppose the memory state change due to calling free on a node can reorder to before the load checking there are no readers. The. The memory can appear to be free memory and get allocated to random other memory that changes state arbitrarily, while there is still a concurrent reader. > > Right but isn't there a control dependency that the hardware will still obey? Or can the hardware write to memory even if that path is never taken? > Regarding UB, I could paste the assembly of that instead (maybe I should have done that). My question was whether the cpu can execute that write instruction before even knowing if that branch will be taken. > Note: I found this interesting article about control dependencies (https://urldefense.com/v3/__https://lwn.net/Articles/860037/__;!!ACWV5N9M2RV99hQ!KJ35L5WteqhN2paAKJd-fNBSSy6UTQMfYkii6nenAdhVtAN4zwcLNDol-4ph7vZvAueJnQE64xlux1FIOG54JI9jcQ$ ). It mentions that the hardware will respect that dependency but there could be some aggressive compiler optimizations on some cases. I don't think that applies here though. > @fisk sorry, not sure I understood the example. @pchilano, it seems that it is true that a control dependency establishes that writes are not moved above the read of a control branch (as we do not know which, if any, branch is taken before the read is done). read-on-read allows for moving it up however. For example: // OK x = true; while(x == true) { } y = a[0]; ~> x = true; y = a[0]; while(x == true) {} // NOT OK x = true; while(x == true) { } a[0] = 5; ~> x = true; a[0] = 5; while(x == true) {} Source: https://urldefense.com/v3/__https://www.cl.cam.ac.uk/*pes20/ppc-supplemental/test7.pdf__;fg!!ACWV5N9M2RV99hQ!KJ35L5WteqhN2paAKJd-fNBSSy6UTQMfYkii6nenAdhVtAN4zwcLNDol-4ph7vZvAueJnQE64xlux1FIOG6gNXcOQg$ section 4.2 and 4.4 I believe that that means that this barrier is unnecessary, but it's good manners to do the `Atomic::load`. Nice catch :-). ------------- PR: https://git.openjdk.org/jdk/pull/9225 From dholmes at openjdk.org Wed Jun 22 22:01:54 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 22 Jun 2022 22:01:54 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 13:54:00 GMT, Johan Sj?l?n wrote: > There are some details here which I have omitted, but this is the gist of it. @jdksjolen - it is the actual details I have concerns about. More seems to be done than just a pointer switch to unlink, and the unlink itself is not an atomic operation - are we guaranteed only a single writer is possible? And even so, as others have noted, without atomics or barriers there is no guarantee readers will see the unlink has happened. I'm a bit surprised as this code has been extensively examined in the past. ------------- PR: https://git.openjdk.org/jdk/pull/9225 From eosterlund at openjdk.org Wed Jun 22 22:22:58 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 22 Jun 2022 22:22:58 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 21:28:12 GMT, Johan Sj?l?n wrote: >> Right but isn't there a control dependency that the hardware will still obey? Or can the hardware write to memory even if that path is never taken? >> Regarding UB, I could paste the assembly of that instead (maybe I should have done that). My question was whether the cpu can execute that write instruction before even knowing if that branch will be taken. >> Note: I found this interesting article about control dependencies (https://urldefense.com/v3/__https://lwn.net/Articles/860037/__;!!ACWV5N9M2RV99hQ!IOIrmfu0oArXPy3TLSB_VXl7RhgOxmdZAlAFkn9GvYKcpKIiJoSbFD8WRD8wf_6y5Mlimf7qQFsxAmxLQgTjIxb0GFB1epPOUA$ ). It mentions that the hardware will respect that dependency but there could be some aggressive compiler optimizations on some cases. I don't think that applies here though. >> @fisk sorry, not sure I understood the example. > > @pchilano, it seems that it is true that a control dependency establishes that writes are not moved above the read of a control branch (as we do not know which, if any, branch is taken before the read is done). read-on-read allows for moving it up however. > > For example: > > > // OK > x = true; > while(x == true) { } > y = a[0]; > ~> > x = true; > y = a[0]; > while(x == true) {} > // NOT OK > x = true; > while(x == true) { } > a[0] = 5; > ~> > x = true; > a[0] = 5; > while(x == true) {} > > > Source: > > https://urldefense.com/v3/__https://www.cl.cam.ac.uk/*pes20/ppc-supplemental/test7.pdf__;fg!!ACWV5N9M2RV99hQ!IOIrmfu0oArXPy3TLSB_VXl7RhgOxmdZAlAFkn9GvYKcpKIiJoSbFD8WRD8wf_6y5Mlimf7qQFsxAmxLQgTjIxb0GFCogvwZ5A$ section 4.2 and 4.4 > > I believe that that means that this barrier is unnecessary, but it's good manners to do the `Atomic::load`. > > Nice catch :-). Hold your horses guys. I think the logic in the cited paper is flawed. It essentially says that surely the hardware couldn't perform stores before knowing what control flow is taken, at which point the value of the load must be known. Therefore the hardware can't reorder the load and store. Well, the hardware can speculate one branch is taken, defer the load, buffer the stores without committing them to caches, and then commit them once the load is executed, and the speculation is proven right, committing the branch. Then the already buffered stores will be published. This will yield a result equivalent to the load and store appearing to have reordered across the control dependency. It would never break a sequential program, but would reorder a LoadStore pairbseparated by a control dependency, requiring barriers. In fact, the official ARMv8 memory model document linked here https://urldefense.com/v3/__https://documentation-service.arm.com/static/6048f1aaee937942ba302655__;!!ACWV5N9M2RV99hQ!IOIrmfu0oArXPy3TLSB_VXl7RhgOxmdZAlAFkn9GvYKcpKIiJoSbFD8WRD8wf_6y5Mlimf7qQFsxAmxLQgTjIxb0GFAgf59piA$ (end of section 6.2) says explicitly that the control dependency is *not* enough to prevent ordering between a load and a store, and that you need explicit barriers if you don't want reordering. So basically I would rather trust the official ARM documentation that explicitly says it may reorder, than an academic paper saying it isn't possible because building such hardware would be tricky. It's essentially proof by lack of imagination IMO. It would be interesting I guess, to run the "S" litmus test on the failing machine. Although I wouldn't want to rely on control dependency tricks for ordering regardless of the outcome. I would follow the spec and assume reordering can happen, as it clearly states. ------------- PR: https://git.openjdk.org/jdk/pull/9225 From pchilanomate at openjdk.org Thu Jun 23 00:28:39 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 23 Jun 2022 00:28:39 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 21:28:12 GMT, Johan Sj?l?n wrote: >> Right but isn't there a control dependency that the hardware will still obey? Or can the hardware write to memory even if that path is never taken? >> Regarding UB, I could paste the assembly of that instead (maybe I should have done that). My question was whether the cpu can execute that write instruction before even knowing if that branch will be taken. >> Note: I found this interesting article about control dependencies (https://urldefense.com/v3/__https://lwn.net/Articles/860037/__;!!ACWV5N9M2RV99hQ!Kzs6Cjo0qIr6Enxz-LcQe8CTnxEOq_LZ2yjWnN-gBsKOmvftMw3Mz2vw26DykXzXasWmnKpJbKlQJ8njG3Fv-jAHAojE4pM_qWEc$ ). It mentions that the hardware will respect that dependency but there could be some aggressive compiler optimizations on some cases. I don't think that applies here though. >> @fisk sorry, not sure I understood the example. > > @pchilano, it seems that it is true that a control dependency establishes that writes are not moved above the read of a control branch (as we do not know which, if any, branch is taken before the read is done). read-on-read allows for moving it up however. > > For example: > > > // OK > x = true; > while(x == true) { } > y = a[0]; > ~> > x = true; > y = a[0]; > while(x == true) {} > // NOT OK > x = true; > while(x == true) { } > a[0] = 5; > ~> > x = true; > a[0] = 5; > while(x == true) {} > > > Source: > > https://urldefense.com/v3/__https://www.cl.cam.ac.uk/*pes20/ppc-supplemental/test7.pdf__;fg!!ACWV5N9M2RV99hQ!Kzs6Cjo0qIr6Enxz-LcQe8CTnxEOq_LZ2yjWnN-gBsKOmvftMw3Mz2vw26DykXzXasWmnKpJbKlQJ8njG3Fv-jAHAojE4pQsVJOK$ section 4.2 and 4.4 > > I believe that that means that this barrier is unnecessary, but it's good manners to do the `Atomic::load`. > > Nice catch :-). @jdksjolen, @fisk thanks for the investigation and linked documents! Mmm there seems to be contradictory definitions then. I also found [1] which as I understand it defines there should be an order between those instructions (sections B2.3.2 and B2.3.3; there is even an intent Note about that). But the fact that we have to look this up and check the fine print is already surprising for me. I thought any cpu would provide that guarantee. [1] Arm Architecture Reference Manual: https://urldefense.com/v3/__https://documentation-service.arm.com/static/623b2de33b9f553dde8fd3b0__;!!ACWV5N9M2RV99hQ!Kzs6Cjo0qIr6Enxz-LcQe8CTnxEOq_LZ2yjWnN-gBsKOmvftMw3Mz2vw26DykXzXasWmnKpJbKlQJ8njG3Fv-jAHAojE4m07XJSL$ ------------- PR: https://git.openjdk.org/jdk/pull/9225 From jpai at openjdk.org Thu Jun 23 01:17:45 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 23 Jun 2022 01:17:45 GMT Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more informative In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 18:19:56 GMT, Roger Riggs wrote: > The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values. > The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value. > The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr. Including both expected and actual values in the exception makes it easier to understand. > > Exception messages should not include newlines. The source changes look fine to me. The test file change would need a copyright year update. test/lib-test/jdk/test/lib/process/OutputAnalyzerTest.java line 223: > 221: try { > 222: // Verify the exception message > 223: OutputAnalyzer out = ProcessTools.executeProcess("true"); Hello Roger, this test seems to run on all OS. Is `true` available on Windows? If yes, does it require a `.exe` suffix? ------------- PR: https://git.openjdk.org/jdk/pull/9247 From naoto at openjdk.org Thu Jun 23 01:44:40 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 23 Jun 2022 01:44:40 GMT Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more informative In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 18:19:56 GMT, Roger Riggs wrote: > The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values. > The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value. > The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr. Including both expected and actual values in the exception makes it easier to understand. > > Exception messages should not include newlines. test/lib/jdk/test/lib/process/OutputAnalyzer.java line 505: > 503: reportDiagnosticSummary(); > 504: throw new RuntimeException("Unexpected to get exit value of [" > 505: + notExpectedExitValue + "], exit value is: [" + getExitValue() + "]"); This seems redundant to me. "Unexpected to get exit value of [notExpectedExitValue]." should suffice? ------------- PR: https://git.openjdk.org/jdk/pull/9247 From stuefe at openjdk.org Thu Jun 23 03:59:54 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 23 Jun 2022 03:59:54 GMT Subject: RFR: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes random crashes In-Reply-To: References: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com> Message-ID: On Wed, 22 Jun 2022 16:50:18 GMT, Xin Liu wrote: > I take a look at linux_arm directory. All functions come in pair(.global and .type function). so it's reasonable. LGTM. I am not a reviewer. we still need other reviewer to approve it. Thank you, Xin! > By adding this .type directive, the compiler knows that SafeFetch32_impl is a function. When static linker resolves it, it will update the correct branch instruction according to its target. In this case, it will use BX on Ubuntu18.04. > > Is my understanding correct? Correct. ------------- PR: https://git.openjdk.org/jdk/pull/9213 From dholmes at openjdk.org Thu Jun 23 06:12:38 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Jun 2022 06:12:38 GMT Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more informative In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 01:40:57 GMT, Naoto Sato wrote: >> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values. >> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value. >> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr. Including both expected and actual values in the exception makes it easier to understand. >> >> Exception messages should not include newlines. > > test/lib/jdk/test/lib/process/OutputAnalyzer.java line 505: > >> 503: reportDiagnosticSummary(); >> 504: throw new RuntimeException("Unexpected to get exit value of [" >> 505: + notExpectedExitValue + "], exit value is: [" + getExitValue() + "]"); > > This seems redundant to me. "Unexpected to get exit value of [notExpectedExitValue]." should suffice? I agree this doesn't need changing as there is only one value to report. ------------- PR: https://git.openjdk.org/jdk/pull/9247 From duke at openjdk.org Thu Jun 23 06:28:26 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Thu, 23 Jun 2022 06:28:26 GMT Subject: RFR: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test [v4] In-Reply-To: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> References: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> Message-ID: <7Sxfb-hZK0rSrYAr5nHrOe0QnIwTYRIl_7YENj7lGrM=.5c9e5a5d-786e-4362-a4d3-01e15ec19602@github.com> > I would like to fix 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test. > > FlightRecorder option has not been tested since JDK13. > I think we should test it, because FlightRecorder option has not been obsolete in the latest JDK. > Users would be in trouble if the option suddenly disappears without notice, > so it's important to confirm the deprication message. > > Also we should add a test of ExtendedDTraceProbes option. > The test was disabled in 8281675, because some jdk can't specify it. > I modified the test to be able to verify ExtendedDTraceProbes in either case that DTRACE_ENABLED is enabled or not. KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9123/files - new: https://git.openjdk.org/jdk/pull/9123/files/5e4b17c3..94437241 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9123&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9123&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9123.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9123/head:pull/9123 PR: https://git.openjdk.org/jdk/pull/9123 From duke at openjdk.org Thu Jun 23 06:28:27 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Thu, 23 Jun 2022 06:28:27 GMT Subject: RFR: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test [v3] In-Reply-To: References: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> Message-ID: On Wed, 22 Jun 2022 12:38:50 GMT, David Holmes wrote: >> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: >> >> 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test > > test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java line 71: > >> 69: )); >> 70: if (wb.isJFRIncluded()) { >> 71: deprecated.add(new String[] {"FlightRecorder", "false"}); > > No need for all the extra whitespace after the comma - just a single space please. That's right. I fixed it. ------------- PR: https://git.openjdk.org/jdk/pull/9123 From dholmes at openjdk.org Thu Jun 23 06:34:47 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 23 Jun 2022 06:34:47 GMT Subject: RFR: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test [v4] In-Reply-To: <7Sxfb-hZK0rSrYAr5nHrOe0QnIwTYRIl_7YENj7lGrM=.5c9e5a5d-786e-4362-a4d3-01e15ec19602@github.com> References: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> <7Sxfb-hZK0rSrYAr5nHrOe0QnIwTYRIl_7YENj7lGrM=.5c9e5a5d-786e-4362-a4d3-01e15ec19602@github.com> Message-ID: On Thu, 23 Jun 2022 06:28:26 GMT, KIRIYAMA Takuya wrote: >> I would like to fix 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test. >> >> FlightRecorder option has not been tested since JDK13. >> I think we should test it, because FlightRecorder option has not been obsolete in the latest JDK. >> Users would be in trouble if the option suddenly disappears without notice, >> so it's important to confirm the deprication message. >> >> Also we should add a test of ExtendedDTraceProbes option. >> The test was disabled in 8281675, because some jdk can't specify it. >> I modified the test to be able to verify ExtendedDTraceProbes in either case that DTRACE_ENABLED is enabled or not. > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9123 From eosterlund at openjdk.org Thu Jun 23 06:44:55 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 23 Jun 2022 06:44:55 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 00:25:21 GMT, Patricio Chilano Mateo wrote: >> @pchilano, it seems that it is true that a control dependency establishes that writes are not moved above the read of a control branch (as we do not know which, if any, branch is taken before the read is done). read-on-read allows for moving it up however. >> >> For example: >> >> >> // OK >> x = true; >> while(x == true) { } >> y = a[0]; >> ~> >> x = true; >> y = a[0]; >> while(x == true) {} >> // NOT OK >> x = true; >> while(x == true) { } >> a[0] = 5; >> ~> >> x = true; >> a[0] = 5; >> while(x == true) {} >> >> >> Source: >> >> https://urldefense.com/v3/__https://www.cl.cam.ac.uk/*pes20/ppc-supplemental/test7.pdf__;fg!!ACWV5N9M2RV99hQ!NCWRDf1vDwPm4fPLuR7h2rfx0zESKwH5pKSsQUW7EXHE7B3Nw4diNRNS9UhaHsrCB1lSR5mTUuV-aNo2XLU4jn7RC-0nfdRWnw$ section 4.2 and 4.4 >> >> I believe that that means that this barrier is unnecessary, but it's good manners to do the `Atomic::load`. >> >> Nice catch :-). > > @jdksjolen, @fisk thanks for the investigation and linked documents! Mmm there seems to be contradictory definitions then. I also found [1] which as I understand it defines there should be an order between those instructions (sections B2.3.2 and B2.3.3; there is even an intent Note about that). But the fact that we have to look this up and check the fine print is already surprising for me. I thought any cpu would provide that guarantee. > > [1] Arm Architecture Reference Manual: https://urldefense.com/v3/__https://documentation-service.arm.com/static/623b2de33b9f553dde8fd3b0__;!!ACWV5N9M2RV99hQ!NCWRDf1vDwPm4fPLuR7h2rfx0zESKwH5pKSsQUW7EXHE7B3Nw4diNRNS9UhaHsrCB1lSR5mTUuV-aNo2XLU4jn7RC-1hRP_Vcw$ Interesting find! So we have 2 ARMv8 memory model documents from ARM, one explicitly saying it may reorder and one explicitly saying it may not. Since the document saying it won't reorder is more recent, I guess they might have completely changed their minds about this. Has happened before, and seems fine. While similarly to how we don't exploit data dependency without language level guarantees (we are writing C++, not assembly), I would not exploit control dependencies either, without a C++ level contract saying that's fine, defined in a C++ context. So we should have fences anyway. However, I would have to assume that ARM would only really be able to update the spec to say this won't reorder, if they knew there are no implementations where it does. So that might at least provide a clue that maybe the reason this code crashed, is due to something different, like maybe the lack of release when allocating new list entries that are injected into the list. So while we might want some fence here anyway, it seems likely it won't stop this code from crashing. Is it time to wrap the whole thing in a readers writer lock? We already increment and decrement a global variable on the reader side, and writes barely ever happen, but are marked with a lock for writers. It would seemingly fix the problems. ------------- PR: https://git.openjdk.org/jdk/pull/9225 From rehn at openjdk.org Thu Jun 23 07:06:56 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 23 Jun 2022 07:06:56 GMT Subject: RFR: 8288904: Incorrect memory ordering in UL [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 20:39:37 GMT, Erik ?sterlund wrote: > Talked to Johan and StefanK earlier today. In general this data structure is very poorly synchronized. Nodes are injected without release store even though there are concurrent readers, there is no fencing or atomics around basically any of the heads or next pointer accesses, despite reading and writing to them concurrently. Not sure how much of it we want to rewrite in this particular patch, but it does need major reworking I think. Maybe the most reasonable option is writing a new data structure entirely. Or maybe this is one of those times where having any form of readers writer lock would make this code way easier to reason about. We already mark where the reader vs writer sections are, but with unnecessarily relaxed and fragile synchronization for what it is. We have other places where we really want a readers writer lock and end up inventing the wheel again. Not sure if fixing this properly should be done in this patch or a follow up patch. If I remember correctly I suggested this code should use the global counter instead. On control flow dependencies, even compiler can change the control flow so this is an issue on x86 also. (in this case the variable is volatile, so it eliminates most issue). According to "Who's afraid of a big bad optimizing compiler?" even this is buggy: // Writer, stores are ordered y = 1; OrderAccess::storestore(); Atomic::store(&x, 1); // Reader int xr = Atomic::load(&x); OrderAccess::loadstore(); if (xr == 1) y = 0; // Compiler can re-write the reader as: int xr = Atomic::load(&x); OrderAccess::loadstore(); if (xr == 1) if (y != 0) // <--- can be reordered with load of x y = 0; This particular compiler re-write seems to be very, very uncommon, but legal. ------------- PR: https://git.openjdk.org/jdk/pull/9225 From lucy at openjdk.org Thu Jun 23 09:25:57 2022 From: lucy at openjdk.org (Lutz Schmidt) Date: Thu, 23 Jun 2022 09:25:57 GMT Subject: RFR: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes random crashes In-Reply-To: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com> References: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com> Message-ID: On Mon, 20 Jun 2022 08:24:49 GMT, Thomas Stuefe wrote: > After [JDK-8284997](https://bugs.openjdk.org/browse/JDK-8284997) delivered just a bandaid, this is hopefully the real fix. > > JDK-8283326 re-implemented SafeFetch as static assembler functions. This broke arm: the VM would crash at random points, usually in Atomic::add(), usually right at startup. In most cases the VM could not even be built correctly, see JDK-8284997. > > This was only reproducible if the VM was built natively, on a Raspberry Pi, inside an Ubuntu18-derived container. Buiding natively on Raspberry Pi OS was fine. Cross-building was fine too. The difference is the default instruction set the toolchain uses. We don't explicitly specify `-mthumb` or `-marm`, so we use the toolchain's default. That default seems to depend on how GCC itself was built. Ubuntu ships a GCC that has been built in thumb mode, thus defaulting to `-mthumb`, whereas Raspberry Pi OS and Fedora ship GCCs that default to `-marm`. > > So, the VM proper is compiled either to arm or thumb code. The `SafeFetch32` assembly function itself uses arm code always. Why this is I don't know for sure, I assume if I wanted thumb I need to specify `.thumb_func` in the assembly. > > If the VM uses thumb, it needs to call SafeFetch32 with a switching branch instruction (BX). But the compiler-generated BL. The instruction set was not switched upon entering SafeFetch32 and garbage thumb code was executed. VM crashes soon after. > > This seems to be a common problem when writing arm assembly by hand, the solution is specify `.type function`. See also [1]: "As of GCC 4.7, the .type directive is pretty much required for functions. Or, rather, it is required if you want ARM and Thumb interworking to work." > > A remaining question is whether we should specify the instruction set explicitly when building on arm32, to prevent surprises like this. Preferably with a configure option. > > ---- > > Testing: > - GHAs are green, but that does not say much: they just do the usual cross building without running the executables. Even if they would run, they would be compiled with -marm and not show the default > - Both @marchof and me tested the fix with a native build on Raspberry Pi. I confirmed that the patch fixes the problem. I ran gtests, which also tests SafeFetch LGTM. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.org/jdk/pull/9213 From stuefe at openjdk.org Thu Jun 23 10:18:07 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 23 Jun 2022 10:18:07 GMT Subject: RFR: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes random crashes In-Reply-To: References: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com> Message-ID: On Mon, 20 Jun 2022 18:50:26 GMT, Sergey Nazarkin wrote: >> After [JDK-8284997](https://bugs.openjdk.org/browse/JDK-8284997) delivered just a bandaid, this is hopefully the real fix. >> >> JDK-8283326 re-implemented SafeFetch as static assembler functions. This broke arm: the VM would crash at random points, usually in Atomic::add(), usually right at startup. In most cases the VM could not even be built correctly, see JDK-8284997. >> >> This was only reproducible if the VM was built natively, on a Raspberry Pi, inside an Ubuntu18-derived container. Buiding natively on Raspberry Pi OS was fine. Cross-building was fine too. The difference is the default instruction set the toolchain uses. We don't explicitly specify `-mthumb` or `-marm`, so we use the toolchain's default. That default seems to depend on how GCC itself was built. Ubuntu ships a GCC that has been built in thumb mode, thus defaulting to `-mthumb`, whereas Raspberry Pi OS and Fedora ship GCCs that default to `-marm`. >> >> So, the VM proper is compiled either to arm or thumb code. The `SafeFetch32` assembly function itself uses arm code always. Why this is I don't know for sure, I assume if I wanted thumb I need to specify `.thumb_func` in the assembly. >> >> If the VM uses thumb, it needs to call SafeFetch32 with a switching branch instruction (BX). But the compiler-generated BL. The instruction set was not switched upon entering SafeFetch32 and garbage thumb code was executed. VM crashes soon after. >> >> This seems to be a common problem when writing arm assembly by hand, the solution is specify `.type function`. See also [1]: "As of GCC 4.7, the .type directive is pretty much required for functions. Or, rather, it is required if you want ARM and Thumb interworking to work." >> >> A remaining question is whether we should specify the instruction set explicitly when building on arm32, to prevent surprises like this. Preferably with a configure option. >> >> ---- >> >> Testing: >> - GHAs are green, but that does not say much: they just do the usual cross building without running the executables. Even if they would run, they would be compiled with -marm and not show the default >> - Both @marchof and me tested the fix with a native build on Raspberry Pi. I confirmed that the patch fixes the problem. I ran gtests, which also tests SafeFetch > > Now I remember jdk8 aarch32 port marks assembly functions specially to handle thumb interworking. AFAIK the bug can be reproduced with overridden C(XX)FLAGS=-mthumb even with crossbuilds. > LGTM Thanks @snazarkin, @navyxliu and @RealLucy ! ------------- PR: https://git.openjdk.org/jdk/pull/9213 From stuefe at openjdk.org Thu Jun 23 10:18:09 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 23 Jun 2022 10:18:09 GMT Subject: Integrated: JDK-8288719: [arm32] SafeFetch32 thumb interleaving causes random crashes In-Reply-To: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com> References: <3HfR5TWv89INSEM5UpcvaPX-yZzntNC2xYrnPGjGgf8=.12105a07-f46d-4821-871f-775f5ac3f07b@github.com> Message-ID: On Mon, 20 Jun 2022 08:24:49 GMT, Thomas Stuefe wrote: > After [JDK-8284997](https://bugs.openjdk.org/browse/JDK-8284997) delivered just a bandaid, this is hopefully the real fix. > > JDK-8283326 re-implemented SafeFetch as static assembler functions. This broke arm: the VM would crash at random points, usually in Atomic::add(), usually right at startup. In most cases the VM could not even be built correctly, see JDK-8284997. > > This was only reproducible if the VM was built natively, on a Raspberry Pi, inside an Ubuntu18-derived container. Buiding natively on Raspberry Pi OS was fine. Cross-building was fine too. The difference is the default instruction set the toolchain uses. We don't explicitly specify `-mthumb` or `-marm`, so we use the toolchain's default. That default seems to depend on how GCC itself was built. Ubuntu ships a GCC that has been built in thumb mode, thus defaulting to `-mthumb`, whereas Raspberry Pi OS and Fedora ship GCCs that default to `-marm`. > > So, the VM proper is compiled either to arm or thumb code. The `SafeFetch32` assembly function itself uses arm code always. Why this is I don't know for sure, I assume if I wanted thumb I need to specify `.thumb_func` in the assembly. > > If the VM uses thumb, it needs to call SafeFetch32 with a switching branch instruction (BX). But the compiler-generated BL. The instruction set was not switched upon entering SafeFetch32 and garbage thumb code was executed. VM crashes soon after. > > This seems to be a common problem when writing arm assembly by hand, the solution is specify `.type function`. See also [1]: "As of GCC 4.7, the .type directive is pretty much required for functions. Or, rather, it is required if you want ARM and Thumb interworking to work." > > A remaining question is whether we should specify the instruction set explicitly when building on arm32, to prevent surprises like this. Preferably with a configure option. > > ---- > > Testing: > - GHAs are green, but that does not say much: they just do the usual cross building without running the executables. Even if they would run, they would be compiled with -marm and not show the default > - Both @marchof and me tested the fix with a native build on Raspberry Pi. I confirmed that the patch fixes the problem. I ran gtests, which also tests SafeFetch This pull request has now been integrated. Changeset: 26c03c18 Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/26c03c1860c6da450b5cd6a46576c78bea682f96 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod 8288719: [arm32] SafeFetch32 thumb interleaving causes random crashes 8284997: arm32 build crashes since JDK-8283326 Reviewed-by: snazarki, xliu, lucy ------------- PR: https://git.openjdk.org/jdk/pull/9213 From rriggs at openjdk.org Thu Jun 23 13:52:46 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 23 Jun 2022 13:52:46 GMT Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more informative In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 01:13:17 GMT, Jaikiran Pai wrote: >> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values. >> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value. >> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr. Including both expected and actual values in the exception makes it easier to understand. >> >> Exception messages should not include newlines. > > test/lib-test/jdk/test/lib/process/OutputAnalyzerTest.java line 223: > >> 221: try { >> 222: // Verify the exception message >> 223: OutputAnalyzer out = ProcessTools.executeProcess("true"); > > Hello Roger, this test seems to run on all OS. Is `true` available on Windows? If yes, does it require a `.exe` suffix? The Windows CreateProcess API appends ".exe". (if there is no suffix). (And CI testing succeeded). ------------- PR: https://git.openjdk.org/jdk/pull/9247 From rriggs at openjdk.org Thu Jun 23 13:57:39 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 23 Jun 2022 13:57:39 GMT Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more informative In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 06:08:49 GMT, David Holmes wrote: >> test/lib/jdk/test/lib/process/OutputAnalyzer.java line 505: >> >>> 503: reportDiagnosticSummary(); >>> 504: throw new RuntimeException("Unexpected to get exit value of [" >>> 505: + notExpectedExitValue + "], exit value is: [" + getExitValue() + "]"); >> >> This seems redundant to me. "Unexpected to get exit value of [notExpectedExitValue]." should suffice? > > I agree this doesn't need changing as there is only one value to report. Right, a bit overzealous on the expected vs actual. ------------- PR: https://git.openjdk.org/jdk/pull/9247 From rriggs at openjdk.org Thu Jun 23 14:09:20 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 23 Jun 2022 14:09:20 GMT Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more informative [v2] In-Reply-To: References: Message-ID: > The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values. > The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value. > The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr. Including both expected and actual values in the exception makes it easier to understand. > > Exception messages should not include newlines. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Revert change to shouldNotHaveExitValue Correct OutputAnalyzerTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9247/files - new: https://git.openjdk.org/jdk/pull/9247/files/4e479b4a..e73bf2bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9247&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9247&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9247.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9247/head:pull/9247 PR: https://git.openjdk.org/jdk/pull/9247 From lmesnik at openjdk.org Thu Jun 23 18:22:53 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 23 Jun 2022 18:22:53 GMT Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more informative [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 14:09:20 GMT, Roger Riggs wrote: >> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values. >> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value. >> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr. Including both expected and actual values in the exception makes it easier to understand. >> >> Exception messages should not include newlines. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revert change to shouldNotHaveExitValue > Correct OutputAnalyzerTest Marked as reviewed by lmesnik (Reviewer). Please update copyrights in the test file, otherwise, the last version looks good. ------------- PR: https://git.openjdk.org/jdk/pull/9247 From naoto at openjdk.org Thu Jun 23 18:34:59 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 23 Jun 2022 18:34:59 GMT Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more informative [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 14:09:20 GMT, Roger Riggs wrote: >> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values. >> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value. >> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr. Including both expected and actual values in the exception makes it easier to understand. >> >> Exception messages should not include newlines. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revert change to shouldNotHaveExitValue > Correct OutputAnalyzerTest LGTM. Thanks for the change. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/9247 From rriggs at openjdk.org Thu Jun 23 19:01:47 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 23 Jun 2022 19:01:47 GMT Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more informative [v3] In-Reply-To: References: Message-ID: > The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values. > The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value. > The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr. Including both expected and actual values in the exception makes it easier to understand. > > Exception messages should not include newlines. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Copyright update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9247/files - new: https://git.openjdk.org/jdk/pull/9247/files/e73bf2bd..a46b4065 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9247&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9247&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9247.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9247/head:pull/9247 PR: https://git.openjdk.org/jdk/pull/9247 From dcubed at openjdk.org Thu Jun 23 20:28:12 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 23 Jun 2022 20:28:12 GMT Subject: RFR: 8288139: JavaThread touches oop after GC barrier is detached [v4] In-Reply-To: References: Message-ID: <2S8KjhL2yL844VDqJPc-yRmVxcqRiT2ypQ1qxdLxV44=.264c919b-daa1-46ae-9d99-3fb541a2c6bc@github.com> On Fri, 17 Jun 2022 00:52:15 GMT, David Holmes wrote: >> I want to fix this bug in JDK19 since it is a blocker for @zhengyu123. I want to >> keep this fix small and focused on the exact crash associated with the bug. >> >> Yes, threadObj() or deeper is a better place. No argument, but I plan to do that >> as a new hunt and I expect there to be many problems and I don't want to hold >> up this fix for additional hunting. If I find more issues, then we'll determine how >> to get them fixed in JDK19. > > Okay New bug: [JDK-8289091](https://bugs.openjdk.org/browse/JDK-8289091) move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() ------------- PR: https://git.openjdk.org/jdk19/pull/21 From hseigel at openjdk.org Thu Jun 23 21:31:33 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Thu, 23 Jun 2022 21:31:33 GMT Subject: RFR: 8288976: classfile parser 'wrong name' error message has the names the wrong way around Message-ID: Please review this small fix for JDK-8288976. The fix was tested by running the new test and mach5 tiers 1-2 on Linux, Mac OS, and Windows. Thanks, Harold ------------- Commit messages: - 8288976: classfile parser 'wrong name' error message has the names the wrong way around Changes: https://git.openjdk.org/jdk/pull/9264/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9264&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288976 Stats: 55 lines in 3 files changed: 49 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9264.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9264/head:pull/9264 PR: https://git.openjdk.org/jdk/pull/9264 From jpai at openjdk.org Fri Jun 24 01:13:40 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 24 Jun 2022 01:13:40 GMT Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more informative [v3] In-Reply-To: References: Message-ID: <-KHGsoLC991hOhQ4nnQIBhfAH-3xHsJmqMB56uJBhqI=.0e308ee2-9cb4-4d91-ac7f-e36ce5fd3984@github.com> On Thu, 23 Jun 2022 19:01:47 GMT, Roger Riggs wrote: >> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values. >> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value. >> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr. Including both expected and actual values in the exception makes it easier to understand. >> >> Exception messages should not include newlines. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Copyright update Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9247 From cjplummer at openjdk.org Fri Jun 24 02:34:45 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 24 Jun 2022 02:34:45 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 12:34:59 GMT, Zhengyu Gu wrote: >> Currently, jdi only check and process class unloading event when it detects a new GC cycle. >> >> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. >> >> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. >> >> It also performs `commonRef_compact()` only when there are classes unloaded. >> >> New test failed about 20% without patch, none with patch. >> >> **Update** >> There are significant changes from early patch. >> >> The new approach: >> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: >> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state >> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state >> >> The new solution breaks up into two steps: >> - Collect all dead object tags with lock >> - Transition to `_in_native` state and post object free events in one batch >> >> This way, JDI event handler can process object free events upon arrivals without delay. > > Zhengyu Gu 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 18 additional commits since the last revision: > > - Improve naming and cleanup > - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event > - v4 > - v3 > - v2 > - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event > - Merge branch 'jdi_tmp' into JDK-8256811-jdi-missing-class-unloading-event > - v0 > - v2 > - v1 > - ... and 8 more: https://git.openjdk.org/jdk/compare/8ac4830c...559b4bf1 It would be good if the test was testing that if there are two `ClassUnloadRequest`, then there should be two `ClassUnloadEvents` in each `EventSet`, one for each `ClassUnloadRequest`. To make it even more interesting, give each `ClassUnloadRequest` a class filter, but have one be more restrictive. You currently use `CLASS_NAME_PREFIX` for each class and then use that as a filter. Maybe you could also have `ALT_CLASS_NAME_PREFIX` that adds a bit more to the prefix, and maybe about half the classes use the ALT prefix. static final String CLASS_NAME_PREFIX = "SampleClass__"; static final String ALT_CLASS_NAME_PREFIX = CLASS_NAME_PREFIX + "ALT__"; Use `CLASS_NAME_PREFIX` as a class filter for one of the `ClassUnloadRequest`s like you are now, and use `ALT_CLASS_NAME_PREFIX` for the other. Then when you get a `ClassUnloadEvent` it should always match `CLASS_NAME_PREFIX`, but if (and only if) it also matches `ALT_CLASS_NAME_PREFIX`, then there should be a second `ClassUnloadEvent` in the `EventSet` that also matches `ALT_CLASS_NAME_PREFIX` ------------- PR: https://git.openjdk.org/jdk/pull/9168 From cjplummer at openjdk.org Fri Jun 24 05:03:15 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 24 Jun 2022 05:03:15 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 12:34:59 GMT, Zhengyu Gu wrote: >> Currently, jdi only check and process class unloading event when it detects a new GC cycle. >> >> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. >> >> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. >> >> It also performs `commonRef_compact()` only when there are classes unloaded. >> >> New test failed about 20% without patch, none with patch. >> >> **Update** >> There are significant changes from early patch. >> >> The new approach: >> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: >> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state >> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state >> >> The new solution breaks up into two steps: >> - Collect all dead object tags with lock >> - Transition to `_in_native` state and post object free events in one batch >> >> This way, JDI event handler can process object free events upon arrivals without delay. > > Zhengyu Gu 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 18 additional commits since the last revision: > > - Improve naming and cleanup > - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event > - v4 > - v3 > - v2 > - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event > - Merge branch 'jdi_tmp' into JDK-8256811-jdi-missing-class-unloading-event > - v0 > - v2 > - v1 > - ... and 8 more: https://git.openjdk.org/jdk/compare/5863bf43...559b4bf1 I think @coleenp and @sspitsyn should review the JVMTI changes. One thing I want to point out is I believe your JVMTI changes mean that the debug agent now gets the ObjectFree events on the Service Thread. At first I was worried this might lead to strange suspend/resume issues of this thread, but I think now it is ok. Let me step through why here. I don't think the Service Thread is a thread that normally even shows up in the debugger's list of java threads. Also, there's no way for the debugger to call ThreadReference.resume() on it, because unlike all other events, there is no ThreadReference included with the ClassUnload event. EventSet.resume() also cannot resume just the Service Thread. However, posting of the CLASS_UNLOAD event eventually leads to (even before your changes): ``` reportEvents(env, eventSessionID, (jthread)NULL, 0, (jclass)NULL, (jmethodID)NULL, 0, eventBag); So the thread provided is NULL. Looking then at `handleReportEventCompositeCommand()`, it looks like if the suspend policy for the event is not NONE, then we do a suspendAll because thread == NULL. If the debugger specified SUSPEND_THREAD as the policy, they will get a SUSPEND_ALL. So it looks like there is no issue with there being an explicit suspend of the Service Thread, and no behavior change here due to your changes. What I'm not sure of is if the Service Thread will get suspended when the debug agent does a Suspend All, but that question is moot, because if it is, it also was before your changes, so you aren't introducing anything new in this respect. src/hotspot/share/prims/jvmtiExport.cpp line 1702: > 1700: } else { > 1701: post_object_free_on_java_thread(env, objects); > 1702: } Can you explain why sometimes it is a VMThread and why sometimes it is a JavaThread? src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 52: > 50: > 51: /* > 52: * Add a class to the prepared class table. This comment is out of date. There is no longer a table and hasn't been for a while. I'd suggest a comment about tagging it so we know when the class is freed. Aslo, maybe `classTrack_trackPreparedClass()` would be a better name. src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 156: > 154: void > 155: classTrack_activate(JNIEnv *env) > 156: { } Remove src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 165: > 163: classTrack_reset(void) > 164: {} > 165: Remove src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 462: > 460: /* Create a synthetic class unload event for every class no longer present. > 461: * Analogous to event_callback combined with a handler in a unload specific > 462: * (no event structure) kind of way. This comment was already out of date. It is based on when we took a new snapshot of loaded classes and compared it with the old snapshot to determine which ones were just unloaded. I would suggest change it to just say something like "Create a synthetic class unload event for the specified signature." src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 627: > 625: > 626: if (evinfo->ei == EI_CLASS_UNLOAD) { > 627: synthesizeUnloadEvent((char*)jlong_to_ptr(evinfo->tag), env); You're in uncharted waters here. Previously `event_callback()` was always called with a `thread` argument except for VMDeath. Now it is being called during an ObjectFree, which has no thread associated with it. That means all the code below that is executed when we have a thread is no longer being executed after the ClassUnload events are generated by the `synthesizeUnloadEvent()` call. Have you thought this part through? My guess is that for the most part it is harmless. The "invoke" support is not relevant in this case. I think/hope that means there is no need for calling `threadControl_onEventHandlerEntry()`. The `filterAndHandleEvent()` probably amounts to an (expensive) nop, although it seems silly to be calling it for the `ObjectFree` event. I'd suggest just returning at this point in the code, but you do still have the restoration of the pending exception to handle. Maybe that should just be done here and then return. It will make it a lot more clear that the rest of the code below is not needed. src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 966: > 964: */ > 965: void JNICALL > 966: cbTrackingObjectFree(jvmtiEnv* jvmti_env, jlong tag) I think it's misleading to have this event handler here since it is handled very differently than all the other events, and with a different `jvmti_env`. Perhaps move this back to classTrack.c, and instead of calling `event_callback()`, call something that just does the parts of `event_callback()` that are really needed for `ObjectFree` (see my comments in `event_callback()` also). What might work bests is to export `synthesizeUnloadEvent()` and just call it from this callback (after relocating it). There's not much of `event_handler()` you need other than the call to `synthesizeUnloadEvent()`. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From dholmes at openjdk.org Fri Jun 24 05:05:46 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 24 Jun 2022 05:05:46 GMT Subject: RFR: 8288495: [test] Make OutputAnalyzer exception more informative [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 19:01:47 GMT, Roger Riggs wrote: >> The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values. >> The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value. >> The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr. Including both expected and actual values in the exception makes it easier to understand. >> >> Exception messages should not include newlines. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Copyright update Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9247 From dholmes at openjdk.org Fri Jun 24 05:07:39 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 24 Jun 2022 05:07:39 GMT Subject: RFR: 8288976: classfile parser 'wrong name' error message has the names the wrong way around In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 21:23:00 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8288976. The fix was tested by running the new test and mach5 tiers 1-2 on Linux, Mac OS, and Windows. > > Thanks, Harold Looks good! Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9264 From shade at openjdk.org Fri Jun 24 06:48:54 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 24 Jun 2022 06:48:54 GMT Subject: RFR: 8288976: classfile parser 'wrong name' error message has the names the wrong way around In-Reply-To: References: Message-ID: <_vVvd3CsN6PuOXexEDmM4XqXEuVZzok9g2StbaLumxI=.fc5821ff-a88e-4ca3-9311-2159de2363ea@github.com> On Thu, 23 Jun 2022 21:23:00 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8288976. The fix was tested by running the new test and mach5 tiers 1-2 on Linux, Mac OS, and Windows. > > Thanks, Harold Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9264 From sspitsyn at openjdk.org Fri Jun 24 09:11:54 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 24 Jun 2022 09:11:54 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 12:34:59 GMT, Zhengyu Gu wrote: >> Currently, jdi only check and process class unloading event when it detects a new GC cycle. >> >> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. >> >> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. >> >> It also performs `commonRef_compact()` only when there are classes unloaded. >> >> New test failed about 20% without patch, none with patch. >> >> **Update** >> There are significant changes from early patch. >> >> The new approach: >> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: >> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state >> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state >> >> The new solution breaks up into two steps: >> - Collect all dead object tags with lock >> - Transition to `_in_native` state and post object free events in one batch >> >> This way, JDI event handler can process object free events upon arrivals without delay. > > Zhengyu Gu 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 18 additional commits since the last revision: > > - Improve naming and cleanup > - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event > - v4 > - v3 > - v2 > - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event > - Merge branch 'jdi_tmp' into JDK-8256811-jdi-missing-class-unloading-event > - v0 > - v2 > - v1 > - ... and 8 more: https://git.openjdk.org/jdk/compare/93b69dbf...559b4bf1 In general, the JVMTI fixes look okay to me at the first glance. Will make another pass tomorrow. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From rpressler at openjdk.org Fri Jun 24 09:42:06 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Fri, 24 Jun 2022 09:42:06 GMT Subject: RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing Message-ID: Please review the following bug fix: `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`. Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode. This change does three things: 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter. 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`. 3. In interp_only_mode, the c2i stub will not patch the callsite. This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128 Passes tiers 1-4 and Loom tiers 1-5. ------------- Commit messages: - fix - Remove outdated comment - Unexclude test Changes: https://git.openjdk.org/jdk19/pull/66/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=66&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288949 Stats: 55 lines in 9 files changed: 48 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk19/pull/66.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/66/head:pull/66 PR: https://git.openjdk.org/jdk19/pull/66 From hseigel at openjdk.org Fri Jun 24 12:06:44 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Fri, 24 Jun 2022 12:06:44 GMT Subject: RFR: 8288976: classfile parser 'wrong name' error message has the names the wrong way around In-Reply-To: References: Message-ID: <6ZoHhR0e55Od2chwRYMVxknsE-f1c4AaLgXQ_V7bwrk=.7ab60dc2-17a2-4f6e-872a-a27f4be9b132@github.com> On Thu, 23 Jun 2022 21:23:00 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8288976. The fix was tested by running the new test and mach5 tiers 1-2 on Linux, Mac OS, and Windows. > > Thanks, Harold Thanks David and Aleksey for the reviews. ------------- PR: https://git.openjdk.org/jdk/pull/9264 From hseigel at openjdk.org Fri Jun 24 12:06:45 2022 From: hseigel at openjdk.org (Harold Seigel) Date: Fri, 24 Jun 2022 12:06:45 GMT Subject: Integrated: 8288976: classfile parser 'wrong name' error message has the names the wrong way around In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 21:23:00 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8288976. The fix was tested by running the new test and mach5 tiers 1-2 on Linux, Mac OS, and Windows. > > Thanks, Harold This pull request has now been integrated. Changeset: 925084c4 Author: Harold Seigel URL: https://git.openjdk.org/jdk/commit/925084c496113c9d8e860ded0b8645fd584380bc Stats: 55 lines in 3 files changed: 49 ins; 1 del; 5 mod 8288976: classfile parser 'wrong name' error message has the names the wrong way around Reviewed-by: dholmes, shade ------------- PR: https://git.openjdk.org/jdk/pull/9264 From coleenp at openjdk.org Fri Jun 24 12:28:02 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 24 Jun 2022 12:28:02 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 12:34:59 GMT, Zhengyu Gu wrote: >> Currently, jdi only check and process class unloading event when it detects a new GC cycle. >> >> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. >> >> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. >> >> It also performs `commonRef_compact()` only when there are classes unloaded. >> >> New test failed about 20% without patch, none with patch. >> >> **Update** >> There are significant changes from early patch. >> >> The new approach: >> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: >> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state >> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state >> >> The new solution breaks up into two steps: >> - Collect all dead object tags with lock >> - Transition to `_in_native` state and post object free events in one batch >> >> This way, JDI event handler can process object free events upon arrivals without delay. > > Zhengyu Gu 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 18 additional commits since the last revision: > > - Improve naming and cleanup > - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event > - v4 > - v3 > - v2 > - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event > - Merge branch 'jdi_tmp' into JDK-8256811-jdi-missing-class-unloading-event > - v0 > - v2 > - v1 > - ... and 8 more: https://git.openjdk.org/jdk/compare/c4855a3d...559b4bf1 src/hotspot/share/prims/jvmtiTagMap.cpp line 1200: > 1198: }; > 1199: > 1200: // PostObjectFree can't be called by JavaThread, so call it from the VM thread. I wish I'd written why here. I think it's because we can't hold a Mutex to do the callback, but now I don't remember. I need to spend some time to understand this. Thanks @plummercj for adding Kim and I. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From rriggs at openjdk.org Fri Jun 24 13:50:59 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 24 Jun 2022 13:50:59 GMT Subject: Integrated: 8288495: [test] Make OutputAnalyzer exception more informative In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 18:19:56 GMT, Roger Riggs wrote: > The RuntimeException from OutputAnalyzer for expected and unexpected exit values should include both the actual and expected values. > The method `shouldHaveExitvalue` and `shouldNotHaveExitValue` include the value expected and the value not expected instead of the actual value returned. The values provided in the exception are already known quantities in the code, what is not known is the actual value. > The actual value is printed to stderr but not the expected value and in the logs, the exception report is frequently to stdout and therefor separated in the log from the output of stderr. Including both expected and actual values in the exception makes it easier to understand. > > Exception messages should not include newlines. This pull request has now been integrated. Changeset: fdc8455c Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/fdc8455c4559a5513c46cb61bdf09f8279d44192 Stats: 47 lines in 2 files changed: 27 ins; 1 del; 19 mod 8288495: [test] Make OutputAnalyzer exception more informative Reviewed-by: lmesnik, naoto, jpai, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/9247 From dcubed at openjdk.org Fri Jun 24 14:12:28 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 24 Jun 2022 14:12:28 GMT Subject: RFR: 8289129: [BACKOUT] JDK-8287281 adjust guarantee in Handshake::execute for the case of target thread being current Message-ID: This reverts commit 9dc9a64fa453d8afc90871e9663a0ccc46212f64. ------------- Commit messages: - 8289129: [BACKOUT] JDK-8287281 adjust guarantee in Handshake::execute for the case of target thread being current Changes: https://git.openjdk.org/jdk/pull/9277/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9277&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289129 Stats: 30 lines in 3 files changed: 14 ins; 8 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9277.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9277/head:pull/9277 PR: https://git.openjdk.org/jdk/pull/9277 From alanb at openjdk.org Fri Jun 24 14:12:28 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 24 Jun 2022 14:12:28 GMT Subject: RFR: 8289129: [BACKOUT] JDK-8287281 adjust guarantee in Handshake::execute for the case of target thread being current In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 14:00:45 GMT, Daniel D. Daugherty wrote: > This reverts commit 9dc9a64fa453d8afc90871e9663a0ccc46212f64. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9277 From dcubed at openjdk.org Fri Jun 24 14:15:58 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 24 Jun 2022 14:15:58 GMT Subject: RFR: 8289129: [BACKOUT] JDK-8287281 adjust guarantee in Handshake::execute for the case of target thread being current In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 14:04:25 GMT, Alan Bateman wrote: >> This reverts commit 9dc9a64fa453d8afc90871e9663a0ccc46212f64. > > Marked as reviewed by alanb (Reviewer). @AlanBateman - Thanks for the fast review! I'm waiting for a couple more builds to pass and then I'll integrate... ------------- PR: https://git.openjdk.org/jdk/pull/9277 From dcubed at openjdk.org Fri Jun 24 14:20:43 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 24 Jun 2022 14:20:43 GMT Subject: Integrated: 8289129: [BACKOUT] JDK-8287281 adjust guarantee in Handshake::execute for the case of target thread being current In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 14:00:45 GMT, Daniel D. Daugherty wrote: > This reverts commit 9dc9a64fa453d8afc90871e9663a0ccc46212f64. This pull request has now been integrated. Changeset: 0d2952e5 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/0d2952e5b37312f4ec08786a9802594115f0f8a1 Stats: 30 lines in 3 files changed: 14 ins; 8 del; 8 mod 8289129: [BACKOUT] JDK-8287281 adjust guarantee in Handshake::execute for the case of target thread being current Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/9277 From mbaesken at openjdk.org Fri Jun 24 14:57:19 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 24 Jun 2022 14:57:19 GMT Subject: RFR: JDK-8289147: unify os::infinite_sleep on posix platforms Message-ID: os::infinite_sleep could be unified on the POSIX platforms (linux, bsd, aix). ------------- Commit messages: - JDK-8289147 Changes: https://git.openjdk.org/jdk/pull/9279/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9279&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289147 Stats: 27 lines in 4 files changed: 6 ins; 21 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9279.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9279/head:pull/9279 PR: https://git.openjdk.org/jdk/pull/9279 From mdoerr at openjdk.org Fri Jun 24 15:25:53 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 24 Jun 2022 15:25:53 GMT Subject: RFR: JDK-8289147: unify os::infinite_sleep on posix platforms In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 14:50:25 GMT, Matthias Baesken wrote: > os::infinite_sleep could be unified on the POSIX platforms (linux, bsd, aix). LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.org/jdk/pull/9279 From dcubed at openjdk.org Fri Jun 24 19:17:50 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 24 Jun 2022 19:17:50 GMT Subject: Integrated: 8289166: ProblemList tools/jlink/plugins/CompressorPluginTest.java Message-ID: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com> A trivial fix to ProblemList tools/jlink/plugins/CompressorPluginTest.java. ------------- Commit messages: - 8289166: ProblemList tools/jlink/plugins/CompressorPluginTest.java Changes: https://git.openjdk.org/jdk/pull/9285/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9285&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289166 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9285.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9285/head:pull/9285 PR: https://git.openjdk.org/jdk/pull/9285 From lmesnik at openjdk.org Fri Jun 24 19:17:50 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 24 Jun 2022 19:17:50 GMT Subject: Integrated: 8289166: ProblemList tools/jlink/plugins/CompressorPluginTest.java In-Reply-To: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com> References: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com> Message-ID: On Fri, 24 Jun 2022 18:51:40 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList tools/jlink/plugins/CompressorPluginTest.java. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9285 From bpb at openjdk.org Fri Jun 24 19:17:51 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 24 Jun 2022 19:17:51 GMT Subject: Integrated: 8289166: ProblemList tools/jlink/plugins/CompressorPluginTest.java In-Reply-To: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com> References: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com> Message-ID: On Fri, 24 Jun 2022 18:51:40 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList tools/jlink/plugins/CompressorPluginTest.java. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9285 From dcubed at openjdk.org Fri Jun 24 19:17:52 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 24 Jun 2022 19:17:52 GMT Subject: Integrated: 8289166: ProblemList tools/jlink/plugins/CompressorPluginTest.java In-Reply-To: References: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com> Message-ID: On Fri, 24 Jun 2022 18:54:42 GMT, Leonid Mesnik wrote: >> A trivial fix to ProblemList tools/jlink/plugins/CompressorPluginTest.java. > > Marked as reviewed by lmesnik (Reviewer). @lmesnik and @bplb - Thanks for the lightning fast reviews! ------------- PR: https://git.openjdk.org/jdk/pull/9285 From dcubed at openjdk.org Fri Jun 24 19:17:53 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 24 Jun 2022 19:17:53 GMT Subject: Integrated: 8289166: ProblemList tools/jlink/plugins/CompressorPluginTest.java In-Reply-To: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com> References: <--tK2OE7dKZXOXgByTB31fzvKvQ8JlcMOxX3Rjsa_NU=.1ef49f50-2255-4247-965f-d7a22134d9a3@github.com> Message-ID: On Fri, 24 Jun 2022 18:51:40 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList tools/jlink/plugins/CompressorPluginTest.java. This pull request has now been integrated. Changeset: 08288819 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/08288819dd915549d17af40b159233a0550db643 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8289166: ProblemList tools/jlink/plugins/CompressorPluginTest.java Reviewed-by: lmesnik, bpb ------------- PR: https://git.openjdk.org/jdk/pull/9285 From kbarrett at openjdk.org Fri Jun 24 19:53:59 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 24 Jun 2022 19:53:59 GMT Subject: RFR: JDK-8289147: unify os::infinite_sleep on posix platforms In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 14:50:25 GMT, Matthias Baesken wrote: > os::infinite_sleep could be unified on the POSIX platforms (linux, bsd, aix). Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9279 From dcubed at openjdk.org Fri Jun 24 20:01:19 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 24 Jun 2022 20:01:19 GMT Subject: RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() Message-ID: A trivial move of the oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj(). Also made adjustments to the threadObj() calls in JavaThread::print_on_error() and JavaThread::get_thread_name_string() so that we don't get secondary crashes when a JavaThread crashes after it has detached the GC barrier. Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. ------------- Commit messages: - 8289091.cr0 Changes: https://git.openjdk.org/jdk19/pull/69/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=69&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289091 Stats: 28 lines in 2 files changed: 11 ins; 5 del; 12 mod Patch: https://git.openjdk.org/jdk19/pull/69.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/69/head:pull/69 PR: https://git.openjdk.org/jdk19/pull/69 From dcubed at openjdk.org Fri Jun 24 20:01:19 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 24 Jun 2022 20:01:19 GMT Subject: RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 19:53:31 GMT, Daniel D. Daugherty wrote: > A trivial move of the oop safety check from SharedRuntime::get_java_tid() to > JavaThread::threadObj(). Also made adjustments to the threadObj() calls in > JavaThread::print_on_error() and JavaThread::get_thread_name_string() so > that we don't get secondary crashes when a JavaThread crashes after it has > detached the GC barrier. > > Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. @dholmes-ora, @fisk, @pchilano, and @robehn - This is a followup from [JDK-8288139](https://bugs.openjdk.org/browse/JDK-8288139) JavaThread touches oop after GC barrier is detached ------------- PR: https://git.openjdk.org/jdk19/pull/69 From rpressler at openjdk.org Fri Jun 24 20:42:56 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Fri, 24 Jun 2022 20:42:56 GMT Subject: RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing In-Reply-To: References: Message-ID: <7PH9bVJW-6hL7tAz5TYvk6qu9RfUPGaLLgkbwnkS3U8=.40f89a35-f43f-4826-981c-7a6a36e7b42e@github.com> On Fri, 24 Jun 2022 09:23:26 GMT, Ron Pressler wrote: > Please review the following bug fix: > > `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`. > > Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode. > > This change does three things: > > 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter. > 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`. > 3. In interp_only_mode, the c2i stub will not patch the callsite. > > This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128 > > > Passes tiers 1-4 and Loom tiers 1-5. src/hotspot/share/code/compiledIC.cpp line 591: > 589: // Do not reset stub here: It is too expensive to call find_stub. > 590: // Instead, rely on caller (nmethod::clear_inline_caches) to clear > 591: // both the call and its stub. While at it, I noticed this comment, which appears to be out of date. ------------- PR: https://git.openjdk.org/jdk19/pull/66 From cjplummer at openjdk.org Fri Jun 24 21:52:58 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 24 Jun 2022 21:52:58 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: <9DXhiJashhHzVprdaDkeueDpLbjylMSOyu3ROEcoexs=.0a646a14-4168-43f0-bbe5-6d48e829dad5@github.com> On Thu, 23 Jun 2022 12:34:59 GMT, Zhengyu Gu wrote: >> Currently, jdi only check and process class unloading event when it detects a new GC cycle. >> >> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. >> >> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. >> >> It also performs `commonRef_compact()` only when there are classes unloaded. >> >> New test failed about 20% without patch, none with patch. >> >> **Update** >> There are significant changes from early patch. >> >> The new approach: >> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: >> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state >> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state >> >> The new solution breaks up into two steps: >> - Collect all dead object tags with lock >> - Transition to `_in_native` state and post object free events in one batch >> >> This way, JDI event handler can process object free events upon arrivals without delay. > > Zhengyu Gu 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 18 additional commits since the last revision: > > - Improve naming and cleanup > - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event > - v4 > - v3 > - v2 > - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event > - Merge branch 'jdi_tmp' into JDK-8256811-jdi-missing-class-unloading-event > - v0 > - v2 > - v1 > - ... and 8 more: https://git.openjdk.org/jdk/compare/661235f2...559b4bf1 You should also remove the following from the hotspot ProblemList.txt: `vmTestbase/nsk/jdi/HiddenClass/events/events001.java 8257705 generic-all` Tye to reproduce without your fix, and then verify your fix is addressing the failure. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From dlong at openjdk.org Sat Jun 25 00:45:41 2022 From: dlong at openjdk.org (Dean Long) Date: Sat, 25 Jun 2022 00:45:41 GMT Subject: RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing In-Reply-To: <7PH9bVJW-6hL7tAz5TYvk6qu9RfUPGaLLgkbwnkS3U8=.40f89a35-f43f-4826-981c-7a6a36e7b42e@github.com> References: <7PH9bVJW-6hL7tAz5TYvk6qu9RfUPGaLLgkbwnkS3U8=.40f89a35-f43f-4826-981c-7a6a36e7b42e@github.com> Message-ID: On Fri, 24 Jun 2022 20:39:08 GMT, Ron Pressler wrote: >> Please review the following bug fix: >> >> `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`. >> >> Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode. >> >> This change does three things: >> >> 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter. >> 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`. >> 3. In interp_only_mode, the c2i stub will not patch the callsite. >> >> This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128 >> >> >> Passes tiers 1-4 and Loom tiers 1-5. > > src/hotspot/share/code/compiledIC.cpp line 591: > >> 589: // Do not reset stub here: It is too expensive to call find_stub. >> 590: // Instead, rely on caller (nmethod::clear_inline_caches) to clear >> 591: // both the call and its stub. > > While at it, I noticed this comment, which appears to be out of date. I read that comment more as a warning, in case in the future someone wondered why we don't reset the stub here, and tried to add it. So I would leave it. I think it's still useful. ------------- PR: https://git.openjdk.org/jdk19/pull/66 From dlong at openjdk.org Sat Jun 25 01:17:57 2022 From: dlong at openjdk.org (Dean Long) Date: Sat, 25 Jun 2022 01:17:57 GMT Subject: RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 09:23:26 GMT, Ron Pressler wrote: > Please review the following bug fix: > > `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`. > > Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode. > > This change does three things: > > 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter. > 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`. > 3. In interp_only_mode, the c2i stub will not patch the callsite. > > This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128 > > > Passes tiers 1-4 and Loom tiers 1-5. src/hotspot/share/code/compiledMethod.cpp line 464: > 462: while(iter.next()) { > 463: if (iter.type() == relocInfo::static_call_type) { > 464: iter.reloc()->clear_inline_cache(); This relies on code patching, and for correctness the change must be seen by the thread requesting interpreter-only mode. If this was being done at a safepoint then it would probably be OK. However, this code seems to be done using a handshake, so I'm not sure if the required serializing instruction is guaranteed to happen (see JDK-8220351). src/hotspot/share/runtime/mutexLocker.cpp line 287: > 285: def(JfieldIdCreation_lock , PaddedMutex , safepoint); > 286: > 287: def(CompiledIC_lock , PaddedMutex , nosafepoint-1); // locks VtableStubs_lock, InlineCacheBuffer_lock Please explain. Is there another lock causing problems? ------------- PR: https://git.openjdk.org/jdk19/pull/66 From rpressler at openjdk.org Sat Jun 25 01:23:47 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Sat, 25 Jun 2022 01:23:47 GMT Subject: RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing [v2] In-Reply-To: References: Message-ID: > Please review the following bug fix: > > `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`. > > Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode. > > This change does three things: > > 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter. > 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`. > 3. In interp_only_mode, the c2i stub will not patch the callsite. > > This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128 > > > Passes tiers 1-4 and Loom tiers 1-5. Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: Revert "Remove outdated comment" This reverts commit 8f571d76e34bc64ceb31894184fba4b909e8fbfe. ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/66/files - new: https://git.openjdk.org/jdk19/pull/66/files/fe8fe94f..4680aed2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=66&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=66&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/66.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/66/head:pull/66 PR: https://git.openjdk.org/jdk19/pull/66 From dlong at openjdk.org Sat Jun 25 01:23:49 2022 From: dlong at openjdk.org (Dean Long) Date: Sat, 25 Jun 2022 01:23:49 GMT Subject: RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 09:23:26 GMT, Ron Pressler wrote: > Please review the following bug fix: > > `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`. > > Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode. > > This change does three things: > > 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter. > 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`. > 3. In interp_only_mode, the c2i stub will not patch the callsite. > > This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128 > > > Passes tiers 1-4 and Loom tiers 1-5. The get_c2i_entry change seems safe enough, but the lock rank change and the code patching changes seem a little risky for jdk19. I'm going to suggest some folks more familiar with handshakes, compiled ICs, and lock ranking to also look at this. ------------- PR: https://git.openjdk.org/jdk19/pull/66 From rpressler at openjdk.org Sat Jun 25 01:23:52 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Sat, 25 Jun 2022 01:23:52 GMT Subject: RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing [v2] In-Reply-To: References: <7PH9bVJW-6hL7tAz5TYvk6qu9RfUPGaLLgkbwnkS3U8=.40f89a35-f43f-4826-981c-7a6a36e7b42e@github.com> Message-ID: On Sat, 25 Jun 2022 00:42:14 GMT, Dean Long wrote: >> src/hotspot/share/code/compiledIC.cpp line 591: >> >>> 589: return true; >>> 590: } >>> 591: >> >> While at it, I noticed this comment, which appears to be out of date. > > I read that comment more as a warning, in case in the future someone wondered why we don't reset the stub here, and tried to add it. So I would leave it. I think it's still useful. ok, reverted. ------------- PR: https://git.openjdk.org/jdk19/pull/66 From rpressler at openjdk.org Sat Jun 25 01:23:53 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Sat, 25 Jun 2022 01:23:53 GMT Subject: RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing [v2] In-Reply-To: References: Message-ID: On Sat, 25 Jun 2022 01:14:25 GMT, Dean Long wrote: >> Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert "Remove outdated comment" >> >> This reverts commit 8f571d76e34bc64ceb31894184fba4b909e8fbfe. > > src/hotspot/share/runtime/mutexLocker.cpp line 287: > >> 285: def(JfieldIdCreation_lock , PaddedMutex , safepoint); >> 286: >> 287: def(CompiledIC_lock , PaddedMutex , nosafepoint-1); // locks VtableStubs_lock, InlineCacheBuffer_lock > > Please explain. Is there another lock causing problems? The handshake lock, which is also nosafepoint. ------------- PR: https://git.openjdk.org/jdk19/pull/66 From sspitsyn at openjdk.org Sat Jun 25 01:41:02 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 25 Jun 2022 01:41:02 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 04:20:45 GMT, Chris Plummer wrote: >> Zhengyu Gu 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 18 additional commits since the last revision: >> >> - Improve naming and cleanup >> - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event >> - v4 >> - v3 >> - v2 >> - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event >> - Merge branch 'jdi_tmp' into JDK-8256811-jdi-missing-class-unloading-event >> - v0 >> - v2 >> - v1 >> - ... and 8 more: https://git.openjdk.org/jdk/compare/fae7ca88...559b4bf1 > > src/hotspot/share/prims/jvmtiExport.cpp line 1702: > >> 1700: } else { >> 1701: post_object_free_on_java_thread(env, objects); >> 1702: } > > Can you explain why sometimes it is a VMThread and why sometimes it is a JavaThread? I hope, it is okay if I explain it. :) The `post_object_free` can be called in different contexts. It is (recursively) called from `JvmtiTagMap::check_hashmaps_for_heapwalk()` which is used in VM_ops: - VM_HeapIterateOperation - VM_HeapWalkOperation Also, the `post_object_free` is called from `JvmtiTagMap` functions: - flush_object_free_events - get_objects_with_tags which can be called from the `ServiceThread` or the JVMTI functions like `SetEvenNotificationMode`, `SetEventCallBacks` or `GetObjectsWithTags`. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From sspitsyn at openjdk.org Sat Jun 25 04:46:59 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 25 Jun 2022 04:46:59 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 12:34:59 GMT, Zhengyu Gu wrote: >> Currently, jdi only check and process class unloading event when it detects a new GC cycle. >> >> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. >> >> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. >> >> It also performs `commonRef_compact()` only when there are classes unloaded. >> >> New test failed about 20% without patch, none with patch. >> >> **Update** >> There are significant changes from early patch. >> >> The new approach: >> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: >> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state >> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state >> >> The new solution breaks up into two steps: >> - Collect all dead object tags with lock >> - Transition to `_in_native` state and post object free events in one batch >> >> This way, JDI event handler can process object free events upon arrivals without delay. > > Zhengyu Gu 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 18 additional commits since the last revision: > > - Improve naming and cleanup > - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event > - v4 > - v3 > - v2 > - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event > - Merge branch 'jdi_tmp' into JDK-8256811-jdi-missing-class-unloading-event > - v0 > - v2 > - v1 > - ... and 8 more: https://git.openjdk.org/jdk/compare/ac69c250...559b4bf1 src/hotspot/share/prims/jvmtiExport.cpp line 1722: > 1720: if (javaThread->is_in_VTMS_transition()) { > 1721: return; // no events should be posted if thread is in a VTMS transition > 1722: } Chris suggested to convert this if-statement to assert. The concern is we want to be sure the debug agent does not skip any CLASS_UNLOAD events. Though, I feel that a probability to get the assert triggered is very low. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From cjplummer at openjdk.org Sat Jun 25 05:45:44 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 25 Jun 2022 05:45:44 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Sat, 25 Jun 2022 04:43:12 GMT, Serguei Spitsyn wrote: > Chris suggested to convert this if-statement to assert. > The concern is we want to be sure the debug agent does not skip any CLASS_UNLOAD events. > Though, I feel that a probability to get the assert triggered is very low. Yes, I think it should be an assert, but was not suggesting that change as part of this PR since it is pre-existing. We can file a separate CR for it. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From stuefe at openjdk.org Sat Jun 25 06:49:11 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 25 Jun 2022 06:49:11 GMT Subject: RFR: JDK-8289182: NMT: MemTracker::baseline should return void Message-ID: Small cleanup. Since MemTracker::baseline() only returns true, it can revert to void, and error handling can be removed from all callers. ------------- Commit messages: - let MemTracker::baseline return void Changes: https://git.openjdk.org/jdk/pull/9288/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9288&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289182 Stats: 47 lines in 8 files changed: 0 ins; 11 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/9288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9288/head:pull/9288 PR: https://git.openjdk.org/jdk/pull/9288 From stuefe at openjdk.org Sun Jun 26 06:53:24 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 26 Jun 2022 06:53:24 GMT Subject: RFR: JDK-8289182: NMT: MemTracker::baseline should return void [v2] In-Reply-To: References: Message-ID: > Small cleanup. > > Since MemTracker::baseline() only returns true, it can revert to void, and error handling can be removed from all callers. Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: let MemTracker::baseline return void ------------- Changes: https://git.openjdk.org/jdk/pull/9288/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9288&range=01 Stats: 47 lines in 8 files changed: 0 ins; 11 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/9288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9288/head:pull/9288 PR: https://git.openjdk.org/jdk/pull/9288 From zgu at openjdk.org Sun Jun 26 11:54:47 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Sun, 26 Jun 2022 11:54:47 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Sat, 25 Jun 2022 01:35:38 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiExport.cpp line 1702: >> >>> 1700: } else { >>> 1701: post_object_free_on_java_thread(env, objects); >>> 1702: } >> >> Can you explain why sometimes it is a VMThread and why sometimes it is a JavaThread? > > I hope, it is okay if I explain it. :) > The `post_object_free` can be called in different contexts. > It is (recursively) called from `JvmtiTagMap::check_hashmaps_for_heapwalk()` which is used in VM_ops: > - VM_HeapIterateOperation > - VM_HeapWalkOperation > > Also, the `post_object_free` is called from `JvmtiTagMap` functions: > - flush_object_free_events > - get_objects_with_tags > which can be called from the `ServiceThread` or the JVMTI functions like `SetEvenNotificationMode`, `SetEventCallBacks` or `GetObjectsWithTags`. @sspitsyn Thanks. Yes, `JvmtiTagMap::check_hashmaps_for_heapwalk()` is where I saw the call from `VMThread`. This patch is intended to **not** post `ObjectFree` events on `VMThread`, so I am going to move this PR back to draft state and take another look. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From rehn at openjdk.org Sun Jun 26 21:09:54 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Sun, 26 Jun 2022 21:09:54 GMT Subject: RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 19:53:31 GMT, Daniel D. Daugherty wrote: > A trivial move of the oop safety check from SharedRuntime::get_java_tid() to > JavaThread::threadObj(). Also made adjustments to the threadObj() calls in > JavaThread::print_on_error() and JavaThread::get_thread_name_string() so > that we don't get secondary crashes when a JavaThread crashes after it has > detached the GC barrier. > > Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. Looks fine to me, thanks! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk19/pull/69 From dholmes at openjdk.org Mon Jun 27 00:54:44 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Jun 2022 00:54:44 GMT Subject: RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 19:53:31 GMT, Daniel D. Daugherty wrote: > A trivial move of the oop safety check from SharedRuntime::get_java_tid() to > JavaThread::threadObj(). Also made adjustments to the threadObj() calls in > JavaThread::print_on_error() and JavaThread::get_thread_name_string() so > that we don't get secondary crashes when a JavaThread crashes after it has > detached the GC barrier. > > Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. Main change is fine but the "other adjustments" are not correct/appropriate. The state of the target thread is not the issue. Thanks. src/hotspot/share/runtime/thread.cpp line 2150: > 2148: void JavaThread::print_on_error(outputStream* st, char *buf, int buflen) const { > 2149: st->print("%s \"%s\"", type_name(), get_thread_name_string(buf, buflen)); > 2150: if (is_oop_safe()) { This is wrong - `is_oop_safe` only has relevance when called on the current JavaThread. It is the current thread that must be oop_safe, not the target thread we are printing. src/hotspot/share/runtime/thread.cpp line 2213: > 2211: const char* JavaThread::get_thread_name_string(char* buf, int buflen) const { > 2212: const char* name_str; > 2213: if (is_oop_safe()) { Same comment - it is the current thread that must be oop_safe. If the target thread has exited then we will detect that via the null threadObj. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk19/pull/69 From dholmes at openjdk.org Mon Jun 27 00:59:52 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Jun 2022 00:59:52 GMT Subject: RFR: JDK-8289147: unify os::infinite_sleep on posix platforms In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 14:50:25 GMT, Matthias Baesken wrote: > os::infinite_sleep could be unified on the POSIX platforms (linux, bsd, aix). Looks good! ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9279 From dholmes at openjdk.org Mon Jun 27 01:05:39 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Jun 2022 01:05:39 GMT Subject: RFR: JDK-8289182: NMT: MemTracker::baseline should return void [v2] In-Reply-To: References: Message-ID: <_dSSUiX9MqAKcj3A4hvnriRy1NRFrT-SsLoa74OtzPI=.bb021a4c-a6ce-4993-95e6-3dd4dc9007ad@github.com> On Sun, 26 Jun 2022 06:53:24 GMT, Thomas Stuefe wrote: >> Small cleanup. >> >> Since MemTracker::baseline() only returns true, it can revert to void, and error handling can be removed from all callers. > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > let MemTracker::baseline return void Seems fine. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9288 From mbaesken at openjdk.org Mon Jun 27 06:47:33 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 27 Jun 2022 06:47:33 GMT Subject: RFR: JDK-8289147: unify os::infinite_sleep on posix platforms In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 14:50:25 GMT, Matthias Baesken wrote: > os::infinite_sleep could be unified on the POSIX platforms (linux, bsd, aix). HI David, Kim and Martin, thanks for the reviews ! ------------- PR: https://git.openjdk.org/jdk/pull/9279 From mbaesken at openjdk.org Mon Jun 27 06:53:57 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 27 Jun 2022 06:53:57 GMT Subject: Integrated: JDK-8289147: unify os::infinite_sleep on posix platforms In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 14:50:25 GMT, Matthias Baesken wrote: > os::infinite_sleep could be unified on the POSIX platforms (linux, bsd, aix). This pull request has now been integrated. Changeset: 62e1e795 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/62e1e7950b37deaede3573a4b37542199552aea3 Stats: 27 lines in 4 files changed: 6 ins; 21 del; 0 mod 8289147: unify os::infinite_sleep on posix platforms Reviewed-by: mdoerr, kbarrett, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/9279 From yyang at openjdk.org Mon Jun 27 08:06:56 2022 From: yyang at openjdk.org (Yi Yang) Date: Mon, 27 Jun 2022 08:06:56 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v4] In-Reply-To: References: Message-ID: On Tue, 21 Jun 2022 13:44:23 GMT, Thomas Stuefe wrote: >>> > > I would have thought that since we don't have the pool anymore, we can just remove this test line. The lines above already >>> > > test against MaxMetaspaceSize. >>> > >>> > >>> > Okay. >>> > > I think you may be right, we need a replacement for the old memory bean for these tests. Whitebox seems easiest. >>> > >>> > >>> > So should we keep test changes as it is or discard existing test changes and then rewrite related tests via new compressed class space query whitebox API? I prefer to keep tests as it is rather than adding whitebox API since I've made a lot of test changes. But I also want to hear your expert suggestions as final conclusion. >>> >>> I think the easier way would be actually to add a whitebox API for class space use, as @iklam suggested, and just replace the memory pool usage calls with that one. That would be a purely mechanical change if a bit onerous. But since the metaspace itself did not change, the numbers are the same, so the tests test the same. Still easier than trying to think through the changed semantics for each test. >>> >>> Sorry that this seems to have exploded in complexity :-( >> >> Never mind:) I did a closer look at these test changes, it seems that many changes are still necessary even if we provide a WhiteBox.getCompressedClassSpaceMemoryUsage(). In particular, tests other than test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/gc/lotsOfCallSites/Test.java need to be tweaked. Can you please confirm it? Thanks. > >> > > > I would have thought that since we don't have the pool anymore, we can just remove this test line. The lines above already >> > > > test against MaxMetaspaceSize. >> > > >> > > >> > > Okay. >> > > > I think you may be right, we need a replacement for the old memory bean for these tests. Whitebox seems easiest. >> > > >> > > >> > > So should we keep test changes as it is or discard existing test changes and then rewrite related tests via new compressed class space query whitebox API? I prefer to keep tests as it is rather than adding whitebox API since I've made a lot of test changes. But I also want to hear your expert suggestions as final conclusion. >> > >> > >> > I think the easier way would be actually to add a whitebox API for class space use, as @iklam suggested, and just replace the memory pool usage calls with that one. That would be a purely mechanical change if a bit onerous. But since the metaspace itself did not change, the numbers are the same, so the tests test the same. Still easier than trying to think through the changed semantics for each test. >> > Sorry that this seems to have exploded in complexity :-( >> >> Never mind:) I did a closer look at these test changes, it seems that many changes are still necessary even if we provide a WhiteBox.getCompressedClassSpaceMemoryUsage(). In particular, tests other than test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/gc/lotsOfCallSites/Test.java need to be tweaked. Can you please confirm it? > > Why, what changes do you have in mind? Hi @tstuefe @iklam, I've added WhiteBox.getCompressedClassSpace, but it seems that new commit is not much better/more straightforward than current version. Things are getting more complicated after adding whitebox API. We fake a compressed class pool via WhiteBox.getCompressedClassMemoryPool, but ManagementFactory.getMemoryPoolMXBeans() can not aware of this newly created pool, because its internal structures are created at VM startup. The consequence is , any test involving iterating all pools, should be tweaked as before. We did much more than before, but we benefit less from it. Please take a look at [new version](https://urldefense.com/v3/__https://github.com/openjdk/jdk/compare/master...kelthuzadx:jmm_calc_v2?expand=1__;!!ACWV5N9M2RV99hQ!Okv9Yfi3uzQSw7XCZnhp7KqqOVq6D8f4YuaR_oukrkpOluISdZqFljpN7IellR2383sDcG7h9f0VZuY0uoinrJlX3Xk$ ), I don't push it directly so that we have a chance to use current version. ------------- PR: https://git.openjdk.org/jdk/pull/8831 From yyang at openjdk.org Mon Jun 27 08:15:01 2022 From: yyang at openjdk.org (Yi Yang) Date: Mon, 27 Jun 2022 08:15:01 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v5] In-Reply-To: References: Message-ID: > It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. > > Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` > > ==> CodeHeap 'non-nmethods' 1532544 (Used) > ==> CodeHeap 'profiled nmethods' 0 > ==> CodeHeap 'non-profiled nmethods' 13952 > ==> Metaspace 506696 > ==> Compressed Class Space 43312 > init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) > > In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`. Yi Yang has updated the pull request incrementally with one additional commit since the last revision: address @tstuefe's comments; remove unnecessary declaration ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8831/files - new: https://git.openjdk.org/jdk/pull/8831/files/c3f02b8f..7a7626a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8831&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8831&range=03-04 Stats: 18 lines in 3 files changed: 0 ins; 18 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/8831.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8831/head:pull/8831 PR: https://git.openjdk.org/jdk/pull/8831 From eosterlund at openjdk.org Mon Jun 27 08:29:31 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 27 Jun 2022 08:29:31 GMT Subject: [jdk19] RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing [v2] In-Reply-To: References: Message-ID: On Sat, 25 Jun 2022 01:12:57 GMT, Dean Long wrote: >> Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert "Remove outdated comment" >> >> This reverts commit 8f571d76e34bc64ceb31894184fba4b909e8fbfe. > > src/hotspot/share/code/compiledMethod.cpp line 464: > >> 462: while(iter.next()) { >> 463: if (iter.type() == relocInfo::static_call_type) { >> 464: iter.reloc()->clear_inline_cache(); > > This relies on code patching, and for correctness the change must be seen by the thread requesting interpreter-only mode. If this was being done at a safepoint then it would probably be OK. However, this code seems to be done using a handshake, so I'm not sure if the required serializing instruction is guaranteed to happen (see JDK-8220351). Maybe this race is OK, as it seems no worse than the scenario described in the description where another thread resets the call site back to the optimized state. The change is not guaranteed to be seen on a concurrent thread, until the next global handshake operation completes. ------------- PR: https://git.openjdk.org/jdk19/pull/66 From rpressler at openjdk.org Mon Jun 27 08:29:32 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Mon, 27 Jun 2022 08:29:32 GMT Subject: [jdk19] RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing [v2] In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 08:17:01 GMT, Erik ?sterlund wrote: >> src/hotspot/share/code/compiledMethod.cpp line 464: >> >>> 462: while(iter.next()) { >>> 463: if (iter.type() == relocInfo::static_call_type) { >>> 464: iter.reloc()->clear_inline_cache(); >> >> This relies on code patching, and for correctness the change must be seen by the thread requesting interpreter-only mode. If this was being done at a safepoint then it would probably be OK. However, this code seems to be done using a handshake, so I'm not sure if the required serializing instruction is guaranteed to happen (see JDK-8220351). Maybe this race is OK, as it seems no worse than the scenario described in the description where another thread resets the call site back to the optimized state. > > The change is not guaranteed to be seen on a concurrent thread, until the next global handshake operation completes. If that concurrent thread is in interp_only_mode, it also would have done the same patching. And if it isn't, then it's okay for it not to see this, but if it does see it, it will re-patch to compiled in c2i, as in the description. ------------- PR: https://git.openjdk.org/jdk19/pull/66 From ehelin at openjdk.org Mon Jun 27 11:47:45 2022 From: ehelin at openjdk.org (Erik Helin) Date: Mon, 27 Jun 2022 11:47:45 GMT Subject: RFR: 8288396: Always create reproducible builds [v5] In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 15:18:04 GMT, Magnus Ihse Bursie wrote: >> When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.) >> >> With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove incorrect argument > - Test if linker can accept the flag The HotSpot changes looks good to me. The only problem I can think of is if some program is parsing the version string and relies on `__DATE__` having the form `Mmm dd yyyy` (as mandated by the C++ spec) and now it will have ISO 8601 format, but I don't think that issue should prevent this change. Those programs will just have to be updated ? ------------- Marked as reviewed by ehelin (Reviewer). PR: https://git.openjdk.org/jdk/pull/9152 From coleenp at openjdk.org Mon Jun 27 14:58:47 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 27 Jun 2022 14:58:47 GMT Subject: [jdk19] RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing [v2] In-Reply-To: References: Message-ID: On Sat, 25 Jun 2022 01:19:10 GMT, Ron Pressler wrote: >> src/hotspot/share/runtime/mutexLocker.cpp line 287: >> >>> 285: def(JfieldIdCreation_lock , PaddedMutex , safepoint); >>> 286: >>> 287: def(CompiledIC_lock , PaddedMutex , nosafepoint-1); // locks VtableStubs_lock, InlineCacheBuffer_lock >> >> Please explain. Is there another lock causing problems? > > The handshake lock, which is also nosafepoint. This should be ok, provided all the tests have been run. It reduces the rank of other locks, but there's still room in the lock rank range (by 1), and there's an assert for that. // These locks have relative rankings, and inherit safepoint checking attributes from that rank. defl(InlineCacheBuffer_lock , PaddedMutex , CompiledIC_lock); defl(VtableStubs_lock , PaddedMutex , CompiledIC_lock); // Also holds DumpTimeTable_lock defl(CodeCache_lock , PaddedMonitor, VtableStubs_lock); defl(CompiledMethod_lock , PaddedMutex , CodeCache_lock); defl(CodeSweeper_lock , PaddedMonitor, CompiledMethod_lock); ------------- PR: https://git.openjdk.org/jdk19/pull/66 From rehn at openjdk.org Mon Jun 27 15:24:43 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 27 Jun 2022 15:24:43 GMT Subject: [jdk19] RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing [v2] In-Reply-To: References: Message-ID: On Sat, 25 Jun 2022 01:23:47 GMT, Ron Pressler wrote: >> Please review the following bug fix: >> >> `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`. >> >> Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode. >> >> This change does three things: >> >> 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter. >> 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`. >> 3. In interp_only_mode, the c2i stub will not patch the callsite. >> >> This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128 >> >> >> Passes tiers 1-4 and Loom tiers 1-5. > > Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Remove outdated comment" > > This reverts commit 8f571d76e34bc64ceb31894184fba4b909e8fbfe. Handshakes are per thread serialization points, so as Erik says, the thread going to interp mode will pick up the correct code, but other threads may or may not see it. Lock rank change may be okay, to much code to trace just say yes for me. ------------- PR: https://git.openjdk.org/jdk19/pull/66 From dcubed at openjdk.org Mon Jun 27 15:36:44 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 27 Jun 2022 15:36:44 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() In-Reply-To: References: Message-ID: On Sun, 26 Jun 2022 21:06:07 GMT, Robbin Ehn wrote: >> A trivial move of the oop safety check from SharedRuntime::get_java_tid() to >> JavaThread::threadObj(). Also made adjustments to the threadObj() calls in >> JavaThread::print_on_error() and JavaThread::get_thread_name_string() so >> that we don't get secondary crashes when a JavaThread crashes after it has >> detached the GC barrier. >> >> Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. > > Looks fine to me, thanks! @robehn - Thanks for the review. @dholmes-ora - Thanks for the review. I need to rework the "other adjustments" portion of the fix. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From dcubed at openjdk.org Mon Jun 27 15:36:48 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 27 Jun 2022 15:36:48 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() In-Reply-To: References: Message-ID: <2Hn3OPtof47uLZM_w1Z8dchjLhM5ZVoCoLOocex8RiA=.2f7d1f29-58cd-40f4-aa8b-39018271160e@github.com> On Mon, 27 Jun 2022 00:48:43 GMT, David Holmes wrote: >> A trivial move of the oop safety check from SharedRuntime::get_java_tid() to >> JavaThread::threadObj(). Also made adjustments to the threadObj() calls in >> JavaThread::print_on_error() and JavaThread::get_thread_name_string() so >> that we don't get secondary crashes when a JavaThread crashes after it has >> detached the GC barrier. >> >> Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. > > src/hotspot/share/runtime/thread.cpp line 2150: > >> 2148: void JavaThread::print_on_error(outputStream* st, char *buf, int buflen) const { >> 2149: st->print("%s \"%s\"", type_name(), get_thread_name_string(buf, buflen)); >> 2150: if (is_oop_safe()) { > > This is wrong - `is_oop_safe` only has relevance when called on the current JavaThread. It is the current thread that must be oop_safe, not the target thread we are printing. Agreed. I had that nagging feeling when I thought about this fix while working on chores on Sunday... > src/hotspot/share/runtime/thread.cpp line 2213: > >> 2211: const char* JavaThread::get_thread_name_string(char* buf, int buflen) const { >> 2212: const char* name_str; >> 2213: if (is_oop_safe()) { > > Same comment - it is the current thread that must be oop_safe. If the target thread has exited then we will detect that via the null threadObj. Agreed. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From coleenp at openjdk.org Mon Jun 27 15:54:49 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 27 Jun 2022 15:54:49 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 12:24:27 GMT, Coleen Phillimore wrote: >> Zhengyu Gu 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 18 additional commits since the last revision: >> >> - Improve naming and cleanup >> - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event >> - v4 >> - v3 >> - v2 >> - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event >> - Merge branch 'jdi_tmp' into JDK-8256811-jdi-missing-class-unloading-event >> - v0 >> - v2 >> - v1 >> - ... and 8 more: https://git.openjdk.org/jdk/compare/3187f126...559b4bf1 > > src/hotspot/share/prims/jvmtiTagMap.cpp line 1200: > >> 1198: }; >> 1199: >> 1200: // PostObjectFree can't be called by JavaThread, so call it from the VM thread. > > I wish I'd written why here. I think it's because we can't hold a Mutex to do the callback, but now I don't remember. I need to spend some time to understand this. Thanks @plummercj for adding Kim and I. Ok, thanks I reread your description and see it now. At this point, you are neither holding the Mutex and have already collected the objects, so that you can transition to native. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From zgu at openjdk.org Mon Jun 27 17:02:04 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 27 Jun 2022 17:02:04 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v4] In-Reply-To: References: Message-ID: > Currently, jdi only check and process class unloading event when it detects a new GC cycle. > > After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. > > This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. > > It also performs `commonRef_compact()` only when there are classes unloaded. > > New test failed about 20% without patch, none with patch. > > **Update** > There are significant changes from early patch. > > The new approach: > No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: > - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state > - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state > > The new solution breaks up into two steps: > - Collect all dead object tags with lock > - Transition to `_in_native` state and post object free events in one batch > > This way, JDI event handler can process object free events upon arrivals without delay. Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: v5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9168/files - new: https://git.openjdk.org/jdk/pull/9168/files/559b4bf1..2d9a81e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=02-03 Stats: 208 lines in 10 files changed: 56 ins; 87 del; 65 mod Patch: https://git.openjdk.org/jdk/pull/9168.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9168/head:pull/9168 PR: https://git.openjdk.org/jdk/pull/9168 From cjplummer at openjdk.org Mon Jun 27 17:03:22 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 27 Jun 2022 17:03:22 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Sun, 26 Jun 2022 11:52:28 GMT, Zhengyu Gu wrote: > This patch is intended to not post ObjectFree events on VMThread, so I am going to move this PR back to draft state and take another look. I'm not so sure it matters to the debug agent. I thought the main change here was to not force posting of ObjectFree events to be deferred to the VMThread, and to change the debug agent to send the CLASS_UNLOAD events right away rather than accumulating them and waiting for a GCFinishEvent. Is there any issue if the posting of ObjectFree and sending of CLASS_UNLOAD is done on the VMThread? ------------- PR: https://git.openjdk.org/jdk/pull/9168 From ccheung at openjdk.org Mon Jun 27 17:41:07 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 27 Jun 2022 17:41:07 GMT Subject: RFR: 8288651: CDS test HelloUnload.java should not use literal string as ClassLoader name Message-ID: <2s2IrvXmWYjJiV53w5K2PZGZ1w8C2scCqBVFldUYfh4=.22047356-4288-4632-b827-7e55646ee69e@github.com> A simple test fix for changing the class loader name to a non-literal string so that the symbol refcount could be decremented upon unloading of the class loader. Passed tiers 1 and 2 testing. Inspected the .jtr file to check the symbol refcount was decremented. ------------- Commit messages: - 8288651: CDS test HelloUnload.java should not use literal string as ClassLoader name Changes: https://git.openjdk.org/jdk/pull/9297/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9297&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288651 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9297.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9297/head:pull/9297 PR: https://git.openjdk.org/jdk/pull/9297 From zgu at openjdk.org Mon Jun 27 17:52:40 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 27 Jun 2022 17:52:40 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 17:01:02 GMT, Chris Plummer wrote: >> @sspitsyn Thanks. >> >> Yes, `JvmtiTagMap::check_hashmaps_for_heapwalk()` is where I saw the call from `VMThread`. >> >> This patch is intended to **not** post `ObjectFree` events on `VMThread`, so I am going to move this PR back to draft state and take another look. > >> This patch is intended to not post ObjectFree events on VMThread, so I am going to move this PR back to draft state and take another look. > > I'm not so sure it matters to the debug agent. I thought the main change here was to not force posting of ObjectFree events to be deferred to the VMThread, and to change the debug agent to send the CLASS_UNLOAD events right away rather than accumulating them and waiting for a GCFinishEvent. Is there any issue if the posting of ObjectFree and sending of CLASS_UNLOAD is done on the VMThread? Hmm... I thought that is the whole purpose for delaying processing class unload events, because it can not be done on `VMThread`? Otherwise, we don't need all this complexity, just have `cbTrackingObjectFree()` calls `synthesizeUnloadEvent()` directly. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From dcubed at openjdk.org Mon Jun 27 18:31:18 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 27 Jun 2022 18:31:18 GMT Subject: [jdk19] RFR: 8289235: ProblemList vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011/TestDescription.java when run with vthread wrapper Message-ID: A trivial fix to ProblemList vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011/TestDescription.java when run with vthread wrapper. ------------- Commit messages: - 8289235: ProblemList vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011/TestDescription.java when run with vthread wrapper Changes: https://git.openjdk.org/jdk19/pull/77/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=77&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289235 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/77.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/77/head:pull/77 PR: https://git.openjdk.org/jdk19/pull/77 From bpb at openjdk.org Mon Jun 27 18:31:19 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 27 Jun 2022 18:31:19 GMT Subject: [jdk19] RFR: 8289235: ProblemList vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011/TestDescription.java when run with vthread wrapper In-Reply-To: References: Message-ID: <7KzqR2iLZ8hbZUWSGS9L-mHoRt88Edh44iXRRMG7JjI=.f988d510-69c8-42ae-899e-74d12bb365cb@github.com> On Mon, 27 Jun 2022 18:24:18 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011/TestDescription.java > when run with vthread wrapper. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/77 From dcubed at openjdk.org Mon Jun 27 18:31:19 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 27 Jun 2022 18:31:19 GMT Subject: [jdk19] RFR: 8289235: ProblemList vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011/TestDescription.java when run with vthread wrapper In-Reply-To: <7KzqR2iLZ8hbZUWSGS9L-mHoRt88Edh44iXRRMG7JjI=.f988d510-69c8-42ae-899e-74d12bb365cb@github.com> References: <7KzqR2iLZ8hbZUWSGS9L-mHoRt88Edh44iXRRMG7JjI=.f988d510-69c8-42ae-899e-74d12bb365cb@github.com> Message-ID: On Mon, 27 Jun 2022 18:26:12 GMT, Brian Burkhalter wrote: >> A trivial fix to ProblemList vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011/TestDescription.java >> when run with vthread wrapper. > > Marked as reviewed by bpb (Reviewer). @bplb - Thanks for the fast review! ------------- PR: https://git.openjdk.org/jdk19/pull/77 From coleenp at openjdk.org Mon Jun 27 18:32:40 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 27 Jun 2022 18:32:40 GMT Subject: RFR: 8288651: CDS test HelloUnload.java should not use literal string as ClassLoader name In-Reply-To: <2s2IrvXmWYjJiV53w5K2PZGZ1w8C2scCqBVFldUYfh4=.22047356-4288-4632-b827-7e55646ee69e@github.com> References: <2s2IrvXmWYjJiV53w5K2PZGZ1w8C2scCqBVFldUYfh4=.22047356-4288-4632-b827-7e55646ee69e@github.com> Message-ID: On Mon, 27 Jun 2022 17:32:24 GMT, Calvin Cheung wrote: > A simple test fix for changing the class loader name to a non-literal string so that the symbol refcount could be decremented upon unloading of the class loader. > > Passed tiers 1 and 2 testing. Inspected the .jtr file to check the symbol refcount was decremented. Ok, that's subtle but good find. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/9297 From dcubed at openjdk.org Mon Jun 27 18:44:26 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 27 Jun 2022 18:44:26 GMT Subject: [jdk19] RFR: 8289240: ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode Message-ID: A trivial fix to ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode. ------------- Commit messages: - 8289240: ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode Changes: https://git.openjdk.org/jdk19/pull/78/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=78&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289240 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/78.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/78/head:pull/78 PR: https://git.openjdk.org/jdk19/pull/78 From bpb at openjdk.org Mon Jun 27 18:44:27 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 27 Jun 2022 18:44:27 GMT Subject: [jdk19] RFR: 8289240: ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode In-Reply-To: References: Message-ID: <_D7m0WPWPZaDi5PuvZTgzb1-xZXtRFfkaDFcc3Ykjdg=.b52f30eb-8acf-4aed-af8c-90ce8e19f2f3@github.com> On Mon, 27 Jun 2022 18:35:53 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/78 From naoto at openjdk.org Mon Jun 27 18:44:27 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 27 Jun 2022 18:44:27 GMT Subject: [jdk19] RFR: 8289240: ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode In-Reply-To: References: Message-ID: <4n5WHpwy0Qw5pR3NNpfTtb2RkeXOMsbfcK6U9EEpy3c=.37fe5513-d46b-43c4-8c23-7598832823b5@github.com> On Mon, 27 Jun 2022 18:35:53 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/78 From dcubed at openjdk.org Mon Jun 27 18:44:27 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 27 Jun 2022 18:44:27 GMT Subject: [jdk19] RFR: 8289240: ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode In-Reply-To: <_D7m0WPWPZaDi5PuvZTgzb1-xZXtRFfkaDFcc3Ykjdg=.b52f30eb-8acf-4aed-af8c-90ce8e19f2f3@github.com> References: <_D7m0WPWPZaDi5PuvZTgzb1-xZXtRFfkaDFcc3Ykjdg=.b52f30eb-8acf-4aed-af8c-90ce8e19f2f3@github.com> Message-ID: On Mon, 27 Jun 2022 18:38:09 GMT, Brian Burkhalter wrote: >> A trivial fix to ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode. > > Marked as reviewed by bpb (Reviewer). @bplb and @naotoj - Thanks for the fast reviews! ------------- PR: https://git.openjdk.org/jdk19/pull/78 From dcubed at openjdk.org Mon Jun 27 18:46:50 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 27 Jun 2022 18:46:50 GMT Subject: [jdk19] Integrated: 8289235: ProblemList vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011/TestDescription.java when run with vthread wrapper In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 18:24:18 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011/TestDescription.java > when run with vthread wrapper. This pull request has now been integrated. Changeset: 28913f47 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk19/commit/28913f474733bff360c6693fc4d3fa8e264ce552 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8289235: ProblemList vmTestbase/nsk/jdi/ClassType/invokeMethod/invokemethod011/TestDescription.java when run with vthread wrapper Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk19/pull/77 From dcubed at openjdk.org Mon Jun 27 18:47:40 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 27 Jun 2022 18:47:40 GMT Subject: [jdk19] Integrated: 8289240: ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode In-Reply-To: References: Message-ID: <38hB-Dnf-useQA0gfQMZK0WVX4-7eEJxLp2_3vpBpQk=.b38f84f9-6680-4ad6-9f0c-1ef949dd515b@github.com> On Mon, 27 Jun 2022 18:35:53 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode. This pull request has now been integrated. Changeset: caa6b74b Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk19/commit/caa6b74b5b2d641ca8fe2e226e09ce1b556eb2fc Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8289240: ProblemList java/lang/reflect/callerCache/ReflectionCallerCacheTest.java in -Xcomp mode Reviewed-by: bpb, naoto ------------- PR: https://git.openjdk.org/jdk19/pull/78 From zgu at openjdk.org Mon Jun 27 19:02:50 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 27 Jun 2022 19:02:50 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 03:42:28 GMT, Chris Plummer wrote: >> Zhengyu Gu 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 18 additional commits since the last revision: >> >> - Improve naming and cleanup >> - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event >> - v4 >> - v3 >> - v2 >> - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event >> - Merge branch 'jdi_tmp' into JDK-8256811-jdi-missing-class-unloading-event >> - v0 >> - v2 >> - v1 >> - ... and 8 more: https://git.openjdk.org/jdk/compare/dfdc1127...559b4bf1 > > src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 52: > >> 50: >> 51: /* >> 52: * Add a class to the prepared class table. > > This comment is out of date. There is no longer a table and hasn't been for a while. I'd suggest a comment about tagging it so we know when the class is freed. Aslo, maybe `classTrack_trackPreparedClass()` would be a better name. Fixed > src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 156: > >> 154: void >> 155: classTrack_activate(JNIEnv *env) >> 156: { } > > Remove Fixed > src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 165: > >> 163: classTrack_reset(void) >> 164: {} >> 165: > > Remove Fixed > src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 462: > >> 460: /* Create a synthetic class unload event for every class no longer present. >> 461: * Analogous to event_callback combined with a handler in a unload specific >> 462: * (no event structure) kind of way. > > This comment was already out of date. It is based on when we took a new snapshot of loaded classes and compared it with the old snapshot to determine which ones were just unloaded. I would suggest change it to just say something like "Create a synthetic class unload event for the specified signature." Fixed ------------- PR: https://git.openjdk.org/jdk/pull/9168 From zgu at openjdk.org Mon Jun 27 19:08:43 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 27 Jun 2022 19:08:43 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: <-e-M6_PKxWeze8X6t_tDYEX2uyH__rsZcI5K0gsOQdw=.3a657065-bcc9-4376-956c-50d4882750b5@github.com> On Sat, 25 Jun 2022 05:42:08 GMT, Chris Plummer wrote: >> src/hotspot/share/prims/jvmtiExport.cpp line 1722: >> >>> 1720: if (javaThread->is_in_VTMS_transition()) { >>> 1721: return; // no events should be posted if thread is in a VTMS transition >>> 1722: } >> >> Chris suggested to convert this if-statement to assert. >> The concern is we want to be sure the debug agent does not skip any CLASS_UNLOAD events. >> Though, I feel that a probability to get the assert triggered is very low. > >> Chris suggested to convert this if-statement to assert. >> The concern is we want to be sure the debug agent does not skip any CLASS_UNLOAD events. >> Though, I feel that a probability to get the assert triggered is very low. > > Yes, I think it should be an assert, but was not suggesting that change as part of this PR since it is pre-existing. We can file a separate CR for it. Yes, I agree that it should be another CR. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From zgu at openjdk.org Mon Jun 27 19:08:50 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 27 Jun 2022 19:08:50 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 03:32:13 GMT, Chris Plummer wrote: >> Zhengyu Gu 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 18 additional commits since the last revision: >> >> - Improve naming and cleanup >> - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event >> - v4 >> - v3 >> - v2 >> - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event >> - Merge branch 'jdi_tmp' into JDK-8256811-jdi-missing-class-unloading-event >> - v0 >> - v2 >> - v1 >> - ... and 8 more: https://git.openjdk.org/jdk/compare/d5eafb33...559b4bf1 > > src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 627: > >> 625: >> 626: if (evinfo->ei == EI_CLASS_UNLOAD) { >> 627: synthesizeUnloadEvent((char*)jlong_to_ptr(evinfo->tag), env); > > You're in uncharted waters here. Previously `event_callback()` was always called with a `thread` argument except for VMDeath. Now it is being called during an ObjectFree, which has no thread associated with it. That means all the code below that is executed when we have a thread is no longer being executed after the ClassUnload events are generated by the `synthesizeUnloadEvent()` call. Have you thought this part through? > > My guess is that for the most part it is harmless. The "invoke" support is not relevant in this case. I think/hope that means there is no need for calling `threadControl_onEventHandlerEntry()`. The `filterAndHandleEvent()` probably amounts to an (expensive) nop, although it seems silly to be calling it for the `ObjectFree` event. I'd suggest just returning at this point in the code, but you do still have the restoration of the pending exception to handle. Maybe that should just be done here and then return. It will make it a lot more clear that the rest of the code below is not needed. I did not thought through this part. I hooked up `ObjectFree` event in `event_callback()` to behave like other events, now I see it is probably not a good idea. Reverted. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From zgu at openjdk.org Mon Jun 27 19:11:55 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 27 Jun 2022 19:11:55 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: <9DXhiJashhHzVprdaDkeueDpLbjylMSOyu3ROEcoexs=.0a646a14-4168-43f0-bbe5-6d48e829dad5@github.com> References: <9DXhiJashhHzVprdaDkeueDpLbjylMSOyu3ROEcoexs=.0a646a14-4168-43f0-bbe5-6d48e829dad5@github.com> Message-ID: On Fri, 24 Jun 2022 21:49:00 GMT, Chris Plummer wrote: > You should also remove the following from the hotspot ProblemList.txt: > > `vmTestbase/nsk/jdi/HiddenClass/events/events001.java 8257705 generic-all` > > Try to reproduce without your fix, and then verify your fix is addressing the failure. I did test it locally, unless you want to make [JDK-8257705](https://bugs.openjdk.org/browse/JDK-8257705) is a duplicate? ------------- PR: https://git.openjdk.org/jdk/pull/9168 From zgu at openjdk.org Mon Jun 27 19:11:57 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 27 Jun 2022 19:11:57 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v4] In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 15:50:47 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/jvmtiTagMap.cpp line 1200: >> >>> 1198: }; >>> 1199: >>> 1200: // PostObjectFree can't be called by JavaThread, so call it from the VM thread. >> >> I wish I'd written why here. I think it's because we can't hold a Mutex to do the callback, but now I don't remember. I need to spend some time to understand this. Thanks @plummercj for adding Kim and I. > > Ok, thanks I reread your description and see it now. At this point, you are neither holding the Mutex and have already collected the objects, so that you can transition to native. Yes. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From zgu at openjdk.org Mon Jun 27 19:24:52 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 27 Jun 2022 19:24:52 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 04:11:24 GMT, Chris Plummer wrote: >> Zhengyu Gu 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 18 additional commits since the last revision: >> >> - Improve naming and cleanup >> - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event >> - v4 >> - v3 >> - v2 >> - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event >> - Merge branch 'jdi_tmp' into JDK-8256811-jdi-missing-class-unloading-event >> - v0 >> - v2 >> - v1 >> - ... and 8 more: https://git.openjdk.org/jdk/compare/7093135d...559b4bf1 > > src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 966: > >> 964: */ >> 965: void JNICALL >> 966: cbTrackingObjectFree(jvmtiEnv* jvmti_env, jlong tag) > > I think it's misleading to have this event handler here since it is handled very differently than all the other events, and with a different `jvmti_env`. Perhaps move this back to classTrack.c, and instead of calling `event_callback()`, call something that just does the parts of `event_callback()` that are really needed for `ObjectFree` (see my comments in `event_callback()` also). What might work bests is to export `synthesizeUnloadEvent()` and just call it from this callback (after relocating it). There's not much of `event_handler()` you need other than the call to `synthesizeUnloadEvent()`. Moved `cbTrackingObjectFree()` back to `classTrack.c` ------------- PR: https://git.openjdk.org/jdk/pull/9168 From dlong at openjdk.org Mon Jun 27 20:47:59 2022 From: dlong at openjdk.org (Dean Long) Date: Mon, 27 Jun 2022 20:47:59 GMT Subject: [jdk19] RFR: 8288949: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing [v2] In-Reply-To: References: Message-ID: On Sat, 25 Jun 2022 01:23:47 GMT, Ron Pressler wrote: >> Please review the following bug fix: >> >> `Continuation.enterSpecial` is a generated special nmethod (albeit not a Java method), with a well-known frame layout that calls `Continuation.enter`. >> >> Because it is compiled, it resolves the call to `Continuation.enter` to its compiled version, if available. But this results in the compiled `Continuation.enter` being called even when the thread is in interp_only_mode. >> >> This change does three things: >> >> 1. When entering interp_only_mode, `Continuation::set_cont_fastpath_thread_state` will clear enterSpecial's resolved callsite to Continuation.enter. >> 2. In interp_only_mode, `SharedRuntime::resolve_static_call_C` will return `Continuation.enter`'s c2i entry rather than `verified_code_entry`. >> 3. In interp_only_mode, the c2i stub will not patch the callsite. >> >> This fix isn't perfect, because a different thread, not in interp_only_mode, might patch the call. A longer-term solution is to create an "interpreted" version of `enterSpecial` and supporting an ad-hoc deoptimization. See https://bugs.openjdk.org/browse/JDK-8289128 >> >> >> Passes tiers 1-4 and Loom tiers 1-5. > > Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Remove outdated comment" > > This reverts commit 8f571d76e34bc64ceb31894184fba4b909e8fbfe. Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/66 From iklam at openjdk.org Mon Jun 27 20:50:44 2022 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 27 Jun 2022 20:50:44 GMT Subject: RFR: 8288651: CDS test HelloUnload.java should not use literal string as ClassLoader name In-Reply-To: <2s2IrvXmWYjJiV53w5K2PZGZ1w8C2scCqBVFldUYfh4=.22047356-4288-4632-b827-7e55646ee69e@github.com> References: <2s2IrvXmWYjJiV53w5K2PZGZ1w8C2scCqBVFldUYfh4=.22047356-4288-4632-b827-7e55646ee69e@github.com> Message-ID: On Mon, 27 Jun 2022 17:32:24 GMT, Calvin Cheung wrote: > A simple test fix for changing the class loader name to a non-literal string so that the symbol refcount could be decremented upon unloading of the class loader. > > Passed tiers 1 and 2 testing. Inspected the .jtr file to check the symbol refcount was decremented. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/9297 From cjplummer at openjdk.org Mon Jun 27 20:44:44 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 27 Jun 2022 20:44:44 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 17:49:25 GMT, Zhengyu Gu wrote: >>> This patch is intended to not post ObjectFree events on VMThread, so I am going to move this PR back to draft state and take another look. >> >> I'm not so sure it matters to the debug agent. I thought the main change here was to not force posting of ObjectFree events to be deferred to the VMThread, and to change the debug agent to send the CLASS_UNLOAD events right away rather than accumulating them and waiting for a GCFinishEvent. Is there any issue if the posting of ObjectFree and sending of CLASS_UNLOAD is done on the VMThread? > > Hmm... I thought that is the whole purpose for delaying processing class unload events, because it can not be done on `VMThread`? Otherwise, we don't need all this complexity, just have `cbTrackingObjectFree()` calls `synthesizeUnloadEvent()` directly. There were two delays. One was the debug agent waiting until the GCFinishEvent before sending out all the queued up CLASS_UNLOAD events. The other was JVMTI deferring the posting the ObjectFree events that arrive on a JavaThread, and instead using the VMThread: 1200 // PostObjectFree can't be called by JavaThread, so call it from the VM thread. 1201 void JvmtiTagMap::post_dead_objects_on_vm_thread() { 1202 VM_JvmtiPostObjectFree op(this); 1203 VMThread::execute(&op); I think this was because the VM state was not consistent, and I believed you have resolved this so it should be ok to post from the JavaThread (which I think is actually the ServiceThread in this case, but I'm not certain). ------------- PR: https://git.openjdk.org/jdk/pull/9168 From dcubed at openjdk.org Mon Jun 27 21:00:47 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 27 Jun 2022 21:00:47 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v2] In-Reply-To: References: Message-ID: > A trivial move of the oop safety check from SharedRuntime::get_java_tid() to > JavaThread::threadObj(). Also made adjustments to the threadObj() calls in > JavaThread::print_on_error() and JavaThread::get_thread_name_string() so > that we don't get secondary crashes when a JavaThread crashes after it has > detached the GC barrier. > > Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: dholmes CR - check if current thread's oop access is safe. ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/69/files - new: https://git.openjdk.org/jdk19/pull/69/files/68d57055..d96d55d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=69&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=69&range=00-01 Stats: 23 lines in 1 file changed: 19 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk19/pull/69.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/69/head:pull/69 PR: https://git.openjdk.org/jdk19/pull/69 From dcubed at openjdk.org Mon Jun 27 21:00:47 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 27 Jun 2022 21:00:47 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 19:53:31 GMT, Daniel D. Daugherty wrote: > A trivial move of the oop safety check from SharedRuntime::get_java_tid() to > JavaThread::threadObj(). Also made adjustments to the threadObj() calls in > JavaThread::print_on_error() and JavaThread::get_thread_name_string() so > that we don't get secondary crashes when a JavaThread crashes after it has > detached the GC barrier. > > Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. Testing the V01 patch with Mach5 Tier1 now; it's 2/3 of the way done and so far is looking good. Will follow with additional Mach5 Tiers. Also tested by temporarily reintroducing the bug fixed by: [JDK-8288139](https://bugs.openjdk.org/browse/JDK-8288139) JavaThread touches oop after GC barrier is detached and verifying that the bad code is still detected and that the hs_err_pid file looks good. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From ccheung at openjdk.org Mon Jun 27 21:16:39 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 27 Jun 2022 21:16:39 GMT Subject: RFR: 8288651: CDS test HelloUnload.java should not use literal string as ClassLoader name In-Reply-To: <2s2IrvXmWYjJiV53w5K2PZGZ1w8C2scCqBVFldUYfh4=.22047356-4288-4632-b827-7e55646ee69e@github.com> References: <2s2IrvXmWYjJiV53w5K2PZGZ1w8C2scCqBVFldUYfh4=.22047356-4288-4632-b827-7e55646ee69e@github.com> Message-ID: On Mon, 27 Jun 2022 17:32:24 GMT, Calvin Cheung wrote: > A simple test fix for changing the class loader name to a non-literal string so that the symbol refcount could be decremented upon unloading of the class loader. > > Passed tiers 1 and 2 testing. Inspected the .jtr file to check the symbol refcount was decremented. Thanks Coleen, Ioi for the review. ------------- PR: https://git.openjdk.org/jdk/pull/9297 From ccheung at openjdk.org Mon Jun 27 21:19:41 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 27 Jun 2022 21:19:41 GMT Subject: Integrated: 8288651: CDS test HelloUnload.java should not use literal string as ClassLoader name In-Reply-To: <2s2IrvXmWYjJiV53w5K2PZGZ1w8C2scCqBVFldUYfh4=.22047356-4288-4632-b827-7e55646ee69e@github.com> References: <2s2IrvXmWYjJiV53w5K2PZGZ1w8C2scCqBVFldUYfh4=.22047356-4288-4632-b827-7e55646ee69e@github.com> Message-ID: On Mon, 27 Jun 2022 17:32:24 GMT, Calvin Cheung wrote: > A simple test fix for changing the class loader name to a non-literal string so that the symbol refcount could be decremented upon unloading of the class loader. > > Passed tiers 1 and 2 testing. Inspected the .jtr file to check the symbol refcount was decremented. This pull request has now been integrated. Changeset: e322e77e Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/e322e77e9535fc3f37b409a1c805e9f6b728377a Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8288651: CDS test HelloUnload.java should not use literal string as ClassLoader name Reviewed-by: coleenp, iklam ------------- PR: https://git.openjdk.org/jdk/pull/9297 From dcubed at openjdk.org Mon Jun 27 21:28:45 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 27 Jun 2022 21:28:45 GMT Subject: [jdk19] Integrated: 8289251: ProblemList java/lang/ref/OOMEInReferenceHandler.java Message-ID: <69MqUw5vNkarSqQCr2G6Rcd33a5kJS7F9_sKipJjAeU=.23be9cad-2b38-45ab-bbbd-cb1681ce8f9e@github.com> A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java. ------------- Commit messages: - 8289251: ProblemList java/lang/ref/OOMEInReferenceHandler.java Changes: https://git.openjdk.org/jdk19/pull/80/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=80&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289251 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/80.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/80/head:pull/80 PR: https://git.openjdk.org/jdk19/pull/80 From dholmes at openjdk.org Mon Jun 27 21:28:45 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Jun 2022 21:28:45 GMT Subject: [jdk19] Integrated: 8289251: ProblemList java/lang/ref/OOMEInReferenceHandler.java In-Reply-To: <69MqUw5vNkarSqQCr2G6Rcd33a5kJS7F9_sKipJjAeU=.23be9cad-2b38-45ab-bbbd-cb1681ce8f9e@github.com> References: <69MqUw5vNkarSqQCr2G6Rcd33a5kJS7F9_sKipJjAeU=.23be9cad-2b38-45ab-bbbd-cb1681ce8f9e@github.com> Message-ID: On Mon, 27 Jun 2022 21:16:29 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/80 From dcubed at openjdk.org Mon Jun 27 21:28:46 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 27 Jun 2022 21:28:46 GMT Subject: [jdk19] Integrated: 8289251: ProblemList java/lang/ref/OOMEInReferenceHandler.java In-Reply-To: References: <69MqUw5vNkarSqQCr2G6Rcd33a5kJS7F9_sKipJjAeU=.23be9cad-2b38-45ab-bbbd-cb1681ce8f9e@github.com> Message-ID: On Mon, 27 Jun 2022 21:17:40 GMT, David Holmes wrote: >> A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java. > > Marked as reviewed by dholmes (Reviewer). @dholmes-ora - Thanks for the lightning fast review! ------------- PR: https://git.openjdk.org/jdk19/pull/80 From dcubed at openjdk.org Mon Jun 27 21:28:47 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 27 Jun 2022 21:28:47 GMT Subject: [jdk19] Integrated: 8289251: ProblemList java/lang/ref/OOMEInReferenceHandler.java In-Reply-To: <69MqUw5vNkarSqQCr2G6Rcd33a5kJS7F9_sKipJjAeU=.23be9cad-2b38-45ab-bbbd-cb1681ce8f9e@github.com> References: <69MqUw5vNkarSqQCr2G6Rcd33a5kJS7F9_sKipJjAeU=.23be9cad-2b38-45ab-bbbd-cb1681ce8f9e@github.com> Message-ID: On Mon, 27 Jun 2022 21:16:29 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/lang/ref/OOMEInReferenceHandler.java. This pull request has now been integrated. Changeset: 2efa89a8 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk19/commit/2efa89a89e01003e2d161ffc0d377c39fd18acb8 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8289251: ProblemList java/lang/ref/OOMEInReferenceHandler.java Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk19/pull/80 From cjplummer at openjdk.org Mon Jun 27 21:33:47 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 27 Jun 2022 21:33:47 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v4] In-Reply-To: References: Message-ID: <1NxU57TAMnhOzmX8D3SyVoibuOwgRXdEGUDlpmg_jNs=.1f4e458e-a129-439a-88e0-27b022bfd0e2@github.com> On Mon, 27 Jun 2022 17:02:04 GMT, Zhengyu Gu wrote: >> Currently, jdi only check and process class unloading event when it detects a new GC cycle. >> >> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. >> >> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. >> >> It also performs `commonRef_compact()` only when there are classes unloaded. >> >> New test failed about 20% without patch, none with patch. >> >> **Update** >> There are significant changes from early patch. >> >> The new approach: >> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: >> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state >> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state >> >> The new solution breaks up into two steps: >> - Collect all dead object tags with lock >> - Transition to `_in_native` state and post object free events in one batch >> >> This way, JDI event handler can process object free events upon arrivals without delay. >> >> ** Update 2 ** >> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks. >> >> // This checks for posting and rehashing before operations that >> // this tagmap table. The calls from a JavaThread only rehash, posting is >> // only done before heap walks. >> void JvmtiTagMap::check_hashmap(bool post_events) { >> >> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. >> Even the events are posted earlier in old code, but they are only processed after next GC cycle. > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > v5 src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 48: > 46: static jvmtiEnv* trackingEnv; > 47: > 48: extern jboolean synthesizeUnloadEvent(char *signature, JNIEnv *env); This should be exported from eventHandler.h and use the `eventHandler_` prefix. src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 462: > 460: /* Create a synthetic class unload event for the specified signature. */ > 461: jboolean > 462: synthesizeUnloadEvent(char *signature, JNIEnv *env) This should now be named `eventHandler_synthesizeUnloadEvent`. src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 1714: > 1712: if (node->ei == EI_GC_FINISH) { > 1713: classTrack_activate(getEnv()); > 1714: } This looked a bit strange to me w.r.t. when we activate class tracking, so I looked into it. It turns out that when the debugger sends a request for CLASS_UNLOAD events, we convert it to EI_GC_FINISH and install a handler for it (and activate class tracking as you see in the above code). Activating doesn't do much. In fact it's not even where the ObjectFree events are enabled. This is done unconditionally in `classTrack_initialize()`, which is called whenever the debug agent is initialized. This means we always have the ObjectFree events enabled, even when the debugger has not requested CLASS_LOAD events. This seems like a bit of a performance issue. Maybe `classTrack_activate()` is where we should be enabling ObjectFree events. We should probably file a separate CR to have this fixed. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From dholmes at openjdk.org Mon Jun 27 22:48:46 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Jun 2022 22:48:46 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v2] In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 21:00:47 GMT, Daniel D. Daugherty wrote: >> A trivial move of the oop safety check from SharedRuntime::get_java_tid() to >> JavaThread::threadObj(). Also made adjustments to the threadObj() calls in >> JavaThread::print_on_error() and JavaThread::get_thread_name_string() so >> that we don't get secondary crashes when a JavaThread crashes after it has >> detached the GC barrier. >> >> Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR - check if current thread's oop access is safe. Hi Dan, The additional checks to avoid secondary crashes seem like a lot of effort for little benefit, afterall the windows during which they would be applicable is quite small on the thread termination path. Somewhat ironically(?) the primary need for these additional checks would be when the current thread has already performed an unsafe oop access and so hit the guarantee and is now doing the thread dump for the hs_err file. Because of that I'm going to approve this, but in general I don't like us making the code jump through hoops for these kind of secondary failure avoidance issues. The current thread is the primary interest during a crash. Thanks. src/hotspot/share/runtime/thread.cpp line 2151: > 2149: st->print("%s \"%s\"", type_name(), get_thread_name_string(buf, buflen)); > 2150: Thread* current = Thread::current_or_null(); > 2151: if (current != nullptr && (!current->is_Java_thread() || JavaThread::cast(current)->is_oop_safe())) { Just realized, we can't have a null current thread if we are calling this as that is checked at a higher level. But we should be using `current_or_null_safe()` here as we could be in a signal-handling context. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk19/pull/69 From dholmes at openjdk.org Mon Jun 27 22:54:44 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 27 Jun 2022 22:54:44 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v2] In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 21:00:47 GMT, Daniel D. Daugherty wrote: >> A trivial move of the oop safety check from SharedRuntime::get_java_tid() to >> JavaThread::threadObj(). Also made adjustments to the threadObj() calls in >> JavaThread::print_on_error() and JavaThread::get_thread_name_string() so >> that we don't get secondary crashes when a JavaThread crashes after it has >> detached the GC barrier. >> >> Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR - check if current thread's oop access is safe. Sorry Dan have to revoke my approval. There are still some issues here that need fixing and I don't like the impact on the code. src/hotspot/share/runtime/thread.cpp line 2220: > 2218: if (current == nullptr) { > 2219: // Current thread is not attached so it can't safely determine this > 2220: // JavaThread's name so use the default thread name. This should not be possible, but again `current_or_null_safe` should be used. Though this code is used a lot in normal operation so the additional overhead of this is more significant than the print_on_error case. I think this check should be moved to the caller if needed (ie the print_on_error code), as in normal use it is not possible to fail this check. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk19/pull/69 From ccheung at openjdk.org Tue Jun 28 05:23:14 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 28 Jun 2022 05:23:14 GMT Subject: RFR: 8289258: ProblemList some failing custom loader tests with ZGC Message-ID: Problem listing the following tests in ProblemList-zgc.txt since they only failed with ZGC. See [JDK-8289257](https://bugs.openjdk.org/browse/JDK-8289257) for details. - runtime/cds/appcds/customLoader/HelloCustom.java - runtime/cds/appcds/customLoader/HelloCustom_JFR.java - runtime/cds/appcds/dynamicArchive/HelloDynamicCustomUnload.java ------------- Commit messages: - 8289258: ProblemList some failing custom loader tests with ZGC Changes: https://git.openjdk.org/jdk/pull/9301/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9301&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289258 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9301.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9301/head:pull/9301 PR: https://git.openjdk.org/jdk/pull/9301 From dholmes at openjdk.org Tue Jun 28 05:23:15 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Jun 2022 05:23:15 GMT Subject: RFR: 8289258: ProblemList some failing custom loader tests with ZGC In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 05:13:02 GMT, Calvin Cheung wrote: > Problem listing the following tests in ProblemList-zgc.txt since they only failed with ZGC. See [JDK-8289257](https://bugs.openjdk.org/browse/JDK-8289257) for details. > > - runtime/cds/appcds/customLoader/HelloCustom.java > - runtime/cds/appcds/customLoader/HelloCustom_JFR.java > - runtime/cds/appcds/dynamicArchive/HelloDynamicCustomUnload.java Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9301 From ccheung at openjdk.org Tue Jun 28 05:23:15 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 28 Jun 2022 05:23:15 GMT Subject: RFR: 8289258: ProblemList some failing custom loader tests with ZGC In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 05:17:05 GMT, David Holmes wrote: >> Problem listing the following tests in ProblemList-zgc.txt since they only failed with ZGC. See [JDK-8289257](https://bugs.openjdk.org/browse/JDK-8289257) for details. >> >> - runtime/cds/appcds/customLoader/HelloCustom.java >> - runtime/cds/appcds/customLoader/HelloCustom_JFR.java >> - runtime/cds/appcds/dynamicArchive/HelloDynamicCustomUnload.java > > Looks good. Thanks. Thanks @dholmes-ora. ------------- PR: https://git.openjdk.org/jdk/pull/9301 From ccheung at openjdk.org Tue Jun 28 05:25:48 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 28 Jun 2022 05:25:48 GMT Subject: Integrated: 8289258: ProblemList some failing custom loader tests with ZGC In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 05:13:02 GMT, Calvin Cheung wrote: > Problem listing the following tests in ProblemList-zgc.txt since they only failed with ZGC. See [JDK-8289257](https://bugs.openjdk.org/browse/JDK-8289257) for details. > > - runtime/cds/appcds/customLoader/HelloCustom.java > - runtime/cds/appcds/customLoader/HelloCustom_JFR.java > - runtime/cds/appcds/dynamicArchive/HelloDynamicCustomUnload.java This pull request has now been integrated. Changeset: 33369719 Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/33369719b2e39bddd4a1b7f300f36506306b03fa Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8289258: ProblemList some failing custom loader tests with ZGC Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/9301 From stuefe at openjdk.org Tue Jun 28 05:32:04 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 28 Jun 2022 05:32:04 GMT Subject: RFR: JDK-8271252: os::reserve_memory should not use mtOther as default NMT flag Message-ID: Small cleanup. We use mtOther as default NMT flag for os::reserve_memory(): `static char* reserve_memory(size_t bytes, bool executable = false, MEMFLAGS flags = mtOther);` mtOther marks allocations coming from outside the VM. It is not a good default flag. Note that in the end mtOther then was ignored in os::reserve_memory() and it defaulted to mtNone anyway. This trivial patch straightens the logic and uses `mtNone` as default. Note that since mtOther was ignored before, there is no behavioral change. ------------- Commit messages: - JDK-8271252-os-reserve-memory-should-not-default-to-mtOther Changes: https://git.openjdk.org/jdk/pull/9287/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9287&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8271252 Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9287.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9287/head:pull/9287 PR: https://git.openjdk.org/jdk/pull/9287 From duke at openjdk.org Tue Jun 28 05:32:05 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Tue, 28 Jun 2022 05:32:05 GMT Subject: RFR: JDK-8271252: os::reserve_memory should not use mtOther as default NMT flag In-Reply-To: References: Message-ID: <-cjRfrRA5YKXAfjS-3mno7YFO9v1Az-8gFdBsTLW_rc=.c93cf729-f345-4d36-9726-ac16c748e389@github.com> On Sat, 25 Jun 2022 05:39:03 GMT, Thomas Stuefe wrote: > Small cleanup. > > We use mtOther as default NMT flag for os::reserve_memory(): > > `static char* reserve_memory(size_t bytes, bool executable = false, MEMFLAGS flags = mtOther);` > > mtOther marks allocations coming from outside the VM. It is not a good default flag. Note that in the end mtOther then was ignored in os::reserve_memory() and it defaulted to mtNone anyway. > > This trivial patch straightens the logic and uses `mtNone` as default. Note that since mtOther was ignored before, there is no behavioral change. Except the title, lgtm. ------------- PR: https://git.openjdk.org/jdk/pull/9287 From stuefe at openjdk.org Tue Jun 28 05:32:05 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 28 Jun 2022 05:32:05 GMT Subject: RFR: JDK-8271252: os::reserve_memory should not use mtOther as default NMT flag In-Reply-To: <-cjRfrRA5YKXAfjS-3mno7YFO9v1Az-8gFdBsTLW_rc=.c93cf729-f345-4d36-9726-ac16c748e389@github.com> References: <-cjRfrRA5YKXAfjS-3mno7YFO9v1Az-8gFdBsTLW_rc=.c93cf729-f345-4d36-9726-ac16c748e389@github.com> Message-ID: On Mon, 27 Jun 2022 15:45:55 GMT, Evgeny Astigeevich wrote: > Except the title, lgtm. Oh, you are right. Thanks for noticing. ------------- PR: https://git.openjdk.org/jdk/pull/9287 From duke at openjdk.org Tue Jun 28 06:49:40 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Tue, 28 Jun 2022 06:49:40 GMT Subject: RFR: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test In-Reply-To: References: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> Message-ID: On Sat, 11 Jun 2022 13:10:18 GMT, David Holmes wrote: >> I would like to fix 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test. >> >> FlightRecorder option has not been tested since JDK13. >> I think we should test it, because FlightRecorder option has not been obsolete in the latest JDK. >> Users would be in trouble if the option suddenly disappears without notice, >> so it's important to confirm the deprication message. >> >> Also we should add a test of ExtendedDTraceProbes option. >> The test was disabled in 8281675, because some jdk can't specify it. >> I modified the test to be able to verify ExtendedDTraceProbes in either case that DTRACE_ENABLED is enabled or not. > >> so it's important to confirm the deprication message. > > It has been confirmed, just not by a regression test. Adding this is harmless _but_ you can only test this on a JVM configured with JFR so you'd need to selectively add the FlightRecorder flag after programmatically checking whether JFR is present or not (I hope we have a WhiteBox or Platform check for that). > >> Also we should add a test of ExtendedDTraceProbes option. > > That might be useful in 19 but this bug is being pushed to 20 and it is incorrect for 20. At the start of every release we remove the options present in the VMDeprecatedOptions test that are obsoleted in that release as the error message changes and so would cause the test to fail. @dholmes-ora Could you sponsor this fix, please? ------------- PR: https://git.openjdk.org/jdk/pull/9123 From dholmes at openjdk.org Tue Jun 28 07:26:36 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 28 Jun 2022 07:26:36 GMT Subject: RFR: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test [v4] In-Reply-To: <7Sxfb-hZK0rSrYAr5nHrOe0QnIwTYRIl_7YENj7lGrM=.5c9e5a5d-786e-4362-a4d3-01e15ec19602@github.com> References: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> <7Sxfb-hZK0rSrYAr5nHrOe0QnIwTYRIl_7YENj7lGrM=.5c9e5a5d-786e-4362-a4d3-01e15ec19602@github.com> Message-ID: On Thu, 23 Jun 2022 06:28:26 GMT, KIRIYAMA Takuya wrote: >> I would like to fix 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test. >> >> FlightRecorder option has not been tested since JDK13. >> I think we should test it, because FlightRecorder option has not been obsolete in the latest JDK. >> Users would be in trouble if the option suddenly disappears without notice, >> so it's important to confirm the deprication message. >> >> Also we should add a test of ExtendedDTraceProbes option. >> The test was disabled in 8281675, because some jdk can't specify it. >> I modified the test to be able to verify ExtendedDTraceProbes in either case that DTRACE_ENABLED is enabled or not. > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test This needs a second review as per hotspot rules. ------------- PR: https://git.openjdk.org/jdk/pull/9123 From ihse at openjdk.org Tue Jun 28 09:04:44 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 28 Jun 2022 09:04:44 GMT Subject: Integrated: 8288396: Always create reproducible builds In-Reply-To: References: Message-ID: On Tue, 14 Jun 2022 09:48:25 GMT, Magnus Ihse Bursie wrote: > When we started introducing some possibly more intrusive compiler flags and functionality for reproducible builds, we also introduced a flag to turn this off out of an abundance of caution. But we have been been using this configuration for a year or so internally within Oracle, with no issues. So there's really no reason to be able to turn this off. (If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one.) > > With this fix, all randomness should be gone from our builds, at least on linux and windows. There are no more `__DATE__` and `__TIME__` macros in the source code. This pull request has now been integrated. Changeset: b4ab5fe1 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/b4ab5fe1daf22a543e1bd973bcd34322360054b4 Stats: 158 lines in 18 files changed: 14 ins; 100 del; 44 mod 8288396: Always create reproducible builds Reviewed-by: amenkov, ehelin ------------- PR: https://git.openjdk.org/jdk/pull/9152 From mgronlun at openjdk.org Tue Jun 28 10:34:43 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 28 Jun 2022 10:34:43 GMT Subject: RFR: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test [v4] In-Reply-To: <7Sxfb-hZK0rSrYAr5nHrOe0QnIwTYRIl_7YENj7lGrM=.5c9e5a5d-786e-4362-a4d3-01e15ec19602@github.com> References: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> <7Sxfb-hZK0rSrYAr5nHrOe0QnIwTYRIl_7YENj7lGrM=.5c9e5a5d-786e-4362-a4d3-01e15ec19602@github.com> Message-ID: On Thu, 23 Jun 2022 06:28:26 GMT, KIRIYAMA Takuya wrote: >> I would like to fix 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test. >> >> FlightRecorder option has not been tested since JDK13. >> I think we should test it, because FlightRecorder option has not been obsolete in the latest JDK. >> Users would be in trouble if the option suddenly disappears without notice, >> so it's important to confirm the deprication message. >> >> Also we should add a test of ExtendedDTraceProbes option. >> The test was disabled in 8281675, because some jdk can't specify it. >> I modified the test to be able to verify ExtendedDTraceProbes in either case that DTRACE_ENABLED is enabled or not. > > KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision: > > 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9123 From duke at openjdk.org Tue Jun 28 11:47:46 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Tue, 28 Jun 2022 11:47:46 GMT Subject: RFR: JDK-8271252: os::reserve_memory should not use mtOther as default NMT flag In-Reply-To: References: Message-ID: On Sat, 25 Jun 2022 05:39:03 GMT, Thomas Stuefe wrote: > Small cleanup. > > We use mtOther as default NMT flag for os::reserve_memory(): > > `static char* reserve_memory(size_t bytes, bool executable = false, MEMFLAGS flags = mtOther);` > > mtOther marks allocations coming from outside the VM. It is not a good default flag. Note that in the end mtOther then was ignored in os::reserve_memory() and it defaulted to mtNone anyway. > > This trivial patch straightens the logic and uses `mtNone` as default. Note that since mtOther was ignored before, there is no behavioral change. lgtm ------------- Marked as reviewed by eastig at github.com (no known OpenJDK username). PR: https://git.openjdk.org/jdk/pull/9287 From duke at openjdk.org Tue Jun 28 11:47:49 2022 From: duke at openjdk.org (Evgeny Astigeevich) Date: Tue, 28 Jun 2022 11:47:49 GMT Subject: RFR: JDK-8271252: os::reserve_memory should not use mtOther as default NMT flag In-Reply-To: References: <-cjRfrRA5YKXAfjS-3mno7YFO9v1Az-8gFdBsTLW_rc=.c93cf729-f345-4d36-9726-ac16c748e389@github.com> Message-ID: On Tue, 28 Jun 2022 05:27:01 GMT, Thomas Stuefe wrote: >> Except the title, lgtm. > >> Except the title, lgtm. > > Oh, you are right. Thanks for noticing. @tstuefe thanks for updating the title. I usually exclude 'JDK-' prefix from a JBS bug id to make commit title shorter. ------------- PR: https://git.openjdk.org/jdk/pull/9287 From zgu at openjdk.org Tue Jun 28 12:17:33 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Tue, 28 Jun 2022 12:17:33 GMT Subject: RFR: JDK-8271252: os::reserve_memory should not use mtOther as default NMT flag In-Reply-To: References: Message-ID: On Sat, 25 Jun 2022 05:39:03 GMT, Thomas Stuefe wrote: > Small cleanup. > > We use mtOther as default NMT flag for os::reserve_memory(): > > `static char* reserve_memory(size_t bytes, bool executable = false, MEMFLAGS flags = mtOther);` > > mtOther marks allocations coming from outside the VM. It is not a good default flag. Note that in the end mtOther then was ignored in os::reserve_memory() and it defaulted to mtNone anyway. > > This trivial patch straightens the logic and uses `mtNone` as default. Note that since mtOther was ignored before, there is no behavioral change. Good to me. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.org/jdk/pull/9287 From stuefe at openjdk.org Tue Jun 28 12:33:42 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 28 Jun 2022 12:33:42 GMT Subject: RFR: JDK-8271252: os::reserve_memory should not use mtOther as default NMT flag In-Reply-To: References: <-cjRfrRA5YKXAfjS-3mno7YFO9v1Az-8gFdBsTLW_rc=.c93cf729-f345-4d36-9726-ac16c748e389@github.com> Message-ID: On Tue, 28 Jun 2022 11:43:59 GMT, Evgeny Astigeevich wrote: >>> Except the title, lgtm. >> >> Oh, you are right. Thanks for noticing. > > @tstuefe thanks for updating the title. I usually exclude 'JDK-' prefix from a JBS bug id to make commit title shorter. Thanks @eastig and @zhengyu123. ------------- PR: https://git.openjdk.org/jdk/pull/9287 From stuefe at openjdk.org Tue Jun 28 12:36:43 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 28 Jun 2022 12:36:43 GMT Subject: Integrated: JDK-8271252: os::reserve_memory should not use mtOther as default NMT flag In-Reply-To: References: Message-ID: On Sat, 25 Jun 2022 05:39:03 GMT, Thomas Stuefe wrote: > Small cleanup. > > We use mtOther as default NMT flag for os::reserve_memory(): > > `static char* reserve_memory(size_t bytes, bool executable = false, MEMFLAGS flags = mtOther);` > > mtOther marks allocations coming from outside the VM. It is not a good default flag. Note that in the end mtOther then was ignored in os::reserve_memory() and it defaulted to mtNone anyway. > > This trivial patch straightens the logic and uses `mtNone` as default. Note that since mtOther was ignored before, there is no behavioral change. This pull request has now been integrated. Changeset: d4eeeb82 Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/d4eeeb82cb2288973a6a247c54513f7e1c6b58f0 Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod 8271252: os::reserve_memory should not use mtOther as default NMT flag Reviewed-by: zgu ------------- PR: https://git.openjdk.org/jdk/pull/9287 From zgu at openjdk.org Tue Jun 28 13:13:51 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Tue, 28 Jun 2022 13:13:51 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v5] In-Reply-To: References: Message-ID: > Currently, jdi only check and process class unloading event when it detects a new GC cycle. > > After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. > > This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. > > It also performs `commonRef_compact()` only when there are classes unloaded. > > New test failed about 20% without patch, none with patch. > > **Update** > There are significant changes from early patch. > > The new approach: > No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: > - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state > - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state > > The new solution breaks up into two steps: > - Collect all dead object tags with lock > - Transition to `_in_native` state and post object free events in one batch > > This way, JDI event handler can process object free events upon arrivals without delay. > > **Update 2** > There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks. > > // This checks for posting and rehashing before operations that > // this tagmap table. The calls from a JavaThread only rehash, posting is > // only done before heap walks. > void JvmtiTagMap::check_hashmap(bool post_events) { > > Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. > Even the events are posted earlier in old code, but they are only processed after next GC cycle. Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Renamed eventHandler_synthesizeUnloadEvent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9168/files - new: https://git.openjdk.org/jdk/pull/9168/files/2d9a81e0..bf334b11 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=03-04 Stats: 6 lines in 3 files changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9168.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9168/head:pull/9168 PR: https://git.openjdk.org/jdk/pull/9168 From dcubed at openjdk.org Tue Jun 28 13:45:54 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 28 Jun 2022 13:45:54 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v2] In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 22:46:43 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> dholmes CR - check if current thread's oop access is safe. > > src/hotspot/share/runtime/thread.cpp line 2151: > >> 2149: st->print("%s \"%s\"", type_name(), get_thread_name_string(buf, buflen)); >> 2150: Thread* current = Thread::current_or_null(); >> 2151: if (current != nullptr && (!current->is_Java_thread() || JavaThread::cast(current)->is_oop_safe())) { > > Just realized, we can't have a null current thread if we are calling this as that is checked at a higher level. But we should be using `current_or_null_safe()` here as we could be in a signal-handling context. I used `Thread::current_or_null()` just to make the code more bullet proof. In all of my testing I never ran into a case where `Thread::current()` returned `nullptr`. I'm going to switch back to `Thread::current()` and remove the extra handling for the `current == nullptr` case. > src/hotspot/share/runtime/thread.cpp line 2220: > >> 2218: if (current == nullptr) { >> 2219: // Current thread is not attached so it can't safely determine this >> 2220: // JavaThread's name so use the default thread name. > > This should not be possible, but again `current_or_null_safe` should be used. > > Though this code is used a lot in normal operation so the additional overhead of this is more significant than the print_on_error case. > > I think this check should be moved to the caller if needed (ie the print_on_error code), as in normal use it is not possible to fail this check. I'm going to switch back to `Thread::current()` and remove the extra handling for the `current == nullptr` case. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From zgu at openjdk.org Tue Jun 28 13:50:46 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Tue, 28 Jun 2022 13:50:46 GMT Subject: RFR: JDK-8289182: NMT: MemTracker::baseline should return void [v2] In-Reply-To: References: Message-ID: On Sun, 26 Jun 2022 06:53:24 GMT, Thomas Stuefe wrote: >> Small cleanup. >> >> Since MemTracker::baseline() only returns true, it can revert to void, and error handling can be removed from all callers. > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > let MemTracker::baseline return void LGTM ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.org/jdk/pull/9288 From dcubed at openjdk.org Tue Jun 28 13:54:41 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 28 Jun 2022 13:54:41 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v2] In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 22:50:48 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> dholmes CR - check if current thread's oop access is safe. > > Sorry Dan have to revoke my approval. There are still some issues here that need fixing and I don't like the impact on the code. @dholmes-ora - Thanks for the re-review. I'm going to update the fix again and switch back to using `Thread::current()` instead of `Thread::current_or_null()`. The reason that this particular handling of a secondary failure is important is that a secondary failure in printing the name of the failing thread will prevent entries for following threads from being printed in the thread list in the hs_err_pid file. Here's an example to show placement: Java Threads: ( => current thread ) 0x00007fd64d808a00 JavaThread "Unknown thread" [_thread_blocked, id=7427, stack(0x0000700003c18000,0x0000700003d18000)] 0x00007fd64e80d400 JavaThread "Unknown thread" [_thread_blocked, id=43011, stack(0x0000700004433000,0x0000700004533000)] 0x00007fd64e80e200 JavaThread "Unknown thread" [_thread_blocked, id=42755, stack(0x0000700004536000,0x0000700004636000)] 0x00007fd64e80e800 JavaThread "Unknown thread" [_thread_blocked, id=42243, stack(0x0000700004639000,0x0000700004739000)] 0x00007fd64e80ee00 JavaThread "Unknown thread" [_thread_blocked, id=22787, stack(0x000070000473c000,0x000070000483c000)] 0x00007fd64e80f400 JavaThread "Unknown thread" [_thread_blocked, id=41731, stack(0x000070000483f000,0x000070000493f000)] 0x00007fd64e81e800 JavaThread "Unknown thread" [_thread_blocked, id=41219, stack(0x0000700004942000,0x0000700004a42000)] 0x00007fd64e81ee00 JavaThread "Unknown thread" [_thread_blocked, id=23299, stack(0x0000700004a45000,0x0000700004b45000)] 0x00007fd650819000 JavaThread "Unknown thread" [_thread_blocked, id=40451, stack(0x0000700004b48000,0x0000700004c48000)] 0x00007fd64e851400 JavaThread "Unknown thread" [_thread_blocked, id=23811, stack(0x0000700004c4b000,0x0000700004d4b000)] 0x00007fd64d84e200 JavaThread "Unknown thread" [_thread_blocked, id=24067, stack(0x0000700004e51000,0x0000700004f51000)] 0x00007fd64e81c600 JavaThread "Unknown thread" [_thread_blocked, id=39171, stack(0x0000700004f54000,0x0000700005054000)] _threads_hazard_ptr=0x00007fd64e0041b0 0x00007fd64d80d000 JavaThread "Unknown thread" [_thread_blocked, id=38915, stack(0x0000700005057000,0x0000700005157000)] =>0x00007fd650812000 JavaThread "" [_thread_in_vm, id=24835, stack(0x000070000515a000,0x000070000525a000)] The entry prefixed with "=>" is the crashing thread that is past the GC barrier detach point. In this example, it happens to be the last thread in the `Java Threads: ( => current thread )` section of the hs_err_pid file. However, if the failing thread happened to be earlier in the list and we didn't prevent the secondary error, then we would be missing entries from the section. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From zgu at openjdk.org Tue Jun 28 14:41:51 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Tue, 28 Jun 2022 14:41:51 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v4] In-Reply-To: <1NxU57TAMnhOzmX8D3SyVoibuOwgRXdEGUDlpmg_jNs=.1f4e458e-a129-439a-88e0-27b022bfd0e2@github.com> References: <1NxU57TAMnhOzmX8D3SyVoibuOwgRXdEGUDlpmg_jNs=.1f4e458e-a129-439a-88e0-27b022bfd0e2@github.com> Message-ID: On Mon, 27 Jun 2022 20:56:26 GMT, Chris Plummer wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> v5 > > src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 48: > >> 46: static jvmtiEnv* trackingEnv; >> 47: >> 48: extern jboolean synthesizeUnloadEvent(char *signature, JNIEnv *env); > > This should be exported from eventHandler.h and use the `eventHandler_` prefix. Done > src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 462: > >> 460: /* Create a synthetic class unload event for the specified signature. */ >> 461: jboolean >> 462: synthesizeUnloadEvent(char *signature, JNIEnv *env) > > This should now be named `eventHandler_synthesizeUnloadEvent`. Done ------------- PR: https://git.openjdk.org/jdk/pull/9168 From zgu at openjdk.org Tue Jun 28 14:41:55 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Tue, 28 Jun 2022 14:41:55 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v5] In-Reply-To: <1NxU57TAMnhOzmX8D3SyVoibuOwgRXdEGUDlpmg_jNs=.1f4e458e-a129-439a-88e0-27b022bfd0e2@github.com> References: <1NxU57TAMnhOzmX8D3SyVoibuOwgRXdEGUDlpmg_jNs=.1f4e458e-a129-439a-88e0-27b022bfd0e2@github.com> Message-ID: On Mon, 27 Jun 2022 21:28:25 GMT, Chris Plummer wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> Renamed eventHandler_synthesizeUnloadEvent > > src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 1714: > >> 1712: if (node->ei == EI_GC_FINISH) { >> 1713: classTrack_activate(getEnv()); >> 1714: } > > This looked a bit strange to me w.r.t. when we activate class tracking, so I looked into it. It turns out that when the debugger sends a request for CLASS_UNLOAD events, we convert it to EI_GC_FINISH and install a handler for it (and activate class tracking as you see in the above code). Activating doesn't do much. In fact it's not even where the ObjectFree events are enabled. This is done unconditionally in `classTrack_initialize()`, which is called whenever the debug agent is initialized. This means we always have the ObjectFree events enabled, even when the debugger has not requested CLASS_LOAD events. This seems like a bit of a performance issue. Maybe `classTrack_activate()` is where we should be enabling ObjectFree events. We should probably file a separate CR to have this fixed. Filed [JDK-8289318](https://bugs.openjdk.org/browse/JDK-8289318) ------------- PR: https://git.openjdk.org/jdk/pull/9168 From dcubed at openjdk.org Tue Jun 28 16:55:29 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 28 Jun 2022 16:55:29 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v3] In-Reply-To: References: Message-ID: <8sp27hzKOw7yBIWssa7M-0rFg-cCsbQbCRZ8E44t3tY=.920eddc4-55c0-48a2-aae5-c63cffcf3cfd@github.com> > A trivial move of the oop safety check from SharedRuntime::get_java_tid() to > JavaThread::threadObj(). Also made adjustments to the threadObj() calls in > JavaThread::print_on_error() and JavaThread::get_thread_name_string() so > that we don't get secondary crashes when a JavaThread crashes after it has > detached the GC barrier. > > Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: dholmes CR - use Thread::current() instead of Thread::current_or_null(). ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/69/files - new: https://git.openjdk.org/jdk19/pull/69/files/d96d55d8..e2f57577 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=69&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=69&range=01-02 Stats: 11 lines in 1 file changed: 0 ins; 5 del; 6 mod Patch: https://git.openjdk.org/jdk19/pull/69.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/69/head:pull/69 PR: https://git.openjdk.org/jdk19/pull/69 From dcubed at openjdk.org Tue Jun 28 16:57:45 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 28 Jun 2022 16:57:45 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v2] In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 21:00:47 GMT, Daniel D. Daugherty wrote: >> A trivial move of the oop safety check from SharedRuntime::get_java_tid() to >> JavaThread::threadObj(). Also made adjustments to the threadObj() calls in >> JavaThread::print_on_error() and JavaThread::get_thread_name_string() so >> that we don't get secondary crashes when a JavaThread crashes after it has >> detached the GC barrier. >> >> Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR - check if current thread's oop access is safe. Testing the V02 patch with Mach5 Tier1 now. Also tested by temporarily reintroducing the bug fixed by: [JDK-8288139](https://bugs.openjdk.org/browse/JDK-8288139) JavaThread touches oop after GC barrier is detached and verifying that the bad code is still detected and that the hs_err_pid file looks good. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From dcubed at openjdk.org Tue Jun 28 20:09:21 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 28 Jun 2022 20:09:21 GMT Subject: [jdk19] Integrated: 8289398: ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again Message-ID: A trivial fix to ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again. ------------- Commit messages: - 8289398: ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again Changes: https://git.openjdk.org/jdk19/pull/86/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=86&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289398 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/86.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/86/head:pull/86 PR: https://git.openjdk.org/jdk19/pull/86 From azvegint at openjdk.org Tue Jun 28 20:09:21 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 28 Jun 2022 20:09:21 GMT Subject: [jdk19] Integrated: 8289398: ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 19:57:46 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again. Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/86 From dcubed at openjdk.org Tue Jun 28 20:09:21 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 28 Jun 2022 20:09:21 GMT Subject: [jdk19] Integrated: 8289398: ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 19:58:45 GMT, Alexander Zvegintsev wrote: >> A trivial fix to ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again. > > Marked as reviewed by azvegint (Reviewer). @azvegint - Thanks for the fast review! ------------- PR: https://git.openjdk.org/jdk19/pull/86 From dcubed at openjdk.org Tue Jun 28 20:09:22 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 28 Jun 2022 20:09:22 GMT Subject: [jdk19] Integrated: 8289398: ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again In-Reply-To: References: Message-ID: <76mVudZeAmSX8Ajef9WJOCfe0RByJd8-8Ueer5CTITM=.72096749-b6ca-4583-97f3-9557bf1aa802@github.com> On Tue, 28 Jun 2022 19:57:46 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again. This pull request has now been integrated. Changeset: 15048048 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk19/commit/1504804896ff099aa23fa05336537dd78e6e2311 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8289398: ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again Reviewed-by: azvegint ------------- PR: https://git.openjdk.org/jdk19/pull/86 From duke at openjdk.org Tue Jun 28 23:39:54 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Tue, 28 Jun 2022 23:39:54 GMT Subject: Integrated: 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test In-Reply-To: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> References: <9P8lxMMykiI4u92hcrRJgspHEaXGmJMYSic3ZILcyBw=.573f19be-90dd-4831-bab3-c9a45c618c50@github.com> Message-ID: On Fri, 10 Jun 2022 10:20:38 GMT, KIRIYAMA Takuya wrote: > I would like to fix 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test. > > FlightRecorder option has not been tested since JDK13. > I think we should test it, because FlightRecorder option has not been obsolete in the latest JDK. > Users would be in trouble if the option suddenly disappears without notice, > so it's important to confirm the deprication message. > > Also we should add a test of ExtendedDTraceProbes option. > The test was disabled in 8281675, because some jdk can't specify it. > I modified the test to be able to verify ExtendedDTraceProbes in either case that DTRACE_ENABLED is enabled or not. This pull request has now been integrated. Changeset: 910053b7 Author: KIRIYAMA Takuya Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/910053b74ec5249b3ecae33b9b0b0a68729ef418 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod 8280235: Deprecated flag FlightRecorder missing from VMDeprecatedOptions test Reviewed-by: dholmes, mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/9123 From cjplummer at openjdk.org Tue Jun 28 23:53:47 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 28 Jun 2022 23:53:47 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v5] In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 13:13:51 GMT, Zhengyu Gu wrote: >> Currently, jdi only check and process class unloading event when it detects a new GC cycle. >> >> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. >> >> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. >> >> It also performs `commonRef_compact()` only when there are classes unloaded. >> >> New test failed about 20% without patch, none with patch. >> >> **Update** >> There are significant changes from early patch. >> >> The new approach: >> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: >> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state >> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state >> >> The new solution breaks up into two steps: >> - Collect all dead object tags with lock >> - Transition to `_in_native` state and post object free events in one batch >> >> This way, JDI event handler can process object free events upon arrivals without delay. >> >> **Update 2** >> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks. >> >> // This checks for posting and rehashing before operations that >> // this tagmap table. The calls from a JavaThread only rehash, posting is >> // only done before heap walks. >> void JvmtiTagMap::check_hashmap(bool post_events) { >> >> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. >> Even the events are posted earlier in old code, but they are only processed after next GC cycle. > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Renamed eventHandler_synthesizeUnloadEvent It looks like TestClassUnloadEvents is failing on Windows-x64: https://github.com/openjdk/jdk/pull/9168/checks?check_run_id=7102500258 ------------- PR: https://git.openjdk.org/jdk/pull/9168 From cjplummer at openjdk.org Tue Jun 28 23:53:45 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 28 Jun 2022 23:53:45 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v3] In-Reply-To: References: <9DXhiJashhHzVprdaDkeueDpLbjylMSOyu3ROEcoexs=.0a646a14-4168-43f0-bbe5-6d48e829dad5@github.com> Message-ID: <_xLbKhB67g8d6KP_P2clv-LpvLYsx7QeEqZG6VWrQS0=.21bc6873-53c3-4ac7-ac08-c70f823f0d95@github.com> On Mon, 27 Jun 2022 19:08:51 GMT, Zhengyu Gu wrote: > > You should also remove the following from the hotspot ProblemList.txt: > > `vmTestbase/nsk/jdi/HiddenClass/events/events001.java 8257705 generic-all` > > Try to reproduce without your fix, and then verify your fix is addressing the failure. > > I did test it locally, unless you want to make [JDK-8257705](https://bugs.openjdk.org/browse/JDK-8257705) a duplicate? JDK-8257705 is a duplicate. I just want to make sure it is getting fixed by your changes and is removed from the problem list. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From cjplummer at openjdk.org Tue Jun 28 23:57:47 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 28 Jun 2022 23:57:47 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v5] In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 13:13:51 GMT, Zhengyu Gu wrote: >> Currently, jdi only check and process class unloading event when it detects a new GC cycle. >> >> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. >> >> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. >> >> It also performs `commonRef_compact()` only when there are classes unloaded. >> >> New test failed about 20% without patch, none with patch. >> >> **Update** >> There are significant changes from early patch. >> >> The new approach: >> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: >> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state >> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state >> >> The new solution breaks up into two steps: >> - Collect all dead object tags with lock >> - Transition to `_in_native` state and post object free events in one batch >> >> This way, JDI event handler can process object free events upon arrivals without delay. >> >> **Update 2** >> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks. >> >> // This checks for posting and rehashing before operations that >> // this tagmap table. The calls from a JavaThread only rehash, posting is >> // only done before heap walks. >> void JvmtiTagMap::check_hashmap(bool post_events) { >> >> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. >> Even the events are posted earlier in old code, but they are only processed after next GC cycle. > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Renamed eventHandler_synthesizeUnloadEvent I didn't see any response to my suggested improvements to the test. Can you please comment on them and update the test if you agree? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From dcubed at openjdk.org Wed Jun 29 01:20:41 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 29 Jun 2022 01:20:41 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v2] In-Reply-To: References: Message-ID: <3EFRe4pOZsh6rT3HrofXT5ju9Esx0sFnRADYyjlmees=.25929130-740a-4f53-b7a5-90ac4e55f075@github.com> On Mon, 27 Jun 2022 22:50:48 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> dholmes CR - check if current thread's oop access is safe. > > Sorry Dan have to revoke my approval. There are still some issues here that need fixing and I don't like the impact on the code. @dholmes-ora - please re-review when you get the chance. Mach5 Tier[1-4] has passed and Tier[5-7] are running along nicely. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From dholmes at openjdk.org Wed Jun 29 02:38:51 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 29 Jun 2022 02:38:51 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v2] In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 13:41:01 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/thread.cpp line 2151: >> >>> 2149: st->print("%s \"%s\"", type_name(), get_thread_name_string(buf, buflen)); >>> 2150: Thread* current = Thread::current_or_null(); >>> 2151: if (current != nullptr && (!current->is_Java_thread() || JavaThread::cast(current)->is_oop_safe())) { >> >> Just realized, we can't have a null current thread if we are calling this as that is checked at a higher level. But we should be using `current_or_null_safe()` here as we could be in a signal-handling context. > > I used `Thread::current_or_null()` just to make the code more bullet proof. In all of > my testing I never ran into a case where `Thread::current()` returned `nullptr`. > I'm going to switch back to `Thread::current()` and remove the extra handling for > the `current == nullptr` case. If the code can be invoked in the context of a signal handler, as can happen for the error reporting path, then you must use `Thread::current_or_null_safe()` or risk introducing a deadlock or secondary crash. It occurs to me that this may mean the existing safety-check is not correct because it may end up being checked in that context too. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From dholmes at openjdk.org Wed Jun 29 02:46:55 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 29 Jun 2022 02:46:55 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v2] In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 13:50:51 GMT, Daniel D. Daugherty wrote: > The reason that this particular handling of a secondary failure is important is that a secondary failure in printing the name of the failing thread will prevent entries for following threads from being printed in the thread list in the hs_err_pid file. Yes I realise that a secondary crash loses some information, but my contention is that: a) the likelihood of crashing after detaching the GC barrier is very, very small; and b) in such a crash it is only the crashing thread that is really of interest, not the other threads in the system So to me trying to make secondary crash handling more robust in the current case is not worth the cost of the extra checks. If the checks were only in the crash reporting path then that would be okay, but not when they impact normal code execution. Sorry. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From dholmes at openjdk.org Wed Jun 29 02:46:58 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 29 Jun 2022 02:46:58 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v3] In-Reply-To: <8sp27hzKOw7yBIWssa7M-0rFg-cCsbQbCRZ8E44t3tY=.920eddc4-55c0-48a2-aae5-c63cffcf3cfd@github.com> References: <8sp27hzKOw7yBIWssa7M-0rFg-cCsbQbCRZ8E44t3tY=.920eddc4-55c0-48a2-aae5-c63cffcf3cfd@github.com> Message-ID: On Tue, 28 Jun 2022 16:55:29 GMT, Daniel D. Daugherty wrote: >> A trivial move of the oop safety check from SharedRuntime::get_java_tid() to >> JavaThread::threadObj(). Also made adjustments to the threadObj() calls in >> JavaThread::print_on_error() and JavaThread::get_thread_name_string() so >> that we don't get secondary crashes when a JavaThread crashes after it has >> detached the GC barrier. >> >> Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR - use Thread::current() instead of Thread::current_or_null(). src/hotspot/share/runtime/thread.cpp line 2153: > 2151: if (!current->is_Java_thread() || JavaThread::cast(current)->is_oop_safe()) { > 2152: // Only access threadObj() if current thread is not a JavaThread > 2153: // or if it is a JavaThread that can safely access oops. How can a non-JavaThread safely access the oop? Is the only safe case the VMThread at a safepoint? ------------- PR: https://git.openjdk.org/jdk19/pull/69 From stuefe at openjdk.org Wed Jun 29 04:13:43 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 29 Jun 2022 04:13:43 GMT Subject: RFR: JDK-8289182: NMT: MemTracker::baseline should return void [v2] In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 13:47:46 GMT, Zhengyu Gu wrote: >> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> let MemTracker::baseline return void > > LGTM Thanks @zhengyu123 and @dholmes-ora ------------- PR: https://git.openjdk.org/jdk/pull/9288 From stuefe at openjdk.org Wed Jun 29 04:16:34 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 29 Jun 2022 04:16:34 GMT Subject: Integrated: JDK-8289182: NMT: MemTracker::baseline should return void In-Reply-To: References: Message-ID: <8Ty3NqBVaxuLUqRnjJ6OSiN4LnFLrmW-lpI-9cNUCrI=.00679892-1597-4901-878d-b1f1aee6a43c@github.com> On Sat, 25 Jun 2022 06:25:37 GMT, Thomas Stuefe wrote: > Small cleanup. > > Since MemTracker::baseline() only returns true, it can revert to void, and error handling can be removed from all callers. This pull request has now been integrated. Changeset: b96ba198 Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/b96ba19807845739b36274efb168dd048db819a3 Stats: 47 lines in 8 files changed: 0 ins; 11 del; 36 mod 8289182: NMT: MemTracker::baseline should return void Reviewed-by: dholmes, zgu ------------- PR: https://git.openjdk.org/jdk/pull/9288 From stuefe at openjdk.org Wed Jun 29 06:40:47 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 29 Jun 2022 06:40:47 GMT Subject: RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong [v5] In-Reply-To: References: Message-ID: <_Tie8F_4wQKMyJesfie8UfyUlCBfOVmOhL9Lc4Q_nhE=.e8cdbe87-3b66-4528-b95b-e35b3d5e35c5@github.com> On Mon, 27 Jun 2022 08:15:01 GMT, Yi Yang wrote: >> It seems that calculation of MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. >> >> Currently, `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` >> >> ==> CodeHeap 'non-nmethods' 1532544 (Used) >> ==> CodeHeap 'profiled nmethods' 0 >> ==> CodeHeap 'non-profiled nmethods' 13952 >> ==> Metaspace 506696 >> ==> Compressed Class Space 43312 >> init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = -1(-1K) >> >> In this way, getNonHeapMemoryUsage is larger than it ought to be, it should be `NonHeapUsage = CodeCache + Metaspace`. > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > address @tstuefe's comments; remove unnecessary declaration I think @iklam meant something somewhat different. Since we remove the class space bean, we now need to rewrite those tests using that bean. Lets say we create the following whitebox APIs - long WB_getClassSpaceUsage - long WB_getClassSpaceCommitted Maybe also (to be symmetric, and to not have to mix bean code and this code in test/hotspot/jtreg/vmTestbase/metaspace/gc/MemoryUsageTest.java: - long WB_getMetaSpaceUsage - long WB_getMetaSpaceCommitted Maybe also: - boolean WB_usesClassSpace() - long WB_classSpaceMax() though these can easily be implemented using existing whitebox method (there is one to get VM flags, so you could get `UseCompressedClassPointers` and `CompressedClassSpaceSize` instead. Now: - In test/hotspot/jtreg/vmTestbase/metaspace/gc/MemoryUsageTest.java, you don't use beans anymore but those functions. You'd rewrite "getUsed()" and "getCommitted()" to use the new whitebox functions. - In metaspce/ShrinkGrowTest, the bean is only used to confirm that class space is active. You can use WB_usesClassSpace for that, or the value of "UseCompressedClassPointers" flag. - In test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/gc/lotsOfCallSites/Test.java, we use Compressed Class Bean to get Compressed Class usage and maximum size. YHere, you would have to exchange `classMetadataPoolMXB.getUsage();` with `WB_getClassSpaceUsage()` and `classMetadataPoolMXB.getUsage();` with `CompressedClassSpaceSize` ---- Note that since this RFR really grew in complexity compared to what you wanted to do originally, I'd be fine with dropping it altogether. If we continue, I think above proposal is the simplest way to go. src/hotspot/share/services/memoryPool.cpp line 188: > 186: > 187: // Note, any NonHeap pools would be counted into Non-Heap memory by MemoryMXBean.getNonHeapMemoryUsage. > 188: // Make sure that it behaves as you expected if you want to add a new type of NonHeap pool This comment is somewhat cryptic. Behave like what? src/hotspot/share/services/memoryPool.cpp line 189: > 187: // Note, any NonHeap pools would be counted into Non-Heap memory by MemoryMXBean.getNonHeapMemoryUsage. > 188: // Make sure that it behaves as you expected if you want to add a new type of NonHeap pool > 189: MetaspacePool::MetaspacePool() : Can you please add a comment like "Accounts for Metaspace (both class space and non-class space). Max usage is MaxMetaspaceSize. Current usage includes prematurely freed blocks. As far as this API is concerned, CompressedClassSpaceSize is ignored." test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp/GarbageUtils.java line 53: > 51: ANY (), > 52: HEAP("Java heap space"), > 53: METASPACE("Metaspace"); This chance is wrong, I think. We still have class space OOMEs. ------------- Changes requested by stuefe (Reviewer). PR: https://git.openjdk.org/jdk/pull/8831 From mbaesken at openjdk.org Wed Jun 29 07:53:57 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 29 Jun 2022 07:53:57 GMT Subject: RFR: JDK-8289146: containers/docker/TestMemoryWithCgroupV1.java fails on linux ppc64le machine with missing Memory and Swap Limit output Message-ID: On Linux ppc64le machines , the test fails with stderr: [WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap. ] exitValue = 0 java.lang.RuntimeException: 'Memory and Swap Limit is: 157286400' missing from stdout/stderr at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:221) at TestMemoryWithCgroupV1.testMemoryLimitWithSwappiness(TestMemoryWithCgroupV1.java:84) at TestMemoryWithCgroupV1.main(TestMemoryWithCgroupV1.java:61) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) at java.base/java.lang.Thread.run(Thread.java:1596) This is most likely related to "kernel does not support swap limit capabilities", we've seen similar issues on other Linux ppc64 le machines in some tests before. So there needs to be some special handling added to the test for the case without kernel swap limit capabilities. ------------- Commit messages: - JDK-8289146 Changes: https://git.openjdk.org/jdk/pull/9319/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9319&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289146 Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9319.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9319/head:pull/9319 PR: https://git.openjdk.org/jdk/pull/9319 From sgehwolf at openjdk.org Wed Jun 29 12:22:40 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 29 Jun 2022 12:22:40 GMT Subject: RFR: JDK-8289146: containers/docker/TestMemoryWithCgroupV1.java fails on linux ppc64le machine with missing Memory and Swap Limit output In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 07:47:20 GMT, Matthias Baesken wrote: > On Linux ppc64le machines , the test fails with > > stderr: [WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap. > ] > exitValue = 0 > > java.lang.RuntimeException: 'Memory and Swap Limit is: 157286400' missing from stdout/stderr > > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:221) > at TestMemoryWithCgroupV1.testMemoryLimitWithSwappiness(TestMemoryWithCgroupV1.java:84) > at TestMemoryWithCgroupV1.main(TestMemoryWithCgroupV1.java:61) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:1596) > > This is most likely related to "kernel does not support swap limit capabilities", > we've seen similar issues on other Linux ppc64 le machines in some tests before. > So there needs to be some special handling added to the test for the case without kernel swap limit capabilities. Looks fine. It matches what we do elsewhere in container tests. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.org/jdk/pull/9319 From mdoerr at openjdk.org Wed Jun 29 12:28:44 2022 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 29 Jun 2022 12:28:44 GMT Subject: RFR: JDK-8289146: containers/docker/TestMemoryWithCgroupV1.java fails on linux ppc64le machine with missing Memory and Swap Limit output In-Reply-To: References: Message-ID: <3TgRCqctX85MuOzFKowpBtdBr0_UMK82bzfIJYcoZs0=.a0a33ed9-df27-4a16-9451-a2a5f20f6aa6@github.com> On Wed, 29 Jun 2022 07:47:20 GMT, Matthias Baesken wrote: > On Linux ppc64le machines , the test fails with > > stderr: [WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap. > ] > exitValue = 0 > > java.lang.RuntimeException: 'Memory and Swap Limit is: 157286400' missing from stdout/stderr > > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:221) > at TestMemoryWithCgroupV1.testMemoryLimitWithSwappiness(TestMemoryWithCgroupV1.java:84) > at TestMemoryWithCgroupV1.main(TestMemoryWithCgroupV1.java:61) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:1596) > > This is most likely related to "kernel does not support swap limit capabilities", > we've seen similar issues on other Linux ppc64 le machines in some tests before. > So there needs to be some special handling added to the test for the case without kernel swap limit capabilities. LGTM, too. Shouldn't this test get fixed in 19? ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.org/jdk/pull/9319 From zgu at openjdk.org Wed Jun 29 12:42:56 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 29 Jun 2022 12:42:56 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v5] In-Reply-To: References: Message-ID: <2iLSLgkNee5b4T1a8E9JuNxSqgLlxGtw21KWNRl2KN0=.76cfad49-1fb4-4e25-9021-2e14b0726f57@github.com> On Tue, 28 Jun 2022 23:54:20 GMT, Chris Plummer wrote: > I didn't see any response to my suggested improvements to the test. Can you please comment on them and update the test if you agree? Thanks. I am still learning JDI and not quite sure how it works. But I think it is unrelated to this CR, can we do it in a separate CR? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From zgu at openjdk.org Wed Jun 29 12:45:08 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 29 Jun 2022 12:45:08 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v6] In-Reply-To: References: Message-ID: > Currently, jdi only check and process class unloading event when it detects a new GC cycle. > > After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. > > This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. > > It also performs `commonRef_compact()` only when there are classes unloaded. > > New test failed about 20% without patch, none with patch. > > **Update** > There are significant changes from early patch. > > The new approach: > No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: > - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state > - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state > > The new solution breaks up into two steps: > - Collect all dead object tags with lock > - Transition to `_in_native` state and post object free events in one batch > > This way, JDI event handler can process object free events upon arrivals without delay. > > **Update 2** > There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks. > > // This checks for posting and rehashing before operations that > // this tagmap table. The calls from a JavaThread only rehash, posting is > // only done before heap walks. > void JvmtiTagMap::check_hashmap(bool post_events) { > > Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. > Even the events are posted earlier in old code, but they are only processed after next GC cycle. Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Removed HiddenClass test from Problem.txt and cleanup test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9168/files - new: https://git.openjdk.org/jdk/pull/9168/files/bf334b11..759e3057 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=04-05 Stats: 14 lines in 2 files changed: 0 ins; 14 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9168.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9168/head:pull/9168 PR: https://git.openjdk.org/jdk/pull/9168 From coleenp at openjdk.org Wed Jun 29 14:36:49 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 29 Jun 2022 14:36:49 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v3] In-Reply-To: <8sp27hzKOw7yBIWssa7M-0rFg-cCsbQbCRZ8E44t3tY=.920eddc4-55c0-48a2-aae5-c63cffcf3cfd@github.com> References: <8sp27hzKOw7yBIWssa7M-0rFg-cCsbQbCRZ8E44t3tY=.920eddc4-55c0-48a2-aae5-c63cffcf3cfd@github.com> Message-ID: On Tue, 28 Jun 2022 16:55:29 GMT, Daniel D. Daugherty wrote: >> A trivial move of the oop safety check from SharedRuntime::get_java_tid() to >> JavaThread::threadObj(). Also made adjustments to the threadObj() calls in >> JavaThread::print_on_error() and JavaThread::get_thread_name_string() so >> that we don't get secondary crashes when a JavaThread crashes after it has >> detached the GC barrier. >> >> Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR - use Thread::current() instead of Thread::current_or_null(). src/hotspot/share/runtime/thread.cpp line 2151: > 2149: st->print("%s \"%s\"", type_name(), get_thread_name_string(buf, buflen)); > 2150: Thread* current = Thread::current(); > 2151: if (!current->is_Java_thread() || JavaThread::cast(current)->is_oop_safe()) { This is really tricky. Why not have threadObj() return null if this is happening. Then you can say why in that function. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From zgu at openjdk.org Wed Jun 29 15:35:42 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 29 Jun 2022 15:35:42 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v5] In-Reply-To: References: Message-ID: On Tue, 28 Jun 2022 23:51:20 GMT, Chris Plummer wrote: > It looks like TestClassUnloadEvents is failing on Windows-x64: https://github.com/openjdk/jdk/pull/9168/checks?check_run_id=7102500258 Thanks for pointing out. I could not reproduce locally so far, but continue debugging it. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From zgu at openjdk.org Wed Jun 29 15:35:41 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 29 Jun 2022 15:35:41 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v7] In-Reply-To: References: Message-ID: > Currently, jdi only check and process class unloading event when it detects a new GC cycle. > > After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. > > This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. > > It also performs `commonRef_compact()` only when there are classes unloaded. > > New test failed about 20% without patch, none with patch. > > **Update** > There are significant changes from early patch. > > The new approach: > No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: > - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state > - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state > > The new solution breaks up into two steps: > - Collect all dead object tags with lock > - Transition to `_in_native` state and post object free events in one batch > > This way, JDI event handler can process object free events upon arrivals without delay. > > **Update 2** > There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks. > > // This checks for posting and rehashing before operations that > // this tagmap table. The calls from a JavaThread only rehash, posting is > // only done before heap walks. > void JvmtiTagMap::check_hashmap(bool post_events) { > > Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. > Even the events are posted earlier in old code, but they are only processed after next GC cycle. Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Adding log for debugging test failure on Windows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9168/files - new: https://git.openjdk.org/jdk/pull/9168/files/759e3057..0b74710f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=05-06 Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9168.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9168/head:pull/9168 PR: https://git.openjdk.org/jdk/pull/9168 From stuefe at openjdk.org Wed Jun 29 17:19:17 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 29 Jun 2022 17:19:17 GMT Subject: RFR: JDK-8289477: Memory corruption caused by CPU_ALLOC, CPU_FREE on muslc Message-ID: In `os::Linux::active_processor_count()`, we use the CPU_xxx macros to manage sets of CPU information. muslc defines those macros to call `calloc(3)` and `free(3)`: #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n))) #define CPU_FREE(set) free(set) whereas glibc uses intermediate functions: #define __CPU_ALLOC(count) __sched_cpualloc (count) #define __CPU_FREE(cpuset) __sched_cpufree (cpuset) which in the end also takes from C-heap, but those calls are not inlined. So, on muslc we call `calloc()` and `free()`. Call happens inside the `os::Linux` namespace, `free()` resolves to `os::free()`. We have no wrapper in os for calloc though, so `calloc()` calls into muslc right away. That means we have raw ::malloc() -> os::free(), which is unbalanced. Raw `::malloc()` does not write the header `os::free()` expects. If NMT is on, we assert now, because NMT does not find its header in os::free(). This can be very easily reproduced by starting an Alpine VM with NMT on (or, a debug VM) and ` -XX:+UnlockDiagnosticVMOptions -XX:+UseCpuAllocPath`. The position of the musl devs is that "calloc" and "free" are reserved words in C, and should not be used [1]. I think they are right. The way we reuse known C- and Posix symbol names in the os namespace has bitten me in the past in similar cases. ------ The fix is minimally invasive for easy backporting. I just move the content of `os::Linux::active_processor_count()` into its own local function, outside the os namespace. That way, CPU_FREE cannot pick up `os::free()` accidentally, and the error is fixed. I really would like a more thorough solution though, renaming all the potential conflict candidates, but leave that for a follow-up RFE. [1] https://www.openwall.com/lists/musl/2022/06/29/3 ------------- Commit messages: - move CPU_xxx calls outside the os:: namespace Changes: https://git.openjdk.org/jdk/pull/9328/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9328&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289477 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9328.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9328/head:pull/9328 PR: https://git.openjdk.org/jdk/pull/9328 From zgu at openjdk.org Wed Jun 29 18:09:18 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 29 Jun 2022 18:09:18 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v8] In-Reply-To: References: Message-ID: > Currently, jdi only check and process class unloading event when it detects a new GC cycle. > > After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. > > This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. > > It also performs `commonRef_compact()` only when there are classes unloaded. > > New test failed about 20% without patch, none with patch. > > **Update** > There are significant changes from early patch. > > The new approach: > No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: > - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state > - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state > > The new solution breaks up into two steps: > - Collect all dead object tags with lock > - Transition to `_in_native` state and post object free events in one batch > > This way, JDI event handler can process object free events upon arrivals without delay. > > **Update 2** > There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks. > > // This checks for posting and rehashing before operations that > // this tagmap table. The calls from a JavaThread only rehash, posting is > // only done before heap walks. > void JvmtiTagMap::check_hashmap(bool post_events) { > > Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. > Even the events are posted earlier in old code, but they are only processed after next GC cycle. Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: debug test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9168/files - new: https://git.openjdk.org/jdk/pull/9168/files/0b74710f..4a2f49e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9168.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9168/head:pull/9168 PR: https://git.openjdk.org/jdk/pull/9168 From dcubed at openjdk.org Wed Jun 29 18:26:36 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 29 Jun 2022 18:26:36 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v3] In-Reply-To: References: <8sp27hzKOw7yBIWssa7M-0rFg-cCsbQbCRZ8E44t3tY=.920eddc4-55c0-48a2-aae5-c63cffcf3cfd@github.com> Message-ID: On Wed, 29 Jun 2022 02:43:29 GMT, David Holmes wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> dholmes CR - use Thread::current() instead of Thread::current_or_null(). > > src/hotspot/share/runtime/thread.cpp line 2153: > >> 2151: if (!current->is_Java_thread() || JavaThread::cast(current)->is_oop_safe()) { >> 2152: // Only access threadObj() if current thread is not a JavaThread >> 2153: // or if it is a JavaThread that can safely access oops. > > How can a non-JavaThread safely access the oop? Is the only safe case the VMThread at a safepoint? The purpose of the `if (!current->is_Java_thread() ||` part of the if-statement is to allow the code to work as it did before for the non-JavaThread case. Before this fix, if a non-JavaThread called into this code, then it was allowed to execute this code. I've preserved that behavior and I've see no failures that indicate that this is a problem. Do I know what non-JavaThreads might wander in here? No I don't. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From dcubed at openjdk.org Wed Jun 29 18:26:36 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 29 Jun 2022 18:26:36 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v3] In-Reply-To: References: <8sp27hzKOw7yBIWssa7M-0rFg-cCsbQbCRZ8E44t3tY=.920eddc4-55c0-48a2-aae5-c63cffcf3cfd@github.com> Message-ID: On Wed, 29 Jun 2022 14:32:54 GMT, Coleen Phillimore wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> dholmes CR - use Thread::current() instead of Thread::current_or_null(). > > src/hotspot/share/runtime/thread.cpp line 2151: > >> 2149: st->print("%s \"%s\"", type_name(), get_thread_name_string(buf, buflen)); >> 2150: Thread* current = Thread::current(); >> 2151: if (!current->is_Java_thread() || JavaThread::cast(current)->is_oop_safe()) { > > This is really tricky. Why not have threadObj() return null if this is happening. Then you can say why in that function. The purpose of the guarantee() in threadObj() is catch bad calls to threadObj() that a thread makes after it has passed the GC barrier detach point. Returning nullptr from threadObj() would defeat this purpose. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From dcubed at openjdk.org Wed Jun 29 18:43:38 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 29 Jun 2022 18:43:38 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v2] In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 02:40:41 GMT, David Holmes wrote: >> @dholmes-ora - Thanks for the re-review. I'm going to update the fix again and >> switch back to using `Thread::current()` instead of `Thread::current_or_null()`. >> >> The reason that this particular handling of a secondary failure is important is >> that a secondary failure in printing the name of the failing thread will prevent >> entries for following threads from being printed in the thread list in the hs_err_pid >> file. >> >> Here's an example to show placement: >> >> Java Threads: ( => current thread ) >> 0x00007fd64d808a00 JavaThread "Unknown thread" [_thread_blocked, id=7427, stack(0x0000700003c18000,0x0000700003d18000)] >> 0x00007fd64e80d400 JavaThread "Unknown thread" [_thread_blocked, id=43011, stack(0x0000700004433000,0x0000700004533000)] >> 0x00007fd64e80e200 JavaThread "Unknown thread" [_thread_blocked, id=42755, stack(0x0000700004536000,0x0000700004636000)] >> 0x00007fd64e80e800 JavaThread "Unknown thread" [_thread_blocked, id=42243, stack(0x0000700004639000,0x0000700004739000)] >> 0x00007fd64e80ee00 JavaThread "Unknown thread" [_thread_blocked, id=22787, stack(0x000070000473c000,0x000070000483c000)] >> 0x00007fd64e80f400 JavaThread "Unknown thread" [_thread_blocked, id=41731, stack(0x000070000483f000,0x000070000493f000)] >> 0x00007fd64e81e800 JavaThread "Unknown thread" [_thread_blocked, id=41219, stack(0x0000700004942000,0x0000700004a42000)] >> 0x00007fd64e81ee00 JavaThread "Unknown thread" [_thread_blocked, id=23299, stack(0x0000700004a45000,0x0000700004b45000)] >> 0x00007fd650819000 JavaThread "Unknown thread" [_thread_blocked, id=40451, stack(0x0000700004b48000,0x0000700004c48000)] >> 0x00007fd64e851400 JavaThread "Unknown thread" [_thread_blocked, id=23811, stack(0x0000700004c4b000,0x0000700004d4b000)] >> 0x00007fd64d84e200 JavaThread "Unknown thread" [_thread_blocked, id=24067, stack(0x0000700004e51000,0x0000700004f51000)] >> 0x00007fd64e81c600 JavaThread "Unknown thread" [_thread_blocked, id=39171, stack(0x0000700004f54000,0x0000700005054000)] _threads_hazard_ptr=0x00007fd64e0041b0 >> 0x00007fd64d80d000 JavaThread "Unknown thread" [_thread_blocked, id=38915, stack(0x0000700005057000,0x0000700005157000)] >> =>0x00007fd650812000 JavaThread "" [_thread_in_vm, id=24835, stack(0x000070000515a000,0x000070000525a000)] >> >> >> The entry prefixed with "=>" is the crashing thread that is past the GC barrier >> detach point. In this example, it happens to be the last thread in the `Java Threads: >> ( => current thread )` section of the hs_err_pid file. However, if the failing thread >> happened to be earlier in the list and we didn't prevent the secondary error, then >> we would be missing entries from the section. > >> The reason that this particular handling of a secondary failure is important is > that a secondary failure in printing the name of the failing thread will prevent > entries for following threads from being printed in the thread list in the hs_err_pid > file. > > Yes I realise that a secondary crash loses some information, but my contention is that: > > a) the likelihood of crashing after detaching the GC barrier is very, very small; and > b) in such a crash it is only the crashing thread that is really of interest, not the other threads in the system > > So to me trying to make secondary crash handling more robust in the current case is not worth the cost of the extra checks. If the checks were only in the crash reporting path then that would be okay, but not when they impact normal code execution. Sorry. @dholmes-ora - I'm very glad that I resisted putting the check in `threadObj()` when I made the changes for: [JDK-8288139](https://bugs.openjdk.org/browse/JDK-8288139) JavaThread touches oop after GC barrier is detached The review for that PR took too long and clearly this discussion would have made it take longer. JDK-8288139 is fixed and Zhengyu can make progress on his issue. I don't see a good way to make forward progress in this PR. It doesn't look like you and I will reach a solution that's acceptable to both of us. The only good news is that my many rounds of testing on this fix have convinced me threadObj() is not being abused in the current code base except for the very narrow case where we crash (for whatever reason) after the GC barrier is detached. Should the GC team chose to put in an appropriate trap in their code that catches a thread accessing an oop after the GC barrier is detached, then threadObj() will be automatically sanity checked by that code. Thanks for your time in doing several rounds of review. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From zgu at openjdk.org Wed Jun 29 19:14:39 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 29 Jun 2022 19:14:39 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v9] In-Reply-To: References: Message-ID: > Currently, jdi only check and process class unloading event when it detects a new GC cycle. > > After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. > > This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. > > It also performs `commonRef_compact()` only when there are classes unloaded. > > New test failed about 20% without patch, none with patch. > > **Update** > There are significant changes from early patch. > > The new approach: > No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: > - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state > - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state > > The new solution breaks up into two steps: > - Collect all dead object tags with lock > - Transition to `_in_native` state and post object free events in one batch > > This way, JDI event handler can process object free events upon arrivals without delay. > > **Update 2** > There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks. > > // This checks for posting and rehashing before operations that > // this tagmap table. The calls from a JavaThread only rehash, posting is > // only done before heap walks. > void JvmtiTagMap::check_hashmap(bool post_events) { > > Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. > Even the events are posted earlier in old code, but they are only processed after next GC cycle. Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Use Shenandoah GC for debuggee for deterministic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9168/files - new: https://git.openjdk.org/jdk/pull/9168/files/4a2f49e8..1c91f24c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9168.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9168/head:pull/9168 PR: https://git.openjdk.org/jdk/pull/9168 From iklam at openjdk.org Wed Jun 29 20:50:26 2022 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 29 Jun 2022 20:50:26 GMT Subject: RFR: JDK-8289146: containers/docker/TestMemoryWithCgroupV1.java fails on linux ppc64le machine with missing Memory and Swap Limit output In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 07:47:20 GMT, Matthias Baesken wrote: > On Linux ppc64le machines , the test fails with > > stderr: [WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap. > ] > exitValue = 0 > > java.lang.RuntimeException: 'Memory and Swap Limit is: 157286400' missing from stdout/stderr > > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:221) > at TestMemoryWithCgroupV1.testMemoryLimitWithSwappiness(TestMemoryWithCgroupV1.java:84) > at TestMemoryWithCgroupV1.main(TestMemoryWithCgroupV1.java:61) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) > at java.base/java.lang.Thread.run(Thread.java:1596) > > This is most likely related to "kernel does not support swap limit capabilities", > we've seen similar issues on other Linux ppc64 le machines in some tests before. > So there needs to be some special handling added to the test for the case without kernel swap limit capabilities. Changes requested by iklam (Reviewer). test/hotspot/jtreg/containers/docker/TestMemoryWithCgroupV1.java line 94: > 92: } catch (RuntimeException ex) { > 93: out.shouldMatch("Memory and Swap Limit is: [0-9]+"); > 94: } With the `catch` clause added, it looks like the tests inside the `try` block don't do anything anymore, even on a host where the kernel actually supports swap limit capabilities. Maybe the correct way to handle this is: if "Your kernel does not support memory swappiness capabilities or the cgroup is not mounted." is in the output, then skip the test inside the `try` block? ------------- PR: https://git.openjdk.org/jdk/pull/9319 From cjplummer at openjdk.org Wed Jun 29 22:36:45 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 29 Jun 2022 22:36:45 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v5] In-Reply-To: <2iLSLgkNee5b4T1a8E9JuNxSqgLlxGtw21KWNRl2KN0=.76cfad49-1fb4-4e25-9021-2e14b0726f57@github.com> References: <2iLSLgkNee5b4T1a8E9JuNxSqgLlxGtw21KWNRl2KN0=.76cfad49-1fb4-4e25-9021-2e14b0726f57@github.com> Message-ID: On Wed, 29 Jun 2022 12:40:42 GMT, Zhengyu Gu wrote: > > I didn't see any response to my suggested improvements to the test. Can you please comment on them and update the test if you agree? Thanks. > > I am still learning JDI and not quite sure how it works. But I think it is unrelated to this CR, can we do it in a separate CR? Thanks. I'd like it done as part of this CR so we can be sure we are properly understanding how/when CLASS_UNLOADS events are sent and grouped, and to make sure there is no behavior change. I can apply your patch and then modify the test if you'd like. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From cjplummer at openjdk.org Wed Jun 29 22:49:50 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 29 Jun 2022 22:49:50 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v9] In-Reply-To: References: Message-ID: <9gGXw8F25KgjQ3a_8GqPAUJWwkxIsPdXBKZ8bTnGJL4=.7f0197c7-0176-49a1-8fd1-0434ed36714a@github.com> On Wed, 29 Jun 2022 19:14:39 GMT, Zhengyu Gu wrote: >> Currently, jdi only check and process class unloading event when it detects a new GC cycle. >> >> After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. >> >> This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. >> >> It also performs `commonRef_compact()` only when there are classes unloaded. >> >> New test failed about 20% without patch, none with patch. >> >> **Update** >> There are significant changes from early patch. >> >> The new approach: >> No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: >> - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state >> - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state >> >> The new solution breaks up into two steps: >> - Collect all dead object tags with lock >> - Transition to `_in_native` state and post object free events in one batch >> >> This way, JDI event handler can process object free events upon arrivals without delay. >> >> **Update 2** >> There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks. >> >> // This checks for posting and rehashing before operations that >> // this tagmap table. The calls from a JavaThread only rehash, posting is >> // only done before heap walks. >> void JvmtiTagMap::check_hashmap(bool post_events) { >> >> Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. >> Even the events are posted earlier in old code, but they are only processed after next GC cycle. > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Use Shenandoah GC for debuggee for deterministic I just noticed the test is being added to a newly created hotspot/jtreg/serviciability/jdi directory. It should be placed in one of the existing jdi test locations, either nsk/jdi or jdk/com/sun/jdi. I think the latter would be better and it can leverage TestScaffold. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From dcubed at openjdk.org Wed Jun 29 23:46:45 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 29 Jun 2022 23:46:45 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v3] In-Reply-To: <8sp27hzKOw7yBIWssa7M-0rFg-cCsbQbCRZ8E44t3tY=.920eddc4-55c0-48a2-aae5-c63cffcf3cfd@github.com> References: <8sp27hzKOw7yBIWssa7M-0rFg-cCsbQbCRZ8E44t3tY=.920eddc4-55c0-48a2-aae5-c63cffcf3cfd@github.com> Message-ID: On Tue, 28 Jun 2022 16:55:29 GMT, Daniel D. Daugherty wrote: >> A trivial move of the oop safety check from SharedRuntime::get_java_tid() to >> JavaThread::threadObj(). Also made adjustments to the threadObj() calls in >> JavaThread::print_on_error() and JavaThread::get_thread_name_string() so >> that we don't get secondary crashes when a JavaThread crashes after it has >> detached the GC barrier. >> >> Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR - use Thread::current() instead of Thread::current_or_null(). Just to be clear: @dholmes-ora wrote above: > So to me trying to make secondary crash handling more robust in the current case > is not worth the cost of the extra checks. If the checks were only in the crash > reporting path then that would be okay, but not when they impact normal code > execution. Sorry. The code we're arguing about is in `JavaThread::get_thread_name_string()` and when you look at the PR with white space changes disabled, you'll see this new code which is executed in the "normal code" case: Thread* current = Thread::current(); if (!current->is_Java_thread() || JavaThread::cast(current)->is_oop_safe()) { // Only access threadObj() if current thread is not a JavaThread // or if it is a JavaThread that can safely access oops. which is one Thread::current() call and one if-statement. There is also this new code block that's only executed in the error case: } else { // Current JavaThread has exited... if (current == this) { // ... and is asking about itself: name_str = ""; } else { // ... and it can't safely determine this JavaThread's name so // use the default thread name. name_str = Thread::name(); } } so none of the else-block matters in the "normal code" case. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From zgu at openjdk.org Thu Jun 30 00:34:29 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 30 Jun 2022 00:34:29 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v5] In-Reply-To: References: <2iLSLgkNee5b4T1a8E9JuNxSqgLlxGtw21KWNRl2KN0=.76cfad49-1fb4-4e25-9021-2e14b0726f57@github.com> Message-ID: On Wed, 29 Jun 2022 22:33:32 GMT, Chris Plummer wrote: > > > I didn't see any response to my suggested improvements to the test. Can you please comment on them and update the test if you agree? Thanks. > > > > > > I am still learning JDI and not quite sure how it works. But I think it is unrelated to this CR, can we do it in a separate CR? Thanks. > > I'd like it done as part of this CR so we can be sure we are properly understanding how/when CLASS_UNLOADS events are sent and grouped, and to make sure there is no behavior change. I can apply your patch and then modify the test if you'd like. Okay, let me fix the test, then you can add/modify the test. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From dholmes at openjdk.org Thu Jun 30 02:00:28 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 30 Jun 2022 02:00:28 GMT Subject: RFR: JDK-8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 16:58:57 GMT, Thomas Stuefe wrote: > In `os::Linux::active_processor_count()`, we use the CPU_xxx macros to manage sets of CPU information. > > muslc defines those macros to call `calloc(3)` and `free(3)`: > > > #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n))) > #define CPU_FREE(set) free(set) > > > whereas glibc uses intermediate functions: > > > #define __CPU_ALLOC(count) __sched_cpualloc (count) > #define __CPU_FREE(cpuset) __sched_cpufree (cpuset) > > > which in the end also takes from C-heap, but those calls are not inlined. > > So, on muslc we call `calloc()` and `free()`. Call happens inside the `os::Linux` namespace, `free()` resolves to `os::free()`. We have no wrapper in os for calloc though, so `calloc()` calls into muslc right away. > > That means we have raw ::malloc() -> os::free(), which is unbalanced. Raw `::malloc()` does not write the header `os::free()` expects. If NMT is on, we assert now, because NMT does not find its header in os::free(). > > This can be very easily reproduced by starting an Alpine VM with NMT on (or, a debug VM) and ` -XX:+UnlockDiagnosticVMOptions -XX:+UseCpuAllocPath`. This causes a NMT fence alert right away: > > > NMT Block at 0x00007fc5a35db9f0, corruption at: 0x00007fc5a35db9f0: > 0x00007fc5a35db970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35db980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35db990: f8 a1 c8 1b ea 55 00 00 00 00 00 00 00 c0 00 00 > 0x00007fc5a35db9a0: 00 a4 c8 1b ea 55 00 00 01 00 00 00 00 c0 00 00 > 0x00007fc5a35db9b0: d8 a3 c8 1b ea 55 00 00 1d 00 00 00 00 a0 00 00 > 0x00007fc5a35db9c0: 2d 63 70 00 00 00 00 00 08 00 00 00 00 61 01 00 > 0x00007fc5a35db9d0: 2d 76 65 72 73 69 6f 6e 00 00 00 00 00 82 02 00 > 0x00007fc5a35db9e0: 2d 73 65 72 76 65 72 00 00 00 00 00 00 83 03 00 > 0x00007fc5a35db9f0: 2d 63 6c 69 65 6e 74 00 00 00 00 00 00 84 04 00 > 0x00007fc5a35dba00: ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/mallocTracker.cpp:151 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/ubuntu/client_home/workspace/build-user-branch-linux_alpine_x86_64/SapMachine/src/hotspot/share/services/mallocTracker.cpp:151), pid=219496, tid=219512 > > > > The position of the musl devs is that "calloc" and "free" are reserved words in C, and should not be used [1]. I think they are right. The way we reuse known C- and Posix symbol names in the os namespace has bitten me in the past in similar cases. > > ------ > > The fix is minimally invasive for easy backporting. I just move the content of `os::Linux::active_processor_count()` into its own local function, outside the os namespace. That way, CPU_FREE cannot pick up `os::free()` accidentally, and the error is fixed. > > I really would like a more thorough solution though, renaming all the potential conflict candidates, but leave that for a follow-up RFE. > > [1] https://www.openwall.com/lists/musl/2022/06/29/3 This seems to rely on the compiler not recognising that the single use of the new function could be inlined into the original. ------------- PR: https://git.openjdk.org/jdk/pull/9328 From dholmes at openjdk.org Thu Jun 30 03:06:50 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 30 Jun 2022 03:06:50 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v3] In-Reply-To: References: <8sp27hzKOw7yBIWssa7M-0rFg-cCsbQbCRZ8E44t3tY=.920eddc4-55c0-48a2-aae5-c63cffcf3cfd@github.com> Message-ID: <2ThxUnMA0ejsqflzC57IYU8SDgDiYmWQYW9oj-xS2cM=.646a84ed-c078-49dd-83be-8a0df48fa142@github.com> On Wed, 29 Jun 2022 18:22:46 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/runtime/thread.cpp line 2153: >> >>> 2151: if (!current->is_Java_thread() || JavaThread::cast(current)->is_oop_safe()) { >>> 2152: // Only access threadObj() if current thread is not a JavaThread >>> 2153: // or if it is a JavaThread that can safely access oops. >> >> How can a non-JavaThread safely access the oop? Is the only safe case the VMThread at a safepoint? > > The purpose of the `if (!current->is_Java_thread() ||` part of the if-statement > is to allow the code to work as it did before for the non-JavaThread case. Before > this fix, if a non-JavaThread called into this code, then it was allowed to execute > this code. I've preserved that behavior and I've see no failures that indicate that > this is a problem. > > Do I know what non-JavaThreads might wander in here? No I don't. I realise this is pre-existing behaviour. It seems odd that a non-JavaThread can touch an oop when an exiting JavaThread cannot - how are they different? Or do we just cross our fingers and hope for the best with a non-JavaThread because it is rare? Perhaps @fisk can explain? ------------- PR: https://git.openjdk.org/jdk19/pull/69 From dholmes at openjdk.org Thu Jun 30 03:16:43 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 30 Jun 2022 03:16:43 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v2] In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 18:40:17 GMT, Daniel D. Daugherty wrote: > I'm very glad that I resisted putting the check in threadObj() when I made the changes for ... The problem has not been (until now) what you put in threadObj but the other checks you decided to put in. But now the issue has been raised, any code that can be executed in the context of a signal handler must use `Thread::current_or_null_safe()`. I don't know if the sharedRuntime code falls into that category but a call to `threadObj()` certainly can. Sorry this has not been smooth sailing. ------------- PR: https://git.openjdk.org/jdk19/pull/69 From stuefe at openjdk.org Thu Jun 30 04:34:39 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 30 Jun 2022 04:34:39 GMT Subject: RFR: JDK-8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 01:57:28 GMT, David Holmes wrote: > This seems to rely on the compiler not recognising that the single use of the new function could be inlined into the original. No. Using free() (without global scope "::") inside os::Linux:: will resolve the the nearest outer scope os::free(). Using free() inside a global function will not do that since free() is already in global scope, so gets resolved to ::free(). This is not dependent on any inlining decisions. ------------- PR: https://git.openjdk.org/jdk/pull/9328 From dholmes at openjdk.org Thu Jun 30 04:45:37 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 30 Jun 2022 04:45:37 GMT Subject: RFR: JDK-8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 16:58:57 GMT, Thomas Stuefe wrote: > In `os::Linux::active_processor_count()`, we use the CPU_xxx macros to manage sets of CPU information. > > muslc defines those macros to call `calloc(3)` and `free(3)`: > > > #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n))) > #define CPU_FREE(set) free(set) > > > whereas glibc uses intermediate functions: > > > #define __CPU_ALLOC(count) __sched_cpualloc (count) > #define __CPU_FREE(cpuset) __sched_cpufree (cpuset) > > > which in the end also takes from C-heap, but those calls are not inlined. > > So, on muslc we call `calloc()` and `free()`. Call happens inside the `os::Linux` namespace, `free()` resolves to `os::free()`. We have no wrapper in os for calloc though, so `calloc()` calls into muslc right away. > > That means we have raw ::malloc() -> os::free(), which is unbalanced. Raw `::malloc()` does not write the header `os::free()` expects. If NMT is on, we assert now, because NMT does not find its header in os::free(). > > This can be very easily reproduced by starting an Alpine VM with NMT on (or, a debug VM) and ` -XX:+UnlockDiagnosticVMOptions -XX:+UseCpuAllocPath`. This causes a NMT fence alert right away: > > > NMT Block at 0x00007fc5a35db9f0, corruption at: 0x00007fc5a35db9f0: > 0x00007fc5a35db970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35db980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35db990: f8 a1 c8 1b ea 55 00 00 00 00 00 00 00 c0 00 00 > 0x00007fc5a35db9a0: 00 a4 c8 1b ea 55 00 00 01 00 00 00 00 c0 00 00 > 0x00007fc5a35db9b0: d8 a3 c8 1b ea 55 00 00 1d 00 00 00 00 a0 00 00 > 0x00007fc5a35db9c0: 2d 63 70 00 00 00 00 00 08 00 00 00 00 61 01 00 > 0x00007fc5a35db9d0: 2d 76 65 72 73 69 6f 6e 00 00 00 00 00 82 02 00 > 0x00007fc5a35db9e0: 2d 73 65 72 76 65 72 00 00 00 00 00 00 83 03 00 > 0x00007fc5a35db9f0: 2d 63 6c 69 65 6e 74 00 00 00 00 00 00 84 04 00 > 0x00007fc5a35dba00: ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/mallocTracker.cpp:151 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/ubuntu/client_home/workspace/build-user-branch-linux_alpine_x86_64/SapMachine/src/hotspot/share/services/mallocTracker.cpp:151), pid=219496, tid=219512 > > > > The position of the musl devs is that "calloc" and "free" are reserved words in C, and should not be used [1]. I think they are right. The way we reuse known C- and Posix symbol names in the os namespace has bitten me in the past in similar cases. > > ------ > > The fix is minimally invasive for easy backporting. I just move the content of `os::Linux::active_processor_count()` into its own local function, outside the os namespace. That way, CPU_FREE cannot pick up `os::free()` accidentally, and the error is fixed. > > I really would like a more thorough solution though, renaming all the potential conflict candidates, but leave that for a follow-up RFE. > > [1] https://www.openwall.com/lists/musl/2022/06/29/3 Okay so the "binding" of `free()` will happen before any potential inlining could occur. It is a nice simple workaround. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9328 From stuefe at openjdk.org Thu Jun 30 05:02:38 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 30 Jun 2022 05:02:38 GMT Subject: RFR: JDK-8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 04:42:05 GMT, David Holmes wrote: > Okay so the "binding" of `free()` will happen before any potential inlining could occur. > > It is a nice simple workaround. > > Thanks. Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/9328 From clanger at openjdk.org Thu Jun 30 05:47:38 2022 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 30 Jun 2022 05:47:38 GMT Subject: RFR: JDK-8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 16:58:57 GMT, Thomas Stuefe wrote: > In `os::Linux::active_processor_count()`, we use the CPU_xxx macros to manage sets of CPU information. > > muslc defines those macros to call `calloc(3)` and `free(3)`: > > > #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n))) > #define CPU_FREE(set) free(set) > > > whereas glibc uses intermediate functions: > > > #define __CPU_ALLOC(count) __sched_cpualloc (count) > #define __CPU_FREE(cpuset) __sched_cpufree (cpuset) > > > which in the end also takes from C-heap, but those calls are not inlined. > > So, on muslc we call `calloc()` and `free()`. Call happens inside the `os::Linux` namespace, `free()` resolves to `os::free()`. We have no wrapper in os for calloc though, so `calloc()` calls into muslc right away. > > That means we have raw ::malloc() -> os::free(), which is unbalanced. Raw `::malloc()` does not write the header `os::free()` expects. If NMT is on, we assert now, because NMT does not find its header in os::free(). > > This can be very easily reproduced by starting an Alpine VM with NMT on (or, a debug VM) and ` -XX:+UnlockDiagnosticVMOptions -XX:+UseCpuAllocPath`. This causes a NMT fence alert right away: > > > NMT Block at 0x00007fc5a35db9f0, corruption at: 0x00007fc5a35db9f0: > 0x00007fc5a35db970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35db980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35db990: f8 a1 c8 1b ea 55 00 00 00 00 00 00 00 c0 00 00 > 0x00007fc5a35db9a0: 00 a4 c8 1b ea 55 00 00 01 00 00 00 00 c0 00 00 > 0x00007fc5a35db9b0: d8 a3 c8 1b ea 55 00 00 1d 00 00 00 00 a0 00 00 > 0x00007fc5a35db9c0: 2d 63 70 00 00 00 00 00 08 00 00 00 00 61 01 00 > 0x00007fc5a35db9d0: 2d 76 65 72 73 69 6f 6e 00 00 00 00 00 82 02 00 > 0x00007fc5a35db9e0: 2d 73 65 72 76 65 72 00 00 00 00 00 00 83 03 00 > 0x00007fc5a35db9f0: 2d 63 6c 69 65 6e 74 00 00 00 00 00 00 84 04 00 > 0x00007fc5a35dba00: ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/mallocTracker.cpp:151 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/ubuntu/client_home/workspace/build-user-branch-linux_alpine_x86_64/SapMachine/src/hotspot/share/services/mallocTracker.cpp:151), pid=219496, tid=219512 > > > > The position of the musl devs is that "calloc" and "free" are reserved words in C, and should not be used [1]. I think they are right. The way we reuse known C- and Posix symbol names in the os namespace has bitten me in the past in similar cases. > > ------ > > The fix is minimally invasive for easy backporting. I just move the content of `os::Linux::active_processor_count()` into its own local function, outside the os namespace. That way, CPU_FREE cannot pick up `os::free()` accidentally, and the error is fixed. > > I really would like a more thorough solution though, renaming all the potential conflict candidates, but leave that for a follow-up RFE. > > [1] https://www.openwall.com/lists/musl/2022/06/29/3 LGTM, thanks for fixing. ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.org/jdk/pull/9328 From stuefe at openjdk.org Thu Jun 30 06:22:38 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 30 Jun 2022 06:22:38 GMT Subject: RFR: JDK-8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 04:42:05 GMT, David Holmes wrote: >> In `os::Linux::active_processor_count()`, we use the CPU_xxx macros to manage sets of CPU information. >> >> muslc defines those macros to call `calloc(3)` and `free(3)`: >> >> >> #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n))) >> #define CPU_FREE(set) free(set) >> >> >> whereas glibc uses intermediate functions: >> >> >> #define __CPU_ALLOC(count) __sched_cpualloc (count) >> #define __CPU_FREE(cpuset) __sched_cpufree (cpuset) >> >> >> which in the end also takes from C-heap, but those calls are not inlined. >> >> So, on muslc we call `calloc()` and `free()`. Call happens inside the `os::Linux` namespace, `free()` resolves to `os::free()`. We have no wrapper in os for calloc though, so `calloc()` calls into muslc right away. >> >> That means we have raw ::malloc() -> os::free(), which is unbalanced. Raw `::malloc()` does not write the header `os::free()` expects. If NMT is on, we assert now, because NMT does not find its header in os::free(). >> >> This can be very easily reproduced by starting an Alpine VM with NMT on (or, a debug VM) and ` -XX:+UnlockDiagnosticVMOptions -XX:+UseCpuAllocPath`. This causes a NMT fence alert right away: >> >> >> NMT Block at 0x00007fc5a35db9f0, corruption at: 0x00007fc5a35db9f0: >> 0x00007fc5a35db970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x00007fc5a35db980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x00007fc5a35db990: f8 a1 c8 1b ea 55 00 00 00 00 00 00 00 c0 00 00 >> 0x00007fc5a35db9a0: 00 a4 c8 1b ea 55 00 00 01 00 00 00 00 c0 00 00 >> 0x00007fc5a35db9b0: d8 a3 c8 1b ea 55 00 00 1d 00 00 00 00 a0 00 00 >> 0x00007fc5a35db9c0: 2d 63 70 00 00 00 00 00 08 00 00 00 00 61 01 00 >> 0x00007fc5a35db9d0: 2d 76 65 72 73 69 6f 6e 00 00 00 00 00 82 02 00 >> 0x00007fc5a35db9e0: 2d 73 65 72 76 65 72 00 00 00 00 00 00 83 03 00 >> 0x00007fc5a35db9f0: 2d 63 6c 69 65 6e 74 00 00 00 00 00 00 84 04 00 >> 0x00007fc5a35dba00: ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x00007fc5a35dba10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x00007fc5a35dba20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x00007fc5a35dba30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x00007fc5a35dba40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x00007fc5a35dba50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x00007fc5a35dba60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: SuppressErrorAt=/mallocTracker.cpp:151 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/home/ubuntu/client_home/workspace/build-user-branch-linux_alpine_x86_64/SapMachine/src/hotspot/share/services/mallocTracker.cpp:151), pid=219496, tid=219512 >> >> >> >> The position of the musl devs is that "calloc" and "free" are reserved words in C, and should not be used [1]. I think they are right. The way we reuse known C- and Posix symbol names in the os namespace has bitten me in the past in similar cases. >> >> ------ >> >> The fix is minimally invasive for easy backporting. I just move the content of `os::Linux::active_processor_count()` into its own local function, outside the os namespace. That way, CPU_FREE cannot pick up `os::free()` accidentally, and the error is fixed. >> >> I really would like a more thorough solution though, renaming all the potential conflict candidates, but leave that for a follow-up RFE. >> >> [1] https://www.openwall.com/lists/musl/2022/06/29/3 > > Okay so the "binding" of `free()` will happen before any potential inlining could occur. > > It is a nice simple workaround. > > Thanks. Thanks @dholmes-ora and @RealCLanger. ------------- PR: https://git.openjdk.org/jdk/pull/9328 From stuefe at openjdk.org Thu Jun 30 06:22:40 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 30 Jun 2022 06:22:40 GMT Subject: Integrated: JDK-8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 16:58:57 GMT, Thomas Stuefe wrote: > In `os::Linux::active_processor_count()`, we use the CPU_xxx macros to manage sets of CPU information. > > muslc defines those macros to call `calloc(3)` and `free(3)`: > > > #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n))) > #define CPU_FREE(set) free(set) > > > whereas glibc uses intermediate functions: > > > #define __CPU_ALLOC(count) __sched_cpualloc (count) > #define __CPU_FREE(cpuset) __sched_cpufree (cpuset) > > > which in the end also takes from C-heap, but those calls are not inlined. > > So, on muslc we call `calloc()` and `free()`. Call happens inside the `os::Linux` namespace, `free()` resolves to `os::free()`. We have no wrapper in os for calloc though, so `calloc()` calls into muslc right away. > > That means we have raw ::malloc() -> os::free(), which is unbalanced. Raw `::malloc()` does not write the header `os::free()` expects. If NMT is on, we assert now, because NMT does not find its header in os::free(). > > This can be very easily reproduced by starting an Alpine VM with NMT on (or, a debug VM) and ` -XX:+UnlockDiagnosticVMOptions -XX:+UseCpuAllocPath`. This causes a NMT fence alert right away: > > > NMT Block at 0x00007fc5a35db9f0, corruption at: 0x00007fc5a35db9f0: > 0x00007fc5a35db970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35db980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35db990: f8 a1 c8 1b ea 55 00 00 00 00 00 00 00 c0 00 00 > 0x00007fc5a35db9a0: 00 a4 c8 1b ea 55 00 00 01 00 00 00 00 c0 00 00 > 0x00007fc5a35db9b0: d8 a3 c8 1b ea 55 00 00 1d 00 00 00 00 a0 00 00 > 0x00007fc5a35db9c0: 2d 63 70 00 00 00 00 00 08 00 00 00 00 61 01 00 > 0x00007fc5a35db9d0: 2d 76 65 72 73 69 6f 6e 00 00 00 00 00 82 02 00 > 0x00007fc5a35db9e0: 2d 73 65 72 76 65 72 00 00 00 00 00 00 83 03 00 > 0x00007fc5a35db9f0: 2d 63 6c 69 65 6e 74 00 00 00 00 00 00 84 04 00 > 0x00007fc5a35dba00: ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x00007fc5a35dba60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/mallocTracker.cpp:151 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/ubuntu/client_home/workspace/build-user-branch-linux_alpine_x86_64/SapMachine/src/hotspot/share/services/mallocTracker.cpp:151), pid=219496, tid=219512 > > > > The position of the musl devs is that "calloc" and "free" are reserved words in C, and should not be used [1]. I think they are right. The way we reuse known C- and Posix symbol names in the os namespace has bitten me in the past in similar cases. > > ------ > > The fix is minimally invasive for easy backporting. I just move the content of `os::Linux::active_processor_count()` into its own local function, outside the os namespace. That way, CPU_FREE cannot pick up `os::free()` accidentally, and the error is fixed. > > I really would like a more thorough solution though, renaming all the potential conflict candidates, but leave that for a follow-up RFE. > > [1] https://www.openwall.com/lists/musl/2022/06/29/3 This pull request has now been integrated. Changeset: da6d1fc0 Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/da6d1fc0e0aeb1fdb504aced4b0dba0290ec240f Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8289477: Memory corruption with CPU_ALLOC, CPU_FREE on muslc Reviewed-by: dholmes, clanger ------------- PR: https://git.openjdk.org/jdk/pull/9328 From mbaesken at openjdk.org Thu Jun 30 07:25:40 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 30 Jun 2022 07:25:40 GMT Subject: RFR: JDK-8289146: containers/docker/TestMemoryWithCgroupV1.java fails on linux ppc64le machine with missing Memory and Swap Limit output In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 20:47:05 GMT, Ioi Lam wrote: >> On Linux ppc64le machines , the test fails with >> >> stderr: [WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap. >> ] >> exitValue = 0 >> >> java.lang.RuntimeException: 'Memory and Swap Limit is: 157286400' missing from stdout/stderr >> >> at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:221) >> at TestMemoryWithCgroupV1.testMemoryLimitWithSwappiness(TestMemoryWithCgroupV1.java:84) >> at TestMemoryWithCgroupV1.main(TestMemoryWithCgroupV1.java:61) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:578) >> at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312) >> at java.base/java.lang.Thread.run(Thread.java:1596) >> >> This is most likely related to "kernel does not support swap limit capabilities", >> we've seen similar issues on other Linux ppc64 le machines in some tests before. >> So there needs to be some special handling added to the test for the case without kernel swap limit capabilities. > > test/hotspot/jtreg/containers/docker/TestMemoryWithCgroupV1.java line 94: > >> 92: } catch (RuntimeException ex) { >> 93: out.shouldMatch("Memory and Swap Limit is: [0-9]+"); >> 94: } > > With the `catch` clause added, it looks like the tests inside the `try` block don't do anything anymore, even on a host where the kernel actually supports swap limit capabilities. > > Maybe the correct way to handle this is: if "Your kernel does not support memory swappiness capabilities or the cgroup is not mounted." is in the output, then skip the test inside the `try` block? Hi Ioi, I think I proposed something like this (testing for the "Your kernel does not support memory swappiness" string) at other places in the test-code where the issue caused us trouble but this was not liked so much. ------------- PR: https://git.openjdk.org/jdk/pull/9319 From zgu at openjdk.org Thu Jun 30 12:30:40 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 30 Jun 2022 12:30:40 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v10] In-Reply-To: References: Message-ID: > Currently, jdi only check and process class unloading event when it detects a new GC cycle. > > After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. > > This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. > > It also performs `commonRef_compact()` only when there are classes unloaded. > > New test failed about 20% without patch, none with patch. > > **Update** > There are significant changes from early patch. > > The new approach: > No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: > - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state > - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state > > The new solution breaks up into two steps: > - Collect all dead object tags with lock > - Transition to `_in_native` state and post object free events in one batch > > This way, JDI event handler can process object free events upon arrivals without delay. > > **Update 2** > There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks. > > // This checks for posting and rehashing before operations that > // this tagmap table. The calls from a JavaThread only rehash, posting is > // only done before heap walks. > void JvmtiTagMap::check_hashmap(bool post_events) { > > Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. > Even the events are posted earlier in old code, but they are only processed after next GC cycle. Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Fix test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9168/files - new: https://git.openjdk.org/jdk/pull/9168/files/1c91f24c..e0338c4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=08-09 Stats: 164 lines in 1 file changed: 71 ins; 54 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/9168.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9168/head:pull/9168 PR: https://git.openjdk.org/jdk/pull/9168 From zgu at openjdk.org Thu Jun 30 14:59:55 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 30 Jun 2022 14:59:55 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v11] In-Reply-To: References: Message-ID: <94jebIPMnMRr3obVGKOyo79vlzdoqzpDuI2-lkicel4=.705ed9cc-bfd6-4ce2-ba6c-e24949575f69@github.com> > Currently, jdi only check and process class unloading event when it detects a new GC cycle. > > After [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879), posting class events can overlap with GC finish event, that results, sometimes, it only captures partial or even empty unloaded class list. The pending list usually can be flushed out at next GC cycle. But for the classes unloaded during the last GC cycle, the class unloading events may lost forever. > > This patch checks and processes class unloading events unconditionally, suggested by @kbarrett, the last pending unloaded class list can be flushed by other events, such as `VM_DEATH`. > > It also performs `commonRef_compact()` only when there are classes unloaded. > > New test failed about 20% without patch, none with patch. > > **Update** > There are significant changes from early patch. > > The new approach: > No longer removing dead objects and post events on VM thread. I believe it was implemented this way to workaround the following issues: > - JDI event handler uses JVMTI raw monitor, it requires thread in `_in_native` state > - The thread can not hold lock, which is needed to protect `JvmtiTagMap` while walking, when transition to `_in_native` state > > The new solution breaks up into two steps: > - Collect all dead object tags with lock > - Transition to `_in_native` state and post object free events in one batch > > This way, JDI event handler can process object free events upon arrivals without delay. > > **Update 2** > There is a comment for ` JvmtiTagMap::check_hashmap()` that states `ObjectFree` events are posted before heap walks. > > // This checks for posting and rehashing before operations that > // this tagmap table. The calls from a JavaThread only rehash, posting is > // only done before heap walks. > void JvmtiTagMap::check_hashmap(bool post_events) { > > Now, the events are actually posted after heap walks, but I don't think it makes any material material difference. > Even the events are posted earlier in old code, but they are only processed after next GC cycle. Zhengyu Gu 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 27 additional commits since the last revision: - Merge branch 'master' into JDK-8256811-jdi-missing-class-unloading-event - Moved TestClassUnloadEvents.java to new location - Fix test - Use Shenandoah GC for debuggee for deterministic - debug test - Adding log for debugging test failure on Windows - Removed HiddenClass test from Problem.txt and cleanup test - Renamed eventHandler_synthesizeUnloadEvent - v5 - Improve naming and cleanup - ... and 17 more: https://git.openjdk.org/jdk/compare/7f52920e...a07b3737 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9168/files - new: https://git.openjdk.org/jdk/pull/9168/files/e0338c4b..a07b3737 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9168&range=09-10 Stats: 25949 lines in 301 files changed: 23407 ins; 1791 del; 751 mod Patch: https://git.openjdk.org/jdk/pull/9168.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9168/head:pull/9168 PR: https://git.openjdk.org/jdk/pull/9168 From zgu at openjdk.org Thu Jun 30 14:59:56 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 30 Jun 2022 14:59:56 GMT Subject: RFR: 8256811: Delayed/missed jdwp class unloading events [v9] In-Reply-To: <9gGXw8F25KgjQ3a_8GqPAUJWwkxIsPdXBKZ8bTnGJL4=.7f0197c7-0176-49a1-8fd1-0434ed36714a@github.com> References: <9gGXw8F25KgjQ3a_8GqPAUJWwkxIsPdXBKZ8bTnGJL4=.7f0197c7-0176-49a1-8fd1-0434ed36714a@github.com> Message-ID: On Wed, 29 Jun 2022 22:46:30 GMT, Chris Plummer wrote: > I just noticed the test is being added to a newly created hotspot/jtreg/serviciability/jdi directory. It should be placed in one of the existing jdi test locations, either nsk/jdi or jdk/com/sun/jdi. I think the latter would be better and it can leverage TestScaffold. > > Another reason to use TestScaffold is that it will automatically add any specified VM options to the debuggee: > > ``` > String vmOpts = System.getProperty("test.vm.opts"); > System.out.println("vmOpts: '" + vmOpts + "'"); > ``` > > This way when we do our testing with various GC configurations, it should end up testing the debuggee with each GC configuration also. Same goes with other VM options that get tested like -Xcomp. Moved new test to jdk/com/sun/jdi. ------------- PR: https://git.openjdk.org/jdk/pull/9168 From iklam at openjdk.org Thu Jun 30 15:00:36 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 30 Jun 2022 15:00:36 GMT Subject: RFR: JDK-8289146: containers/docker/TestMemoryWithCgroupV1.java fails on linux ppc64le machine with missing Memory and Swap Limit output In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 07:22:18 GMT, Matthias Baesken wrote: >> test/hotspot/jtreg/containers/docker/TestMemoryWithCgroupV1.java line 94: >> >>> 92: } catch (RuntimeException ex) { >>> 93: out.shouldMatch("Memory and Swap Limit is: [0-9]+"); >>> 94: } >> >> With the `catch` clause added, it looks like the tests inside the `try` block don't do anything anymore, even on a host where the kernel actually supports swap limit capabilities. >> >> Maybe the correct way to handle this is: if "Your kernel does not support memory swappiness capabilities or the cgroup is not mounted." is in the output, then skip the test inside the `try` block? > > Hi Ioi, I think I proposed something like this (testing for the "Your kernel does not support memory swappiness" string) at other places in the test-code where the issue caused us trouble but this was not liked so much. I don't know why that wasn't liked. Your patch essentially reduces `testMemoryLimitWithSwappiness` to test for only this: out.shouldMatch("Memory and Swap Limit is: [0-9]+"); So if we go with this way, you may as well remove everything inside the `try` block. ------------- PR: https://git.openjdk.org/jdk/pull/9319 From sgehwolf at openjdk.org Thu Jun 30 16:18:39 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 30 Jun 2022 16:18:39 GMT Subject: RFR: JDK-8289146: containers/docker/TestMemoryWithCgroupV1.java fails on linux ppc64le machine with missing Memory and Swap Limit output In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 14:56:48 GMT, Ioi Lam wrote: >> Hi Ioi, I think I proposed something like this (testing for the "Your kernel does not support memory swappiness" string) at other places in the test-code where the issue caused us trouble but this was not liked so much. > > I don't know why that wasn't liked. Your patch essentially reduces `testMemoryLimitWithSwappiness` to test for only this: > > > out.shouldMatch("Memory and Swap Limit is: [0-9]+"); > > > So if we go with this way, you may as well remove everything inside the `try` block. The issue with asserting a specific error from a container engine is that it might be different from one (`docker`) to the other (`podman`). Another way to address this, could be to pre-assert that on systems where this is happening (no swap), to skip the test. I.e. along the lines of: docker run --memory 100 --memory-swap 200 and inside a container have this code: if (metrics.getMemoryAndSwapLimit() == metrics.getMemoryLimit()) { // system doesn't support swap, skip test } Basically akin to: https://github.com/openjdk/jdk/blob/master/test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java#L283..L284 ------------- PR: https://git.openjdk.org/jdk/pull/9319 From dcubed at openjdk.org Thu Jun 30 20:05:46 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 30 Jun 2022 20:05:46 GMT Subject: [jdk19] RFR: 8289091: move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() [v3] In-Reply-To: <8sp27hzKOw7yBIWssa7M-0rFg-cCsbQbCRZ8E44t3tY=.920eddc4-55c0-48a2-aae5-c63cffcf3cfd@github.com> References: <8sp27hzKOw7yBIWssa7M-0rFg-cCsbQbCRZ8E44t3tY=.920eddc4-55c0-48a2-aae5-c63cffcf3cfd@github.com> Message-ID: On Tue, 28 Jun 2022 16:55:29 GMT, Daniel D. Daugherty wrote: >> A trivial move of the oop safety check from SharedRuntime::get_java_tid() to >> JavaThread::threadObj(). Also made adjustments to the threadObj() calls in >> JavaThread::print_on_error() and JavaThread::get_thread_name_string() so >> that we don't get secondary crashes when a JavaThread crashes after it has >> detached the GC barrier. >> >> Tested with Mach5 Tier[1-7]. A Mach5 Tier8 will be started this weekend. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > dholmes CR - use Thread::current() instead of Thread::current_or_null(). I've re-read the history behind: [JDK-8132510](https://bugs.openjdk.org/browse/JDK-8132510) Replace ThreadLocalStorage with compiler/language-based thread-local variables which is the fix that introduced `Thread::current_or_null_safe()`. Wow does that fix and the code review process bring back memories. I remember the struggle to get the fix in before JDK9 FC... 10 releases ago... yikes! I'm mulling and researching on what to do... ------------- PR: https://git.openjdk.org/jdk19/pull/69 From ccheung at openjdk.org Thu Jun 30 22:47:04 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 30 Jun 2022 22:47:04 GMT Subject: RFR: 8289257: Some custom loader tests failed due to symbol refcount not decremented Message-ID: Removing the test for class loader name symbol refcount since similar test exists in runtime/ClassUnload/UnloadTest.java. Tested locally on linux-x64 with ZGC. Running more tests via mach5. An alternative approach would be adding a `WB.fullGC()` call after `ClassUnloadCommon.triggerUnloading()` as follows: --- a/test/hotspot/jtreg/runtime/cds/appcds/customLoader/test-classes/HelloUnload.java +++ b/test/hotspot/jtreg/runtime/cds/appcds/customLoader/test-classes/HelloUnload.java @@ -105,6 +105,7 @@ public class HelloUnload { urlClassLoader = null; c = null; o = null; ClassUnloadCommon.triggerUnloading(); + wb.fullGC(); System.out.println("Is CustomLoadee alive? " + wb.isClassAlive(className)); ClassUnloadCommon.failIf(wb.isClassAlive(className), "should have been unloaded"); ------------- Commit messages: - update ProblemList-zgc.txt - 8289257: Some custom loader tests failed due to symbol refcount not decremented Changes: https://git.openjdk.org/jdk/pull/9340/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9340&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289257 Stats: 14 lines in 2 files changed: 0 ins; 14 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9340.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9340/head:pull/9340 PR: https://git.openjdk.org/jdk/pull/9340 From iklam at openjdk.org Thu Jun 30 23:03:40 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 30 Jun 2022 23:03:40 GMT Subject: RFR: 8289257: Some custom loader tests failed due to symbol refcount not decremented In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 22:28:26 GMT, Calvin Cheung wrote: > Removing the test for class loader name symbol refcount since similar test exists in runtime/ClassUnload/UnloadTest.java. > > Tested locally on linux-x64 with ZGC. Running more tests via mach5. > > An alternative approach would be adding a `WB.fullGC()` call after `ClassUnloadCommon.triggerUnloading()` as follows: > > > --- a/test/hotspot/jtreg/runtime/cds/appcds/customLoader/test-classes/HelloUnload.java > +++ b/test/hotspot/jtreg/runtime/cds/appcds/customLoader/test-classes/HelloUnload.java > @@ -105,6 +105,7 @@ public class HelloUnload { > > urlClassLoader = null; c = null; o = null; > ClassUnloadCommon.triggerUnloading(); > + wb.fullGC(); > System.out.println("Is CustomLoadee alive? " + wb.isClassAlive(className)); > ClassUnloadCommon.failIf(wb.isClassAlive(className), "should have been unloaded"); LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/9340