From ysuenaga at openjdk.org Thu Sep 1 02:26:13 2022 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 1 Sep 2022 02:26:13 GMT Subject: RFR: 8175382: clhsdb pmap should print the end addresses of the load modules In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 23:04:18 GMT, Chris Plummer wrote: > The clhsdb 'pmap' command prints the start addresses and the sizes of the various load modules. It would be more intuitive to have the end address printed as the VM.dynlibs jcmd does. > > Before: > > 0x00007f8839c38000 5920K /usr/lib64/libc-2.17.so > 0x00007f883a006000 4072K /usr/lib64/libdl-2.17.so > 0x00007f883a20a000 4056K /usr/lib64/libpthread-2.17.so > 0x00007f883a426000 3944K /usr/lib64/libz.so.1.2.7 > > After: > > 0x7f0f8e482000-0x7f0f8ea00000 5624K /usr/lib64/libc-2.17.so > 0x7f0f8e850000-0x7f0f8ec00000 3776K /usr/lib64/libdl-2.17.so > 0x7f0f8ea54000-0x7f0f8ee00000 3760K /usr/lib64/libpthread-2.17.so > 0x7f0f8ec70000-0x7f0f8f000000 3648K /usr/lib64/libz.so.1.2.7 > > Note that VM.dynlibs doesn't use the 0x prefix. I considered doing the same for pmap, but it did cause one test failure that was searching for the address starting with 0x, so I decided to leave it in. Notice I also dropped the leading 0's to keep things a big more compact (VM.dynlibs does the same). Looks good! ------------- Marked as reviewed by ysuenaga (Reviewer). PR: https://git.openjdk.org/jdk/pull/10087 From dholmes at openjdk.org Thu Sep 1 04:15:28 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Sep 2022 04:15:28 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, add assert. src/hotspot/share/classfile/protectionDomainCache.hpp line 33: > 31: > 32: // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are > 33: // registered by DictionaryEntry::add_protection_domain() to a unique WeakHandle. Now that I understand what this table does, this comment is confusing to me. The table maps each PD to itself (using the WeakHandle as the actual key and value) as a means to track which PDs have been seen/registered. I would describe it thus: // The ProtectionDomainCacheTable records all of the java.security.ProtectionDomain instances that have // been registered by DictionaryEntry::add_protection_domain(). We use a hashtable to map each PD // instance to itself (using WeakHandles) to allow for fast lookup. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Thu Sep 1 04:15:28 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Sep 2022 04:15:28 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v4] In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 12:30:24 GMT, Coleen Phillimore wrote: >> I still can't decipher what this "map" actually holds. What does the unique WeakHandle actually refer to? > > WeakHandles are wrappers around a pointer to an oop that has been allocated in OopStorage. We cannot hold oops directly in hashtables because then we'd have to tell GC how and when to walk the hashtable. We want to save the oops though because they tell us whether this protection domain has been checked for the class that we're currently loading. The Old Hashtable held WeakHandles. So does this one, except with the wart in that we need the WeakHandle for both lookup and to return a unique WeakHandle for the protection domain oop. I've suggested a different comment above. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Thu Sep 1 04:29:07 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Sep 2022 04:29:07 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, add assert. src/hotspot/share/classfile/protectionDomainCache.cpp line 186: > 184: > 185: // The object_no_keepalive() call peeks at the phantomly reachable oop without > 186: // keeping it alive. This is used for traversing DictionaryEntry pd_set. My confusion here was that the comment belonged to the `ProtectionDomainCacheEntry::object_no_keepalive` method, but you have deleted that and are now applying the comment to the `ProtectionDomainEntry::object_no_keepalive()` method. The end result is okay. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From iklam at openjdk.org Thu Sep 1 06:44:17 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 1 Sep 2022 06:44:17 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Thu, 1 Sep 2022 04:12:32 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comments, add assert. > > src/hotspot/share/classfile/protectionDomainCache.hpp line 33: > >> 31: >> 32: // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are >> 33: // registered by DictionaryEntry::add_protection_domain() to a unique WeakHandle. > > Now that I understand what this table does, this comment is confusing to me. The table maps each PD to itself (using the WeakHandle as the actual key and value) as a means to track which PDs have been seen/registered. I would describe it thus: > > // The ProtectionDomainCacheTable records all of the java.security.ProtectionDomain instances that have > // been registered by DictionaryEntry::add_protection_domain(). We use a hashtable to > map each PD > // instance to itself (using WeakHandles) to allow for fast lookup. ?Mapping to itself? is how this table works internally. I am not sure if this information is useful here. But the purpose of this table is really to keep track of all PDs that have been registered and not yet garbage collected. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Thu Sep 1 06:55:03 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Sep 2022 06:55:03 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Thu, 1 Sep 2022 06:42:06 GMT, Ioi Lam wrote: >> src/hotspot/share/classfile/protectionDomainCache.hpp line 33: >> >>> 31: >>> 32: // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are >>> 33: // registered by DictionaryEntry::add_protection_domain() to a unique WeakHandle. >> >> Now that I understand what this table does, this comment is confusing to me. The table maps each PD to itself (using the WeakHandle as the actual key and value) as a means to track which PDs have been seen/registered. I would describe it thus: >> >> // The ProtectionDomainCacheTable records all of the java.security.ProtectionDomain instances that have >> // been registered by DictionaryEntry::add_protection_domain(). We use a hashtable to >> map each PD >> // instance to itself (using WeakHandles) to allow for fast lookup. > > ?Mapping to itself? is how this table works internally. I am not sure if this information is useful here. But the purpose of this table is really to keep track of all PDs that have been registered and not yet garbage collected. "mapping to itself" is more useful than "mapping ... to a unique Weakhandle" - which is even more of an internal implementation detail. I found the use of this table very hard to discern based on the internal use of the hashtable, as there is no real mapping operation - we simply track if a PD has been seen or not. The use of the hashtable is purely for lookup convenience - we could instead have a linked-list of PD's that we traverse for lookup. So perhaps we drop my second sentence above, and move it to where the hashtable itself is declared? ------------- PR: https://git.openjdk.org/jdk/pull/10043 From iklam at openjdk.org Thu Sep 1 07:16:09 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 1 Sep 2022 07:16:09 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, add assert. I am utterly confused about why we need ProtectionDomainCacheTable at all. The only interface between this class and the rest of the world is: DictionaryEntry::add_protection_domain() { WeakHandle obj = ProtectionDomainCacheTable::add_if_absent(protection_domain); // Additions and deletions hold the SystemDictionary_lock, readers are lock-free ProtectionDomainEntry* new_head = new ProtectionDomainEntry(obj, _pd_set); } (and there's code elsewhere for cleaning up this table, but that wouldn't be necessary if no one calls `add_if_absent`!). Why doesn't DictionaryEntry::add_protection_domain allocate the WeakHandle itself? I am looking at the JDK 8 code. It seems like ProtectionDomainCacheTable was needed before we had WeakHandle, so we had to do all the reference management by hand: https://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/classfile/dictionary.hpp#l137 But for today, is ProtectionDomainCacheTable a relic that can be thrown away? ------------- PR: https://git.openjdk.org/jdk/pull/10043 From iklam at openjdk.org Thu Sep 1 07:25:11 2022 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 1 Sep 2022 07:25:11 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Thu, 1 Sep 2022 06:51:21 GMT, David Holmes wrote: >> ?Mapping to itself? is how this table works internally. I am not sure if this information is useful here. But the purpose of this table is really to keep track of all PDs that have been registered and not yet garbage collected. > > "mapping to itself" is more useful than "mapping ... to a unique Weakhandle" - which is even more of an internal implementation detail. I found the use of this table very hard to discern based on the internal use of the hashtable, as there is no real mapping operation - we simply track if a PD has been seen or not. The use of the hashtable is purely for lookup convenience - we could instead have a linked-list of PD's that we traverse for lookup. > So perhaps we drop my second sentence above, and move it to where the hashtable itself is declared? "mapping a PD to a unique Weakhandle" is not an implementation detail. It's the only useful API provided by this class: WeakHandle obj = ProtectionDomainCacheTable::add_if_absent(protection_domain); and that's the reason I question why this table is needed at all. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Thu Sep 1 07:57:14 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Sep 2022 07:57:14 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Thu, 1 Sep 2022 07:12:25 GMT, Ioi Lam wrote: > I am utterly confused about why we need ProtectionDomainCacheTable at all. It tracks whether we have seen this PD before so that `validate_protection_domain` can skip the Java upcall to `checkPackageAccess`. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Thu Sep 1 07:57:15 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 1 Sep 2022 07:57:15 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: <6WXzI0rm-YVn2NO-wJpFokTRrihFQtSpIIoWHb7-BWA=.7ec7ea33-c104-4686-b6db-071d4c31d5ae@github.com> On Thu, 1 Sep 2022 07:23:03 GMT, Ioi Lam wrote: >> "mapping to itself" is more useful than "mapping ... to a unique Weakhandle" - which is even more of an internal implementation detail. I found the use of this table very hard to discern based on the internal use of the hashtable, as there is no real mapping operation - we simply track if a PD has been seen or not. The use of the hashtable is purely for lookup convenience - we could instead have a linked-list of PD's that we traverse for lookup. >> So perhaps we drop my second sentence above, and move it to where the hashtable itself is declared? > > "mapping a PD to a unique Weakhandle" is not an implementation detail. It's the only useful API provided by this class: > > > WeakHandle obj = ProtectionDomainCacheTable::add_if_absent(protection_domain); > > > and that's the reason I question why this table is needed at all. The fact it is a weakhandle is an implementation detail. The table simply records whether a PD (wrapped in a WeakHandle) has been seen. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Thu Sep 1 12:21:24 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 1 Sep 2022 12:21:24 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, add assert. The reason we have the table is that you can have the same instance of java.security.ProtectionDomain used on multiple DictionaryEntry._pd_set lists. That is, multiple classes in the class loader data have had their loading initiated with the same protection domain, which is common. Creating WeakHandles for each is redundant and wasteful, so we want to have one WeakHandle for multiple entries to point to. The table is a place to store it. I had another version that stored the WeakHandle entries in the ClassLoaderData of the Dictionary of loaded classes that had them in their pd_set, but they had a linear lookup to determine if they were unique. We even performance tested that. In the end, I just translated the table to ResourceHashtable to make it easier to review and understand what this does. As an example, if you run hello world with the security manager allowed, you see this: java -Xlog:protectiondomain=trace -Djava.security.manager=allow -cp ~/work Hello [0.188s][trace][protectiondomain] adding protection domain for class java/lang/Object class loader: a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90} protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd set count = #1 [0.189s][trace][protectiondomain] adding protection domain for class java/lang/String class loader: a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90} protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd set count = #1 [0.189s][trace][protectiondomain] adding protection domain for class java/lang/Exception class loader: a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90} protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd set count = #1 [0.189s][trace][protectiondomain] adding protection domain for class java/lang/System class loader: a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90} protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd set count = #1 [0.189s][trace][protectiondomain] adding protection domain for class java/io/PrintStream class loader: a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000007fef58f90} protection domain: a 'java/security/ProtectionDomain'{0x000000011f01d820} pd set count = #1 Hello5 Whenever we initiate loading (for example) java.lang.Object in a non bootstrap class loader with the SecureClassLoader, we pass this protection domain. Notice how the same protection domain is added to each class. In JDK8 we pointed to the oop itself which required the GC to walk the global SystemDictionary. We definitely never want that, so moved it to a table, and made several other changes to enable concurrent class unloading after that - moved the Dictionaries of loaded classes to each class loader data. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Thu Sep 1 12:25:22 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 1 Sep 2022 12:25:22 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6WXzI0rm-YVn2NO-wJpFokTRrihFQtSpIIoWHb7-BWA=.7ec7ea33-c104-4686-b6db-071d4c31d5ae@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> <6WXzI0rm-YVn2NO-wJpFokTRrihFQtSpIIoWHb7-BWA=.7ec7ea33-c104-4686-b6db-071d4c31d5ae@github.com> Message-ID: <1SP_BMq5WR8aEaDrOltFkrf3ArzSTd0yZrjt9DfIkmg=.da033eb4-8b71-4fce-a3e2-d2ec1021b6e4@github.com> On Thu, 1 Sep 2022 07:53:07 GMT, David Holmes wrote: >> "mapping a PD to a unique Weakhandle" is not an implementation detail. It's the only useful API provided by this class: >> >> >> WeakHandle obj = ProtectionDomainCacheTable::add_if_absent(protection_domain); >> >> >> and that's the reason I question why this table is needed at all. > > The fact it is a weakhandle is an implementation detail. The table simply records whether a PD (wrapped in a WeakHandle) has been seen. Since I know what this table does, either comment is fine if it helps someone understand it. The "map each PD to itself" is pretty odd to me too. How about collect each PD for fast lookup in a hashtable? The code says how it's mapped. There isn't that much code and it's easy to see how the Key is mapped. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Thu Sep 1 12:33:16 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 1 Sep 2022 12:33:16 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <1SP_BMq5WR8aEaDrOltFkrf3ArzSTd0yZrjt9DfIkmg=.da033eb4-8b71-4fce-a3e2-d2ec1021b6e4@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> <6WXzI0rm-YVn2NO-wJpFokTRrihFQtSpIIoWHb7-BWA=.7ec7ea33-c104-4686-b6db-071d4c31d5ae@github.com> <1SP_BMq5WR8aEaDrOltFkrf3ArzSTd0yZrjt9DfIkmg=.da033eb4-8b71-4fce-a3e2-d2ec1021b6e4@github.com> Message-ID: On Thu, 1 Sep 2022 12:21:30 GMT, Coleen Phillimore wrote: >> The fact it is a weakhandle is an implementation detail. The table simply records whether a PD (wrapped in a WeakHandle) has been seen. > > Since I know what this table does, either comment is fine if it helps someone understand it. > The "map each PD to itself" is pretty odd to me too. How about collect each PD for fast lookup in a hashtable? The code says how it's mapped. There isn't that much code and it's easy to see how the Key is mapped. // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are // registered by DictionaryEntry::add_protection_domain() to a unique entry. The entry // is a WeakHandle that holds the protection domain oop. or points to.... either is accurate. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From duke at openjdk.org Thu Sep 1 15:07:03 2022 From: duke at openjdk.org (Daniel Skantz) Date: Thu, 1 Sep 2022 15:07:03 GMT Subject: RFR: 8283627: Outdated comment in MachineDescriptionTwosComplement.isLP64 [v2] In-Reply-To: <3phI4L8RUaBPkDovtGNk94bAtx7R_9Inj1_i0bpEq6k=.3a91baf2-b59a-4857-aa03-e8f07d1d2a60@github.com> References: <3phI4L8RUaBPkDovtGNk94bAtx7R_9Inj1_i0bpEq6k=.3a91baf2-b59a-4857-aa03-e8f07d1d2a60@github.com> Message-ID: > Update MachineDescriptionTwosComplement.java comment to indicate that LP64 machines are no longer uncommon. Daniel Skantz has updated the pull request incrementally with one additional commit since the last revision: JDK-8283627 - Update MachineDescription.java JDK-8283627 - Update comment also in MachineDescription.java regarding LP64 (as noted by @plummercj, @sspitsyn) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9967/files - new: https://git.openjdk.org/jdk/pull/9967/files/c927a8c7..6a0efae0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9967&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9967&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9967.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9967/head:pull/9967 PR: https://git.openjdk.org/jdk/pull/9967 From sspitsyn at openjdk.org Thu Sep 1 15:29:12 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 1 Sep 2022 15:29:12 GMT Subject: RFR: 8283627: Outdated comment in MachineDescriptionTwosComplement.isLP64 [v2] In-Reply-To: References: <3phI4L8RUaBPkDovtGNk94bAtx7R_9Inj1_i0bpEq6k=.3a91baf2-b59a-4857-aa03-e8f07d1d2a60@github.com> Message-ID: On Thu, 1 Sep 2022 15:07:03 GMT, Daniel Skantz wrote: >> Update MachineDescriptionTwosComplement.java comment to indicate that LP64 machines are no longer uncommon. > > Daniel Skantz has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8283627 - Update MachineDescription.java > > JDK-8283627 - Update comment also in MachineDescription.java regarding LP64 (as noted by @plummercj, @sspitsyn) Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9967 From cjplummer at openjdk.org Thu Sep 1 16:33:19 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 16:33:19 GMT Subject: RFR: 8293006: sun/tools/jhsdb/JStackStressTest.java fails with "UnalignedAddressException: 8baadbabe" In-Reply-To: <30MiZ6W_yFw0pgh8t8LUcoeUPllcUgjlUmzIE7-UJhU=.46a806ca-006e-43be-b1db-76277242f2b9@github.com> References: <30MiZ6W_yFw0pgh8t8LUcoeUPllcUgjlUmzIE7-UJhU=.46a806ca-006e-43be-b1db-76277242f2b9@github.com> Message-ID: On Tue, 30 Aug 2022 23:29:18 GMT, Chris Plummer wrote: > The root cause of this CR is that we are trying to access the java heap during the middle of a GC. This particular test is prone to that happening since it runs jstack 4 times on the debuggee as it starts up (the debuggee is jshell, so it does a lot of initialization on startup). > > SA needs to deal with potentially bad references to java objects. These might come from VM structs (such as the JavaThread reference to its java Thread instance), or a java object reference from a field of another java objects. There's always the possibility that these can be invalid. We work around this in most of our testing by getting the debuggee into a steady state so no GC can be in progress. > > For the most part SA is pretty good about dealing with these bad object refernces, and fails gracefully with an exception, but otherwise continues to run. However, this test exposed some holes that resulted in (1) way to many exception stack traces and (2) exiting the SA tool rather than trying to continue. > > The main fix is in JavaThread.printThreadInfo() where we now do a better job of dealing with exceptions if any of the java objects references are not valid. Even without access to the Thread instance, we can still produce a stack trace, but it will be missing things like the thread name and priority. This is a lot better than just giving up with the first exception. > > The other changes are for the most part just improvements in the error output, and getting rid of the printStackTrace() that was cluttering up the output. Ping. This one is causing quite a bit of noise in our CI, so I would like to get it pushed soon. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10088 From cjplummer at openjdk.org Thu Sep 1 16:36:19 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 16:36:19 GMT Subject: RFR: 8175382: clhsdb pmap should print the end addresses of the load modules In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 23:04:18 GMT, Chris Plummer wrote: > The clhsdb 'pmap' command prints the start addresses and the sizes of the various load modules. It would be more intuitive to have the end address printed as the VM.dynlibs jcmd does. > > Before: > > 0x00007f8839c38000 5920K /usr/lib64/libc-2.17.so > 0x00007f883a006000 4072K /usr/lib64/libdl-2.17.so > 0x00007f883a20a000 4056K /usr/lib64/libpthread-2.17.so > 0x00007f883a426000 3944K /usr/lib64/libz.so.1.2.7 > > After: > > 0x7f0f8e482000-0x7f0f8ea00000 5624K /usr/lib64/libc-2.17.so > 0x7f0f8e850000-0x7f0f8ec00000 3776K /usr/lib64/libdl-2.17.so > 0x7f0f8ea54000-0x7f0f8ee00000 3760K /usr/lib64/libpthread-2.17.so > 0x7f0f8ec70000-0x7f0f8f000000 3648K /usr/lib64/libz.so.1.2.7 > > Note that VM.dynlibs doesn't use the 0x prefix. I considered doing the same for pmap, but it did cause one test failure that was searching for the address starting with 0x, so I decided to leave it in. Notice I also dropped the leading 0's to keep things a big more compact (VM.dynlibs does the same). Thanks Seguei and Yasumasa! ------------- PR: https://git.openjdk.org/jdk/pull/10087 From cjplummer at openjdk.org Thu Sep 1 16:39:17 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 16:39:17 GMT Subject: Integrated: 8175382: clhsdb pmap should print the end addresses of the load modules In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 23:04:18 GMT, Chris Plummer wrote: > The clhsdb 'pmap' command prints the start addresses and the sizes of the various load modules. It would be more intuitive to have the end address printed as the VM.dynlibs jcmd does. > > Before: > > 0x00007f8839c38000 5920K /usr/lib64/libc-2.17.so > 0x00007f883a006000 4072K /usr/lib64/libdl-2.17.so > 0x00007f883a20a000 4056K /usr/lib64/libpthread-2.17.so > 0x00007f883a426000 3944K /usr/lib64/libz.so.1.2.7 > > After: > > 0x7f0f8e482000-0x7f0f8ea00000 5624K /usr/lib64/libc-2.17.so > 0x7f0f8e850000-0x7f0f8ec00000 3776K /usr/lib64/libdl-2.17.so > 0x7f0f8ea54000-0x7f0f8ee00000 3760K /usr/lib64/libpthread-2.17.so > 0x7f0f8ec70000-0x7f0f8f000000 3648K /usr/lib64/libz.so.1.2.7 > > Note that VM.dynlibs doesn't use the 0x prefix. I considered doing the same for pmap, but it did cause one test failure that was searching for the address starting with 0x, so I decided to leave it in. Notice I also dropped the leading 0's to keep things a big more compact (VM.dynlibs does the same). This pull request has now been integrated. Changeset: 07616de0 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/07616de00c3e1c305852fcc44df8dadafd0dbf3f Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod 8175382: clhsdb pmap should print the end addresses of the load modules Reviewed-by: sspitsyn, ysuenaga ------------- PR: https://git.openjdk.org/jdk/pull/10087 From cjplummer at openjdk.org Thu Sep 1 16:45:42 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 16:45:42 GMT Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails with "'Thread "Common-Cleaner"' missing from stdout/stderr" Message-ID: While dumping all registers (and doing a findpc on each), the following exception occurred for r8: r8: 0x000000750e4fdffc Error: java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 at jdk.hotspot.agent/sun.jvm.hotspot.debugger.Page.getLong(Page.java:182) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:364) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:312) at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:71) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:58) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) This exception is the result of using PointerFinder ("findpc") on invalid address that starts on the last 32-bit word of a page. "page" in this case is referring to a page in SA's PageCache, which are always 4k in size. Note findpc is frequently done using an invalid address. In this test case it is being called on each x64 register, which could contain anything. findpc relies on getting some sort of AddressException when this happens, and will then say the address points to something that is unknown. However, in the case of the address pointing to the last 32-bot word of a page, it results in an ArrayIndexOutOfBoundsException when the page cache tries to read past the end of the page. This is happening in Page.getLong(), which you can see in the stack trace. The main culprit here is some weakening of the alignment checks being done. The alignment check should have resulted in an UnalignedAddressException long before we ever got to Page.getLong(). However, we have the following override, which is allowing the unaligned address to pass the alignment check. public void checkAlignment(long address, long alignment) { // Need to override default checkAlignment because we need to // relax alignment constraints on Bsd/x86 if ( (address % alignment != 0) &&(alignment != 8 || address % 4 != 0)) { throw new UnalignedAddressException( "Trying to read at address: " + addressValueToString(address) + " with alignment: " + alignment, address); } } }; This allows a pointer to a 64-bit value to only be 32-bit aligned. But there's more to it than that. I modified ClhsdbFindPC.java to fetch a tid (a thread address), and did a findpc on the address OR'd with 0xffc. `findpc` uses PointerFinder. This forced a read of a 64-bit value that starts in the last 32-bits of a page. It passed on linux-x64 but failed on windowx-x64 in the same manner described in the description of this CR. The difference between the two implementations is that windows relies on the default implementation of DebuggerBase.readCInteger() whereas linux has an override. DebuggerBase.readCInteger() does the following: public long readCInteger(long address, long numBytes, boolean isUnsigned) { utils.checkAlignment(address, numBytes); if (useFastAccessors) { if (isUnsigned) { switch((int) numBytes) { case 1: return cache.getByte(address) & 0xFF; case 2: return cache.getShort(address, bigEndian) & 0xFFFF; case 4: return cache.getInt(address, bigEndian) & 0xFFFFFFFFL; case 8: return cache.getLong(address, bigEndian); ... There is an alignment check here, but it is the "relaxed" override shown above, which allows 64-bit addresses on 32-bit boundaries. The override in LinuxDebuggerLocal is: /** Need to override this to relax alignment checks on x86. */ public long readCInteger(long address, long numBytes, boolean isUnsigned) throws UnmappedAddressException, UnalignedAddressException { // Only slightly relaxed semantics -- this is a hack, but is // necessary on x86 where it seems the compiler is // putting some global 64-bit data on 32-bit boundaries if (numBytes == 8) { utils.checkAlignment(address, 4); } else { utils.checkAlignment(address, numBytes); } byte[] data = readBytes(address, numBytes); return utils.dataToCInteger(data, isUnsigned); Although there is a relaxed alignment check here also, the code that reads from the address does not assume all the bytes are on the same page. It uses readBytes() intead of cache.getLong(), so it won't run into the PageCache issue with reading a 64-bit value that starts in the last 32-bit word of a page. I think the introduction of these relaxed alignment checks has a muddled history, probably made more muddled by ports cloning code that maybe wasn't necessary. Probably also initial fixes (the relaxed alignment check) seemed to work at first, but later the PageCache issue was discovered, leading to readBytes() workaround in the LinuxDebuggerLocal.readCInteger() override, but was not also done on other ports (so we got this CR for windows). For 64-bit support it's clear this easing of the 64-bit alignment is not needed, and getting rid of it would result in the proper UnalignedAddressException being thrown. The question is whether it is still needed for 32-bit x86, and if so is it needed on all ports. I can't test linux-x86, so I can't tell if it still allows 64-bit values on 32-bit aligned addresses, so for now I'll assume it does. So the approach being taken is whenever an address of a 64-bit type points to the last 32-bit word of a page, use readBytes() to get the 64-bit value one byte at a time. It still uses the page cache in the end, but it doesn't try to get all 8 bytes from the same page. Note for 64-bit systems, the conditoin will never arise because of the removal of the relaxed alignment check. Instead there will be an UnalignedAddressException at an early point when the alignment check is made. One windfall of this change is now we always read 64-bit values from the page cache in a way that is much more efficient than reading a byte at a time. This has resulted in about a 25% performance improvement in a test I have that does a heap dump. ------------- Commit messages: - Fix jcheck error - Undo some temp test changes. - Fix 64-bit alignment requirements Changes: https://git.openjdk.org/jdk/pull/10090/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10090&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292201 Stats: 227 lines in 11 files changed: 52 ins; 154 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/10090.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10090/head:pull/10090 PR: https://git.openjdk.org/jdk/pull/10090 From cjplummer at openjdk.org Thu Sep 1 17:20:33 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 17:20:33 GMT Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails with "'Thread "Common-Cleaner"' missing from stdout/stderr" [v2] In-Reply-To: References: Message-ID: > While dumping all registers (and doing a findpc on each), the following exception occurred for r8: > > > r8: 0x000000750e4fdffc > Error: java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 > java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.Page.getLong(Page.java:182) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:364) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:312) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:71) > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:58) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) > > > This exception is the result of using PointerFinder ("findpc") on invalid address that starts on the last 32-bit word of a page. "page" in this case is referring to a page in SA's PageCache, which are always 4k in size. Note findpc is frequently done using an invalid address. In this test case it is being called on each x64 register, which could contain anything. findpc relies on getting some sort of AddressException when this happens, and will then say the address points to something that is unknown. However, in the case of the address pointing to the last 32-bot word of a page, it results in an ArrayIndexOutOfBoundsException when the page cache tries to read past the end of the page. This is happening in Page.getLong(), which you can see in the stack trace. > > The main culprit here is some weakening of the alignment checks being done. The alignment check should have resulted in an UnalignedAddressException long before we ever got to Page.getLong(). However, we have the following override, which is allowing the unaligned address to pass the alignment check. > > > public void checkAlignment(long address, long alignment) { > // Need to override default checkAlignment because we need to > // relax alignment constraints on Bsd/x86 > if ( (address % alignment != 0) > &&(alignment != 8 || address % 4 != 0)) { > throw new UnalignedAddressException( > "Trying to read at address: " > + addressValueToString(address) > + " with alignment: " + alignment, > address); > } > } > }; > > > This allows a pointer to a 64-bit value to only be 32-bit aligned. But there's more to it than that. I modified ClhsdbFindPC.java to fetch a tid (a thread address), and did a findpc on the address OR'd with 0xffc. `findpc` uses PointerFinder. This forced a read of a 64-bit value that starts in the last 32-bits of a page. It passed on linux-x64 but failed on windowx-x64 in the same manner described in the description of this CR. The difference between the two implementations is that windows relies on the default implementation of DebuggerBase.readCInteger() whereas linux has an override. DebuggerBase.readCInteger() does the following: > > > public long readCInteger(long address, long numBytes, boolean isUnsigned) { > utils.checkAlignment(address, numBytes); > if (useFastAccessors) { > if (isUnsigned) { > switch((int) numBytes) { > case 1: return cache.getByte(address) & 0xFF; > case 2: return cache.getShort(address, bigEndian) & 0xFFFF; > case 4: return cache.getInt(address, bigEndian) & 0xFFFFFFFFL; > case 8: return cache.getLong(address, bigEndian); > ... > > > There is an alignment check here, but it is the "relaxed" override shown above, which allows 64-bit addresses on 32-bit boundaries. The override in LinuxDebuggerLocal is: > > > /** Need to override this to relax alignment checks on x86. */ > public long readCInteger(long address, long numBytes, boolean isUnsigned) > throws UnmappedAddressException, UnalignedAddressException { > // Only slightly relaxed semantics -- this is a hack, but is > // necessary on x86 where it seems the compiler is > // putting some global 64-bit data on 32-bit boundaries > if (numBytes == 8) { > utils.checkAlignment(address, 4); > } else { > utils.checkAlignment(address, numBytes); > } > byte[] data = readBytes(address, numBytes); > return utils.dataToCInteger(data, isUnsigned); > > > Although there is a relaxed alignment check here also, the code that reads from the address does not assume all the bytes are on the same page. It uses readBytes() intead of cache.getLong(), so it won't run into the PageCache issue with reading a 64-bit value that starts in the last 32-bit word of a page. > > I think the introduction of these relaxed alignment checks has a muddled history, probably made more muddled by ports cloning code that maybe wasn't necessary. Probably also initial fixes (the relaxed alignment check) seemed to work at first, but later the PageCache issue was discovered, leading to readBytes() workaround in the LinuxDebuggerLocal.readCInteger() override, but was not also done on other ports (so we got this CR for windows). > > For 64-bit support it's clear this easing of the 64-bit alignment is not needed, and getting rid of it would result in the proper UnalignedAddressException being thrown. The question is whether it is still needed for 32-bit x86, and if so is it needed on all ports. > > I can't test linux-x86, so I can't tell if it still allows 64-bit values on 32-bit aligned addresses, so for now I'll assume it does. So the approach being taken is whenever an address of a 64-bit type points to the last 32-bit word of a page, use readBytes() to get the 64-bit value one byte at a time. It still uses the page cache in the end, but it doesn't try to get all 8 bytes from the same page. Note for 64-bit systems, the conditoin will never arise because of the removal of the relaxed alignment check. Instead there will be an UnalignedAddressException at an early point when the alignment check is made. > > One windfall of this change is now we always read 64-bit values from the page cache in a way that is much more efficient than reading a byte at a time. This has resulted in about a 25% performance improvement in a test I have that does a heap dump. Chris Plummer 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 - Fix jcheck error - Undo some temp test changes. - Fix 64-bit alignment requirements ------------- Changes: https://git.openjdk.org/jdk/pull/10090/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10090&range=01 Stats: 227 lines in 11 files changed: 52 ins; 154 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/10090.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10090/head:pull/10090 PR: https://git.openjdk.org/jdk/pull/10090 From cjplummer at openjdk.org Thu Sep 1 17:25:41 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 17:25:41 GMT Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails with "'Thread "Common-Cleaner"' missing from stdout/stderr" [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 17:20:33 GMT, Chris Plummer wrote: >> While dumping all registers (and doing a findpc on each), the following exception occurred for r8: >> >> >> r8: 0x000000750e4fdffc >> Error: java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 >> java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.Page.getLong(Page.java:182) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:364) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:312) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:71) >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:58) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) >> >> >> This exception is the result of using PointerFinder ("findpc") on invalid address that starts on the last 32-bit word of a page. "page" in this case is referring to a page in SA's PageCache, which are always 4k in size. Note findpc is frequently done using an invalid address. In this test case it is being called on each x64 register, which could contain anything. findpc relies on getting some sort of AddressException when this happens, and will then say the address points to something that is unknown. However, in the case of the address pointing to the last 32-bot word of a page, it results in an ArrayIndexOutOfBoundsException when the page cache tries to read past the end of the page. This is happening in Page.getLong(), which you can see in the stack trace. >> >> The main culprit here is some weakening of the alignment checks being done. The alignment check should have resulted in an UnalignedAddressException long before we ever got to Page.getLong(). However, we have the following override, which is allowing the unaligned address to pass the alignment check. >> >> >> public void checkAlignment(long address, long alignment) { >> // Need to override default checkAlignment because we need to >> // relax alignment constraints on Bsd/x86 >> if ( (address % alignment != 0) >> &&(alignment != 8 || address % 4 != 0)) { >> throw new UnalignedAddressException( >> "Trying to read at address: " >> + addressValueToString(address) >> + " with alignment: " + alignment, >> address); >> } >> } >> }; >> >> >> This allows a pointer to a 64-bit value to only be 32-bit aligned. But there's more to it than that. I modified ClhsdbFindPC.java to fetch a tid (a thread address), and did a findpc on the address OR'd with 0xffc. `findpc` uses PointerFinder. This forced a read of a 64-bit value that starts in the last 32-bits of a page. It passed on linux-x64 but failed on windowx-x64 in the same manner described in the description of this CR. The difference between the two implementations is that windows relies on the default implementation of DebuggerBase.readCInteger() whereas linux has an override. DebuggerBase.readCInteger() does the following: >> >> >> public long readCInteger(long address, long numBytes, boolean isUnsigned) { >> utils.checkAlignment(address, numBytes); >> if (useFastAccessors) { >> if (isUnsigned) { >> switch((int) numBytes) { >> case 1: return cache.getByte(address) & 0xFF; >> case 2: return cache.getShort(address, bigEndian) & 0xFFFF; >> case 4: return cache.getInt(address, bigEndian) & 0xFFFFFFFFL; >> case 8: return cache.getLong(address, bigEndian); >> ... >> >> >> There is an alignment check here, but it is the "relaxed" override shown above, which allows 64-bit addresses on 32-bit boundaries. The override in LinuxDebuggerLocal is: >> >> >> /** Need to override this to relax alignment checks on x86. */ >> public long readCInteger(long address, long numBytes, boolean isUnsigned) >> throws UnmappedAddressException, UnalignedAddressException { >> // Only slightly relaxed semantics -- this is a hack, but is >> // necessary on x86 where it seems the compiler is >> // putting some global 64-bit data on 32-bit boundaries >> if (numBytes == 8) { >> utils.checkAlignment(address, 4); >> } else { >> utils.checkAlignment(address, numBytes); >> } >> byte[] data = readBytes(address, numBytes); >> return utils.dataToCInteger(data, isUnsigned); >> >> >> Although there is a relaxed alignment check here also, the code that reads from the address does not assume all the bytes are on the same page. It uses readBytes() intead of cache.getLong(), so it won't run into the PageCache issue with reading a 64-bit value that starts in the last 32-bit word of a page. >> >> I think the introduction of these relaxed alignment checks has a muddled history, probably made more muddled by ports cloning code that maybe wasn't necessary. Probably also initial fixes (the relaxed alignment check) seemed to work at first, but later the PageCache issue was discovered, leading to readBytes() workaround in the LinuxDebuggerLocal.readCInteger() override, but was not also done on other ports (so we got this CR for windows). >> >> For 64-bit support it's clear this easing of the 64-bit alignment is not needed, and getting rid of it would result in the proper UnalignedAddressException being thrown. The question is whether it is still needed for 32-bit x86, and if so is it needed on all ports. >> >> I can't test linux-x86, so I can't tell if it still allows 64-bit values on 32-bit aligned addresses, so for now I'll assume it does. So the approach being taken is whenever an address of a 64-bit type points to the last 32-bit word of a page, use readBytes() to get the 64-bit value one byte at a time. It still uses the page cache in the end, but it doesn't try to get all 8 bytes from the same page. Note for 64-bit systems, the conditoin will never arise because of the removal of the relaxed alignment check. Instead there will be an UnalignedAddressException at an early point when the alignment check is made. >> >> One windfall of this change is now we always read 64-bit values from the page cache in a way that is much more efficient than reading a byte at a time. This has resulted in about a 25% performance improvement in a test I have that does a heap dump. > > Chris Plummer 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 > - Fix jcheck error > - Undo some temp test changes. > - Fix 64-bit alignment requirements src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java line 46: > 44: private RemoteDebugger remoteDebugger; > 45: private RemoteThreadFactory threadFactory; > 46: private boolean unalignedAccessesOkay = false; After getting rid of the `readCInteger` and `readJLong` overrides below, `unalignedAccessesOkay` is no longer needed. The `DebuggerBase` superclass understands the alignment requirements. ------------- PR: https://git.openjdk.org/jdk/pull/10090 From dcubed at openjdk.org Thu Sep 1 18:02:45 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 1 Sep 2022 18:02:45 GMT Subject: RFR: 8293006: sun/tools/jhsdb/JStackStressTest.java fails with "UnalignedAddressException: 8baadbabe" In-Reply-To: <30MiZ6W_yFw0pgh8t8LUcoeUPllcUgjlUmzIE7-UJhU=.46a806ca-006e-43be-b1db-76277242f2b9@github.com> References: <30MiZ6W_yFw0pgh8t8LUcoeUPllcUgjlUmzIE7-UJhU=.46a806ca-006e-43be-b1db-76277242f2b9@github.com> Message-ID: <3mkb50hEcZGCzdE3BnhmnilRg_qk2-moW4ate1gvd5c=.76be4aca-1abf-48f3-bab6-292505bb1915@github.com> On Tue, 30 Aug 2022 23:29:18 GMT, Chris Plummer wrote: > The root cause of this CR is that we are trying to access the java heap during the middle of a GC. This particular test is prone to that happening since it runs jstack 4 times on the debuggee as it starts up (the debuggee is jshell, so it does a lot of initialization on startup). > > SA needs to deal with potentially bad references to java objects. These might come from VM structs (such as the JavaThread reference to its java Thread instance), or a java object reference from a field of another java objects. There's always the possibility that these can be invalid. We work around this in most of our testing by getting the debuggee into a steady state so no GC can be in progress. > > For the most part SA is pretty good about dealing with these bad object references, and fails gracefully with an exception, but otherwise continues to run. However, this test exposed some holes that resulted in (1) way to many exception stack traces and (2) exiting the SA tool rather than trying to continue. > > The main fix is in JavaThread.printThreadInfo() where we now do a better job of dealing with exceptions if any of the java objects references are not valid. Even without access to the Thread instance, we can still produce a stack trace, but it will be missing things like the thread name and priority. This is a lot better than just giving up with the first exception. > > The other changes are for the most part just improvements in the error output, and getting rid of the printStackTrace() that was cluttering up the output. I only found minor nits. Your hardened code appears to keep things in the same output format which is good. I think your "noise" reductions when there are errors are also good to have. I look forward to seeing the reduction in CI noise. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 357: > 355: obj = vmOopHandle.resolve(); > 356: } catch (Exception e) { > 357: System.out.println("WARNING: could not get Thread object: " + e); nit: This code seems to use an indent of 2 spaces. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 516: > 514: Oop threadOop = this.getThreadObj(); > 515: if (threadOop == null) { > 516: System.out.println("Could not get the java Thread object. Thread info will be limitted."); typo: s/limitted/limited/ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 546: > 544: out.print(this.getAddress()); > 545: out.print(" nid="); > 546: out.print(String.format("%d ",this.getOSThread().threadId())); nit space after ',' src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 550: > 548: out.print(" ["); > 549: if (this.getLastJavaSP() == null) { > 550: out.print(String.format(ADDRESS_FORMAT,0L)); nit: space after ',' src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java line 69: > 67: } else { > 68: klassName = ""; > 69: } nit: existing code uses 2 spaces, but your addition uses 4. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/10088 From cjplummer at openjdk.org Thu Sep 1 18:28:58 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 18:28:58 GMT Subject: RFR: 8293006: sun/tools/jhsdb/JStackStressTest.java fails with "UnalignedAddressException: 8baadbabe" [v2] In-Reply-To: <30MiZ6W_yFw0pgh8t8LUcoeUPllcUgjlUmzIE7-UJhU=.46a806ca-006e-43be-b1db-76277242f2b9@github.com> References: <30MiZ6W_yFw0pgh8t8LUcoeUPllcUgjlUmzIE7-UJhU=.46a806ca-006e-43be-b1db-76277242f2b9@github.com> Message-ID: <5kZUqNKyadWd8IrTcFFC8jIdfNcDNWAp4OJXBDzZ3Co=.eddffd92-5cdc-4993-945c-d6c42f239933@github.com> > The root cause of this CR is that we are trying to access the java heap during the middle of a GC. This particular test is prone to that happening since it runs jstack 4 times on the debuggee as it starts up (the debuggee is jshell, so it does a lot of initialization on startup). > > SA needs to deal with potentially bad references to java objects. These might come from VM structs (such as the JavaThread reference to its java Thread instance), or a java object reference from a field of another java objects. There's always the possibility that these can be invalid. We work around this in most of our testing by getting the debuggee into a steady state so no GC can be in progress. > > For the most part SA is pretty good about dealing with these bad object references, and fails gracefully with an exception, but otherwise continues to run. However, this test exposed some holes that resulted in (1) way to many exception stack traces and (2) exiting the SA tool rather than trying to continue. > > The main fix is in JavaThread.printThreadInfo() where we now do a better job of dealing with exceptions if any of the java objects references are not valid. Even without access to the Thread instance, we can still produce a stack trace, but it will be missing things like the thread name and priority. This is a lot better than just giving up with the first exception. > > The other changes are for the most part just improvements in the error output, and getting rid of the printStackTrace() that was cluttering up the output. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Minor indent, spelling, and formatting fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10088/files - new: https://git.openjdk.org/jdk/pull/10088/files/02105d7e..377a8684 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10088&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10088&range=00-01 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10088.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10088/head:pull/10088 PR: https://git.openjdk.org/jdk/pull/10088 From sspitsyn at openjdk.org Thu Sep 1 18:28:58 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 1 Sep 2022 18:28:58 GMT Subject: RFR: 8293006: sun/tools/jhsdb/JStackStressTest.java fails with "UnalignedAddressException: 8baadbabe" [v2] In-Reply-To: <5kZUqNKyadWd8IrTcFFC8jIdfNcDNWAp4OJXBDzZ3Co=.eddffd92-5cdc-4993-945c-d6c42f239933@github.com> References: <30MiZ6W_yFw0pgh8t8LUcoeUPllcUgjlUmzIE7-UJhU=.46a806ca-006e-43be-b1db-76277242f2b9@github.com> <5kZUqNKyadWd8IrTcFFC8jIdfNcDNWAp4OJXBDzZ3Co=.eddffd92-5cdc-4993-945c-d6c42f239933@github.com> Message-ID: On Thu, 1 Sep 2022 18:26:05 GMT, Chris Plummer wrote: >> The root cause of this CR is that we are trying to access the java heap during the middle of a GC. This particular test is prone to that happening since it runs jstack 4 times on the debuggee as it starts up (the debuggee is jshell, so it does a lot of initialization on startup). >> >> SA needs to deal with potentially bad references to java objects. These might come from VM structs (such as the JavaThread reference to its java Thread instance), or a java object reference from a field of another java objects. There's always the possibility that these can be invalid. We work around this in most of our testing by getting the debuggee into a steady state so no GC can be in progress. >> >> For the most part SA is pretty good about dealing with these bad object references, and fails gracefully with an exception, but otherwise continues to run. However, this test exposed some holes that resulted in (1) way to many exception stack traces and (2) exiting the SA tool rather than trying to continue. >> >> The main fix is in JavaThread.printThreadInfo() where we now do a better job of dealing with exceptions if any of the java objects references are not valid. Even without access to the Thread instance, we can still produce a stack trace, but it will be missing things like the thread name and priority. This is a lot better than just giving up with the first exception. >> >> The other changes are for the most part just improvements in the error output, and getting rid of the printStackTrace() that was cluttering up the output. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Minor indent, spelling, and formatting fixes This looks good modulo minor comments from Dan. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10088 From cjplummer at openjdk.org Thu Sep 1 18:28:59 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 18:28:59 GMT Subject: RFR: 8293006: sun/tools/jhsdb/JStackStressTest.java fails with "UnalignedAddressException: 8baadbabe" [v2] In-Reply-To: <5kZUqNKyadWd8IrTcFFC8jIdfNcDNWAp4OJXBDzZ3Co=.eddffd92-5cdc-4993-945c-d6c42f239933@github.com> References: <30MiZ6W_yFw0pgh8t8LUcoeUPllcUgjlUmzIE7-UJhU=.46a806ca-006e-43be-b1db-76277242f2b9@github.com> <5kZUqNKyadWd8IrTcFFC8jIdfNcDNWAp4OJXBDzZ3Co=.eddffd92-5cdc-4993-945c-d6c42f239933@github.com> Message-ID: On Thu, 1 Sep 2022 18:26:05 GMT, Chris Plummer wrote: >> The root cause of this CR is that we are trying to access the java heap during the middle of a GC. This particular test is prone to that happening since it runs jstack 4 times on the debuggee as it starts up (the debuggee is jshell, so it does a lot of initialization on startup). >> >> SA needs to deal with potentially bad references to java objects. These might come from VM structs (such as the JavaThread reference to its java Thread instance), or a java object reference from a field of another java objects. There's always the possibility that these can be invalid. We work around this in most of our testing by getting the debuggee into a steady state so no GC can be in progress. >> >> For the most part SA is pretty good about dealing with these bad object references, and fails gracefully with an exception, but otherwise continues to run. However, this test exposed some holes that resulted in (1) way to many exception stack traces and (2) exiting the SA tool rather than trying to continue. >> >> The main fix is in JavaThread.printThreadInfo() where we now do a better job of dealing with exceptions if any of the java objects references are not valid. Even without access to the Thread instance, we can still produce a stack trace, but it will be missing things like the thread name and priority. This is a lot better than just giving up with the first exception. >> >> The other changes are for the most part just improvements in the error output, and getting rid of the printStackTrace() that was cluttering up the output. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Minor indent, spelling, and formatting fixes Thanks for review Dan! ------------- PR: https://git.openjdk.org/jdk/pull/10088 From cjplummer at openjdk.org Thu Sep 1 18:29:06 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 18:29:06 GMT Subject: RFR: 8293006: sun/tools/jhsdb/JStackStressTest.java fails with "UnalignedAddressException: 8baadbabe" [v2] In-Reply-To: <3mkb50hEcZGCzdE3BnhmnilRg_qk2-moW4ate1gvd5c=.76be4aca-1abf-48f3-bab6-292505bb1915@github.com> References: <30MiZ6W_yFw0pgh8t8LUcoeUPllcUgjlUmzIE7-UJhU=.46a806ca-006e-43be-b1db-76277242f2b9@github.com> <3mkb50hEcZGCzdE3BnhmnilRg_qk2-moW4ate1gvd5c=.76be4aca-1abf-48f3-bab6-292505bb1915@github.com> Message-ID: On Thu, 1 Sep 2022 17:21:55 GMT, Daniel D. Daugherty wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor indent, spelling, and formatting fixes > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 357: > >> 355: obj = vmOopHandle.resolve(); >> 356: } catch (Exception e) { >> 357: System.out.println("WARNING: could not get Thread object: " + e); > > nit: This code seems to use an indent of 2 spaces. fixed > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 516: > >> 514: Oop threadOop = this.getThreadObj(); >> 515: if (threadOop == null) { >> 516: System.out.println("Could not get the java Thread object. Thread info will be limitted."); > > typo: s/limitted/limited/ fixed > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 546: > >> 544: out.print(this.getAddress()); >> 545: out.print(" nid="); >> 546: out.print(String.format("%d ",this.getOSThread().threadId())); > > nit space after ',' fixed > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java line 550: > >> 548: out.print(" ["); >> 549: if (this.getLastJavaSP() == null) { >> 550: out.print(String.format(ADDRESS_FORMAT,0L)); > > nit: space after ',' fixed > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java line 69: > >> 67: } else { >> 68: klassName = ""; >> 69: } > > nit: existing code uses 2 spaces, but your addition uses 4. fixed ------------- PR: https://git.openjdk.org/jdk/pull/10088 From cjplummer at openjdk.org Thu Sep 1 19:17:43 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 19:17:43 GMT Subject: RFR: 8289400: Improve com/sun/jdi/TestScaffold error reporting Message-ID: com/sun/jdi tests report errors by calling TestScaffold.failure(msg), which prints the failure message and sets the testFailed flag. At some later point the failure is detected and an exception is thrown. The end result is the exception has just has a vanilla message that says something like "TestXXX failed", and the backtrace is not indicative of where the failure occurred. If you have tools that search logs looking for exceptions to determine the reason for the failure, you likely won't find any. Here's an example: [2ms] run args: [SuspendAfterDeathTarg] [514ms] FAILED: got Breakpoint event before ThreadDeath event. java.lang.Exception: SuspendAfterDeath: failed at SuspendAfterDeath.runTests(SuspendAfterDeath.java:110) at TestScaffold.startTests(TestScaffold.java:432) at SuspendAfterDeath.main(SuspendAfterDeath.java:47) 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.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:1589) So the reason for the failure is clear (the "FAILED" message), but its stack trace is missing and the reason is not included in the exception message that is printed much later on. This PR adds printing of the stack trace at the time of the failure. ------------- Commit messages: - Includes stack trace when there is a failure. Changes: https://git.openjdk.org/jdk/pull/10127/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10127&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289400 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10127.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10127/head:pull/10127 PR: https://git.openjdk.org/jdk/pull/10127 From cjplummer at openjdk.org Thu Sep 1 19:22:42 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 19:22:42 GMT Subject: RFR: 8283627: Outdated comment in MachineDescriptionTwosComplement.isLP64 [v2] In-Reply-To: References: <3phI4L8RUaBPkDovtGNk94bAtx7R_9Inj1_i0bpEq6k=.3a91baf2-b59a-4857-aa03-e8f07d1d2a60@github.com> Message-ID: <5Hb0HI3bkT-3jr-6TdWf8-r_66B3z7uEA7oBWOs055s=.ca172505-b86a-4824-8963-2f6b22cd70ea@github.com> On Thu, 1 Sep 2022 15:07:03 GMT, Daniel Skantz wrote: >> Update MachineDescriptionTwosComplement.java comment to indicate that LP64 machines are no longer uncommon. > > Daniel Skantz has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8283627 - Update MachineDescription.java > > JDK-8283627 - Update comment also in MachineDescription.java regarding LP64 (as noted by @plummercj, @sspitsyn) Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9967 From cjplummer at openjdk.org Thu Sep 1 19:48:25 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 19:48:25 GMT Subject: RFR: 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:47:05 GMT, Serguei Spitsyn wrote: > The problem is that the following assert in the JvmtiExport::post_object_free is wrong: > ` assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE), "checking");` > > Even though the condition was checked before, it can be changed later as it is racy by JVM TI design. > It has to be replaced with the check: > > if (!env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { > return; // the event type has been already disabled > } > > > In progress: mach5 nsk.jvmti and nsk.jdi test runs. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10109 From zgu at openjdk.org Thu Sep 1 20:14:10 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 1 Sep 2022 20:14:10 GMT Subject: RFR: 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:47:05 GMT, Serguei Spitsyn wrote: > The problem is that the following assert in the JvmtiExport::post_object_free is wrong: > ` assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE), "checking");` > > Even though the condition was checked before, it can be changed later as it is racy by JVM TI design. > It has to be replaced with the check: > > if (!env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { > return; // the event type has been already disabled > } > > > In progress: mach5 nsk.jvmti and nsk.jdi test runs. Looks good. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.org/jdk/pull/10109 From amenkov at openjdk.org Thu Sep 1 20:14:18 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Sep 2022 20:14:18 GMT Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails with "'Thread "Common-Cleaner"' missing from stdout/stderr" [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 17:20:33 GMT, Chris Plummer wrote: >> While dumping all registers (and doing a findpc on each), the following exception occurred for r8: >> >> >> r8: 0x000000750e4fdffc >> Error: java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 >> java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.Page.getLong(Page.java:182) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:364) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:312) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:71) >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:58) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) >> >> >> This exception is the result of using PointerFinder ("findpc") on invalid address that starts on the last 32-bit word of a page. "page" in this case is referring to a page in SA's PageCache, which are always 4k in size. Note findpc is frequently done using an invalid address. In this test case it is being called on each x64 register, which could contain anything. findpc relies on getting some sort of AddressException when this happens, and will then say the address points to something that is unknown. However, in the case of the address pointing to the last 32-bot word of a page, it results in an ArrayIndexOutOfBoundsException when the page cache tries to read past the end of the page. This is happening in Page.getLong(), which you can see in the stack trace. >> >> The main culprit here is some weakening of the alignment checks being done. The alignment check should have resulted in an UnalignedAddressException long before we ever got to Page.getLong(). However, we have the following override, which is allowing the unaligned address to pass the alignment check. >> >> >> public void checkAlignment(long address, long alignment) { >> // Need to override default checkAlignment because we need to >> // relax alignment constraints on Bsd/x86 >> if ( (address % alignment != 0) >> &&(alignment != 8 || address % 4 != 0)) { >> throw new UnalignedAddressException( >> "Trying to read at address: " >> + addressValueToString(address) >> + " with alignment: " + alignment, >> address); >> } >> } >> }; >> >> >> This allows a pointer to a 64-bit value to only be 32-bit aligned. But there's more to it than that. I modified ClhsdbFindPC.java to fetch a tid (a thread address), and did a findpc on the address OR'd with 0xffc. `findpc` uses PointerFinder. This forced a read of a 64-bit value that starts in the last 32-bits of a page. It passed on linux-x64 but failed on windowx-x64 in the same manner described in the description of this CR. The difference between the two implementations is that windows relies on the default implementation of DebuggerBase.readCInteger() whereas linux has an override. DebuggerBase.readCInteger() does the following: >> >> >> public long readCInteger(long address, long numBytes, boolean isUnsigned) { >> utils.checkAlignment(address, numBytes); >> if (useFastAccessors) { >> if (isUnsigned) { >> switch((int) numBytes) { >> case 1: return cache.getByte(address) & 0xFF; >> case 2: return cache.getShort(address, bigEndian) & 0xFFFF; >> case 4: return cache.getInt(address, bigEndian) & 0xFFFFFFFFL; >> case 8: return cache.getLong(address, bigEndian); >> ... >> >> >> There is an alignment check here, but it is the "relaxed" override shown above, which allows 64-bit addresses on 32-bit boundaries. The override in LinuxDebuggerLocal is: >> >> >> /** Need to override this to relax alignment checks on x86. */ >> public long readCInteger(long address, long numBytes, boolean isUnsigned) >> throws UnmappedAddressException, UnalignedAddressException { >> // Only slightly relaxed semantics -- this is a hack, but is >> // necessary on x86 where it seems the compiler is >> // putting some global 64-bit data on 32-bit boundaries >> if (numBytes == 8) { >> utils.checkAlignment(address, 4); >> } else { >> utils.checkAlignment(address, numBytes); >> } >> byte[] data = readBytes(address, numBytes); >> return utils.dataToCInteger(data, isUnsigned); >> >> >> Although there is a relaxed alignment check here also, the code that reads from the address does not assume all the bytes are on the same page. It uses readBytes() intead of cache.getLong(), so it won't run into the PageCache issue with reading a 64-bit value that starts in the last 32-bit word of a page. >> >> I think the introduction of these relaxed alignment checks has a muddled history, probably made more muddled by ports cloning code that maybe wasn't necessary. Probably also initial fixes (the relaxed alignment check) seemed to work at first, but later the PageCache issue was discovered, leading to readBytes() workaround in the LinuxDebuggerLocal.readCInteger() override, but was not also done on other ports (so we got this CR for windows). >> >> For 64-bit support it's clear this easing of the 64-bit alignment is not needed, and getting rid of it would result in the proper UnalignedAddressException being thrown. The question is whether it is still needed for 32-bit x86, and if so is it needed on all ports. >> >> I can't test linux-x86, so I can't tell if it still allows 64-bit values on 32-bit aligned addresses, so for now I'll assume it does. So the approach being taken is whenever an address of a 64-bit type points to the last 32-bit word of a page, use readBytes() to get the 64-bit value one byte at a time. It still uses the page cache in the end, but it doesn't try to get all 8 bytes from the same page. Note for 64-bit systems, the conditoin will never arise because of the removal of the relaxed alignment check. Instead there will be an UnalignedAddressException at an early point when the alignment check is made. >> >> One windfall of this change is now we always read 64-bit values from the page cache in a way that is much more efficient than reading a byte at a time. This has resulted in about a 25% performance improvement in a test I have that does a heap dump. > > Chris Plummer 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 > - Fix jcheck error > - Undo some temp test changes. > - Fix 64-bit alignment requirements src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java line 242: > 240: private boolean canUsePageCacheFor64bitRead(long address) { > 241: long pageMask = ~(pageSize - 1); > 242: if ((address & pageMask) != ((address + 4) & pageMask)) { This looks a bit over-complicated. Maybe something like ` long pageMask = pageSize - 1; if ((address & pageMask) > (pageSize - 8)) { return false; }` ------------- PR: https://git.openjdk.org/jdk/pull/10090 From amenkov at openjdk.org Thu Sep 1 20:21:11 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Sep 2022 20:21:11 GMT Subject: RFR: 8289400: Improve com/sun/jdi/TestScaffold error reporting In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 19:09:25 GMT, Chris Plummer wrote: > com/sun/jdi tests report errors by calling TestScaffold.failure(msg), which prints the failure message and sets the testFailed flag. At some later point the failure is detected and an exception is thrown. The end result is the exception has just has a vanilla message that says something like "TestXXX failed", and the backtrace is not indicative of where the failure occurred. If you have tools that search logs looking for exceptions to determine the reason for the failure, you likely won't find any. Here's an example: > > [2ms] run args: [SuspendAfterDeathTarg] > [514ms] FAILED: got Breakpoint event before ThreadDeath event. > java.lang.Exception: SuspendAfterDeath: failed > at SuspendAfterDeath.runTests(SuspendAfterDeath.java:110) > at TestScaffold.startTests(TestScaffold.java:432) > at SuspendAfterDeath.main(SuspendAfterDeath.java:47) > 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.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:1589) > > So the reason for the failure is clear (the "FAILED" message), but its stack trace is missing and the reason is not included in the exception message that is printed much later on. This PR adds printing of the stack trace at the time of the failure. test/jdk/com/sun/jdi/TestScaffold.java line 457: > 455: println(str); > 456: StackTraceElement[] trace = Thread.currentThread().getStackTrace(); > 457: for (StackTraceElement traceElement : trace) Please add curly braces around the cycle body ------------- PR: https://git.openjdk.org/jdk/pull/10127 From amenkov at openjdk.org Thu Sep 1 20:27:12 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Sep 2022 20:27:12 GMT Subject: RFR: JDK-8292066 Convert TestInputArgument.sh and TestSystemLoadAvg.sh to java version [v3] In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 22:39:06 GMT, Bill Huang wrote: >> This task converts 2 shell tests to java version. >> test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh >> test/java/lang/management/RuntimeMXBean/TestInputArgument.sh > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Implemented more review comments. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9848 From cjplummer at openjdk.org Thu Sep 1 21:11:09 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 21:11:09 GMT Subject: RFR: 8289400: Improve com/sun/jdi/TestScaffold error reporting [v2] In-Reply-To: References: Message-ID: > com/sun/jdi tests report errors by calling TestScaffold.failure(msg), which prints the failure message and sets the testFailed flag. At some later point the failure is detected and an exception is thrown. The end result is the exception has just has a vanilla message that says something like "TestXXX failed", and the backtrace is not indicative of where the failure occurred. If you have tools that search logs looking for exceptions to determine the reason for the failure, you likely won't find any. Here's an example: > > [2ms] run args: [SuspendAfterDeathTarg] > [514ms] FAILED: got Breakpoint event before ThreadDeath event. > java.lang.Exception: SuspendAfterDeath: failed > at SuspendAfterDeath.runTests(SuspendAfterDeath.java:110) > at TestScaffold.startTests(TestScaffold.java:432) > at SuspendAfterDeath.main(SuspendAfterDeath.java:47) > 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.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:1589) > > So the reason for the failure is clear (the "FAILED" message), but its stack trace is missing and the reason is not included in the exception message that is printed much later on. This PR adds printing of the stack trace at the time of the failure. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Add curly braces. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10127/files - new: https://git.openjdk.org/jdk/pull/10127/files/86e42e53..49cbaf6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10127&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10127&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10127.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10127/head:pull/10127 PR: https://git.openjdk.org/jdk/pull/10127 From cjplummer at openjdk.org Thu Sep 1 21:11:14 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 21:11:14 GMT Subject: RFR: 8289400: Improve com/sun/jdi/TestScaffold error reporting [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 20:15:04 GMT, Alex Menkov wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> Add curly braces. > > test/jdk/com/sun/jdi/TestScaffold.java line 457: > >> 455: println(str); >> 456: StackTraceElement[] trace = Thread.currentThread().getStackTrace(); >> 457: for (StackTraceElement traceElement : trace) > > Please add curly braces around the cycle body Ok. This was a copy-n-paste from Throwable.printStackTrace(), and I didn't noticed the omission when copying. ------------- PR: https://git.openjdk.org/jdk/pull/10127 From lmesnik at openjdk.org Thu Sep 1 21:21:30 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 1 Sep 2022 21:21:30 GMT Subject: RFR: 8283627: Outdated comment in MachineDescriptionTwosComplement.isLP64 [v2] In-Reply-To: References: <3phI4L8RUaBPkDovtGNk94bAtx7R_9Inj1_i0bpEq6k=.3a91baf2-b59a-4857-aa03-e8f07d1d2a60@github.com> Message-ID: On Thu, 1 Sep 2022 15:07:03 GMT, Daniel Skantz wrote: >> Update MachineDescriptionTwosComplement.java comment to indicate that LP64 machines are no longer uncommon. > > Daniel Skantz has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8283627 - Update MachineDescription.java > > JDK-8283627 - Update comment also in MachineDescription.java regarding LP64 (as noted by @plummercj, @sspitsyn) Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9967 From cjplummer at openjdk.org Thu Sep 1 21:21:31 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 21:21:31 GMT Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails with "'Thread "Common-Cleaner"' missing from stdout/stderr" [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 20:10:45 GMT, Alex Menkov wrote: >> Chris Plummer 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 >> - Fix jcheck error >> - Undo some temp test changes. >> - Fix 64-bit alignment requirements > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java line 242: > >> 240: private boolean canUsePageCacheFor64bitRead(long address) { >> 241: long pageMask = ~(pageSize - 1); >> 242: if ((address & pageMask) != ((address + 4) & pageMask)) { > > This looks a bit over-complicated. > Maybe something like > ` long pageMask = pageSize - 1; > if ((address & pageMask) > (pageSize - 8)) { > return false; > }` I tinkered with this code quite a bit before I had something that both worked and I liked. I don't know that your approach is actually any simpler, and at the moment I still prefer mine, but that might just be because I'm more familiar with it. However, it does seem that there should be a more elegant way of doing this. ------------- PR: https://git.openjdk.org/jdk/pull/10090 From lmesnik at openjdk.org Thu Sep 1 21:22:52 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 1 Sep 2022 21:22:52 GMT Subject: RFR: 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:47:05 GMT, Serguei Spitsyn wrote: > The problem is that the following assert in the JvmtiExport::post_object_free is wrong: > ` assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE), "checking");` > > Even though the condition was checked before, it can be changed later as it is racy by JVM TI design. > It has to be replaced with the check: > > if (!env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { > return; // the event type has been already disabled > } > > > In progress: mach5 nsk.jvmti and nsk.jdi test runs. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10109 From duke at openjdk.org Thu Sep 1 21:33:02 2022 From: duke at openjdk.org (Bill Huang) Date: Thu, 1 Sep 2022 21:33:02 GMT Subject: Integrated: JDK-8292066 Convert TestInputArgument.sh and TestSystemLoadAvg.sh to java version In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 21:12:08 GMT, Bill Huang wrote: > This task converts 2 shell tests to java version. > test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh > test/java/lang/management/RuntimeMXBean/TestInputArgument.sh This pull request has now been integrated. Changeset: 032be168 Author: Bill Huang Committer: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/032be168b5a6af6f9e82deb8c8cafcd2c44b5447 Stats: 222 lines in 4 files changed: 54 ins; 142 del; 26 mod 8292066: Convert TestInputArgument.sh and TestSystemLoadAvg.sh to java version Reviewed-by: lmesnik, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/9848 From amenkov at openjdk.org Thu Sep 1 21:50:12 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Sep 2022 21:50:12 GMT Subject: RFR: 8289400: Improve com/sun/jdi/TestScaffold error reporting [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 21:11:09 GMT, Chris Plummer wrote: >> com/sun/jdi tests report errors by calling TestScaffold.failure(msg), which prints the failure message and sets the testFailed flag. At some later point the failure is detected and an exception is thrown. The end result is the exception has just has a vanilla message that says something like "TestXXX failed", and the backtrace is not indicative of where the failure occurred. If you have tools that search logs looking for exceptions to determine the reason for the failure, you likely won't find any. Here's an example: >> >> >> [2ms] run args: [SuspendAfterDeathTarg] >> [514ms] FAILED: got Breakpoint event before ThreadDeath event. >> java.lang.Exception: SuspendAfterDeath: failed >> at SuspendAfterDeath.runTests(SuspendAfterDeath.java:110) >> at TestScaffold.startTests(TestScaffold.java:432) >> at SuspendAfterDeath.main(SuspendAfterDeath.java:47) >> 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.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:1589) >> >> >> So the reason for the failure is clear (the "FAILED" message), but its stack trace is missing and the reason is not included in the exception message that is printed much later on. This PR adds printing of the stack trace at the time of the failure. >> >> >> [2ms] run args: [SuspendAfterDeathTarg] >> [514ms] FAILED: got Breakpoint event before ThreadDeath event. >> at TestScaffold.failure(TestScaffold.java:455) >> at SuspendAfterDeath.breakpointReached(SuspendAfterDeath.java:64) >> at TestScaffold$EventHandler.notifyEvent(TestScaffold.java:194) >> at TestScaffold$EventHandler.run(TestScaffold.java:278) >> at java.base/java.lang.Thread.run(Thread.java:1589) >> java.lang.Exception: SuspendAfterDeath: failed >> at SuspendAfterDeath.runTests(SuspendAfterDeath.java:110) >> at TestScaffold.startTests(TestScaffold.java:432) >> at SuspendAfterDeath.main(SuspendAfterDeath.java:47) >> 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.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:1589) > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Add curly braces. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10127 From amenkov at openjdk.org Thu Sep 1 22:08:42 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Sep 2022 22:08:42 GMT Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails with "'Thread "Common-Cleaner"' missing from stdout/stderr" [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 17:20:33 GMT, Chris Plummer wrote: >> While dumping all registers (and doing a findpc on each), the following exception occurred for r8: >> >> >> r8: 0x000000750e4fdffc >> Error: java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 >> java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.Page.getLong(Page.java:182) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:364) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:312) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:71) >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:58) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) >> >> >> This exception is the result of using PointerFinder ("findpc") on invalid address that starts on the last 32-bit word of a page. "page" in this case is referring to a page in SA's PageCache, which are always 4k in size. Note findpc is frequently done using an invalid address. In this test case it is being called on each x64 register, which could contain anything. findpc relies on getting some sort of AddressException when this happens, and will then say the address points to something that is unknown. However, in the case of the address pointing to the last 32-bot word of a page, it results in an ArrayIndexOutOfBoundsException when the page cache tries to read past the end of the page. This is happening in Page.getLong(), which you can see in the stack trace. >> >> The main culprit here is some weakening of the alignment checks being done. The alignment check should have resulted in an UnalignedAddressException long before we ever got to Page.getLong(). However, we have the following override, which is allowing the unaligned address to pass the alignment check. >> >> >> public void checkAlignment(long address, long alignment) { >> // Need to override default checkAlignment because we need to >> // relax alignment constraints on Bsd/x86 >> if ( (address % alignment != 0) >> &&(alignment != 8 || address % 4 != 0)) { >> throw new UnalignedAddressException( >> "Trying to read at address: " >> + addressValueToString(address) >> + " with alignment: " + alignment, >> address); >> } >> } >> }; >> >> >> This allows a pointer to a 64-bit value to only be 32-bit aligned. But there's more to it than that. I modified ClhsdbFindPC.java to fetch a tid (a thread address), and did a findpc on the address OR'd with 0xffc. `findpc` uses PointerFinder. This forced a read of a 64-bit value that starts in the last 32-bits of a page. It passed on linux-x64 but failed on windowx-x64 in the same manner described in the description of this CR. The difference between the two implementations is that windows relies on the default implementation of DebuggerBase.readCInteger() whereas linux has an override. DebuggerBase.readCInteger() does the following: >> >> >> public long readCInteger(long address, long numBytes, boolean isUnsigned) { >> utils.checkAlignment(address, numBytes); >> if (useFastAccessors) { >> if (isUnsigned) { >> switch((int) numBytes) { >> case 1: return cache.getByte(address) & 0xFF; >> case 2: return cache.getShort(address, bigEndian) & 0xFFFF; >> case 4: return cache.getInt(address, bigEndian) & 0xFFFFFFFFL; >> case 8: return cache.getLong(address, bigEndian); >> ... >> >> >> There is an alignment check here, but it is the "relaxed" override shown above, which allows 64-bit addresses on 32-bit boundaries. The override in LinuxDebuggerLocal is: >> >> >> /** Need to override this to relax alignment checks on x86. */ >> public long readCInteger(long address, long numBytes, boolean isUnsigned) >> throws UnmappedAddressException, UnalignedAddressException { >> // Only slightly relaxed semantics -- this is a hack, but is >> // necessary on x86 where it seems the compiler is >> // putting some global 64-bit data on 32-bit boundaries >> if (numBytes == 8) { >> utils.checkAlignment(address, 4); >> } else { >> utils.checkAlignment(address, numBytes); >> } >> byte[] data = readBytes(address, numBytes); >> return utils.dataToCInteger(data, isUnsigned); >> >> >> Although there is a relaxed alignment check here also, the code that reads from the address does not assume all the bytes are on the same page. It uses readBytes() intead of cache.getLong(), so it won't run into the PageCache issue with reading a 64-bit value that starts in the last 32-bit word of a page. >> >> I think the introduction of these relaxed alignment checks has a muddled history, probably made more muddled by ports cloning code that maybe wasn't necessary. Probably also initial fixes (the relaxed alignment check) seemed to work at first, but later the PageCache issue was discovered, leading to readBytes() workaround in the LinuxDebuggerLocal.readCInteger() override, but was not also done on other ports (so we got this CR for windows). >> >> For 64-bit support it's clear this easing of the 64-bit alignment is not needed, and getting rid of it would result in the proper UnalignedAddressException being thrown. The question is whether it is still needed for 32-bit x86, and if so is it needed on all ports. >> >> I can't test linux-x86, so I can't tell if it still allows 64-bit values on 32-bit aligned addresses, so for now I'll assume it does. So the approach being taken is whenever an address of a 64-bit type points to the last 32-bit word of a page, use readBytes() to get the 64-bit value one byte at a time. It still uses the page cache in the end, but it doesn't try to get all 8 bytes from the same page. Note for 64-bit systems, the conditoin will never arise because of the removal of the relaxed alignment check. Instead there will be an UnalignedAddressException at an early point when the alignment check is made. >> >> One windfall of this change is now we always read 64-bit values from the page cache in a way that is much more efficient than reading a byte at a time. This has resulted in about a 25% performance improvement in a test I have that does a heap dump. > > Chris Plummer 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 > - Fix jcheck error > - Undo some temp test changes. > - Fix 64-bit alignment requirements Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10090 From amenkov at openjdk.org Thu Sep 1 22:08:43 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Sep 2022 22:08:43 GMT Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails with "'Thread "Common-Cleaner"' missing from stdout/stderr" [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 21:12:08 GMT, Chris Plummer wrote: >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java line 242: >> >>> 240: private boolean canUsePageCacheFor64bitRead(long address) { >>> 241: long pageMask = ~(pageSize - 1); >>> 242: if ((address & pageMask) != ((address + 4) & pageMask)) { >> >> This looks a bit over-complicated. >> Maybe something like >> ` long pageMask = pageSize - 1; >> if ((address & pageMask) > (pageSize - 8)) { >> return false; >> }` > > I tinkered with this code quite a bit before I had something that both worked and I liked. I don't know that your approach is actually any simpler, and at the moment I still prefer mine, but that might just be because I'm more familiar with it. However, it does seem that there should be a more elegant way of doing this. Your code works only for the exact case - address of 64bit value points to the last 32bit of the page. My idea is to use more generic approach - check that the whole value is in the page, i.e. this is special case of more common boolean canUsePageCacheForRead(long address, int bits) { long pageMask = pageSize - 1; return ((address & pageMask) <= (pageSize - bits/8)); } But I have no strong objections, feel free to keep your version ------------- PR: https://git.openjdk.org/jdk/pull/10090 From cjplummer at openjdk.org Thu Sep 1 22:25:53 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Sep 2022 22:25:53 GMT Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails with "'Thread "Common-Cleaner"' missing from stdout/stderr" [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 22:05:02 GMT, Alex Menkov wrote: > Your code works only for the exact case - address of 64bit value points to the last 32bit of the page. That's the only case we need to worry about. Any others would have already failed the alignment check. ------------- PR: https://git.openjdk.org/jdk/pull/10090 From jrose at openjdk.org Fri Sep 2 00:00:16 2022 From: jrose at openjdk.org (John R Rose) Date: Fri, 2 Sep 2022 00:00:16 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file Message-ID: Refactor code from inside of CompressedStream into its own unit. This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). Add gtests. ------------- Commit messages: - 8292758: put support for UNSIGNED5 format into its own header file Changes: https://git.openjdk.org/jdk/pull/10067/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292758 Stats: 935 lines in 8 files changed: 797 ins; 93 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/10067.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10067/head:pull/10067 PR: https://git.openjdk.org/jdk/pull/10067 From jrose at openjdk.org Fri Sep 2 00:00:16 2022 From: jrose at openjdk.org (John R Rose) Date: Fri, 2 Sep 2022 00:00:16 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 18:20:42 GMT, John R Rose wrote: > Refactor code from inside of CompressedStream into its own unit. > > This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). > > Add gtests. This code passes tiers 1,2,3. ------------- PR: https://git.openjdk.org/jdk/pull/10067 From jrose at openjdk.org Fri Sep 2 00:04:17 2022 From: jrose at openjdk.org (John R Rose) Date: Fri, 2 Sep 2022 00:04:17 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: References: Message-ID: > Refactor code from inside of CompressedStream into its own unit. > > This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). > > Add gtests. John R Rose has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' of https://git.openjdk.org/jdk into compressed-stream - 8292758: put support for UNSIGNED5 format into its own header file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10067/files - new: https://git.openjdk.org/jdk/pull/10067/files/e938b018..d903f2c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=00-01 Stats: 9272 lines in 306 files changed: 2846 ins; 5909 del; 517 mod Patch: https://git.openjdk.org/jdk/pull/10067.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10067/head:pull/10067 PR: https://git.openjdk.org/jdk/pull/10067 From jrose at openjdk.org Fri Sep 2 00:08:09 2022 From: jrose at openjdk.org (John R Rose) Date: Fri, 2 Sep 2022 00:08:09 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 00:04:17 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' of https://git.openjdk.org/jdk into compressed-stream > - 8292758: put support for UNSIGNED5 format into its own header file The new header file presents the encoding algorithm by means of templates. The template arguments in general are: - `ARY` - a logical base address for reads and writes of bytes - `OFF` - an integral type (of any size or signed-ness) providing an offset to `ARY` - `GET` and `SET` - function-like arguments (e.g., lambdas) which get or set bytes from an address logically of the form `a[i]` shaped like `ARY[OFF]` - `GFN` a lambda used when the application requires on-the fly resizing of an output buffer (of type `ARY`) Defaults are set in such a way that any C++ types that natively support `a[i]` can be fully inferred, including the get/set behaviors. In addition, there are small "gadgets" for reading a series of ints from a buffer, writing a series to a buffer, and sizing a series (which is faster than writing or reading). These are not yet used. However, prototyping of further use cases for this compression (particularly, `FieldInfo`) makes it clear that these are repeated tasks that "canned" templates will help with. ------------- PR: https://git.openjdk.org/jdk/pull/10067 From sspitsyn at openjdk.org Fri Sep 2 01:15:54 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 2 Sep 2022 01:15:54 GMT Subject: RFR: 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:47:05 GMT, Serguei Spitsyn wrote: > The problem is that the following assert in the JvmtiExport::post_object_free is wrong: > ` assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE), "checking");` > > Even though the condition was checked before, it can be changed later as it is racy by JVM TI design. > It has to be replaced with the check: > > if (!env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { > return; // the event type has been already disabled > } > > > In progress: mach5 nsk.jvmti and nsk.jdi test runs. Chris, Zhengyu and Leonid, thank you for review! ------------- PR: https://git.openjdk.org/jdk/pull/10109 From dlong at openjdk.org Fri Sep 2 01:54:45 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 2 Sep 2022 01:54:45 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: References: Message-ID: <0IH0pSQJ9vkKzJh4rYlEMTx_0X5wNbVhkXNp5p_q3cw=.a7efccaf-700c-4b53-a87c-5e9cb89abf15@github.com> On Fri, 2 Sep 2022 00:04:17 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' of https://git.openjdk.org/jdk into compressed-stream > - 8292758: put support for UNSIGNED5 format into its own header file src/hotspot/share/code/compressedStream.cpp line 85: > 83: const int min_expansion = UNSIGNED5::MAX_LENGTH; > 84: if (nsize < min_expansion*2) > 85: nsize = min_expansion*2; It's not clear if this is needed or just an optimization. Maybe add a comment. Also, using MIN2 might be clearer. ------------- PR: https://git.openjdk.org/jdk/pull/10067 From sspitsyn at openjdk.org Fri Sep 2 01:55:43 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 2 Sep 2022 01:55:43 GMT Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails with "'Thread "Common-Cleaner"' missing from stdout/stderr" [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 17:20:33 GMT, Chris Plummer wrote: >> While dumping all registers (and doing a findpc on each), the following exception occurred for r8: >> >> >> r8: 0x000000750e4fdffc >> Error: java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 >> java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.Page.getLong(Page.java:182) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:364) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:312) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:71) >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:58) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) >> >> >> This exception is the result of using PointerFinder ("findpc") on invalid address that starts on the last 32-bit word of a page. "page" in this case is referring to a page in SA's PageCache, which are always 4k in size. Note findpc is frequently done using an invalid address. In this test case it is being called on each x64 register, which could contain anything. findpc relies on getting some sort of AddressException when this happens, and will then say the address points to something that is unknown. However, in the case of the address pointing to the last 32-bot word of a page, it results in an ArrayIndexOutOfBoundsException when the page cache tries to read past the end of the page. This is happening in Page.getLong(), which you can see in the stack trace. >> >> The main culprit here is some weakening of the alignment checks being done. The alignment check should have resulted in an UnalignedAddressException long before we ever got to Page.getLong(). However, we have the following override, which is allowing the unaligned address to pass the alignment check. >> >> >> public void checkAlignment(long address, long alignment) { >> // Need to override default checkAlignment because we need to >> // relax alignment constraints on Bsd/x86 >> if ( (address % alignment != 0) >> &&(alignment != 8 || address % 4 != 0)) { >> throw new UnalignedAddressException( >> "Trying to read at address: " >> + addressValueToString(address) >> + " with alignment: " + alignment, >> address); >> } >> } >> }; >> >> >> This allows a pointer to a 64-bit value to only be 32-bit aligned. But there's more to it than that. I modified ClhsdbFindPC.java to fetch a tid (a thread address), and did a findpc on the address OR'd with 0xffc. `findpc` uses PointerFinder. This forced a read of a 64-bit value that starts in the last 32-bits of a page. It passed on linux-x64 but failed on windowx-x64 in the same manner described in the description of this CR. The difference between the two implementations is that windows relies on the default implementation of DebuggerBase.readCInteger() whereas linux has an override. DebuggerBase.readCInteger() does the following: >> >> >> public long readCInteger(long address, long numBytes, boolean isUnsigned) { >> utils.checkAlignment(address, numBytes); >> if (useFastAccessors) { >> if (isUnsigned) { >> switch((int) numBytes) { >> case 1: return cache.getByte(address) & 0xFF; >> case 2: return cache.getShort(address, bigEndian) & 0xFFFF; >> case 4: return cache.getInt(address, bigEndian) & 0xFFFFFFFFL; >> case 8: return cache.getLong(address, bigEndian); >> ... >> >> >> There is an alignment check here, but it is the "relaxed" override shown above, which allows 64-bit addresses on 32-bit boundaries. The override in LinuxDebuggerLocal is: >> >> >> /** Need to override this to relax alignment checks on x86. */ >> public long readCInteger(long address, long numBytes, boolean isUnsigned) >> throws UnmappedAddressException, UnalignedAddressException { >> // Only slightly relaxed semantics -- this is a hack, but is >> // necessary on x86 where it seems the compiler is >> // putting some global 64-bit data on 32-bit boundaries >> if (numBytes == 8) { >> utils.checkAlignment(address, 4); >> } else { >> utils.checkAlignment(address, numBytes); >> } >> byte[] data = readBytes(address, numBytes); >> return utils.dataToCInteger(data, isUnsigned); >> >> >> Although there is a relaxed alignment check here also, the code that reads from the address does not assume all the bytes are on the same page. It uses readBytes() intead of cache.getLong(), so it won't run into the PageCache issue with reading a 64-bit value that starts in the last 32-bit word of a page. >> >> I think the introduction of these relaxed alignment checks has a muddled history, probably made more muddled by ports cloning code that maybe wasn't necessary. Probably also initial fixes (the relaxed alignment check) seemed to work at first, but later the PageCache issue was discovered, leading to readBytes() workaround in the LinuxDebuggerLocal.readCInteger() override, but was not also done on other ports (so we got this CR for windows). >> >> For 64-bit support it's clear this easing of the 64-bit alignment is not needed, and getting rid of it would result in the proper UnalignedAddressException being thrown. The question is whether it is still needed for 32-bit x86, and if so is it needed on all ports. >> >> I can't test linux-x86, so I can't tell if it still allows 64-bit values on 32-bit aligned addresses, so for now I'll assume it does. So the approach being taken is whenever an address of a 64-bit type points to the last 32-bit word of a page, use readBytes() to get the 64-bit value one byte at a time. It still uses the page cache in the end, but it doesn't try to get all 8 bytes from the same page. Note for 64-bit systems, the conditoin will never arise because of the removal of the relaxed alignment check. Instead there will be an UnalignedAddressException at an early point when the alignment check is made. >> >> One windfall of this change is now we always read 64-bit values from the page cache in a way that is much more efficient than reading a byte at a time. This has resulted in about a 25% performance improvement in a test I have that does a heap dump. > > Chris Plummer 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 > - Fix jcheck error > - Undo some temp test changes. > - Fix 64-bit alignment requirements This looks okay to me. Thanks, Serguei src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/DebuggerUtilities.java line 64: > 62: return; > 63: } > 64: } The indent above has to be 2. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10090 From sspitsyn at openjdk.org Fri Sep 2 02:03:48 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 2 Sep 2022 02:03:48 GMT Subject: Integrated: 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails: assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:47:05 GMT, Serguei Spitsyn wrote: > The problem is that the following assert in the JvmtiExport::post_object_free is wrong: > ` assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE), "checking");` > > Even though the condition was checked before, it can be changed later as it is racy by JVM TI design. > It has to be replaced with the check: > > if (!env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { > return; // the event type has been already disabled > } > > > In progress: mach5 nsk.jvmti and nsk.jdi test runs. This pull request has now been integrated. Changeset: 99c3ab01 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/99c3ab01773fcab885aa041345aab1a1ad4d852f Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8293010: JDI ObjectReference/referringObjects/referringObjects001 fails: assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking Reviewed-by: cjplummer, zgu, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/10109 From cjplummer at openjdk.org Fri Sep 2 03:20:56 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Sep 2022 03:20:56 GMT Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails with "'Thread "Common-Cleaner"' missing from stdout/stderr" [v3] In-Reply-To: References: Message-ID: > While dumping all registers (and doing a findpc on each), the following exception occurred for r8: > > > r8: 0x000000750e4fdffc > Error: java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 > java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.Page.getLong(Page.java:182) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:364) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:312) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:71) > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:58) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) > > > This exception is the result of using PointerFinder ("findpc") on invalid address that starts on the last 32-bit word of a page. "page" in this case is referring to a page in SA's PageCache, which are always 4k in size. Note findpc is frequently done using an invalid address. In this test case it is being called on each x64 register, which could contain anything. findpc relies on getting some sort of AddressException when this happens, and will then say the address points to something that is unknown. However, in the case of the address pointing to the last 32-bot word of a page, it results in an ArrayIndexOutOfBoundsException when the page cache tries to read past the end of the page. This is happening in Page.getLong(), which you can see in the stack trace. > > The main culprit here is some weakening of the alignment checks being done. The alignment check should have resulted in an UnalignedAddressException long before we ever got to Page.getLong(). However, we have the following override, which is allowing the unaligned address to pass the alignment check. > > > public void checkAlignment(long address, long alignment) { > // Need to override default checkAlignment because we need to > // relax alignment constraints on Bsd/x86 > if ( (address % alignment != 0) > &&(alignment != 8 || address % 4 != 0)) { > throw new UnalignedAddressException( > "Trying to read at address: " > + addressValueToString(address) > + " with alignment: " + alignment, > address); > } > } > }; > > > This allows a pointer to a 64-bit value to only be 32-bit aligned. But there's more to it than that. I modified ClhsdbFindPC.java to fetch a tid (a thread address), and did a findpc on the address OR'd with 0xffc. `findpc` uses PointerFinder. This forced a read of a 64-bit value that starts in the last 32-bits of a page. It passed on linux-x64 but failed on windowx-x64 in the same manner described in the description of this CR. The difference between the two implementations is that windows relies on the default implementation of DebuggerBase.readCInteger() whereas linux has an override. DebuggerBase.readCInteger() does the following: > > > public long readCInteger(long address, long numBytes, boolean isUnsigned) { > utils.checkAlignment(address, numBytes); > if (useFastAccessors) { > if (isUnsigned) { > switch((int) numBytes) { > case 1: return cache.getByte(address) & 0xFF; > case 2: return cache.getShort(address, bigEndian) & 0xFFFF; > case 4: return cache.getInt(address, bigEndian) & 0xFFFFFFFFL; > case 8: return cache.getLong(address, bigEndian); > ... > > > There is an alignment check here, but it is the "relaxed" override shown above, which allows 64-bit addresses on 32-bit boundaries. The override in LinuxDebuggerLocal is: > > > /** Need to override this to relax alignment checks on x86. */ > public long readCInteger(long address, long numBytes, boolean isUnsigned) > throws UnmappedAddressException, UnalignedAddressException { > // Only slightly relaxed semantics -- this is a hack, but is > // necessary on x86 where it seems the compiler is > // putting some global 64-bit data on 32-bit boundaries > if (numBytes == 8) { > utils.checkAlignment(address, 4); > } else { > utils.checkAlignment(address, numBytes); > } > byte[] data = readBytes(address, numBytes); > return utils.dataToCInteger(data, isUnsigned); > > > Although there is a relaxed alignment check here also, the code that reads from the address does not assume all the bytes are on the same page. It uses readBytes() intead of cache.getLong(), so it won't run into the PageCache issue with reading a 64-bit value that starts in the last 32-bit word of a page. > > I think the introduction of these relaxed alignment checks has a muddled history, probably made more muddled by ports cloning code that maybe wasn't necessary. Probably also initial fixes (the relaxed alignment check) seemed to work at first, but later the PageCache issue was discovered, leading to readBytes() workaround in the LinuxDebuggerLocal.readCInteger() override, but was not also done on other ports (so we got this CR for windows). > > For 64-bit support it's clear this easing of the 64-bit alignment is not needed, and getting rid of it would result in the proper UnalignedAddressException being thrown. The question is whether it is still needed for 32-bit x86, and if so is it needed on all ports. > > I can't test linux-x86, so I can't tell if it still allows 64-bit values on 32-bit aligned addresses, so for now I'll assume it does. So the approach being taken is whenever an address of a 64-bit type points to the last 32-bit word of a page, use readBytes() to get the 64-bit value one byte at a time. It still uses the page cache in the end, but it doesn't try to get all 8 bytes from the same page. Note for 64-bit systems, the conditoin will never arise because of the removal of the relaxed alignment check. Instead there will be an UnalignedAddressException at an early point when the alignment check is made. > > One windfall of this change is now we always read 64-bit values from the page cache in a way that is much more efficient than reading a byte at a time. This has resulted in about a 25% performance improvement in a test I have that does a heap dump. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Fix indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10090/files - new: https://git.openjdk.org/jdk/pull/10090/files/9f8bcf20..61b6b908 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10090&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10090&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10090.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10090/head:pull/10090 PR: https://git.openjdk.org/jdk/pull/10090 From dholmes at openjdk.org Fri Sep 2 05:30:42 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 2 Sep 2022 05:30:42 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, add assert. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10043 From dholmes at openjdk.org Fri Sep 2 05:30:43 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 2 Sep 2022 05:30:43 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> <6WXzI0rm-YVn2NO-wJpFokTRrihFQtSpIIoWHb7-BWA=.7ec7ea33-c104-4686-b6db-071d4c31d5ae@github.com> <1SP_BMq5WR8aEaDrOltFkrf3ArzSTd0yZrjt9DfIkmg=.da033eb4-8b71-4fce-a3e2-d2ec1021b6e4@github.com> Message-ID: On Thu, 1 Sep 2022 12:29:41 GMT, Coleen Phillimore wrote: >> Since I know what this table does, either comment is fine if it helps someone understand it. >> The "map each PD to itself" is pretty odd to me too. How about collect each PD for fast lookup in a hashtable? The code says how it's mapped. There isn't that much code and it's easy to see how the Key is mapped. > > // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are > // registered by DictionaryEntry::add_protection_domain() to a unique entry. The entry > // is a WeakHandle that holds the protection domain oop. > > or points to.... either is accurate. It is the "maps ... to a unique entry" that I find most problematic - it begs the question as to what the unique entry is, when in reality it maps a PD instance (wrapped in a WeakHandle) to itself (wrapped in a WeakHandle). For the sake of progress, approved. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From alanb at openjdk.org Fri Sep 2 05:42:53 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 2 Sep 2022 05:42:53 GMT Subject: RFR: 8289400: Improve com/sun/jdi/TestScaffold error reporting [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 21:11:09 GMT, Chris Plummer wrote: >> com/sun/jdi tests report errors by calling TestScaffold.failure(msg), which prints the failure message and sets the testFailed flag. At some later point the failure is detected and an exception is thrown. The end result is the exception has just has a vanilla message that says something like "TestXXX failed", and the backtrace is not indicative of where the failure occurred. If you have tools that search logs looking for exceptions to determine the reason for the failure, you likely won't find any. Here's an example: >> >> >> [2ms] run args: [SuspendAfterDeathTarg] >> [514ms] FAILED: got Breakpoint event before ThreadDeath event. >> java.lang.Exception: SuspendAfterDeath: failed >> at SuspendAfterDeath.runTests(SuspendAfterDeath.java:110) >> at TestScaffold.startTests(TestScaffold.java:432) >> at SuspendAfterDeath.main(SuspendAfterDeath.java:47) >> 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.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:1589) >> >> >> So the reason for the failure is clear (the "FAILED" message), but its stack trace is missing and the reason is not included in the exception message that is printed much later on. This PR adds printing of the stack trace at the time of the failure. >> >> >> [2ms] run args: [SuspendAfterDeathTarg] >> [514ms] FAILED: got Breakpoint event before ThreadDeath event. >> at TestScaffold.failure(TestScaffold.java:455) >> at SuspendAfterDeath.breakpointReached(SuspendAfterDeath.java:64) >> at TestScaffold$EventHandler.notifyEvent(TestScaffold.java:194) >> at TestScaffold$EventHandler.run(TestScaffold.java:278) >> at java.base/java.lang.Thread.run(Thread.java:1589) >> java.lang.Exception: SuspendAfterDeath: failed >> at SuspendAfterDeath.runTests(SuspendAfterDeath.java:110) >> at TestScaffold.startTests(TestScaffold.java:432) >> at SuspendAfterDeath.main(SuspendAfterDeath.java:47) >> 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.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:1589) > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Add curly braces. test/jdk/com/sun/jdi/TestScaffold.java line 459: > 457: for (StackTraceElement traceElement : trace) { > 458: System.err.println("\tat " + traceElement); > 459: } Thread.dumpStack() prints to System.errr. ------------- PR: https://git.openjdk.org/jdk/pull/10127 From iklam at openjdk.org Fri Sep 2 05:45:42 2022 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 2 Sep 2022 05:45:42 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, add assert. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10043 From cjplummer at openjdk.org Fri Sep 2 06:17:43 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Sep 2022 06:17:43 GMT Subject: RFR: 8289400: Improve com/sun/jdi/TestScaffold error reporting [v2] In-Reply-To: References: Message-ID: <6fW5VwhMaa6El7FB3atdljrdm7g4Y7reOqalZg2Eq2Y=.79cf484e-ff4a-4f3f-adb2-baac7f5c5fbf@github.com> On Fri, 2 Sep 2022 05:40:38 GMT, Alan Bateman wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> Add curly braces. > > test/jdk/com/sun/jdi/TestScaffold.java line 459: > >> 457: for (StackTraceElement traceElement : trace) { >> 458: System.err.println("\tat " + traceElement); >> 459: } > > Thread.dumpStack() prints to System.errr. But it does so by creating an Exception and calling printStackTrace() on it. I didn't want that because it includes the Exception itself in the output, not just the stack trace. ------------- PR: https://git.openjdk.org/jdk/pull/10127 From stefank at openjdk.org Fri Sep 2 09:58:18 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 2 Sep 2022 09:58:18 GMT Subject: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT Message-ID: During the discussion of [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was voiced that we should stop using INTPTR_FORMAT when printing pointers. Some background that could explain why some tend to use INTPTR_FORMAT instead of PTR_FORMAT: Both those format specifiers require an integer and the compiler barfs if you send in a pointer. We therefore have a utility function named p2i, which converts the pointer to an integer. So, everywhere we have to write print line like this: `print("my pointer: " PTR_FORMAT, p2i(my_pointer));`. Now, p2i returns an intptr_t, and it becomes natural for some to consider the type of the converted value (that we need because of the mentioned workaround), instead of the original type of the value. With this enhancement I'd like to clean up the code that I often work in, so that it uses PTR_FORMAT when printing pointers. I'm leaving the rest of the code base for others to consider cleaning up. Cleanups have been done in directories gc/, utilities/, memory/, and oops/. ------------- Commit messages: - Fix oops/ - Fix memory/ - Fix utilities/ - Fix gc/ - Add SIZE_FORMAT_X_0 Changes: https://git.openjdk.org/jdk/pull/10141/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10141&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293304 Stats: 125 lines in 39 files changed: 6 ins; 0 del; 119 mod Patch: https://git.openjdk.org/jdk/pull/10141.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10141/head:pull/10141 PR: https://git.openjdk.org/jdk/pull/10141 From coleenp at openjdk.org Fri Sep 2 13:09:03 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 Sep 2022 13:09:03 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> Message-ID: On Wed, 31 Aug 2022 12:39:08 GMT, Coleen Phillimore wrote: >> Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. >> Also tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments, add assert. Thank you David and Ioi for approving and reviewing. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Fri Sep 2 13:09:03 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 Sep 2022 13:09:03 GMT Subject: RFR: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable [v7] In-Reply-To: References: <6g6ZOkhjlfeUVtB-a0_3gXt0mI-6qeHr6FtCo1vHABs=.dd86b1a2-a55f-43f1-9cbf-2d25c5bb6dc3@github.com> <6WXzI0rm-YVn2NO-wJpFokTRrihFQtSpIIoWHb7-BWA=.7ec7ea33-c104-4686-b6db-071d4c31d5ae@github.com> <1SP_BMq5WR8aEaDrOltFkrf3ArzSTd0yZrjt9DfIkmg=.da033eb4-8b71-4fce-a3e2-d2ec1021b6e4@github.com> Message-ID: On Fri, 2 Sep 2022 05:26:45 GMT, David Holmes wrote: >> // The ProtectionDomainCacheTable maps all java.security.ProtectionDomain objects that are >> // registered by DictionaryEntry::add_protection_domain() to a unique entry. The entry >> // is a WeakHandle that holds the protection domain oop. >> >> or points to.... either is accurate. > > It is the "maps ... to a unique entry" that I find most problematic - it begs the question as to what the unique entry is, when in reality it maps a PD instance (wrapped in a WeakHandle) to itself (wrapped in a WeakHandle). > > For the sake of progress, approved. The "unique" means there's only one value in the table for this protection domain oop. So the oop is unique. The use of word "mapping" might be what's confusing. If we ever have to visit this code again (which I hope not, except to remove it because the security manager is finally removed since not many use it), we can see if this comment still makes sense to at least some of us. Thanks for approving for progress. ------------- PR: https://git.openjdk.org/jdk/pull/10043 From coleenp at openjdk.org Fri Sep 2 13:11:48 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 Sep 2022 13:11:48 GMT Subject: Integrated: 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 13:43:00 GMT, Coleen Phillimore wrote: > Please review this simple conversion for the ProtectionDomainCacheTable from Old Hashtable to ResourceHashtable. There are specific tests for this table in test/hotspot/jtreg/runtime/Dictionary and serviceability/dcmd/vm/DictionaryStatsTest.java. > Also tested with tier1-7. This pull request has now been integrated. Changeset: fcc0cf96 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/fcc0cf96772644ece6430eee93fb018c3432135b Stats: 260 lines in 9 files changed: 58 ins; 127 del; 75 mod 8292375: Convert ProtectionDomainCacheTable to ResourceHashtable Reviewed-by: dholmes, iklam ------------- PR: https://git.openjdk.org/jdk/pull/10043 From kevinw at openjdk.org Fri Sep 2 15:09:47 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 2 Sep 2022 15:09:47 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread Message-ID: This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). A JVMTI operation could call threadObj() and clear the Windows GetLastError value. Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. ------------- Commit messages: - chmod - whitespace - 8292302: GetLastError value overwritten when running in debugger Changes: https://git.openjdk.org/jdk/pull/10147/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10147&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292302 Stats: 102 lines in 3 files changed: 98 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10147.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10147/head:pull/10147 PR: https://git.openjdk.org/jdk/pull/10147 From lmesnik at openjdk.org Fri Sep 2 15:11:45 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 2 Sep 2022 15:11:45 GMT Subject: RFR: 8289400: Improve com/sun/jdi/TestScaffold error reporting [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 21:11:09 GMT, Chris Plummer wrote: >> com/sun/jdi tests report errors by calling TestScaffold.failure(msg), which prints the failure message and sets the testFailed flag. At some later point the failure is detected and an exception is thrown. The end result is the exception has just has a vanilla message that says something like "TestXXX failed", and the backtrace is not indicative of where the failure occurred. If you have tools that search logs looking for exceptions to determine the reason for the failure, you likely won't find any. Here's an example: >> >> >> [2ms] run args: [SuspendAfterDeathTarg] >> [514ms] FAILED: got Breakpoint event before ThreadDeath event. >> java.lang.Exception: SuspendAfterDeath: failed >> at SuspendAfterDeath.runTests(SuspendAfterDeath.java:110) >> at TestScaffold.startTests(TestScaffold.java:432) >> at SuspendAfterDeath.main(SuspendAfterDeath.java:47) >> 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.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:1589) >> >> >> So the reason for the failure is clear (the "FAILED" message), but its stack trace is missing and the reason is not included in the exception message that is printed much later on. This PR adds printing of the stack trace at the time of the failure. >> >> >> [2ms] run args: [SuspendAfterDeathTarg] >> [514ms] FAILED: got Breakpoint event before ThreadDeath event. >> at TestScaffold.failure(TestScaffold.java:455) >> at SuspendAfterDeath.breakpointReached(SuspendAfterDeath.java:64) >> at TestScaffold$EventHandler.notifyEvent(TestScaffold.java:194) >> at TestScaffold$EventHandler.run(TestScaffold.java:278) >> at java.base/java.lang.Thread.run(Thread.java:1589) >> java.lang.Exception: SuspendAfterDeath: failed >> at SuspendAfterDeath.runTests(SuspendAfterDeath.java:110) >> at TestScaffold.startTests(TestScaffold.java:432) >> at SuspendAfterDeath.main(SuspendAfterDeath.java:47) >> 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.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:1589) > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Add curly braces. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10127 From cjplummer at openjdk.org Fri Sep 2 16:07:50 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Sep 2022 16:07:50 GMT Subject: RFR: 8289400: Improve com/sun/jdi/TestScaffold error reporting [v2] In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 21:11:09 GMT, Chris Plummer wrote: >> com/sun/jdi tests report errors by calling TestScaffold.failure(msg), which prints the failure message and sets the testFailed flag. At some later point the failure is detected and an exception is thrown. The end result is the exception has just has a vanilla message that says something like "TestXXX failed", and the backtrace is not indicative of where the failure occurred. If you have tools that search logs looking for exceptions to determine the reason for the failure, you likely won't find any. Here's an example: >> >> >> [2ms] run args: [SuspendAfterDeathTarg] >> [514ms] FAILED: got Breakpoint event before ThreadDeath event. >> java.lang.Exception: SuspendAfterDeath: failed >> at SuspendAfterDeath.runTests(SuspendAfterDeath.java:110) >> at TestScaffold.startTests(TestScaffold.java:432) >> at SuspendAfterDeath.main(SuspendAfterDeath.java:47) >> 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.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:1589) >> >> >> So the reason for the failure is clear (the "FAILED" message), but its stack trace is missing and the reason is not included in the exception message that is printed much later on. This PR adds printing of the stack trace at the time of the failure. >> >> >> [2ms] run args: [SuspendAfterDeathTarg] >> [514ms] FAILED: got Breakpoint event before ThreadDeath event. >> at TestScaffold.failure(TestScaffold.java:455) >> at SuspendAfterDeath.breakpointReached(SuspendAfterDeath.java:64) >> at TestScaffold$EventHandler.notifyEvent(TestScaffold.java:194) >> at TestScaffold$EventHandler.run(TestScaffold.java:278) >> at java.base/java.lang.Thread.run(Thread.java:1589) >> java.lang.Exception: SuspendAfterDeath: failed >> at SuspendAfterDeath.runTests(SuspendAfterDeath.java:110) >> at TestScaffold.startTests(TestScaffold.java:432) >> at SuspendAfterDeath.main(SuspendAfterDeath.java:47) >> 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.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:1589) > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Add curly braces. Thanks Alex and Leonid! ------------- PR: https://git.openjdk.org/jdk/pull/10127 From cjplummer at openjdk.org Fri Sep 2 16:10:51 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Sep 2022 16:10:51 GMT Subject: Integrated: 8289400: Improve com/sun/jdi/TestScaffold error reporting In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 19:09:25 GMT, Chris Plummer wrote: > com/sun/jdi tests report errors by calling TestScaffold.failure(msg), which prints the failure message and sets the testFailed flag. At some later point the failure is detected and an exception is thrown. The end result is the exception has just has a vanilla message that says something like "TestXXX failed", and the backtrace is not indicative of where the failure occurred. If you have tools that search logs looking for exceptions to determine the reason for the failure, you likely won't find any. Here's an example: > > > [2ms] run args: [SuspendAfterDeathTarg] > [514ms] FAILED: got Breakpoint event before ThreadDeath event. > java.lang.Exception: SuspendAfterDeath: failed > at SuspendAfterDeath.runTests(SuspendAfterDeath.java:110) > at TestScaffold.startTests(TestScaffold.java:432) > at SuspendAfterDeath.main(SuspendAfterDeath.java:47) > 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.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:1589) > > > So the reason for the failure is clear (the "FAILED" message), but its stack trace is missing and the reason is not included in the exception message that is printed much later on. This PR adds printing of the stack trace at the time of the failure. > > > [2ms] run args: [SuspendAfterDeathTarg] > [514ms] FAILED: got Breakpoint event before ThreadDeath event. > at TestScaffold.failure(TestScaffold.java:455) > at SuspendAfterDeath.breakpointReached(SuspendAfterDeath.java:64) > at TestScaffold$EventHandler.notifyEvent(TestScaffold.java:194) > at TestScaffold$EventHandler.run(TestScaffold.java:278) > at java.base/java.lang.Thread.run(Thread.java:1589) > java.lang.Exception: SuspendAfterDeath: failed > at SuspendAfterDeath.runTests(SuspendAfterDeath.java:110) > at TestScaffold.startTests(TestScaffold.java:432) > at SuspendAfterDeath.main(SuspendAfterDeath.java:47) > 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.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:1589) This pull request has now been integrated. Changeset: da99e3e8 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/da99e3e8299f3a476603aa43a99164c2c01adff4 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8289400: Improve com/sun/jdi/TestScaffold error reporting Reviewed-by: amenkov, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/10127 From cjplummer at openjdk.org Fri Sep 2 16:11:58 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Sep 2022 16:11:58 GMT Subject: RFR: 8293006: sun/tools/jhsdb/JStackStressTest.java fails with "UnalignedAddressException: 8baadbabe" [v2] In-Reply-To: <5kZUqNKyadWd8IrTcFFC8jIdfNcDNWAp4OJXBDzZ3Co=.eddffd92-5cdc-4993-945c-d6c42f239933@github.com> References: <30MiZ6W_yFw0pgh8t8LUcoeUPllcUgjlUmzIE7-UJhU=.46a806ca-006e-43be-b1db-76277242f2b9@github.com> <5kZUqNKyadWd8IrTcFFC8jIdfNcDNWAp4OJXBDzZ3Co=.eddffd92-5cdc-4993-945c-d6c42f239933@github.com> Message-ID: On Thu, 1 Sep 2022 18:28:58 GMT, Chris Plummer wrote: >> The root cause of this CR is that we are trying to access the java heap during the middle of a GC. This particular test is prone to that happening since it runs jstack 4 times on the debuggee as it starts up (the debuggee is jshell, so it does a lot of initialization on startup). >> >> SA needs to deal with potentially bad references to java objects. These might come from VM structs (such as the JavaThread reference to its java Thread instance), or a java object reference from a field of another java objects. There's always the possibility that these can be invalid. We work around this in most of our testing by getting the debuggee into a steady state so no GC can be in progress. >> >> For the most part SA is pretty good about dealing with these bad object references, and fails gracefully with an exception, but otherwise continues to run. However, this test exposed some holes that resulted in (1) way to many exception stack traces and (2) exiting the SA tool rather than trying to continue. >> >> The main fix is in JavaThread.printThreadInfo() where we now do a better job of dealing with exceptions if any of the java objects references are not valid. Even without access to the Thread instance, we can still produce a stack trace, but it will be missing things like the thread name and priority. This is a lot better than just giving up with the first exception. >> >> The other changes are for the most part just improvements in the error output, and getting rid of the printStackTrace() that was cluttering up the output. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Minor indent, spelling, and formatting fixes Thanks Dan and Serguei! ------------- PR: https://git.openjdk.org/jdk/pull/10088 From cjplummer at openjdk.org Fri Sep 2 16:14:52 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Sep 2022 16:14:52 GMT Subject: Integrated: 8293006: sun/tools/jhsdb/JStackStressTest.java fails with "UnalignedAddressException: 8baadbabe" In-Reply-To: <30MiZ6W_yFw0pgh8t8LUcoeUPllcUgjlUmzIE7-UJhU=.46a806ca-006e-43be-b1db-76277242f2b9@github.com> References: <30MiZ6W_yFw0pgh8t8LUcoeUPllcUgjlUmzIE7-UJhU=.46a806ca-006e-43be-b1db-76277242f2b9@github.com> Message-ID: On Tue, 30 Aug 2022 23:29:18 GMT, Chris Plummer wrote: > The root cause of this CR is that we are trying to access the java heap during the middle of a GC. This particular test is prone to that happening since it runs jstack 4 times on the debuggee as it starts up (the debuggee is jshell, so it does a lot of initialization on startup). > > SA needs to deal with potentially bad references to java objects. These might come from VM structs (such as the JavaThread reference to its java Thread instance), or a java object reference from a field of another java objects. There's always the possibility that these can be invalid. We work around this in most of our testing by getting the debuggee into a steady state so no GC can be in progress. > > For the most part SA is pretty good about dealing with these bad object references, and fails gracefully with an exception, but otherwise continues to run. However, this test exposed some holes that resulted in (1) way to many exception stack traces and (2) exiting the SA tool rather than trying to continue. > > The main fix is in JavaThread.printThreadInfo() where we now do a better job of dealing with exceptions if any of the java objects references are not valid. Even without access to the Thread instance, we can still produce a stack trace, but it will be missing things like the thread name and priority. This is a lot better than just giving up with the first exception. > > The other changes are for the most part just improvements in the error output, and getting rid of the printStackTrace() that was cluttering up the output. This pull request has now been integrated. Changeset: 2baeebbc Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/2baeebbc021b2cca8bd8ca866b83ab592d78b4ce Stats: 77 lines in 5 files changed: 38 ins; 0 del; 39 mod 8293006: sun/tools/jhsdb/JStackStressTest.java fails with "UnalignedAddressException: 8baadbabe" Reviewed-by: dcubed, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/10088 From cjplummer at openjdk.org Fri Sep 2 16:23:46 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Sep 2022 16:23:46 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 14:47:35 GMT, Kevin Walls wrote: > This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). > > A JVMTI operation could call threadObj() and clear the Windows GetLastError value. > > Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. The new test looks good. I'll let someone with a better understanding of JDK-8289091 comment on the runtime changes. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/10147 From lmesnik at openjdk.org Fri Sep 2 18:11:43 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 2 Sep 2022 18:11:43 GMT Subject: RFR: JDK-8292067 Convert test/sun/management/jmxremote/bootstrap shell tests to java version [v3] In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 22:39:15 GMT, Bill Huang wrote: >> This task convert 3 shell tests below to java version. >> test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh >> test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Implemented more review comments. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9973 From duke at openjdk.org Fri Sep 2 18:14:33 2022 From: duke at openjdk.org (Bill Huang) Date: Fri, 2 Sep 2022 18:14:33 GMT Subject: Integrated: JDK-8292067 Convert test/sun/management/jmxremote/bootstrap shell tests to java version In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 22:51:50 GMT, Bill Huang wrote: > This task convert 3 shell tests below to java version. > test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh > test/sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.sh This pull request has now been integrated. Changeset: 3993a1f9 Author: Bill Huang Committer: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/3993a1f9eaa8353ab8b24fe56c870580ef34fb52 Stats: 1641 lines in 9 files changed: 591 ins; 728 del; 322 mod 8292067: Convert test/sun/management/jmxremote/bootstrap shell tests to java version Reviewed-by: lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/9973 From cjplummer at openjdk.org Fri Sep 2 18:57:25 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Sep 2022 18:57:25 GMT Subject: RFR: 8293325: Minor improvements to macos catch_mach_exception_raise() error handling Message-ID: While trying to find a fix for [JDK-8288429](https://bugs.openjdk.org/browse/JDK-8288429) (no fix was found), I made some adjustments to the error handling in catch_mach_exception_raise() to make it a bit easier to understand the code, and to provide a more meaningful error message when the soft signal is invalid. This PR is for pushing those changes. ------------- Commit messages: - Cleanup error handling Changes: https://git.openjdk.org/jdk/pull/10149/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10149&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293325 Stats: 15 lines in 1 file changed: 8 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10149.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10149/head:pull/10149 PR: https://git.openjdk.org/jdk/pull/10149 From amenkov at openjdk.org Fri Sep 2 19:06:40 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 2 Sep 2022 19:06:40 GMT Subject: RFR: 8293325: Minor improvements to macos catch_mach_exception_raise() error handling In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 18:49:27 GMT, Chris Plummer wrote: > While trying to find a fix for [JDK-8288429](https://bugs.openjdk.org/browse/JDK-8288429) (no fix was found), I made some adjustments to the error handling in catch_mach_exception_raise() to make it a bit easier to understand the code, and to provide a more meaningful error message when the soft signal is invalid. This PR is for pushing those changes. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10149 From dcubed at openjdk.org Fri Sep 2 19:40:50 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 2 Sep 2022 19:40:50 GMT Subject: RFR: 8293325: Minor improvements to macos catch_mach_exception_raise() error handling In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 18:49:27 GMT, Chris Plummer wrote: > While trying to find a fix for [JDK-8288429](https://bugs.openjdk.org/browse/JDK-8288429) (no fix was found), I made some adjustments to the error handling in catch_mach_exception_raise() to make it a bit easier to understand the code, and to provide a more meaningful error message when the soft signal is invalid. This PR is for pushing those changes. Definitely an improvement. Thanks! Forgot to ask: what kind of testing has been done? ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/10149 From dholmes at openjdk.org Fri Sep 2 20:40:59 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 2 Sep 2022 20:40:59 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread In-Reply-To: References: Message-ID: <8Utk-bzbBROX3wb9XELnyeJCldtrwlWf_bBHQD7KicU=.4adb9aab-baeb-4d5e-9ebd-e2345b1b7e83@github.com> On Fri, 2 Sep 2022 14:47:35 GMT, Kevin Walls wrote: > This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). > > A JVMTI operation could call threadObj() and clear the Windows GetLastError value. > > Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. This is fine to me - modulo changing the comment as below. As I'm away on vacation I will pre-approve. Please be sure @dcubed-ojdk sees this before integrating. Thanks. src/hotspot/share/runtime/javaThread.cpp line 165: > 163: oop JavaThread::threadObj() const { > 164: // Using Thread::current_or_null_safe() here risks that calling threadObj() can > 165: // overwrite a native thread local, e.g. JVMTI operations clearing GetLastError on Windows. Suggestion: // Ideally we would verify the current thread is oop_safe when this is called, but as we can // be called from a signal handler we would have to use Thread::current_or_null_safe(). That // has overhead and also interacts poorly with GetLastError on Windows due to the use of TLS. // Instead callers must verify oop safe access. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10147 From cjplummer at openjdk.org Fri Sep 2 20:56:41 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Sep 2022 20:56:41 GMT Subject: RFR: 8293325: Minor improvements to macos catch_mach_exception_raise() error handling In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 19:37:16 GMT, Daniel D. Daugherty wrote: > Forgot to ask: what kind of testing has been done? I ran test/jdk/sun/tools/jhsdb about 300 times, basically enough times to at least reproduce the SIGILL failure once. I don't seem to see the SIGTRAP failure anymore. ERROR: catch_mach_exception_raise: signal is not SIGSTOP (4) ERROR: attach: wait_for_exception: catch_mach_exception_raise() got unknown exception type ERROR: attach: wait_for_exception() failed. Retried 0 times Error attaching to process: Can't attach to the process. Issues with reception of the exception message. sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process. Issues with reception of the exception message. ------------- PR: https://git.openjdk.org/jdk/pull/10149 From dcubed at openjdk.org Fri Sep 2 21:17:43 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 2 Sep 2022 21:17:43 GMT Subject: RFR: 8293325: Minor improvements to macos catch_mach_exception_raise() error handling In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 18:49:27 GMT, Chris Plummer wrote: > While trying to find a fix for [JDK-8288429](https://bugs.openjdk.org/browse/JDK-8288429) (no fix was found), I made some adjustments to the error handling in catch_mach_exception_raise() to make it a bit easier to understand the code, and to provide a more meaningful error message when the soft signal is invalid. This PR is for pushing those changes. Thanks for the testing info! ------------- PR: https://git.openjdk.org/jdk/pull/10149 From dlong at openjdk.org Fri Sep 2 23:30:44 2022 From: dlong at openjdk.org (Dean Long) Date: Fri, 2 Sep 2022 23:30:44 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: References: Message-ID: <61NHaDLfEQn-CYuywwXtsaW5yjla8A-T7GM_Qd6Htyc=.f7fab619-df0c-455f-bcce-b26ce2abfa6b@github.com> On Fri, 2 Sep 2022 00:04:17 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' of https://git.openjdk.org/jdk into compressed-stream > - 8292758: put support for UNSIGNED5 format into its own header file I'm concerned about the "excluded bytes" change. It appears to change the encoding, which would mean that SA would not be able to read streams from earlier JVMs, which may or may not be a concern. I suggest splitting this up into the straight-forward refactor (without the excluded bytes change), then adding excluded bytes as a follow-up. ------------- Changes requested by dlong (Reviewer). PR: https://git.openjdk.org/jdk/pull/10067 From sspitsyn at openjdk.org Sat Sep 3 01:01:11 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 3 Sep 2022 01:01:11 GMT Subject: RFR: 8291586: Broken links in JVMTI specification Message-ID: The Loom related spec of the extension VirtualThreadMount and VirtualThreadUnmount events in the jvmti.xml is surrounded by the elements ` ... `, so these specs have to be ignored when the `jvmti.html `is generated. However the `jvmti.xsl` which does the XSL transformation misses to do that when the description of the JVM TI capabilities is collected. The fix is a one-liner: diff --git a/src/hotspot/share/prims/jvmti.xsl b/src/hotspot/share/prims/jvmti.xsl index 5ef89f91daf..d54d2a371e6 100644 --- a/src/hotspot/share/prims/jvmti.xsl +++ b/src/hotspot/share/prims/jvmti.xsl @@ -1172,7 +1172,7 @@ typedef struct { - + The correctness verification both the generated `jvmti.html` and `jvmti.h` was checked. TBD: mach5 sanity builds and `nsk.jvmti` tests runs. ------------- Commit messages: - 8291586: Broken links in JVMTI specification Changes: https://git.openjdk.org/jdk/pull/10153/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10153&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291586 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10153.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10153/head:pull/10153 PR: https://git.openjdk.org/jdk/pull/10153 From sspitsyn at openjdk.org Sat Sep 3 01:29:38 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 3 Sep 2022 01:29:38 GMT Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails with "'Thread "Common-Cleaner"' missing from stdout/stderr" [v3] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 03:20:56 GMT, Chris Plummer wrote: >> While dumping all registers (and doing a findpc on each), the following exception occurred for r8: >> >> >> r8: 0x000000750e4fdffc >> Error: java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 >> java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.Page.getLong(Page.java:182) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:364) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:312) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:71) >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:58) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) >> >> >> This exception is the result of using PointerFinder ("findpc") on invalid address that starts on the last 32-bit word of a page. "page" in this case is referring to a page in SA's PageCache, which are always 4k in size. Note findpc is frequently done using an invalid address. In this test case it is being called on each x64 register, which could contain anything. findpc relies on getting some sort of AddressException when this happens, and will then say the address points to something that is unknown. However, in the case of the address pointing to the last 32-bot word of a page, it results in an ArrayIndexOutOfBoundsException when the page cache tries to read past the end of the page. This is happening in Page.getLong(), which you can see in the stack trace. >> >> The main culprit here is some weakening of the alignment checks being done. The alignment check should have resulted in an UnalignedAddressException long before we ever got to Page.getLong(). However, we have the following override, which is allowing the unaligned address to pass the alignment check. >> >> >> public void checkAlignment(long address, long alignment) { >> // Need to override default checkAlignment because we need to >> // relax alignment constraints on Bsd/x86 >> if ( (address % alignment != 0) >> &&(alignment != 8 || address % 4 != 0)) { >> throw new UnalignedAddressException( >> "Trying to read at address: " >> + addressValueToString(address) >> + " with alignment: " + alignment, >> address); >> } >> } >> }; >> >> >> This allows a pointer to a 64-bit value to only be 32-bit aligned. But there's more to it than that. I modified ClhsdbFindPC.java to fetch a tid (a thread address), and did a findpc on the address OR'd with 0xffc. `findpc` uses PointerFinder. This forced a read of a 64-bit value that starts in the last 32-bits of a page. It passed on linux-x64 but failed on windowx-x64 in the same manner described in the description of this CR. The difference between the two implementations is that windows relies on the default implementation of DebuggerBase.readCInteger() whereas linux has an override. DebuggerBase.readCInteger() does the following: >> >> >> public long readCInteger(long address, long numBytes, boolean isUnsigned) { >> utils.checkAlignment(address, numBytes); >> if (useFastAccessors) { >> if (isUnsigned) { >> switch((int) numBytes) { >> case 1: return cache.getByte(address) & 0xFF; >> case 2: return cache.getShort(address, bigEndian) & 0xFFFF; >> case 4: return cache.getInt(address, bigEndian) & 0xFFFFFFFFL; >> case 8: return cache.getLong(address, bigEndian); >> ... >> >> >> There is an alignment check here, but it is the "relaxed" override shown above, which allows 64-bit addresses on 32-bit boundaries. The override in LinuxDebuggerLocal is: >> >> >> /** Need to override this to relax alignment checks on x86. */ >> public long readCInteger(long address, long numBytes, boolean isUnsigned) >> throws UnmappedAddressException, UnalignedAddressException { >> // Only slightly relaxed semantics -- this is a hack, but is >> // necessary on x86 where it seems the compiler is >> // putting some global 64-bit data on 32-bit boundaries >> if (numBytes == 8) { >> utils.checkAlignment(address, 4); >> } else { >> utils.checkAlignment(address, numBytes); >> } >> byte[] data = readBytes(address, numBytes); >> return utils.dataToCInteger(data, isUnsigned); >> >> >> Although there is a relaxed alignment check here also, the code that reads from the address does not assume all the bytes are on the same page. It uses readBytes() intead of cache.getLong(), so it won't run into the PageCache issue with reading a 64-bit value that starts in the last 32-bit word of a page. >> >> I think the introduction of these relaxed alignment checks has a muddled history, probably made more muddled by ports cloning code that maybe wasn't necessary. Probably also initial fixes (the relaxed alignment check) seemed to work at first, but later the PageCache issue was discovered, leading to readBytes() workaround in the LinuxDebuggerLocal.readCInteger() override, but was not also done on other ports (so we got this CR for windows). >> >> For 64-bit support it's clear this easing of the 64-bit alignment is not needed, and getting rid of it would result in the proper UnalignedAddressException being thrown. The question is whether it is still needed for 32-bit x86, and if so is it needed on all ports. >> >> I can't test linux-x86, so I can't tell if it still allows 64-bit values on 32-bit aligned addresses, so for now I'll assume it does. So the approach being taken is whenever an address of a 64-bit type points to the last 32-bit word of a page, use readBytes() to get the 64-bit value one byte at a time. It still uses the page cache in the end, but it doesn't try to get all 8 bytes from the same page. Note for 64-bit systems, the conditoin will never arise because of the removal of the relaxed alignment check. Instead there will be an UnalignedAddressException at an early point when the alignment check is made. >> >> One windfall of this change is now we always read 64-bit values from the page cache in a way that is much more efficient than reading a byte at a time. This has resulted in about a 25% performance improvement in a test I have that does a heap dump. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10090 From sspitsyn at openjdk.org Sat Sep 3 01:43:40 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 3 Sep 2022 01:43:40 GMT Subject: RFR: 8293325: Minor improvements to macos catch_mach_exception_raise() error handling In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 18:49:27 GMT, Chris Plummer wrote: > While trying to find a fix for [JDK-8288429](https://bugs.openjdk.org/browse/JDK-8288429) (no fix was found), I made some adjustments to the error handling in catch_mach_exception_raise() to make it a bit easier to understand the code, and to provide a more meaningful error message when the soft signal is invalid. This PR is for pushing those changes. Looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10149 From jrose at openjdk.org Sat Sep 3 03:38:35 2022 From: jrose at openjdk.org (John R Rose) Date: Sat, 3 Sep 2022 03:38:35 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: <61NHaDLfEQn-CYuywwXtsaW5yjla8A-T7GM_Qd6Htyc=.f7fab619-df0c-455f-bcce-b26ce2abfa6b@github.com> References: <61NHaDLfEQn-CYuywwXtsaW5yjla8A-T7GM_Qd6Htyc=.f7fab619-df0c-455f-bcce-b26ce2abfa6b@github.com> Message-ID: On Fri, 2 Sep 2022 23:28:38 GMT, Dean Long wrote: > I suggest splitting this up into the straight-forward refactor (without the excluded bytes change), then adding excluded bytes as a follow-up. Yes, that is a slight change. Splitting is not necessary for the reason you mention because this PR includes SA changes. This SA change is tested by several jtreg tests: That is, injecting bugs causes SA tests to fail, and fixing them fixes the tests. This is the case because the compressed stream data structure is used for all stack walking. So if there's a bug, we find it immediately. And the same is true for SA unit tests which peform stack walking. Net result: It's safe, there is no bug, because testing coverage is robust. The math of the encoding is the same whether there are 255 or 256 byte values available, so the adjustment is very low risk. (The math works for any underlying byte type or size; we choose 8-bit bytes excluding nulls to provide 255 distinct tokens.) The benefit is that the encoding can be accompanied by null termination, which enhances debuggability and resilience against bad counts and bad pointers. ------------- PR: https://git.openjdk.org/jdk/pull/10067 From alanb at openjdk.org Sat Sep 3 06:05:38 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 3 Sep 2022 06:05:38 GMT Subject: RFR: 8291586: Broken links in JVMTI specification In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 00:52:56 GMT, Serguei Spitsyn wrote: > The Loom related spec of the extension VirtualThreadMount and VirtualThreadUnmount events in the jvmti.xml is surrounded by the elements ` ... `, so these specs have to be ignored when the `jvmti.html `is generated. However the `jvmti.xsl` which does the XSL transformation misses to do that when the description of the JVM TI capabilities is collected. > > The fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmti.xsl b/src/hotspot/share/prims/jvmti.xsl > index 5ef89f91daf..d54d2a371e6 100644 > --- a/src/hotspot/share/prims/jvmti.xsl > +++ b/src/hotspot/share/prims/jvmti.xsl > @@ -1172,7 +1172,7 @@ typedef struct { > > > > - > + > > > > > > The correctness verification both the generated `jvmti.html` and `jvmti.h` was checked. > TBD: mach5 sanity builds and `nsk.jvmti` tests runs. `not(ancestor::elide)` looks right. Looks good. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/10153 From dlong at openjdk.org Sat Sep 3 07:52:31 2022 From: dlong at openjdk.org (Dean Long) Date: Sat, 3 Sep 2022 07:52:31 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: References: Message-ID: <-RXfpRzuGeXmyRSEg2u0XNJETE5VHaI9wrailPSF3IA=.26c9b859-fa04-442b-9fdb-9ead1b07ab0c@github.com> On Fri, 2 Sep 2022 00:04:17 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' of https://git.openjdk.org/jdk into compressed-stream > - 8292758: put support for UNSIGNED5 format into its own header file Wouldn't the SA stack walk fail when attaching to a core dump from an earlier JVM that does not exclude nulls? ------------- PR: https://git.openjdk.org/jdk/pull/10067 From sspitsyn at openjdk.org Sat Sep 3 09:26:38 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 3 Sep 2022 09:26:38 GMT Subject: RFR: 8291586: Broken links in JVMTI specification In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 00:52:56 GMT, Serguei Spitsyn wrote: > The Loom related spec of the extension VirtualThreadMount and VirtualThreadUnmount events in the jvmti.xml is surrounded by the elements ` ... `, so these specs have to be ignored when the `jvmti.html `is generated. However the `jvmti.xsl` which does the XSL transformation misses to do that when the description of the JVM TI capabilities is collected. > > The fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmti.xsl b/src/hotspot/share/prims/jvmti.xsl > index 5ef89f91daf..d54d2a371e6 100644 > --- a/src/hotspot/share/prims/jvmti.xsl > +++ b/src/hotspot/share/prims/jvmti.xsl > @@ -1172,7 +1172,7 @@ typedef struct { > > > > - > + > > > > > > The correctness verification both the generated `jvmti.html` and `jvmti.h` was checked. > TBD: mach5 sanity builds and `nsk.jvmti` tests runs. Thank you for review, Alan! ------------- PR: https://git.openjdk.org/jdk/pull/10153 From sspitsyn at openjdk.org Sat Sep 3 09:32:51 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 3 Sep 2022 09:32:51 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v2] In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:28:24 GMT, Alex Menkov wrote: >> The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) >> >> cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. >> After successful RedefineClasses it should be reset. >> The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated comments test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 76: > 74: private static byte[] initialClassBytes; > 75: > 76: private static class VersionScanner extends ClassVisitor { This class needs some explanation. It is unclear how does it work. Could you, please, add relevant comments where needed? For instance, how are the class file bytes constructed and what role does the version play. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 236: > 234: redefine(2, 5); // updates cached class bytes > 235: retransform(3, 2); > 236: retransform(4, 2); The comments for all test cases need to be aligned. Also, it is better to comment all redefine/retransform cases. ------------- PR: https://git.openjdk.org/jdk/pull/10032 From sspitsyn at openjdk.org Sat Sep 3 09:42:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 3 Sep 2022 09:42:22 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v2] In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:28:24 GMT, Alex Menkov wrote: >> The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) >> >> cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. >> After successful RedefineClasses it should be reset. >> The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated comments test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 179: > 177: if (err != JVMTI_ERROR_NONE) { > 178: _log("nRedefine: SetEventNotificationMode(JVMTI_DISABLE) error %d\n", err); > 179: } It makes sense to introduce an utility function which does SetEventNotificationMode. It can be two separate functions to enable and disable or one single function can support both cases. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 195: > 193: _log("nRedefine: classLoadHookSavedClassBytes is NULL\n"); > 194: return nullptr; > 195: } The checks 181-195 seems to be the same in functions nRedefine and nRetransform, so one utility function can be used in both cases. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 274: > 272: classLoadHookSavedClassBytes = nullptr; > 273: > 274: return result; The fragments 197-214 and 256-274 do the same. I'd suggest to define and use a function that does this post-processing. ------------- PR: https://git.openjdk.org/jdk/pull/10032 From sspitsyn at openjdk.org Sat Sep 3 09:50:01 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 3 Sep 2022 09:50:01 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v2] In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 21:28:24 GMT, Alex Menkov wrote: >> The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) >> >> cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. >> After successful RedefineClasses it should be reset. >> The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated comments Alex, My apology for latency with review. The fix itself looks good to me. Thank you for your good analysis and fix! I've posted several comments on new test. It feels like more comments are needed. Could you, please, add them where you consider it relevant? Also, I'm curious how did you verify that no regressions have been introduced? Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10032 From kevinw at openjdk.org Sat Sep 3 11:08:41 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Sat, 3 Sep 2022 11:08:41 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread In-Reply-To: <8Utk-bzbBROX3wb9XELnyeJCldtrwlWf_bBHQD7KicU=.4adb9aab-baeb-4d5e-9ebd-e2345b1b7e83@github.com> References: <8Utk-bzbBROX3wb9XELnyeJCldtrwlWf_bBHQD7KicU=.4adb9aab-baeb-4d5e-9ebd-e2345b1b7e83@github.com> Message-ID: On Fri, 2 Sep 2022 20:33:37 GMT, David Holmes wrote: >> This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). >> >> A JVMTI operation could call threadObj() and clear the Windows GetLastError value. >> >> Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. > > src/hotspot/share/runtime/javaThread.cpp line 165: > >> 163: oop JavaThread::threadObj() const { >> 164: // Using Thread::current_or_null_safe() here risks that calling threadObj() can >> 165: // overwrite a native thread local, e.g. JVMTI operations clearing GetLastError on Windows. > > Suggestion: > > // Ideally we would verify the current thread is oop_safe when this is called, but as we can > // be called from a signal handler we would have to use Thread::current_or_null_safe(). That > // has overhead and also interacts poorly with GetLastError on Windows due to the use of TLS. > // Instead callers must verify oop safe access. Thanks David, will update comment and check Dan is OK with this. ------------- PR: https://git.openjdk.org/jdk/pull/10147 From cjplummer at openjdk.org Sat Sep 3 16:07:30 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 3 Sep 2022 16:07:30 GMT Subject: RFR: 8292201: serviceability/sa/ClhsdbThreadContext.java fails with "'Thread "Common-Cleaner"' missing from stdout/stderr" [v3] In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 03:20:56 GMT, Chris Plummer wrote: >> While dumping all registers (and doing a findpc on each), the following exception occurred for r8: >> >> >> r8: 0x000000750e4fdffc >> Error: java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 >> java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.Page.getLong(Page.java:182) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:364) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:312) >> at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:71) >> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:58) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) >> >> >> This exception is the result of using PointerFinder ("findpc") on invalid address that starts on the last 32-bit word of a page. "page" in this case is referring to a page in SA's PageCache, which are always 4k in size. Note findpc is frequently done using an invalid address. In this test case it is being called on each x64 register, which could contain anything. findpc relies on getting some sort of AddressException when this happens, and will then say the address points to something that is unknown. However, in the case of the address pointing to the last 32-bot word of a page, it results in an ArrayIndexOutOfBoundsException when the page cache tries to read past the end of the page. This is happening in Page.getLong(), which you can see in the stack trace. >> >> The main culprit here is some weakening of the alignment checks being done. The alignment check should have resulted in an UnalignedAddressException long before we ever got to Page.getLong(). However, we have the following override, which is allowing the unaligned address to pass the alignment check. >> >> >> public void checkAlignment(long address, long alignment) { >> // Need to override default checkAlignment because we need to >> // relax alignment constraints on Bsd/x86 >> if ( (address % alignment != 0) >> &&(alignment != 8 || address % 4 != 0)) { >> throw new UnalignedAddressException( >> "Trying to read at address: " >> + addressValueToString(address) >> + " with alignment: " + alignment, >> address); >> } >> } >> }; >> >> >> This allows a pointer to a 64-bit value to only be 32-bit aligned. But there's more to it than that. I modified ClhsdbFindPC.java to fetch a tid (a thread address), and did a findpc on the address OR'd with 0xffc. `findpc` uses PointerFinder. This forced a read of a 64-bit value that starts in the last 32-bits of a page. It passed on linux-x64 but failed on windowx-x64 in the same manner described in the description of this CR. The difference between the two implementations is that windows relies on the default implementation of DebuggerBase.readCInteger() whereas linux has an override. DebuggerBase.readCInteger() does the following: >> >> >> public long readCInteger(long address, long numBytes, boolean isUnsigned) { >> utils.checkAlignment(address, numBytes); >> if (useFastAccessors) { >> if (isUnsigned) { >> switch((int) numBytes) { >> case 1: return cache.getByte(address) & 0xFF; >> case 2: return cache.getShort(address, bigEndian) & 0xFFFF; >> case 4: return cache.getInt(address, bigEndian) & 0xFFFFFFFFL; >> case 8: return cache.getLong(address, bigEndian); >> ... >> >> >> There is an alignment check here, but it is the "relaxed" override shown above, which allows 64-bit addresses on 32-bit boundaries. The override in LinuxDebuggerLocal is: >> >> >> /** Need to override this to relax alignment checks on x86. */ >> public long readCInteger(long address, long numBytes, boolean isUnsigned) >> throws UnmappedAddressException, UnalignedAddressException { >> // Only slightly relaxed semantics -- this is a hack, but is >> // necessary on x86 where it seems the compiler is >> // putting some global 64-bit data on 32-bit boundaries >> if (numBytes == 8) { >> utils.checkAlignment(address, 4); >> } else { >> utils.checkAlignment(address, numBytes); >> } >> byte[] data = readBytes(address, numBytes); >> return utils.dataToCInteger(data, isUnsigned); >> >> >> Although there is a relaxed alignment check here also, the code that reads from the address does not assume all the bytes are on the same page. It uses readBytes() intead of cache.getLong(), so it won't run into the PageCache issue with reading a 64-bit value that starts in the last 32-bit word of a page. >> >> I think the introduction of these relaxed alignment checks has a muddled history, probably made more muddled by ports cloning code that maybe wasn't necessary. Probably also initial fixes (the relaxed alignment check) seemed to work at first, but later the PageCache issue was discovered, leading to readBytes() workaround in the LinuxDebuggerLocal.readCInteger() override, but was not also done on other ports (so we got this CR for windows). >> >> For 64-bit support it's clear this easing of the 64-bit alignment is not needed, and getting rid of it would result in the proper UnalignedAddressException being thrown. The question is whether it is still needed for 32-bit x86, and if so is it needed on all ports. >> >> I can't test linux-x86, so I can't tell if it still allows 64-bit values on 32-bit aligned addresses, so for now I'll assume it does. So the approach being taken is whenever an address of a 64-bit type points to the last 32-bit word of a page, use readBytes() to get the 64-bit value one byte at a time. It still uses the page cache in the end, but it doesn't try to get all 8 bytes from the same page. Note for 64-bit systems, the conditoin will never arise because of the removal of the relaxed alignment check. Instead there will be an UnalignedAddressException at an early point when the alignment check is made. >> >> One windfall of this change is now we always read 64-bit values from the page cache in a way that is much more efficient than reading a byte at a time. This has resulted in about a 25% performance improvement in a test I have that does a heap dump. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation Thanks Alex and Serguei! ------------- PR: https://git.openjdk.org/jdk/pull/10090 From cjplummer at openjdk.org Sat Sep 3 16:08:53 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 3 Sep 2022 16:08:53 GMT Subject: Integrated: 8292201: serviceability/sa/ClhsdbThreadContext.java fails with "'Thread "Common-Cleaner"' missing from stdout/stderr" In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 23:57:55 GMT, Chris Plummer wrote: > While dumping all registers (and doing a findpc on each), the following exception occurred for r8: > > > r8: 0x000000750e4fdffc > Error: java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 > java.lang.ArrayIndexOutOfBoundsException: Index 4099 out of bounds for length 4096 > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.Page.getLong(Page.java:182) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getLong(PageCache.java:100) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:364) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:462) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgDebuggerLocal.readAddress(WindbgDebuggerLocal.java:312) > at jdk.hotspot.agent/sun.jvm.hotspot.debugger.windbg.WindbgAddress.getAddressAt(WindbgAddress.java:71) > at jdk.hotspot.agent/sun.jvm.hotspot.utilities.PointerFinder.find(PointerFinder.java:58) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadContextOn(JavaThread.java:493) > > > This exception is the result of using PointerFinder ("findpc") on invalid address that starts on the last 32-bit word of a page. "page" in this case is referring to a page in SA's PageCache, which are always 4k in size. Note findpc is frequently done using an invalid address. In this test case it is being called on each x64 register, which could contain anything. findpc relies on getting some sort of AddressException when this happens, and will then say the address points to something that is unknown. However, in the case of the address pointing to the last 32-bot word of a page, it results in an ArrayIndexOutOfBoundsException when the page cache tries to read past the end of the page. This is happening in Page.getLong(), which you can see in the stack trace. > > The main culprit here is some weakening of the alignment checks being done. The alignment check should have resulted in an UnalignedAddressException long before we ever got to Page.getLong(). However, we have the following override, which is allowing the unaligned address to pass the alignment check. > > > public void checkAlignment(long address, long alignment) { > // Need to override default checkAlignment because we need to > // relax alignment constraints on Bsd/x86 > if ( (address % alignment != 0) > &&(alignment != 8 || address % 4 != 0)) { > throw new UnalignedAddressException( > "Trying to read at address: " > + addressValueToString(address) > + " with alignment: " + alignment, > address); > } > } > }; > > > This allows a pointer to a 64-bit value to only be 32-bit aligned. But there's more to it than that. I modified ClhsdbFindPC.java to fetch a tid (a thread address), and did a findpc on the address OR'd with 0xffc. `findpc` uses PointerFinder. This forced a read of a 64-bit value that starts in the last 32-bits of a page. It passed on linux-x64 but failed on windowx-x64 in the same manner described in the description of this CR. The difference between the two implementations is that windows relies on the default implementation of DebuggerBase.readCInteger() whereas linux has an override. DebuggerBase.readCInteger() does the following: > > > public long readCInteger(long address, long numBytes, boolean isUnsigned) { > utils.checkAlignment(address, numBytes); > if (useFastAccessors) { > if (isUnsigned) { > switch((int) numBytes) { > case 1: return cache.getByte(address) & 0xFF; > case 2: return cache.getShort(address, bigEndian) & 0xFFFF; > case 4: return cache.getInt(address, bigEndian) & 0xFFFFFFFFL; > case 8: return cache.getLong(address, bigEndian); > ... > > > There is an alignment check here, but it is the "relaxed" override shown above, which allows 64-bit addresses on 32-bit boundaries. The override in LinuxDebuggerLocal is: > > > /** Need to override this to relax alignment checks on x86. */ > public long readCInteger(long address, long numBytes, boolean isUnsigned) > throws UnmappedAddressException, UnalignedAddressException { > // Only slightly relaxed semantics -- this is a hack, but is > // necessary on x86 where it seems the compiler is > // putting some global 64-bit data on 32-bit boundaries > if (numBytes == 8) { > utils.checkAlignment(address, 4); > } else { > utils.checkAlignment(address, numBytes); > } > byte[] data = readBytes(address, numBytes); > return utils.dataToCInteger(data, isUnsigned); > > > Although there is a relaxed alignment check here also, the code that reads from the address does not assume all the bytes are on the same page. It uses readBytes() intead of cache.getLong(), so it won't run into the PageCache issue with reading a 64-bit value that starts in the last 32-bit word of a page. > > I think the introduction of these relaxed alignment checks has a muddled history, probably made more muddled by ports cloning code that maybe wasn't necessary. Probably also initial fixes (the relaxed alignment check) seemed to work at first, but later the PageCache issue was discovered, leading to readBytes() workaround in the LinuxDebuggerLocal.readCInteger() override, but was not also done on other ports (so we got this CR for windows). > > For 64-bit support it's clear this easing of the 64-bit alignment is not needed, and getting rid of it would result in the proper UnalignedAddressException being thrown. The question is whether it is still needed for 32-bit x86, and if so is it needed on all ports. > > I can't test linux-x86, so I can't tell if it still allows 64-bit values on 32-bit aligned addresses, so for now I'll assume it does. So the approach being taken is whenever an address of a 64-bit type points to the last 32-bit word of a page, use readBytes() to get the 64-bit value one byte at a time. It still uses the page cache in the end, but it doesn't try to get all 8 bytes from the same page. Note for 64-bit systems, the conditoin will never arise because of the removal of the relaxed alignment check. Instead there will be an UnalignedAddressException at an early point when the alignment check is made. > > One windfall of this change is now we always read 64-bit values from the page cache in a way that is much more efficient than reading a byte at a time. This has resulted in about a 25% performance improvement in a test I have that does a heap dump. This pull request has now been integrated. Changeset: 767262e6 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/767262e67cec8e7a5e5eba2c6ebea7f60186d2cb Stats: 227 lines in 11 files changed: 52 ins; 154 del; 21 mod 8292201: serviceability/sa/ClhsdbThreadContext.java fails with "'Thread "Common-Cleaner"' missing from stdout/stderr" Reviewed-by: amenkov, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/10090 From cjplummer at openjdk.org Sat Sep 3 23:19:03 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 3 Sep 2022 23:19:03 GMT Subject: RFR: 8293325: Minor improvements to macos catch_mach_exception_raise() error handling In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 18:49:27 GMT, Chris Plummer wrote: > While trying to find a fix for [JDK-8288429](https://bugs.openjdk.org/browse/JDK-8288429) (no fix was found), I made some adjustments to the error handling in catch_mach_exception_raise() to make it a bit easier to understand the code, and to provide a more meaningful error message when the soft signal is invalid. This PR is for pushing those changes. Thanks Dan, Alex, and Serguei! ------------- PR: https://git.openjdk.org/jdk/pull/10149 From cjplummer at openjdk.org Sat Sep 3 23:19:04 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Sat, 3 Sep 2022 23:19:04 GMT Subject: Integrated: 8293325: Minor improvements to macos catch_mach_exception_raise() error handling In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 18:49:27 GMT, Chris Plummer wrote: > While trying to find a fix for [JDK-8288429](https://bugs.openjdk.org/browse/JDK-8288429) (no fix was found), I made some adjustments to the error handling in catch_mach_exception_raise() to make it a bit easier to understand the code, and to provide a more meaningful error message when the soft signal is invalid. This PR is for pushing those changes. This pull request has now been integrated. Changeset: e92b9e40 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/e92b9e4030ce490140b05f3a6b1435846a212e5d Stats: 15 lines in 1 file changed: 8 ins; 2 del; 5 mod 8293325: Minor improvements to macos catch_mach_exception_raise() error handling Reviewed-by: amenkov, dcubed, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/10149 From jrose at openjdk.org Sat Sep 3 23:46:41 2022 From: jrose at openjdk.org (John R Rose) Date: Sat, 3 Sep 2022 23:46:41 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v3] In-Reply-To: References: Message-ID: > Refactor code from inside of CompressedStream into its own unit. > > This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). > > Add gtests. John R Rose has updated the pull request incrementally with one additional commit since the last revision: add more support for SA including vmStructs; tweak some debug code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10067/files - new: https://git.openjdk.org/jdk/pull/10067/files/d903f2c7..dc30f7ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=01-02 Stats: 346 lines in 6 files changed: 284 ins; 43 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/10067.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10067/head:pull/10067 PR: https://git.openjdk.org/jdk/pull/10067 From cjplummer at openjdk.org Sun Sep 4 00:26:44 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Sun, 4 Sep 2022 00:26:44 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: <-RXfpRzuGeXmyRSEg2u0XNJETE5VHaI9wrailPSF3IA=.26c9b859-fa04-442b-9fdb-9ead1b07ab0c@github.com> References: <-RXfpRzuGeXmyRSEg2u0XNJETE5VHaI9wrailPSF3IA=.26c9b859-fa04-442b-9fdb-9ead1b07ab0c@github.com> Message-ID: On Sat, 3 Sep 2022 07:48:50 GMT, Dean Long wrote: > Wouldn't the SA stack walk fail when attaching to a core dump from an earlier JVM that does not exclude nulls? I'm not sure how important compatibility is with older JVMs. SA is capable of (if properly maintained) connecting to any JVM. You'll see signs of that in the code: // The threadStatus is only present starting in 1.5 if (threadStatusField != null) { Oop holderOop = threadHolderField.getValue(threadOop); return (int) threadStatusField.getValue(holderOop); } else { // All we can easily figure out is if it is alive, but that is // enough info for a valid unknown status. ... } However, attempts like this one are ancient, and certainly this one should be removed. There's probably a 100 other reasons why attaching to a 1.5 JVM won't work. We don't do any compatibility testing with older JVMs. For the most part I'd say SA users should always match SA with the version of the JVM they are targeting. I'd be interested in hearing if anyone feels otherwise. ------------- PR: https://git.openjdk.org/jdk/pull/10067 From sspitsyn at openjdk.org Mon Sep 5 08:54:28 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 5 Sep 2022 08:54:28 GMT Subject: RFR: 8291586: Broken links in JVMTI specification In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 00:52:56 GMT, Serguei Spitsyn wrote: > The Loom related spec of the extension VirtualThreadMount and VirtualThreadUnmount events in the jvmti.xml is surrounded by the elements ` ... `, so these specs have to be ignored when the `jvmti.html `is generated. However the `jvmti.xsl` which does the XSL transformation misses to do that when the description of the JVM TI capabilities is collected. > > The fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmti.xsl b/src/hotspot/share/prims/jvmti.xsl > index 5ef89f91daf..d54d2a371e6 100644 > --- a/src/hotspot/share/prims/jvmti.xsl > +++ b/src/hotspot/share/prims/jvmti.xsl > @@ -1172,7 +1172,7 @@ typedef struct { > > > > - > + > > > > > > The correctness verification both the generated `jvmti.html` and `jvmti.h` was checked. > TBD: mach5 sanity builds and `nsk.jvmti` tests runs. I'm going to integrate this fix with one review as trivial. In fact, the fix does not change anything in the implementation and behavior. It only results in removal of a couple of unneeded links in the JVM TI spec (jvmti.html). ------------- PR: https://git.openjdk.org/jdk/pull/10153 From sspitsyn at openjdk.org Mon Sep 5 08:54:29 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 5 Sep 2022 08:54:29 GMT Subject: Integrated: 8291586: Broken links in JVMTI specification In-Reply-To: References: Message-ID: <1eQcjWn5FABJIfskCv5ula6MgrlLjQEVroIZ9Rg1hjA=.4e674b2b-14eb-495b-a8c9-3d9cb4f969a1@github.com> On Sat, 3 Sep 2022 00:52:56 GMT, Serguei Spitsyn wrote: > The Loom related spec of the extension VirtualThreadMount and VirtualThreadUnmount events in the jvmti.xml is surrounded by the elements ` ... `, so these specs have to be ignored when the `jvmti.html `is generated. However the `jvmti.xsl` which does the XSL transformation misses to do that when the description of the JVM TI capabilities is collected. > > The fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmti.xsl b/src/hotspot/share/prims/jvmti.xsl > index 5ef89f91daf..d54d2a371e6 100644 > --- a/src/hotspot/share/prims/jvmti.xsl > +++ b/src/hotspot/share/prims/jvmti.xsl > @@ -1172,7 +1172,7 @@ typedef struct { > > > > - > + > > > > > > The correctness verification both the generated `jvmti.html` and `jvmti.h` was checked. > TBD: mach5 sanity builds and `nsk.jvmti` tests runs. This pull request has now been integrated. Changeset: 4067321e Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/4067321ef413cc6c934aa5e7ec652c56dfdf81eb Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8291586: Broken links in JVMTI specification Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/10153 From coleenp at openjdk.org Mon Sep 5 18:25:24 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 5 Sep 2022 18:25:24 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v3] In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 23:46:41 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose has updated the pull request incrementally with one additional commit since the last revision: > > add more support for SA including vmStructs; tweak some debug code Thank you for adding the SA and debug.cpp for debugging this. src/hotspot/share/code/compressedStream.cpp line 85: > 83: const int min_expansion = UNSIGNED5::MAX_LENGTH; > 84: if (nsize < min_expansion*2) > 85: nsize = min_expansion*2; I think our coding style guide recommends having {} around even one line code inside if and else statements. I usually ignore this if it's on the same line, but on a separate line, it seems worth pointing out. src/hotspot/share/utilities/unsigned5.cpp line 35: > 33: template u4 UNSIGNED5::read_uint(u_char* array, int& offset_rw, int limit, AGS); > 34: template void UNSIGNED5::write_uint(uint32_t value, u_char* array, int& offset_rw, int limit, AGS); > 35: template int UNSIGNED5::check_length(u_char* array, int offset, int limit, AGS); I don't know why you'd need these explicit instantiations. The entire templates are in the hpp files so the caller will instantiate them. src/hotspot/share/utilities/unsigned5.hpp line 174: > 172: > 173: // returns the encoded byte length of an unsigned 32-bit int > 174: static constexpr int encoded_length(uint32_t value) { Should all of these functions be private? src/hotspot/share/utilities/unsigned5.hpp line 312: > 310: : _array(const_cast(array)), _limit_ptr(NULL) > 311: // note: if _limit_ptr is NULL, the ARR& is never reassigned > 312: { limit_init(); _position = 0; } indent needed. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/Unsigned5.java line 59: > 57: hval = db.lookupIntConstant("UNSIGNED5::H").intValue(); > 58: lval = db.lookupIntConstant("UNSIGNED5::L").intValue(); > 59: xval = db.lookupIntConstant("UNSIGNED5::X").intValue(); These constants aren't likely to change ever, are they? I don't see why we'd need the SA to get these constants from the VM. It could just hard-code them like you have here. Then UNSIGNED5 doesn't have to make VMStructs a friend class. Also, there isn't a compatibility issue with older SA - it might work sometimes but the SA version should match the JVM that is being debugged. test/hotspot/gtest/utilities/test_unsigned5.cpp line 31: > 29: // T.I.L. > 30: // $ sh ./configure ... --with-gtest=<...>/googletest ... > 31: // $ make exploded-test TEST=gtest:unsigned5 What does T.I.L mean? This isn't the only way to run this test, so don't include this. ------------- PR: https://git.openjdk.org/jdk/pull/10067 From kevinw at openjdk.org Tue Sep 6 08:42:13 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 6 Sep 2022 08:42:13 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread [v2] In-Reply-To: References: Message-ID: > This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). > > A JVMTI operation could call threadObj() and clear the Windows GetLastError value. > > Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Comment update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10147/files - new: https://git.openjdk.org/jdk/pull/10147/files/2cbaa186..8de54561 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10147&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10147&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10147.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10147/head:pull/10147 PR: https://git.openjdk.org/jdk/pull/10147 From kevinw at openjdk.org Tue Sep 6 08:42:14 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 6 Sep 2022 08:42:14 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread [v2] In-Reply-To: References: <8Utk-bzbBROX3wb9XELnyeJCldtrwlWf_bBHQD7KicU=.4adb9aab-baeb-4d5e-9ebd-e2345b1b7e83@github.com> Message-ID: On Sat, 3 Sep 2022 11:05:18 GMT, Kevin Walls wrote: >> src/hotspot/share/runtime/javaThread.cpp line 165: >> >>> 163: oop JavaThread::threadObj() const { >>> 164: // Using Thread::current_or_null_safe() here risks that calling threadObj() can >>> 165: // overwrite a native thread local, e.g. JVMTI operations clearing GetLastError on Windows. >> >> Suggestion: >> >> // Ideally we would verify the current thread is oop_safe when this is called, but as we can >> // be called from a signal handler we would have to use Thread::current_or_null_safe(). That >> // has overhead and also interacts poorly with GetLastError on Windows due to the use of TLS. >> // Instead callers must verify oop safe access. > > Thanks David, will update comment and check Dan is OK with this. Updated comment. ------------- PR: https://git.openjdk.org/jdk/pull/10147 From asotona at openjdk.org Tue Sep 6 12:25:24 2022 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 6 Sep 2022 12:25:24 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v15] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge branch 'openjdk:master' into JDK-8244681 - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le - Merge branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module - Added man-page line about lossy-conversion lint - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments re-enabled warnings for java.base, java.rmi and java.smartcardio - Merge branch 'openjdk:master' into JDK-8244681 - ... and 9 more: https://git.openjdk.org/jdk/compare/6a1e98cb...4a7ce942 ------------- Changes: https://git.openjdk.org/jdk/pull/8599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=14 Stats: 439 lines in 14 files changed: 437 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.org/jdk/pull/8599 From aturbanov at openjdk.org Tue Sep 6 13:28:25 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 6 Sep 2022 13:28:25 GMT Subject: RFR: 8293432: Use diamond operator in java.management Message-ID: The diamond operator was introduced in Java 7. We can take advantage of this language feature to make code easier to read. Tested on Linux release x64. `make test TEST="jdk/java/lang/management jdk/javax/management jdk/com/sun/jmx jdk/sun/management"` Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/jdk/java/lang/management 69 69 0 0 jtreg:test/jdk/javax/management 246 246 0 0 jtreg:test/jdk/com/sun/jmx 3 3 0 0 >> jtreg:test/jdk/sun/management 33 32 0 1 << Single failure - is a test `RmiBootstrapTest.java#id1`. It's known issue - [JDK-8293335](https://bugs.openjdk.org/browse/JDK-8293335). ------------- Commit messages: - [PATCH] Use diamond operator in java.management Changes: https://git.openjdk.org/jdk/pull/10173/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10173&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293432 Stats: 363 lines in 61 files changed: 2 ins; 72 del; 289 mod Patch: https://git.openjdk.org/jdk/pull/10173.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10173/head:pull/10173 PR: https://git.openjdk.org/jdk/pull/10173 From aturbanov at openjdk.org Tue Sep 6 13:28:26 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 6 Sep 2022 13:28:26 GMT Subject: RFR: 8293432: Use diamond operator in java.management In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 19:56:44 GMT, Andrey Turbanov wrote: > The diamond operator was introduced in Java 7. We can take advantage of this language feature to make code easier to read. > Tested on Linux release x64. `make test TEST="jdk/java/lang/management jdk/javax/management jdk/com/sun/jmx jdk/sun/management"` > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk/java/lang/management 69 69 0 0 > jtreg:test/jdk/javax/management 246 246 0 0 > jtreg:test/jdk/com/sun/jmx 3 3 0 0 >>> jtreg:test/jdk/sun/management 33 32 0 1 << > > Single failure - is a test `RmiBootstrapTest.java#id1`. It's known issue - [JDK-8293335](https://bugs.openjdk.org/browse/JDK-8293335). src/java.management/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java line 89: > 87: **/ > 88: private synchronized boolean add(ObjectName name, ClassLoader cl) { > 89: List l = new ArrayList<>(Arrays.asList(loaders)); I found it strange that ArrayList is used to just append one element to array. I think it's better to just use Arrays.copyOf with length+1. ------------- PR: https://git.openjdk.org/jdk/pull/10173 From rriggs at openjdk.org Tue Sep 6 17:49:39 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 6 Sep 2022 17:49:39 GMT Subject: RFR: 8293432: Use diamond operator in java.management In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 19:56:44 GMT, Andrey Turbanov wrote: > The diamond operator was introduced in Java 7. We can take advantage of this language feature to make code easier to read. > Tested on Linux release x64. `make test TEST="jdk/java/lang/management jdk/javax/management jdk/com/sun/jmx jdk/sun/management"` > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk/java/lang/management 69 69 0 0 > jtreg:test/jdk/javax/management 246 246 0 0 > jtreg:test/jdk/com/sun/jmx 3 3 0 0 >>> jtreg:test/jdk/sun/management 33 32 0 1 << > > Single failure - is a test `RmiBootstrapTest.java#id1`. It's known issue - [JDK-8293335](https://bugs.openjdk.org/browse/JDK-8293335). LGTM, a changeset this large is easy to review if all the changes are simple substitutions. If you see other miscellaneous improvements, make a separate PR. :) ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/10173 From jrose at openjdk.org Tue Sep 6 18:41:45 2022 From: jrose at openjdk.org (John R Rose) Date: Tue, 6 Sep 2022 18:41:45 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v4] In-Reply-To: References: Message-ID: > Refactor code from inside of CompressedStream into its own unit. > > This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). > > Add gtests. John R Rose has updated the pull request incrementally with one additional commit since the last revision: respond to reviewer comments; move printing code to a better place; remove vmStructs coupling from SA ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10067/files - new: https://git.openjdk.org/jdk/pull/10067/files/dc30f7ce..439b108b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=02-03 Stats: 228 lines in 8 files changed: 112 ins; 85 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/10067.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10067/head:pull/10067 PR: https://git.openjdk.org/jdk/pull/10067 From cjplummer at openjdk.org Tue Sep 6 19:33:42 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 Sep 2022 19:33:42 GMT Subject: RFR: 8283010: serviceability/sa/ClhsdbThread.java failed with "'Base of Stack:' missing from stdout/stderr " Message-ID: <0XT3wfxBd1xlzY21gfkQ8oc9ZJX5rPMORnX2rotI0c4=.a7572e61-5a34-4c04-ab39-1ebb101b1ceb@github.com> Each time you attach to a target JVM on Windows, thread Id's can change (although they rarely do). For this reason you can't reliably do what this test is doing, which is attach, run jstack to get the threadId of a thread, detach, attach again and run the `thread` command using the threadId. It might not be valid any more. For this reason I am changing the test to ignore the result of the `thread` command when running on windows. This is the same fix as was done for [JDK-8280770](https://bugs.openjdk.org/browse/JDK-8280770) I'd like to push this as a trivial change. ------------- Commit messages: - Ignore results on windows Changes: https://git.openjdk.org/jdk/pull/10185/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10185&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8283010 Stats: 13 lines in 1 file changed: 8 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10185.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10185/head:pull/10185 PR: https://git.openjdk.org/jdk/pull/10185 From cjplummer at openjdk.org Tue Sep 6 19:37:14 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 Sep 2022 19:37:14 GMT Subject: RFR: 8293445: clhsdb "thread" command gives incorrect error message for bad threadID Message-ID: As pointed out in [JDK-8283010](https://bugs.openjdk.org/browse/JDK-8283010), when a bad threadID is passed to the clhsdb "thread" command, the error message is incorrect: hsdb> thread 18 Couldn't find thread thread It should say "thread 18", not "thread thread". The code looks like: out.println("Couldn't find thread " + name); "name" is the name of the command. It should instead use "id". I'd like to push this as a trivial change. ------------- Commit messages: - Fix output when passing a bad threadid to the thread command. Changes: https://git.openjdk.org/jdk/pull/10186/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10186&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293445 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10186.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10186/head:pull/10186 PR: https://git.openjdk.org/jdk/pull/10186 From dcubed at openjdk.org Tue Sep 6 20:07:45 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 6 Sep 2022 20:07:45 GMT Subject: RFR: 8293445: clhsdb "thread" command gives incorrect error message for bad threadID In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 19:28:15 GMT, Chris Plummer wrote: > As pointed out in [JDK-8283010](https://bugs.openjdk.org/browse/JDK-8283010), when a bad threadID is passed to the clhsdb "thread" command, the error message is incorrect: > > hsdb> thread 18 > Couldn't find thread thread > > It should say "thread 18", not "thread thread". The code looks like: > > out.println("Couldn't find thread " + name); > > "name" is the name of the command. It should instead use "id". > > I'd like to push this as a trivial change. Thumbs up. I agree that this is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/10186 From cjplummer at openjdk.org Tue Sep 6 22:30:50 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 Sep 2022 22:30:50 GMT Subject: RFR: 8293445: clhsdb "thread" command gives incorrect error message for bad threadID In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 19:28:15 GMT, Chris Plummer wrote: > As pointed out in [JDK-8283010](https://bugs.openjdk.org/browse/JDK-8283010), when a bad threadID is passed to the clhsdb "thread" command, the error message is incorrect: > > hsdb> thread 18 > Couldn't find thread thread > > It should say "thread 18", not "thread thread". The code looks like: > > out.println("Couldn't find thread " + name); > > "name" is the name of the command. It should instead use "id". > > I'd like to push this as a trivial change. Thanks, Dan! ------------- PR: https://git.openjdk.org/jdk/pull/10186 From cjplummer at openjdk.org Tue Sep 6 22:30:51 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 Sep 2022 22:30:51 GMT Subject: Integrated: 8293445: clhsdb "thread" command gives incorrect error message for bad threadID In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 19:28:15 GMT, Chris Plummer wrote: > As pointed out in [JDK-8283010](https://bugs.openjdk.org/browse/JDK-8283010), when a bad threadID is passed to the clhsdb "thread" command, the error message is incorrect: > > hsdb> thread 18 > Couldn't find thread thread > > It should say "thread 18", not "thread thread". The code looks like: > > out.println("Couldn't find thread " + name); > > "name" is the name of the command. It should instead use "id". > > I'd like to push this as a trivial change. This pull request has now been integrated. Changeset: 710a1434 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/710a14347344f3cc136f3b7f41aad231fbe43625 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8293445: clhsdb "thread" command gives incorrect error message for bad threadID Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk/pull/10186 From jrose at openjdk.org Wed Sep 7 01:05:38 2022 From: jrose at openjdk.org (John R Rose) Date: Wed, 7 Sep 2022 01:05:38 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v5] In-Reply-To: References: Message-ID: > Refactor code from inside of CompressedStream into its own unit. > > This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). > > Add gtests. John R Rose has updated the pull request incrementally with one additional commit since the last revision: add missing "this->" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10067/files - new: https://git.openjdk.org/jdk/pull/10067/files/439b108b..172420ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10067&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10067.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10067/head:pull/10067 PR: https://git.openjdk.org/jdk/pull/10067 From cjplummer at openjdk.org Wed Sep 7 02:12:19 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 7 Sep 2022 02:12:19 GMT Subject: RFR: 8283224: Remove THREAD_NOT_ALIVE from possible JDWP error codes Message-ID: <-uXeHdtNBceQvqp-l256Tx1kI80v-tbD8-OMV_oMD7I=.34fbf6f5-2edc-4ed7-87cd-5734064b76c8@github.com> THREAD_NOT_ALIVE originates from JVMTI. However, the debug agent converts it to INVALID_THREAD before passing it on to the debug agent client (the debugger, usually JDI), so debug agent users (JDI) should never see it. Currently ThreadReference.forceEarlyReturn() is the only API that even bothers to check for it, and it throws com.sun.jdi.IllegalThreadStateException, which is the same thing it already does for INVALID_THREAD. In the JDWP spec I change the description of THREAD_NOT_ALIVE to "Not used". If you have a suggestion for better wording, please let me now. (I was thinking maybe "Unused" would be better. In the JDI ThreadReference.forceEarlyReturn implementation, I removed the code that checks for THREAD_NOT_ALIVE since it should never occur. There is no behavior change associated with this change, and there is no JDI spec update necessary. The spec already says IllegalThreadStateException means "the thread is not suspended", and not being alive implies not suspended. Note the JDWP spec for ThreadReference.ForceEarlyReturn used to mention THREAD_NOT_ALIVE as a possible error code, but it was removed as part of the loom work. ------------- Commit messages: - Cleanup THREAD_NOT_ALIVE usage Changes: https://git.openjdk.org/jdk/pull/10189/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10189&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8283224 Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10189.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10189/head:pull/10189 PR: https://git.openjdk.org/jdk/pull/10189 From sspitsyn at openjdk.org Wed Sep 7 05:59:25 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 7 Sep 2022 05:59:25 GMT Subject: RFR: 8293333: Broken links in JDI specification Message-ID: The JDI files `com/sun/jdi/ClassLoaderReference.java` and `com/sun/jdi/VirtualMachine.java` have incorrect links to the JVM TI spec with the extra folder name `jvmti`. The fix is to get rid unneeded part from the links: --- a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java +++ b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java @@ -93,7 +93,7 @@ public interface ClassLoaderReference extends ObjectReference { * classes which this class loader can find by name. The list * has length 0 if no classes are visible to this classloader. * - * @see + * @see * JVM TI GetClassLoaderClasses */ List visibleClasses(); diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java index 12cdd566989..64c91c8d1bb 100644 --- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java +++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java @@ -144,7 +144,7 @@ public interface VirtualMachine extends Mirror { * * @return a list of {@link ReferenceType} objects, each mirroring * a loaded type in the target VM. - * @see + * @see * JVM TI GetLoadedClasses regarding how class and interface creation can be triggered */ List allClasses(); ------------- Commit messages: - 8293333: Broken links in JDI specification Changes: https://git.openjdk.org/jdk/pull/10191/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10191&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293333 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10191.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10191/head:pull/10191 PR: https://git.openjdk.org/jdk/pull/10191 From alanb at openjdk.org Wed Sep 7 05:59:40 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 Sep 2022 05:59:40 GMT Subject: RFR: 8283224: Remove THREAD_NOT_ALIVE from possible JDWP error codes In-Reply-To: <-uXeHdtNBceQvqp-l256Tx1kI80v-tbD8-OMV_oMD7I=.34fbf6f5-2edc-4ed7-87cd-5734064b76c8@github.com> References: <-uXeHdtNBceQvqp-l256Tx1kI80v-tbD8-OMV_oMD7I=.34fbf6f5-2edc-4ed7-87cd-5734064b76c8@github.com> Message-ID: <6Wy9qMUgvr4sTtVE_fN6OK3jJmVVP8nEseltlSvThXQ=.3125ec75-fc3c-4d60-87a6-ff1ae38ebff2@github.com> On Wed, 7 Sep 2022 02:04:13 GMT, Chris Plummer wrote: > THREAD_NOT_ALIVE originates from JVMTI. However, the debug agent converts it to INVALID_THREAD before passing it on to the debug agent client (the debugger, usually JDI), so debug agent users (JDI) should never see it. Currently ThreadReference.forceEarlyReturn() is the only API that even bothers to check for it, and it throws com.sun.jdi.IllegalThreadStateException, which is the same thing it already does for INVALID_THREAD. > > In the JDWP spec I change the description of THREAD_NOT_ALIVE to "Not used". If you have a suggestion for better wording, please let me now. (I was thinking maybe "Unused" would be better. > > In the JDI ThreadReference.forceEarlyReturn implementation, I removed the code that checks for THREAD_NOT_ALIVE since it should never occur. There is no behavior change associated with this change, and there is no JDI spec update necessary. The spec already says IllegalThreadStateException means "the thread is not suspended", and not being alive implies not suspended. > > Note the JDWP spec for ThreadReference.ForceEarlyReturn used to mention THREAD_NOT_ALIVE as a possible error code, but it was removed as part of the loom work. src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java line 600: > 598: case JDWP.Error.THREAD_NOT_ALIVE: > 599: throw new IncompatibleThreadStateException( > 600: "Thread has not started or has finished"); When doing anything here we have to take into account that the debugger (or JDI tool) may be connected to a target VM on an older or newer release. So if I read the issue correctly, the reply to the ThreadReference/ForceEarlyReturn command never returned THREAD_NOT_ALIVE so it's okay to remove the mapping to IncompatibleThreadStateException. ------------- PR: https://git.openjdk.org/jdk/pull/10189 From alanb at openjdk.org Wed Sep 7 06:07:42 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 Sep 2022 06:07:42 GMT Subject: RFR: 8283224: Remove THREAD_NOT_ALIVE from possible JDWP error codes In-Reply-To: <-uXeHdtNBceQvqp-l256Tx1kI80v-tbD8-OMV_oMD7I=.34fbf6f5-2edc-4ed7-87cd-5734064b76c8@github.com> References: <-uXeHdtNBceQvqp-l256Tx1kI80v-tbD8-OMV_oMD7I=.34fbf6f5-2edc-4ed7-87cd-5734064b76c8@github.com> Message-ID: On Wed, 7 Sep 2022 02:04:13 GMT, Chris Plummer wrote: > THREAD_NOT_ALIVE originates from JVMTI. However, the debug agent converts it to INVALID_THREAD before passing it on to the debug agent client (the debugger, usually JDI), so debug agent users (JDI) should never see it. Currently ThreadReference.forceEarlyReturn() is the only API that even bothers to check for it, and it throws com.sun.jdi.IllegalThreadStateException, which is the same thing it already does for INVALID_THREAD. > > In the JDWP spec I change the description of THREAD_NOT_ALIVE to "Not used". If you have a suggestion for better wording, please let me now. (I was thinking maybe "Unused" would be better. > > In the JDI ThreadReference.forceEarlyReturn implementation, I removed the code that checks for THREAD_NOT_ALIVE since it should never occur. There is no behavior change associated with this change, and there is no JDI spec update necessary. The spec already says IllegalThreadStateException means "the thread is not suspended", and not being alive implies not suspended. > > Note the JDWP spec for ThreadReference.ForceEarlyReturn used to mention THREAD_NOT_ALIVE as a possible error code, but it was removed as part of the loom work. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10189 From alanb at openjdk.org Wed Sep 7 06:09:39 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 Sep 2022 06:09:39 GMT Subject: RFR: 8293333: Broken links in JDI specification In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 05:51:53 GMT, Serguei Spitsyn wrote: > The JDI files `com/sun/jdi/ClassLoaderReference.java` and `com/sun/jdi/VirtualMachine.java` have incorrect links to the JVM TI spec with the extra folder name `jvmti`. > > The fix is to get rid unneeded part from the links: > > --- a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > @@ -93,7 +93,7 @@ public interface ClassLoaderReference extends ObjectReference { > * classes which this class loader can find by name. The list > * has length 0 if no classes are visible to this classloader. > * > - * @see > + * @see > * JVM TI GetClassLoaderClasses > */ > List visibleClasses(); > diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > index 12cdd566989..64c91c8d1bb 100644 > --- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > @@ -144,7 +144,7 @@ public interface VirtualMachine extends Mirror { > * > * @return a list of {@link ReferenceType} objects, each mirroring > * a loaded type in the target VM. > - * @see > + * @see > * JVM TI GetLoadedClasses regarding how class and interface creation can be triggered > */ > List allClasses(); Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10191 From sspitsyn at openjdk.org Wed Sep 7 06:15:57 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 7 Sep 2022 06:15:57 GMT Subject: RFR: 8293432: Use diamond operator in java.management In-Reply-To: References: Message-ID: <9BqxIRjxTOhZ8LYwNYnxWFsfd8GqS-NQJyLInnXisf0=.79615543-7a69-42c7-90f8-bbedfcb3b5aa@github.com> On Mon, 5 Sep 2022 19:56:44 GMT, Andrey Turbanov wrote: > The diamond operator was introduced in Java 7. We can take advantage of this language feature to make code easier to read. > Tested on Linux release x64. `make test TEST="jdk/java/lang/management jdk/javax/management jdk/com/sun/jmx jdk/sun/management"` > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk/java/lang/management 69 69 0 0 > jtreg:test/jdk/javax/management 246 246 0 0 > jtreg:test/jdk/com/sun/jmx 3 3 0 0 >>> jtreg:test/jdk/sun/management 33 32 0 1 << > > Single failure - is a test `RmiBootstrapTest.java#id1`. It's known issue - [JDK-8293335](https://bugs.openjdk.org/browse/JDK-8293335). LGTM. Thanks, Serguei Marked as reviewed by sspitsyn (Reviewer). ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10173 From sspitsyn at openjdk.org Wed Sep 7 06:21:54 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 7 Sep 2022 06:21:54 GMT Subject: RFR: 8283224: Remove THREAD_NOT_ALIVE from possible JDWP error codes In-Reply-To: <-uXeHdtNBceQvqp-l256Tx1kI80v-tbD8-OMV_oMD7I=.34fbf6f5-2edc-4ed7-87cd-5734064b76c8@github.com> References: <-uXeHdtNBceQvqp-l256Tx1kI80v-tbD8-OMV_oMD7I=.34fbf6f5-2edc-4ed7-87cd-5734064b76c8@github.com> Message-ID: On Wed, 7 Sep 2022 02:04:13 GMT, Chris Plummer wrote: > THREAD_NOT_ALIVE originates from JVMTI. However, the debug agent converts it to INVALID_THREAD before passing it on to the debug agent client (the debugger, usually JDI), so debug agent users (JDI) should never see it. Currently ThreadReference.forceEarlyReturn() is the only API that even bothers to check for it, and it throws com.sun.jdi.IllegalThreadStateException, which is the same thing it already does for INVALID_THREAD. > > In the JDWP spec I change the description of THREAD_NOT_ALIVE to "Not used". If you have a suggestion for better wording, please let me now. (I was thinking maybe "Unused" would be better. > > In the JDI ThreadReference.forceEarlyReturn implementation, I removed the code that checks for THREAD_NOT_ALIVE since it should never occur. There is no behavior change associated with this change, and there is no JDI spec update necessary. The spec already says IllegalThreadStateException means "the thread is not suspended", and not being alive implies not suspended. > > Note the JDWP spec for ThreadReference.ForceEarlyReturn used to mention THREAD_NOT_ALIVE as a possible error code, but it was removed as part of the loom work. This looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10189 From cjplummer at openjdk.org Wed Sep 7 06:34:47 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 7 Sep 2022 06:34:47 GMT Subject: RFR: 8293333: Broken links in JDI specification In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 05:51:53 GMT, Serguei Spitsyn wrote: > The JDI files `com/sun/jdi/ClassLoaderReference.java` and `com/sun/jdi/VirtualMachine.java` have incorrect links to the JVM TI spec with the extra folder name `jvmti`. > > The fix is to get rid unneeded part from the links: > > --- a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > @@ -93,7 +93,7 @@ public interface ClassLoaderReference extends ObjectReference { > * classes which this class loader can find by name. The list > * has length 0 if no classes are visible to this classloader. > * > - * @see > + * @see > * JVM TI GetClassLoaderClasses > */ > List visibleClasses(); > diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > index 12cdd566989..64c91c8d1bb 100644 > --- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > @@ -144,7 +144,7 @@ public interface VirtualMachine extends Mirror { > * > * @return a list of {@link ReferenceType} objects, each mirroring > * a loaded type in the target VM. > - * @see > + * @see > * JVM TI GetLoadedClasses regarding how class and interface creation can be triggered > */ > List allClasses(); Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10191 From cjplummer at openjdk.org Wed Sep 7 06:37:40 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 7 Sep 2022 06:37:40 GMT Subject: RFR: 8283224: Remove THREAD_NOT_ALIVE from possible JDWP error codes In-Reply-To: <6Wy9qMUgvr4sTtVE_fN6OK3jJmVVP8nEseltlSvThXQ=.3125ec75-fc3c-4d60-87a6-ff1ae38ebff2@github.com> References: <-uXeHdtNBceQvqp-l256Tx1kI80v-tbD8-OMV_oMD7I=.34fbf6f5-2edc-4ed7-87cd-5734064b76c8@github.com> <6Wy9qMUgvr4sTtVE_fN6OK3jJmVVP8nEseltlSvThXQ=.3125ec75-fc3c-4d60-87a6-ff1ae38ebff2@github.com> Message-ID: On Wed, 7 Sep 2022 05:55:56 GMT, Alan Bateman wrote: > So if I read the issue correctly, the reply to the ThreadReference/ForceEarlyReturn command never returned THREAD_NOT_ALIVE so it's okay to remove the mapping to IncompatibleThreadStateException. It was not some recent change in the debug agent that eliminated returning THREAD_NOT_ALIVE. However, I can't say for sure that it has never returned it. In fact I would assume at some point it did return it, but that could be as far back as the JVMDI days. ------------- PR: https://git.openjdk.org/jdk/pull/10189 From stefank at openjdk.org Wed Sep 7 07:06:47 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 7 Sep 2022 07:06:47 GMT Subject: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 09:51:06 GMT, Stefan Karlsson wrote: > During the discussion of [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was voiced that we should stop using INTPTR_FORMAT when printing pointers. > > Some background that could explain why some tend to use INTPTR_FORMAT instead of PTR_FORMAT: > > Both those format specifiers require an integer and the compiler barfs if you send in a pointer. We therefore have a utility function named p2i, which converts the pointer to an integer. So, everywhere we have to write print line like this: `print("my pointer: " PTR_FORMAT, p2i(my_pointer));`. Now, p2i returns an intptr_t, and it becomes natural for some to consider the type of the converted value (that we need because of the mentioned workaround), instead of the original type of the value. > > With this enhancement I'd like to clean up the code that I often work in, so that it uses PTR_FORMAT when printing pointers. I'm leaving the rest of the code base for others to consider cleaning up. > > Cleanups have been done in directories gc/, utilities/, memory/, and oops/. @kimbarrett You commented on the "incorrect" usages of INTPTR_FORMAT in JDK-8292981. Do you think this PR moves the code in the right direction? ------------- PR: https://git.openjdk.org/jdk/pull/10141 From cjplummer at openjdk.org Wed Sep 7 08:13:43 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 7 Sep 2022 08:13:43 GMT Subject: RFR: 8283224: Remove THREAD_NOT_ALIVE from possible JDWP error codes In-Reply-To: References: <-uXeHdtNBceQvqp-l256Tx1kI80v-tbD8-OMV_oMD7I=.34fbf6f5-2edc-4ed7-87cd-5734064b76c8@github.com> <6Wy9qMUgvr4sTtVE_fN6OK3jJmVVP8nEseltlSvThXQ=.3125ec75-fc3c-4d60-87a6-ff1ae38ebff2@github.com> Message-ID: On Wed, 7 Sep 2022 06:35:23 GMT, Chris Plummer wrote: >> src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java line 600: >> >>> 598: case JDWP.Error.THREAD_NOT_ALIVE: >>> 599: throw new IncompatibleThreadStateException( >>> 600: "Thread has not started or has finished"); >> >> When doing anything here we have to take into account that the debugger (or JDI tool) may be connected to a target VM on an older or newer release. So if I read the issue correctly, the reply to the ThreadReference/ForceEarlyReturn command never returned THREAD_NOT_ALIVE so it's okay to remove the mapping to IncompatibleThreadStateException. > >> So if I read the issue correctly, the reply to the ThreadReference/ForceEarlyReturn command never returned THREAD_NOT_ALIVE so it's okay to remove the mapping to IncompatibleThreadStateException. > > It was not some recent change in the debug agent that eliminated returning THREAD_NOT_ALIVE. However, I can't say for sure that it has never returned it. In fact I would assume at some point it did return it, but that could be as far back as the JVMDI days. BTW, if any command gets a THREAD_NOT_ALIVE, the following is done: ` return new InternalException("Unexpected JDWP Error: " + errorCode, errorCode);` ------------- PR: https://git.openjdk.org/jdk/pull/10189 From sspitsyn at openjdk.org Wed Sep 7 09:05:56 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 7 Sep 2022 09:05:56 GMT Subject: RFR: 8293333: Broken links in JDI specification In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 05:51:53 GMT, Serguei Spitsyn wrote: > The JDI files `com/sun/jdi/ClassLoaderReference.java` and `com/sun/jdi/VirtualMachine.java` have incorrect links to the JVM TI spec with the extra folder name `jvmti`. > > The fix is to get rid unneeded part from the links: > > --- a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > @@ -93,7 +93,7 @@ public interface ClassLoaderReference extends ObjectReference { > * classes which this class loader can find by name. The list > * has length 0 if no classes are visible to this classloader. > * > - * @see > + * @see > * JVM TI GetClassLoaderClasses > */ > List visibleClasses(); > diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > index 12cdd566989..64c91c8d1bb 100644 > --- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > @@ -144,7 +144,7 @@ public interface VirtualMachine extends Mirror { > * > * @return a list of {@link ReferenceType} objects, each mirroring > * a loaded type in the target VM. > - * @see > + * @see > * JVM TI GetLoadedClasses regarding how class and interface creation can be triggered > */ > List allClasses(); Alan and Chris, thank you for quick review! ------------- PR: https://git.openjdk.org/jdk/pull/10191 From sspitsyn at openjdk.org Wed Sep 7 09:07:13 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 7 Sep 2022 09:07:13 GMT Subject: Integrated: 8293333: Broken links in JDI specification In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 05:51:53 GMT, Serguei Spitsyn wrote: > The JDI files `com/sun/jdi/ClassLoaderReference.java` and `com/sun/jdi/VirtualMachine.java` have incorrect links to the JVM TI spec with the extra folder name `jvmti`. > > The fix is to get rid unneeded part from the links: > > --- a/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/ClassLoaderReference.java > @@ -93,7 +93,7 @@ public interface ClassLoaderReference extends ObjectReference { > * classes which this class loader can find by name. The list > * has length 0 if no classes are visible to this classloader. > * > - * @see > + * @see > * JVM TI GetClassLoaderClasses > */ > List visibleClasses(); > diff --git a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > index 12cdd566989..64c91c8d1bb 100644 > --- a/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > +++ b/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > @@ -144,7 +144,7 @@ public interface VirtualMachine extends Mirror { > * > * @return a list of {@link ReferenceType} objects, each mirroring > * a loaded type in the target VM. > - * @see > + * @see > * JVM TI GetLoadedClasses regarding how class and interface creation can be triggered > */ > List allClasses(); This pull request has now been integrated. Changeset: 4f9065d3 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/4f9065d3d5e914f8e89daf1ff27bba3578b19e20 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8293333: Broken links in JDI specification Reviewed-by: alanb, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/10191 From coleenp at openjdk.org Wed Sep 7 17:37:44 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 7 Sep 2022 17:37:44 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v5] In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 01:05:38 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose has updated the pull request incrementally with one additional commit since the last revision: > > add missing "this->" src/hotspot/share/utilities/unsigned5.hpp line 190: > 188: // reports the largest uint32_t value that can be encoded using len bytes > 189: // len must be in the range [1..5] > 190: static constexpr uint32_t max_encoded_in_length(uint32_t len) { A few of the classes make the gtest test a friend so that internal functions can be private. ------------- PR: https://git.openjdk.org/jdk/pull/10067 From coleenp at openjdk.org Wed Sep 7 17:46:59 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 7 Sep 2022 17:46:59 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v5] In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 01:05:38 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose has updated the pull request incrementally with one additional commit since the last revision: > > add missing "this->" This looks good to me, for the current CompressedStream and for upcoming changes. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/10067 From cjplummer at openjdk.org Wed Sep 7 19:48:47 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 7 Sep 2022 19:48:47 GMT Subject: RFR: 8283224: Remove THREAD_NOT_ALIVE from possible JDWP error codes In-Reply-To: <-uXeHdtNBceQvqp-l256Tx1kI80v-tbD8-OMV_oMD7I=.34fbf6f5-2edc-4ed7-87cd-5734064b76c8@github.com> References: <-uXeHdtNBceQvqp-l256Tx1kI80v-tbD8-OMV_oMD7I=.34fbf6f5-2edc-4ed7-87cd-5734064b76c8@github.com> Message-ID: On Wed, 7 Sep 2022 02:04:13 GMT, Chris Plummer wrote: > THREAD_NOT_ALIVE originates from JVMTI. However, the debug agent converts it to INVALID_THREAD before passing it on to the debug agent client (the debugger, usually JDI), so debug agent users (JDI) should never see it. Currently ThreadReference.forceEarlyReturn() is the only API that even bothers to check for it, and it throws com.sun.jdi.IllegalThreadStateException, which is the same thing it already does for INVALID_THREAD. > > In the JDWP spec I change the description of THREAD_NOT_ALIVE to "Not used". If you have a suggestion for better wording, please let me now. (I was thinking maybe "Unused" would be better. > > In the JDI ThreadReference.forceEarlyReturn implementation, I removed the code that checks for THREAD_NOT_ALIVE since it should never occur. There is no behavior change associated with this change, and there is no JDI spec update necessary. The spec already says IllegalThreadStateException means "the thread is not suspended", and not being alive implies not suspended. > > Note the JDWP spec for ThreadReference.ForceEarlyReturn used to mention THREAD_NOT_ALIVE as a possible error code, but it was removed as part of the loom work. Thanks Serguei and Alan! ------------- PR: https://git.openjdk.org/jdk/pull/10189 From cjplummer at openjdk.org Wed Sep 7 19:48:47 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 7 Sep 2022 19:48:47 GMT Subject: Integrated: 8283224: Remove THREAD_NOT_ALIVE from possible JDWP error codes In-Reply-To: <-uXeHdtNBceQvqp-l256Tx1kI80v-tbD8-OMV_oMD7I=.34fbf6f5-2edc-4ed7-87cd-5734064b76c8@github.com> References: <-uXeHdtNBceQvqp-l256Tx1kI80v-tbD8-OMV_oMD7I=.34fbf6f5-2edc-4ed7-87cd-5734064b76c8@github.com> Message-ID: On Wed, 7 Sep 2022 02:04:13 GMT, Chris Plummer wrote: > THREAD_NOT_ALIVE originates from JVMTI. However, the debug agent converts it to INVALID_THREAD before passing it on to the debug agent client (the debugger, usually JDI), so debug agent users (JDI) should never see it. Currently ThreadReference.forceEarlyReturn() is the only API that even bothers to check for it, and it throws com.sun.jdi.IllegalThreadStateException, which is the same thing it already does for INVALID_THREAD. > > In the JDWP spec I change the description of THREAD_NOT_ALIVE to "Not used". If you have a suggestion for better wording, please let me now. (I was thinking maybe "Unused" would be better. > > In the JDI ThreadReference.forceEarlyReturn implementation, I removed the code that checks for THREAD_NOT_ALIVE since it should never occur. There is no behavior change associated with this change, and there is no JDI spec update necessary. The spec already says IllegalThreadStateException means "the thread is not suspended", and not being alive implies not suspended. > > Note the JDWP spec for ThreadReference.ForceEarlyReturn used to mention THREAD_NOT_ALIVE as a possible error code, but it was removed as part of the loom work. This pull request has now been integrated. Changeset: aff9a696 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/aff9a696cb0b281a736e66007a4087923d7abab2 Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod 8283224: Remove THREAD_NOT_ALIVE from possible JDWP error codes Reviewed-by: alanb, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/10189 From amenkov at openjdk.org Wed Sep 7 20:09:05 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 7 Sep 2022 20:09:05 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v3] In-Reply-To: References: Message-ID: > The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) > > cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. > After successful RedefineClasses it should be reset. > The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: updated test. comments, code reorg ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10032/files - new: https://git.openjdk.org/jdk/pull/10032/files/d86ae7fa..9bc08346 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=01-02 Stats: 303 lines in 2 files changed: 129 ins; 104 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/10032.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10032/head:pull/10032 PR: https://git.openjdk.org/jdk/pull/10032 From amenkov at openjdk.org Wed Sep 7 20:09:06 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 7 Sep 2022 20:09:06 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v2] In-Reply-To: References: Message-ID: On Sat, 3 Sep 2022 09:47:05 GMT, Serguei Spitsyn wrote: > Also, I'm curious how did you verify that no regressions have been introduced? Run all Redefine/Retransform Classes tests: test/jdk/java/lang/instrument test/hotspot/jtreg/serviceability/jvmti/RedefineClasses test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 76: > >> 74: private static byte[] initialClassBytes; >> 75: >> 76: private static class VersionScanner extends ClassVisitor { > > This class needs some explanation. > It is unclear how does it work. > Could you, please, add relevant comments where needed? > For instance, how are the class file bytes constructed and what role does the version play. Done. > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 236: > >> 234: redefine(2, 5); // updates cached class bytes >> 235: retransform(3, 2); >> 236: retransform(4, 2); > > The comments for all test cases need to be aligned. > Also, it is better to comment all redefine/retransform cases. Done. > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 179: > >> 177: if (err != JVMTI_ERROR_NONE) { >> 178: _log("nRedefine: SetEventNotificationMode(JVMTI_DISABLE) error %d\n", err); >> 179: } > > It makes sense to introduce an utility function which does SetEventNotificationMode. > It can be two separate functions to enable and disable or one single function can support both cases. Removed code duplication - now the code is in helper class > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 195: > >> 193: _log("nRedefine: classLoadHookSavedClassBytes is NULL\n"); >> 194: return nullptr; >> 195: } > > The checks 181-195 seems to be the same in functions nRedefine and nRetransform, > so one utility function can be used in both cases. Removed code duplication - now the code is in helper class > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 274: > >> 272: classLoadHookSavedClassBytes = nullptr; >> 273: >> 274: return result; > > The fragments 197-214 and 256-274 do the same. > I'd suggest to define and use a function that does this post-processing. reworked the code a bit, moved all common code to helper class ------------- PR: https://git.openjdk.org/jdk/pull/10032 From amenkov at openjdk.org Wed Sep 7 20:13:56 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 7 Sep 2022 20:13:56 GMT Subject: RFR: 8283010: serviceability/sa/ClhsdbThread.java failed with "'Base of Stack:' missing from stdout/stderr " In-Reply-To: <0XT3wfxBd1xlzY21gfkQ8oc9ZJX5rPMORnX2rotI0c4=.a7572e61-5a34-4c04-ab39-1ebb101b1ceb@github.com> References: <0XT3wfxBd1xlzY21gfkQ8oc9ZJX5rPMORnX2rotI0c4=.a7572e61-5a34-4c04-ab39-1ebb101b1ceb@github.com> Message-ID: On Tue, 6 Sep 2022 19:26:09 GMT, Chris Plummer wrote: > Each time you attach to a target JVM on Windows, thread Id's can change (although they rarely do). For this reason you can't reliably do what this test is doing, which is attach, run jstack to get the threadId of a thread, detach, attach again and run the `thread` command using the threadId. It might not be valid any more. For this reason I am changing the test to ignore the result of the `thread` command when running on windows. This is the same fix as was done for [JDK-8280770](https://bugs.openjdk.org/browse/JDK-8280770) > > I'd like to push this as a trivial change. I agree that this may be considered as a trivial change ------------- Marked as reviewed by amenkov (Reviewer). PR: https://git.openjdk.org/jdk/pull/10185 From cjplummer at openjdk.org Wed Sep 7 21:52:44 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 7 Sep 2022 21:52:44 GMT Subject: RFR: 8283010: serviceability/sa/ClhsdbThread.java failed with "'Base of Stack:' missing from stdout/stderr " In-Reply-To: <0XT3wfxBd1xlzY21gfkQ8oc9ZJX5rPMORnX2rotI0c4=.a7572e61-5a34-4c04-ab39-1ebb101b1ceb@github.com> References: <0XT3wfxBd1xlzY21gfkQ8oc9ZJX5rPMORnX2rotI0c4=.a7572e61-5a34-4c04-ab39-1ebb101b1ceb@github.com> Message-ID: On Tue, 6 Sep 2022 19:26:09 GMT, Chris Plummer wrote: > Each time you attach to a target JVM on Windows, thread Id's can change (although they rarely do). For this reason you can't reliably do what this test is doing, which is attach, run jstack to get the threadId of a thread, detach, attach again and run the `thread` command using the threadId. It might not be valid any more. For this reason I am changing the test to ignore the result of the `thread` command when running on windows. This is the same fix as was done for [JDK-8280770](https://bugs.openjdk.org/browse/JDK-8280770) > > I'd like to push this as a trivial change. Thanks Alex! ------------- PR: https://git.openjdk.org/jdk/pull/10185 From cjplummer at openjdk.org Wed Sep 7 21:54:12 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 7 Sep 2022 21:54:12 GMT Subject: Integrated: 8283010: serviceability/sa/ClhsdbThread.java failed with "'Base of Stack:' missing from stdout/stderr " In-Reply-To: <0XT3wfxBd1xlzY21gfkQ8oc9ZJX5rPMORnX2rotI0c4=.a7572e61-5a34-4c04-ab39-1ebb101b1ceb@github.com> References: <0XT3wfxBd1xlzY21gfkQ8oc9ZJX5rPMORnX2rotI0c4=.a7572e61-5a34-4c04-ab39-1ebb101b1ceb@github.com> Message-ID: On Tue, 6 Sep 2022 19:26:09 GMT, Chris Plummer wrote: > Each time you attach to a target JVM on Windows, thread Id's can change (although they rarely do). For this reason you can't reliably do what this test is doing, which is attach, run jstack to get the threadId of a thread, detach, attach again and run the `thread` command using the threadId. It might not be valid any more. For this reason I am changing the test to ignore the result of the `thread` command when running on windows. This is the same fix as was done for [JDK-8280770](https://bugs.openjdk.org/browse/JDK-8280770) > > I'd like to push this as a trivial change. This pull request has now been integrated. Changeset: 51de7658 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/51de765867d4d44fc2e2953a0296ca6804135d89 Stats: 13 lines in 1 file changed: 8 ins; 0 del; 5 mod 8283010: serviceability/sa/ClhsdbThread.java failed with "'Base of Stack:' missing from stdout/stderr " Reviewed-by: amenkov ------------- PR: https://git.openjdk.org/jdk/pull/10185 From dcubed at openjdk.org Wed Sep 7 22:09:29 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 7 Sep 2022 22:09:29 GMT Subject: RFR: 8293512: ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode Message-ID: Trivial fixes to ProblemList 4 tests that fail in the upper Tiers: [JDK-8293512](https://bugs.openjdk.org/browse/JDK-8293512) ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode [JDK-8293516](https://bugs.openjdk.org/browse/JDK-8293516) ProblemList gc/cslocker/TestCSLocker.java in -Xcomp mode [JDK-8293517](https://bugs.openjdk.org/browse/JDK-8293517) ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 [JDK-8293518](https://bugs.openjdk.org/browse/JDK-8293518) ProblemList sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java ------------- Commit messages: - 8293518: ProblemList sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java - 8293517: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 - 8293516: ProblemList gc/cslocker/TestCSLocker.java in -Xcomp mode - 8293512: ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode Changes: https://git.openjdk.org/jdk/pull/10209/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10209&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293512 Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10209.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10209/head:pull/10209 PR: https://git.openjdk.org/jdk/pull/10209 From bpb at openjdk.org Wed Sep 7 22:09:30 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 7 Sep 2022 22:09:30 GMT Subject: RFR: 8293512: ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 21:53:06 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList 4 tests that fail in the upper Tiers: > > [JDK-8293512](https://bugs.openjdk.org/browse/JDK-8293512) ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode > > [JDK-8293516](https://bugs.openjdk.org/browse/JDK-8293516) ProblemList gc/cslocker/TestCSLocker.java in -Xcomp mode > > [JDK-8293517](https://bugs.openjdk.org/browse/JDK-8293517) ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 > > [JDK-8293518](https://bugs.openjdk.org/browse/JDK-8293518) ProblemList sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10209 From kbarrett at openjdk.org Wed Sep 7 22:09:47 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 7 Sep 2022 22:09:47 GMT Subject: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT In-Reply-To: References: Message-ID: <0Nhq3dcg-Z0G4AYgpcHDGa4xMDHSSBC97eGtKmiw_bY=.934c0f0c-7c1a-4f90-9cce-91bcf0c2ac00@github.com> On Fri, 2 Sep 2022 09:51:06 GMT, Stefan Karlsson wrote: > During the discussion of [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was voiced that we should stop using INTPTR_FORMAT when printing pointers. > > Some background that could explain why some tend to use INTPTR_FORMAT instead of PTR_FORMAT: > > Both those format specifiers require an integer and the compiler barfs if you send in a pointer. We therefore have a utility function named p2i, which converts the pointer to an integer. So, everywhere we have to write print line like this: `print("my pointer: " PTR_FORMAT, p2i(my_pointer));`. Now, p2i returns an intptr_t, and it becomes natural for some to consider the type of the converted value (that we need because of the mentioned workaround), instead of the original type of the value. > > With this enhancement I'd like to clean up the code that I often work in, so that it uses PTR_FORMAT when printing pointers. I'm leaving the rest of the code base for others to consider cleaning up. > > Cleanups have been done in directories gc/, utilities/, memory/, and oops/. Looks good. I did notice a couple INTPTR_FORMAT => (new) SIZE_FORMAT_X_0. Good change. I also noticed a place where there are sequential asserts, one (previously) using INTPTR_FORMAT and the next PTR_FORMAT, for the same value. Seems like somebody wasn't paying attention. Again good change. Also noticed some pre-existing unnecessary (void*) casts of the pointer argument to p2i. Not your problem, and not really appropriate for this change to do anything about them, but I really hate eye-catching cast junk like that. There were also a few INTPTR_FORMAT uses that were left in place. All that I recall looked like they could/should instead be SIZE_FORMAT_X_0 or maybe even SIZE_FORMAT_X if the zero padding isn't useful. Leaving those for a later pass seems fine. I wonder how many INTPTR_FORMATs are left in the areas you worked on? ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/10141 From dcubed at openjdk.org Wed Sep 7 23:09:43 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 7 Sep 2022 23:09:43 GMT Subject: RFR: 8293512: ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 22:03:43 GMT, Brian Burkhalter wrote: >> Trivial fixes to ProblemList 4 tests that fail in the upper Tiers: >> >> [JDK-8293512](https://bugs.openjdk.org/browse/JDK-8293512) ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode >> >> [JDK-8293516](https://bugs.openjdk.org/browse/JDK-8293516) ProblemList gc/cslocker/TestCSLocker.java in -Xcomp mode >> >> [JDK-8293517](https://bugs.openjdk.org/browse/JDK-8293517) ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 >> >> [JDK-8293518](https://bugs.openjdk.org/browse/JDK-8293518) ProblemList sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java > > Marked as reviewed by bpb (Reviewer). @bplb - Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/10209 From dcubed at openjdk.org Wed Sep 7 23:12:44 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 7 Sep 2022 23:12:44 GMT Subject: Integrated: 8293512: ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 21:53:06 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList 4 tests that fail in the upper Tiers: > > [JDK-8293512](https://bugs.openjdk.org/browse/JDK-8293512) ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode > > [JDK-8293516](https://bugs.openjdk.org/browse/JDK-8293516) ProblemList gc/cslocker/TestCSLocker.java in -Xcomp mode > > [JDK-8293517](https://bugs.openjdk.org/browse/JDK-8293517) ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 > > [JDK-8293518](https://bugs.openjdk.org/browse/JDK-8293518) ProblemList sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java This pull request has now been integrated. Changeset: 2d13f530 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/2d13f53017377128b7a8f1e3da9a09f7af92085a Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod 8293512: ProblemList serviceability/tmtools/jstat/GcNewTest.java in -Xcomp mode 8293516: ProblemList gc/cslocker/TestCSLocker.java in -Xcomp mode 8293517: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 8293518: ProblemList sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk/pull/10209 From sspitsyn at openjdk.org Thu Sep 8 00:10:42 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 8 Sep 2022 00:10:42 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v3] In-Reply-To: References: Message-ID: <94C15Oo65ApUHiIfsMs68E_bk1isRLk3KQXndfb6_tM=.c96142ba-e8ae-4274-af6f-f9225ebd7201@github.com> On Wed, 7 Sep 2022 20:09:05 GMT, Alex Menkov wrote: >> The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) >> >> cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. >> After successful RedefineClasses it should be reset. >> The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated test. comments, code reorg Alex, Thank you for the update! It looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10032 From dlong at openjdk.org Thu Sep 8 01:37:01 2022 From: dlong at openjdk.org (Dean Long) Date: Thu, 8 Sep 2022 01:37:01 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v5] In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 01:05:38 GMT, John R Rose wrote: >> Refactor code from inside of CompressedStream into its own unit. >> >> This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). >> >> Add gtests. > > John R Rose has updated the pull request incrementally with one additional commit since the last revision: > > add missing "this->" Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10067 From jrose at openjdk.org Thu Sep 8 07:37:53 2022 From: jrose at openjdk.org (John R Rose) Date: Thu, 8 Sep 2022 07:37:53 GMT Subject: RFR: 8292758: put support for UNSIGNED5 format into its own header file [v2] In-Reply-To: <-RXfpRzuGeXmyRSEg2u0XNJETE5VHaI9wrailPSF3IA=.26c9b859-fa04-442b-9fdb-9ead1b07ab0c@github.com> References: <-RXfpRzuGeXmyRSEg2u0XNJETE5VHaI9wrailPSF3IA=.26c9b859-fa04-442b-9fdb-9ead1b07ab0c@github.com> Message-ID: On Sat, 3 Sep 2022 07:48:50 GMT, Dean Long wrote: >> John R Rose has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' of https://git.openjdk.org/jdk into compressed-stream >> - 8292758: put support for UNSIGNED5 format into its own header file > > Wouldn't the SA stack walk fail when attaching to a core dump from an earlier JVM that does not exclude nulls? @dean-long and @coleenp Thank you for the reviews. The public functions in `UNSIGNED5` are not internal but are designed to be useful by themselves. That is why the gtest tests them separately. For example, `check_length` is used inside the `Reader` but if you are building your own reader-like logic, you might want to use it to avoid buffer overflows. Likewise `fits_in_limit` is used by the sizing logic of `write_uint_grow` but if you are rolling your own auto-grow logic, you would want to call that function on its own, or maybe `encoded_length`. The fancy API points like `Reader` and `Sizer` and `write_uint_grow` are not intended to be primitives, but rather best practices for using the static functions, which are the real primitives. Testing notes: This change passes a targeted test that runs `test/hotspot/jtreg/compiler/c2/Test6*.java` (about 50 tests) with `CONF=fastdebug` and `JTREG="JAVA_OPTIONS=-Xcomp -XX:+TraceDeoptimization"`. That run is chosen to deoptimize many times (about 39k), so as to exercise the pre-existing stack walk logic, which relies on compressed streams. Fault injection confirms that any JVM run crashes immediately if there is a bug in the encoding. It also passes tiers 1/2/3 (in a slightly earlier version) and all gtests (in the latest version). ------------- PR: https://git.openjdk.org/jdk/pull/10067 From jrose at openjdk.org Thu Sep 8 07:39:53 2022 From: jrose at openjdk.org (John R Rose) Date: Thu, 8 Sep 2022 07:39:53 GMT Subject: Integrated: 8292758: put support for UNSIGNED5 format into its own header file In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 18:20:42 GMT, John R Rose wrote: > Refactor code from inside of CompressedStream into its own unit. > > This code is likely to be used in future refactorings, such as JDK-8292818 (replace 96-bit representation for field metadata with variable-sized streams). > > Add gtests. This pull request has now been integrated. Changeset: 8d3399bf Author: John R Rose URL: https://git.openjdk.org/jdk/commit/8d3399bf5f354931b0c62d2ed8095e554be71680 Stats: 1257 lines in 9 files changed: 1100 ins; 128 del; 29 mod 8292758: put support for UNSIGNED5 format into its own header file Reviewed-by: dlong, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/10067 From stefank at openjdk.org Thu Sep 8 08:42:30 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 Sep 2022 08:42:30 GMT Subject: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT [v2] In-Reply-To: References: Message-ID: > During the discussion of [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was voiced that we should stop using INTPTR_FORMAT when printing pointers. > > Some background that could explain why some tend to use INTPTR_FORMAT instead of PTR_FORMAT: > > Both those format specifiers require an integer and the compiler barfs if you send in a pointer. We therefore have a utility function named p2i, which converts the pointer to an integer. So, everywhere we have to write print line like this: `print("my pointer: " PTR_FORMAT, p2i(my_pointer));`. Now, p2i returns an intptr_t, and it becomes natural for some to consider the type of the converted value (that we need because of the mentioned workaround), instead of the original type of the value. > > With this enhancement I'd like to clean up the code that I often work in, so that it uses PTR_FORMAT when printing pointers. I'm leaving the rest of the code base for others to consider cleaning up. > > Cleanups have been done in directories gc/, utilities/, memory/, and oops/. Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Remove redundant casts - More conversions - Merge remote-tracking branch 'upstream/master' into 8293304_replace_intptr_format - Fix oops/ - Fix memory/ - Fix utilities/ - Fix gc/ - Add SIZE_FORMAT_X_0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10141/files - new: https://git.openjdk.org/jdk/pull/10141/files/e3d8f643..153b0f24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10141&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10141&range=00-01 Stats: 45757 lines in 300 files changed: 22272 ins; 19201 del; 4284 mod Patch: https://git.openjdk.org/jdk/pull/10141.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10141/head:pull/10141 PR: https://git.openjdk.org/jdk/pull/10141 From stefank at openjdk.org Thu Sep 8 08:46:40 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 Sep 2022 08:46:40 GMT Subject: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT [v2] In-Reply-To: <0Nhq3dcg-Z0G4AYgpcHDGa4xMDHSSBC97eGtKmiw_bY=.934c0f0c-7c1a-4f90-9cce-91bcf0c2ac00@github.com> References: <0Nhq3dcg-Z0G4AYgpcHDGa4xMDHSSBC97eGtKmiw_bY=.934c0f0c-7c1a-4f90-9cce-91bcf0c2ac00@github.com> Message-ID: On Wed, 7 Sep 2022 22:06:11 GMT, Kim Barrett wrote: > Looks good. Thanks. > Also noticed some pre-existing unnecessary (void*) casts of the pointer argument to p2i. Not your problem, and not really appropriate for this change to do anything about them, but I really hate eye-catching cast junk like that. I agree. I cleaned out some of that. There's a lot of casts from `oop` to `void*` that are unnecessary after we rewrote the fastdebug oop class and/or `p2i`. > > There were also a few INTPTR_FORMAT uses that were left in place. All that I recall looked like they could/should instead be SIZE_FORMAT_X_0 or maybe even SIZE_FORMAT_X if the zero padding isn't useful. Leaving those for a later pass seems fine. I wonder how many INTPTR_FORMATs are left in the areas you worked on? I saw a lot of intptr_t/uintptr_t being printed with INTPRT_FORMAT, I don't think those should be changed to use SIZE_FORMAT_. I found and converted three more lingering INTPTR_FORMAT usages. We are now down to a little bit less then 30 usages of INTPTR_FORMAT in the directories relevant to this PR. Most in: g1HeapRegionAttr.hpp to print an index elfFile.hpp to print a integer typed address markWord.cpp to print the mark word stackChunk/instanceStackChunk files to print relative stack pointers ------------- PR: https://git.openjdk.org/jdk/pull/10141 From kevinw at openjdk.org Thu Sep 8 11:09:26 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 Sep 2022 11:09:26 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" Message-ID: Test update to cope with heap size changing (shrinking) in the early life of the test app. A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. Recognising a shrinking heap and retrying resolves this. (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) ------------- Commit messages: - comment - un-problemlist - Merge branch 'master' into 8293218_GcNewTest - 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" Changes: https://git.openjdk.org/jdk/pull/10218/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10218&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293218 Stats: 21 lines in 2 files changed: 12 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/10218.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10218/head:pull/10218 PR: https://git.openjdk.org/jdk/pull/10218 From aturbanov at openjdk.org Thu Sep 8 11:09:53 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 8 Sep 2022 11:09:53 GMT Subject: RFR: 8293432: Use diamond operator in java.management In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 19:56:44 GMT, Andrey Turbanov wrote: > The diamond operator was introduced in Java 7. We can take advantage of this language feature to make code easier to read. > Tested on Linux release x64. `make test TEST="jdk/java/lang/management jdk/javax/management jdk/com/sun/jmx jdk/sun/management"` > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk/java/lang/management 69 69 0 0 > jtreg:test/jdk/javax/management 246 246 0 0 > jtreg:test/jdk/com/sun/jmx 3 3 0 0 >>> jtreg:test/jdk/sun/management 33 32 0 1 << > > Single failure - is a test `RmiBootstrapTest.java#id1`. It's known issue - [JDK-8293335](https://bugs.openjdk.org/browse/JDK-8293335). Thank you for review! ------------- PR: https://git.openjdk.org/jdk/pull/10173 From aturbanov at openjdk.org Thu Sep 8 11:09:54 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 8 Sep 2022 11:09:54 GMT Subject: Integrated: 8293432: Use diamond operator in java.management In-Reply-To: References: Message-ID: On Mon, 5 Sep 2022 19:56:44 GMT, Andrey Turbanov wrote: > The diamond operator was introduced in Java 7. We can take advantage of this language feature to make code easier to read. > Tested on Linux release x64. `make test TEST="jdk/java/lang/management jdk/javax/management jdk/com/sun/jmx jdk/sun/management"` > > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:test/jdk/java/lang/management 69 69 0 0 > jtreg:test/jdk/javax/management 246 246 0 0 > jtreg:test/jdk/com/sun/jmx 3 3 0 0 >>> jtreg:test/jdk/sun/management 33 32 0 1 << > > Single failure - is a test `RmiBootstrapTest.java#id1`. It's known issue - [JDK-8293335](https://bugs.openjdk.org/browse/JDK-8293335). This pull request has now been integrated. Changeset: 98da03af Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/98da03af50e2372817a7b5e381eea5ee6f2cb919 Stats: 363 lines in 61 files changed: 2 ins; 72 del; 289 mod 8293432: Use diamond operator in java.management Reviewed-by: rriggs, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/10173 From coleenp at openjdk.org Thu Sep 8 12:32:42 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 8 Sep 2022 12:32:42 GMT Subject: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT [v2] In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 08:42:30 GMT, Stefan Karlsson wrote: >> During the discussion of [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was voiced that we should stop using INTPTR_FORMAT when printing pointers. >> >> Some background that could explain why some tend to use INTPTR_FORMAT instead of PTR_FORMAT: >> >> Both those format specifiers require an integer and the compiler barfs if you send in a pointer. We therefore have a utility function named p2i, which converts the pointer to an integer. So, everywhere we have to write print line like this: `print("my pointer: " PTR_FORMAT, p2i(my_pointer));`. Now, p2i returns an intptr_t, and it becomes natural for some to consider the type of the converted value (that we need because of the mentioned workaround), instead of the original type of the value. >> >> With this enhancement I'd like to clean up the code that I often work in, so that it uses PTR_FORMAT when printing pointers. I'm leaving the rest of the code base for others to consider cleaning up. >> >> Cleanups have been done in directories gc/, utilities/, memory/, and oops/. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Remove redundant casts > - More conversions > - Merge remote-tracking branch 'upstream/master' into 8293304_replace_intptr_format > - Fix oops/ > - Fix memory/ > - Fix utilities/ > - Fix gc/ > - Add SIZE_FORMAT_X_0 Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10141 From stefank at openjdk.org Thu Sep 8 13:39:48 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 Sep 2022 13:39:48 GMT Subject: RFR: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT [v2] In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 08:42:30 GMT, Stefan Karlsson wrote: >> During the discussion of [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was voiced that we should stop using INTPTR_FORMAT when printing pointers. >> >> Some background that could explain why some tend to use INTPTR_FORMAT instead of PTR_FORMAT: >> >> Both those format specifiers require an integer and the compiler barfs if you send in a pointer. We therefore have a utility function named p2i, which converts the pointer to an integer. So, everywhere we have to write print line like this: `print("my pointer: " PTR_FORMAT, p2i(my_pointer));`. Now, p2i returns an intptr_t, and it becomes natural for some to consider the type of the converted value (that we need because of the mentioned workaround), instead of the original type of the value. >> >> With this enhancement I'd like to clean up the code that I often work in, so that it uses PTR_FORMAT when printing pointers. I'm leaving the rest of the code base for others to consider cleaning up. >> >> Cleanups have been done in directories gc/, utilities/, memory/, and oops/. > > Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Remove redundant casts > - More conversions > - Merge remote-tracking branch 'upstream/master' into 8293304_replace_intptr_format > - Fix oops/ > - Fix memory/ > - Fix utilities/ > - Fix gc/ > - Add SIZE_FORMAT_X_0 Thanks for reviewing! ------------- PR: https://git.openjdk.org/jdk/pull/10141 From stefank at openjdk.org Thu Sep 8 13:39:49 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 Sep 2022 13:39:49 GMT Subject: Integrated: 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 09:51:06 GMT, Stefan Karlsson wrote: > During the discussion of [JDK-8292981](https://bugs.openjdk.org/browse/JDK-8292981) an opinion was voiced that we should stop using INTPTR_FORMAT when printing pointers. > > Some background that could explain why some tend to use INTPTR_FORMAT instead of PTR_FORMAT: > > Both those format specifiers require an integer and the compiler barfs if you send in a pointer. We therefore have a utility function named p2i, which converts the pointer to an integer. So, everywhere we have to write print line like this: `print("my pointer: " PTR_FORMAT, p2i(my_pointer));`. Now, p2i returns an intptr_t, and it becomes natural for some to consider the type of the converted value (that we need because of the mentioned workaround), instead of the original type of the value. > > With this enhancement I'd like to clean up the code that I often work in, so that it uses PTR_FORMAT when printing pointers. I'm leaving the rest of the code base for others to consider cleaning up. > > Cleanups have been done in directories gc/, utilities/, memory/, and oops/. This pull request has now been integrated. Changeset: 6bd27941 Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/6bd2794175bac3c221d9b514bea01b0faa7af4a6 Stats: 137 lines in 41 files changed: 6 ins; 0 del; 131 mod 8293304: Replace some usages of INTPTR_FORMAT with PTR_FORMAT Reviewed-by: kbarrett, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/10141 From cjplummer at openjdk.org Thu Sep 8 14:54:32 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 8 Sep 2022 14:54:32 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 09:56:05 GMT, Kevin Walls wrote: > Test update to cope with heap size changing (shrinking) in the early life of the test app. > > A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. > Recognising a shrinking heap and retrying resolves this. > > (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) What is the purpose of the outer loop of this test? Is it to test while the heap is shrinking? If so, it seems there is no reason for the inner loop to be added, and also possibly just re-ordering the read of the heap size is the correct fix. ------------- PR: https://git.openjdk.org/jdk/pull/10218 From dcubed at openjdk.org Thu Sep 8 16:28:54 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 8 Sep 2022 16:28:54 GMT Subject: RFR: 8293548: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 Message-ID: A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64. This time for sure Rocky! I've included the "#id1" sub-test identifier. ------------- Commit messages: - 8293548: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 Changes: https://git.openjdk.org/jdk/pull/10220/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10220&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293548 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10220.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10220/head:pull/10220 PR: https://git.openjdk.org/jdk/pull/10220 From ccheung at openjdk.org Thu Sep 8 16:28:55 2022 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 8 Sep 2022 16:28:55 GMT Subject: RFR: 8293548: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 16:19:15 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64. > This time for sure Rocky! I've included the "#id1" sub-test identifier. LGTM ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.org/jdk/pull/10220 From azvegint at openjdk.org Thu Sep 8 16:28:56 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 8 Sep 2022 16:28:56 GMT Subject: RFR: 8293548: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 16:19:15 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64. > This time for sure Rocky! I've included the "#id1" sub-test identifier. Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10220 From dcubed at openjdk.org Thu Sep 8 16:33:45 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 8 Sep 2022 16:33:45 GMT Subject: RFR: 8293548: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 In-Reply-To: References: Message-ID: <4hmPijOw7DfgSk2_cLK31qNmC2U0xBDTk7xobErGICY=.4e6dc753-cb1e-4b0f-a2bb-4e86b28f0466@github.com> On Thu, 8 Sep 2022 16:24:19 GMT, Calvin Cheung wrote: >> A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64. >> This time for sure Rocky! I've included the "#id1" sub-test identifier. > > LGTM @calvinccheung and @azvegint - Thanks for the fast reviews! ------------- PR: https://git.openjdk.org/jdk/pull/10220 From dcubed at openjdk.org Thu Sep 8 16:33:47 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 8 Sep 2022 16:33:47 GMT Subject: Integrated: 8293548: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 In-Reply-To: References: Message-ID: <5-mPFtns7p2SzFNs4XiG1qLhkputuCBHamF-2HVs0o4=.2601b85e-0544-49e3-9f4b-d7885c3d228d@github.com> On Thu, 8 Sep 2022 16:19:15 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64. > This time for sure Rocky! I've included the "#id1" sub-test identifier. This pull request has now been integrated. Changeset: 4c5501c3 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/4c5501c31c7ab8fa7d1a6ce479060a899514c671 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8293548: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 Reviewed-by: ccheung, azvegint ------------- PR: https://git.openjdk.org/jdk/pull/10220 From sspitsyn at openjdk.org Thu Sep 8 18:04:43 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 8 Sep 2022 18:04:43 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 14:51:06 GMT, Chris Plummer wrote: > What is the purpose of the outer loop of this test? Is it to test while the heap is shrinking? If so, it seems there is no reason for the inner loop to be added, and also possibly just re-ordering the read of the heap size is the correct fix. Agreed. At least, the outer loop is confusing and needs a comment explaining why it is needed. ------------- PR: https://git.openjdk.org/jdk/pull/10218 From kevinw at openjdk.org Thu Sep 8 21:44:41 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 Sep 2022 21:44:41 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" In-Reply-To: References: Message-ID: <23o7Tufx6pGFAMFDKi0WtKCGgXrwWSL15qF9NRALtGI=.a5685d6c-068e-49dd-abf2-7662faebf78d@github.com> On Thu, 8 Sep 2022 09:56:05 GMT, Kevin Walls wrote: > Test update to cope with heap size changing (shrinking) in the early life of the test app. > > A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. > Recognising a shrinking heap and retrying resolves this. > > (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) Right, that outer loop is the original test, and it's not obvious if it is needed at all. Testing without it is fine, for all the tests in that directory. Possibly it was to make "really sure" we allocate enough memory to cause a GC. But after allocating whatever fraction of memory eden is, it does that again, and then calls System.gc(). No reason to do that 3 times... ------------- PR: https://git.openjdk.org/jdk/pull/10218 From aboldtch at openjdk.org Fri Sep 9 06:53:33 2022 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 9 Sep 2022 06:53:33 GMT Subject: RFR: 8291237: Encapsulate nmethod Deoptimization logic [v9] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 08:35:58 GMT, Axel Boldt-Christmas wrote: >> The proposal is to encapsulate the nmethod mark for deoptimization logic in one place and only allow access to the `mark_for_deoptimization` from a closure object: >> ```C++ >> class DeoptimizationMarkerClosure : StackObj { >> public: >> virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0; >> }; >> >> This closure takes a `MarkFn` which it uses to mark which nmethods should be deoptimized. This marking can only be done through the `MarkFn` and a `MarkFn` can only be created in the following code which runs the closure. >> ```C++ >> { >> NoSafepointVerifier nsv; >> assert_locked_or_safepoint(Compile_lock); >> marker_closure.marker_do(MarkFn()); >> anything_deoptimized = deoptimize_all_marked(); >> } >> if (anything_deoptimized) { >> run_deoptimize_closure(); >> } >> >> This ensures that this logic is encapsulated and the `NoSafepointVerifier` and `assert_locked_or_safepoint(Compile_lock)` makes `deoptimize_all_marked` not having to scan the whole code cache sound. >> >> The exception to this pattern, from `InstanceKlass::unload_class`, is discussed in the JBS issue, and gives reasons why not marking for deoptimization there is ok. >> >> An effect of this encapsulation is that the deoptimization logic was moved from the `CodeCache` class to the `Deoptimization` class and the class redefinition logic was moved from the `CodeCache` class to the `VM_RedefineClasses` class/operation. >> >> Testing: Tier 1-5 >> >> _Update_ >> --- >> Switched too using a RAII object to track the context instead of putting code in a closure. But all the encapsulation is still the same. >> >> Testing: Tier 1-7 >> >> _Update_ >> --- >>> @stefank suggested splitting out unloading klass logic change into a separate issue [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). >>> >>> Will probably also limit this PR to only encapsulation. (Skipping the linked list optimisation) And create a separate issue for that as well. >>> >>> But this creates a chain of three dependent issues. [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237) depends on [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718). And the link list optimisation depend will depend on [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237). >>> >>> Will mark this as a draft for now and create a PR for [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first. >> >> _Update_ >> --- >> Testing after 11d9dd2: Oracle platforms tier 1-5 > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: > > - Merge remote-tracking branch 'upstream/master' into JDK-8291237 > - Add asserts and comments > - Merge remote-tracking branch 'upstream/master' into JDK-8291237 > - Add context active assert > - Cleanup comment > - Add list optimization > - Merge remote-tracking branch 'upstream/master' into JDK-8291237 > - Rename deoptimize_done enum value > - Add missing code from list revert > - Initial draft new terminology > - ... and 19 more: https://git.openjdk.org/jdk/compare/512fee1d...c35f5ed6 Just an update and a call for reviews. [JDK-8290025](https://bugs.openjdk.org/browse/JDK-8290025) / #9741 was merged in 030ed7e which makes this change easier to reson about as the lifetime of nmethods are simpler. The merge was tested on oracle platforms tier 1-5. ------------- PR: https://git.openjdk.org/jdk/pull/9655 From kevinw at openjdk.org Fri Sep 9 08:26:47 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Sep 2022 08:26:47 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v2] In-Reply-To: References: Message-ID: <0D7eu-LLBcKoP4gtPi4F90wq5_1YpL72cZG-EO0xJq4=.840b07ca-1995-4074-8513-2a0cc2f8c093@github.com> > Test update to cope with heap size changing (shrinking) in the early life of the test app. > > A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. > Recognising a shrinking heap and retrying resolves this. > > (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Remove outer loop ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10218/files - new: https://git.openjdk.org/jdk/pull/10218/files/c387cf63..75e10b6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10218&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10218&range=00-01 Stats: 24 lines in 1 file changed: 3 ins; 5 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/10218.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10218/head:pull/10218 PR: https://git.openjdk.org/jdk/pull/10218 From sspitsyn at openjdk.org Fri Sep 9 09:16:52 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 9 Sep 2022 09:16:52 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v2] In-Reply-To: <0D7eu-LLBcKoP4gtPi4F90wq5_1YpL72cZG-EO0xJq4=.840b07ca-1995-4074-8513-2a0cc2f8c093@github.com> References: <0D7eu-LLBcKoP4gtPi4F90wq5_1YpL72cZG-EO0xJq4=.840b07ca-1995-4074-8513-2a0cc2f8c093@github.com> Message-ID: <3GDfUkiWbduOrMyNr-izhEJ_KLG2b_EvaXiNCl2SKzM=.95d870ab-5ec3-4958-bcc5-c76c1bff21b2@github.com> On Fri, 9 Sep 2022 08:26:47 GMT, Kevin Walls wrote: >> Test update to cope with heap size changing (shrinking) in the early life of the test app. >> >> A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. >> Recognising a shrinking heap and retrying resolves this. >> >> (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove outer loop Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10218 From kevinw at openjdk.org Fri Sep 9 09:28:38 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Sep 2022 09:28:38 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v3] In-Reply-To: References: Message-ID: > Test update to cope with heap size changing (shrinking) in the early life of the test app. > > A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. > Recognising a shrinking heap and retrying resolves this. > > (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Clarify that loop is for checking heap not changing. Exception if continually changing. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10218/files - new: https://git.openjdk.org/jdk/pull/10218/files/75e10b6e..7a203f58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10218&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10218&range=01-02 Stats: 13 lines in 1 file changed: 6 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10218.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10218/head:pull/10218 PR: https://git.openjdk.org/jdk/pull/10218 From duke at openjdk.org Fri Sep 9 16:18:17 2022 From: duke at openjdk.org (Bill Huang) Date: Fri, 9 Sep 2022 16:18:17 GMT Subject: RFR: JDK-8293343 sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java failed with "Agent communication error: java.io.EOFException" Message-ID: This task provides a fix for java.io.EOFException on RmiSslNoKeyStoreTest and RmiBootstrapTest. The EOFException is only seen when tests are run in concurrent mode. It could be caused by a bug in prepareTestFiles() which creates a race condition that RmiBootstrapTest/RmiSslNoKeyStoreTest changes the file permissions while the other one reading the same files. In addition, tests are failing intermittently for SocketException with agentvm mode. ------------- Commit messages: - Removed RmiBootstrapTest and RmiSslNoKeyStoreTest from ProblemList. - Made tests run in othervm mode. - Fixed prepareTestFile() to return property files in the test folder. Changes: https://git.openjdk.org/jdk/pull/10224/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10224&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293343 Stats: 6 lines in 4 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10224.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10224/head:pull/10224 PR: https://git.openjdk.org/jdk/pull/10224 From kevinw at openjdk.org Fri Sep 9 16:18:17 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Sep 2022 16:18:17 GMT Subject: RFR: JDK-8293343 sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java failed with "Agent communication error: java.io.EOFException" In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 23:20:19 GMT, Bill Huang wrote: > This task provides a fix for java.io.EOFException on RmiSslNoKeyStoreTest and RmiBootstrapTest. > > The EOFException is only seen when tests are run in concurrent mode. It could be caused by a bug in prepareTestFiles() which creates a race condition that RmiBootstrapTest/RmiSslNoKeyStoreTest changes the file permissions while the other one reading the same files. > > In addition, tests are failing intermittently for SocketException with agentvm mode. Looks good, I've tested othervm and had success also. One more thing - these tests are now in the problemlist, so we need to remove them from test/jdk/ProblemList.txt: 527 sun/management/jmxremote/bootstrap/RmiBootstrapTest.java 8293335 linux-x64 528 sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java 8293343 linux-aarch64,macosx-x64 ------------- PR: https://git.openjdk.org/jdk/pull/10224 From kevinw at openjdk.org Fri Sep 9 16:22:39 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 9 Sep 2022 16:22:39 GMT Subject: RFR: JDK-8293343 sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java failed with "Agent communication error: java.io.EOFException" In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 23:20:19 GMT, Bill Huang wrote: > This task provides a fix for java.io.EOFException on RmiSslNoKeyStoreTest and RmiBootstrapTest. > > The EOFException is only seen when tests are run in concurrent mode. It could be caused by a bug in prepareTestFiles() which creates a race condition that RmiBootstrapTest/RmiSslNoKeyStoreTest changes the file permissions while the other one reading the same files. > > In addition, tests are failing intermittently for SocketException with agentvm mode. Looks good! ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.org/jdk/pull/10224 From cjplummer at openjdk.org Fri Sep 9 18:03:37 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Sep 2022 18:03:37 GMT Subject: RFR: JDK-8293343 sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java failed with "Agent communication error: java.io.EOFException" In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 23:20:19 GMT, Bill Huang wrote: > This task provides a fix for java.io.EOFException on RmiSslNoKeyStoreTest and RmiBootstrapTest. > > The EOFException is only seen when tests are run in concurrent mode. It could be caused by a bug in prepareTestFiles() which creates a race condition that RmiBootstrapTest/RmiSslNoKeyStoreTest changes the file permissions while the other one reading the same files. > > In addition, tests are failing intermittently for SocketException with agentvm mode. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10224 From cjplummer at openjdk.org Fri Sep 9 18:24:50 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Sep 2022 18:24:50 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v3] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 09:28:38 GMT, Kevin Walls wrote: >> Test update to cope with heap size changing (shrinking) in the early life of the test app. >> >> A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. >> Recognising a shrinking heap and retrying resolves this. >> >> (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Clarify that loop is for checking heap not changing. Exception if continually changing. This code still isn't sitting right with me and I'm still not sure of it's original intent. The method is called `provokeGc`, but it seems to be quite a bit more complex than that. It (used to) loop 3 times, each time calculating the youngGen size as a % of the heap size (according to the MemoryPoolMXBean values). It then (on each iteration) allocates that much memory by applying the % to Runtime.maxMemory(), and does so twice. It could have just allocated the youngGen size twice, but instead used the round about way of determining how much to allocate. I'm not sure why. In any case, the end result should be triggering at least one youngGen GC per iteration, but more likely two unless it was empty at the start. Then it follows this up with a full GC (on each iteration). So what is the point of any of this? It it testing consistency of the MemoryPoolMXBean values? Is it testing the relation between the MemoryPoolMXBean heap size and Runtime.maxMemory()? You have changed it to only do the allocation part once rather than on every iteration, so now the loop is only checking if the heap is still shrinking, but just because heapSize == heapSize0 doesn't mean it's not shrinking. It can just mean no GC happened between the two Pools.getHeapCommittedSize() calls. I think maybe the original intend was to do the allocateHeap() part while the heap is shrinking, not just once after it has stabilized. BTW, make sure you test with ZGC. ------------- PR: https://git.openjdk.org/jdk/pull/10218 From dcubed at openjdk.org Fri Sep 9 19:37:49 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 9 Sep 2022 19:37:49 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread [v2] In-Reply-To: References: Message-ID: <4mPJ1Noq06Km9zQFBhCL6ENKn1vxMBUu6bZtknY5YMY=.7e19aab9-839b-4f86-a266-4ee1418a663b@github.com> On Tue, 6 Sep 2022 08:42:13 GMT, Kevin Walls wrote: >> This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). >> >> A JVMTI operation could call threadObj() and clear the Windows GetLastError value. >> >> Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Comment update I agree with your choices in your partial [BACKOUT] of: [JDK-8289091](https://bugs.openjdk.org/browse/JDK-8289091) move oop safety check from SharedRuntime::get_java_tid() to JavaThread::threadObj() Thanks for adding the new test. I like it. Concerning: > More follow up needed about the last error reset caused by GC. Have you filed a follow up bug in hotspot/gc for that issue? Thumbs up on this fix and new test. test/jdk/com/sun/jdi/JdbLastErrorTest.java line 42: > 40: import java.lang.foreign.SymbolLookup; > 41: import java.lang.invoke.MethodHandle; > 42: import java.lang.foreign.ValueLayout; L41 and L42 should be swapped for proper alpha sort order. test/jdk/com/sun/jdi/JdbLastErrorTest.java line 60: > 58: FunctionDescriptor.ofVoid(ValueLayout.JAVA_INT)); > 59: > 60: for (int i=0; i<10; i++) { nit: should be space around '=' and '<'. test/jdk/com/sun/jdi/JdbLastErrorTest.java line 61: > 59: > 60: for (int i=0; i<10; i++) { > 61: setLastError.invoke(42); If you use final variable for the '42', then you can use the variable here on L61 and below on L64. Then you can call is something cool: static final int THE_ANSWER = 42; // ... to life, the universe and everything! ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/10147 From sspitsyn at openjdk.org Sat Sep 10 00:18:47 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 10 Sep 2022 00:18:47 GMT Subject: RFR: 8293339: vm/jvmti/StopThread/stop001/stop00103 crashes with SIGSEGV in Continuation::is_continuation_mounted Message-ID: I was not able to reproduce this issue in thousands of mach5 runs on multiple platforms. However, the root cause seems to be pretty simple. A JvmtiVTMSTransitionDisabler needs to be added to make the JVM TI StopThread function to be VTMS (Virtual Thread Mount state) transition safe. So the fix is a one-liner: diff --git a/src/hotspot/share/prims/jvmtiEnv.cpp b/src/hotspot/share/prims/jvmtiEnv.cpp index a9efe01c92e..f5e9176230a 100644 --- a/src/hotspot/share/prims/jvmtiEnv.cpp +++ b/src/hotspot/share/prims/jvmtiEnv.cpp @@ -1182,6 +1182,8 @@ JvmtiEnv::ResumeAllVirtualThreads(jint except_count, const jthread* except_list) jvmtiError JvmtiEnv::StopThread(jthread thread, jobject exception) { JavaThread* current_thread = JavaThread::current(); + + JvmtiVTMSTransitionDisabler disabler; ThreadsListHandle tlh(current_thread); JavaThread* java_thread = NULL; oop thread_oop = NULL; ------------- Commit messages: - 8293339: vm/jvmti/StopThread/stop001/stop00103 crashes with SIGSEGV in Continuation::is_continuation_mounted Changes: https://git.openjdk.org/jdk/pull/10235/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10235&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293339 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10235.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10235/head:pull/10235 PR: https://git.openjdk.org/jdk/pull/10235 From dcubed at openjdk.org Sat Sep 10 15:13:54 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 10 Sep 2022 15:13:54 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v3] In-Reply-To: References: Message-ID: On Wed, 7 Sep 2022 20:09:05 GMT, Alex Menkov wrote: >> The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) >> >> cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. >> After successful RedefineClasses it should be reset. >> The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated test. comments, code reorg I like the fact that the fix is small and I really like the new test. I only have minor comments and a couple of questions. Please run these changes thru Tier[456] since that's where JVM/TI tests run in different configs w/ different options. src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4333: > 4331: > 4332: if (scratch_class->get_cached_class_file() != the_class->get_cached_class_file()) { > 4333: // 1. the_class doesn't have a cache yet, scratch_class does have. typo: s/does have./does have a cache./ src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4337: > 4335: // are multiple concurrent RetransformClasses calls on different threads. > 4336: // the_class and scratch_class have the same cached bytes, but different buffers. > 4337: // In such cases we need to deallocate one of the buffer. typo: s/the buffer/the buffers/ src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4338: > 4336: // the_class and scratch_class have the same cached bytes, but different buffers. > 4337: // In such cases we need to deallocate one of the buffer. > 4338: // 3. RedefineClasses and the_class has cached bytes from previous transformation. typo: s/has cached/have cached/ typo: s/from previous/from a previous/ src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4340: > 4338: // 3. RedefineClasses and the_class has cached bytes from previous transformation. > 4339: // In the case we need to use class bytes from scratch_class. > 4340: if (the_class->get_cached_class_file() != 0) { s/!= 0/!= nullptr/ test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 174: > 172: throw new RuntimeException("Redefine error (ver = " + ver + ")"); > 173: } > 174: // verity ClassFileLoadHook get expected class bytes typos: s/verity/verify/ s/get/gets the/ test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 197: > 195: int testCase; > 196: try { > 197: testCase= Integer.valueOf(args[0]); nit: please add space before '=' test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 215: > 213: redefine(1); // cached class bytes are not set > 214: retransform(2, 1); // sets cached class bytes to ver 1 > 215: redefine(3); // resets cached class bytes Perhaps: ```// resets cached class bytes to nullptr``` test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 224: > 222: redefine(1); // cached class bytes are not set > 223: retransform(2, 1); // sets cached class bytes to ver 1 > 224: redefine(3); // resets cached class bytes Perhaps: ```// resets cached class bytes to nullptr``` test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 232: > 230: test("Retransform-Redefine-Retransform-Retransform", () -> { > 231: retransform(1, 0); // sets cached class bytes to ver 0 (initially loaded) > 232: redefine(2); // resets cached class bytes Perhaps: ```// resets cached class bytes to nullptr``` test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 240: > 238: case 5: > 239: test("Redefine-Retransform-Redefine-Retransform with CFLH", () -> { > 240: redefine(1, 5); // CFLH sets cached class bytes to ver 1 I'm having trouble understanding why the CFLH version is '5' here. Update: I _think_ this is just to have the CFLH return a different version of the class bytes before the RedefineClasses() call does its work. I don't understand why you want to do this... test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 242: > 240: redefine(1, 5); // CFLH sets cached class bytes to ver 1 > 241: retransform(2, 1); // uses existing cache > 242: redefine(3, 6); // resets cached class bytes, I'm having trouble understanding why the CFLH version is '6' here. Update: I _think_ this is just to have the CFLH return a different version of the class bytes before the RedefineClasses() call does its work. I don't understand why you want to do this... Perhaps: ```// resets cached class bytes to nullptr,``` test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 251: > 249: test("Retransform-Redefine-Retransform-Retransform with CFLH", () -> { > 250: retransform(1, 0); // sets cached class bytes to ver 0 (initially loaded) > 251: redefine(2, 5); // resets cached class bytes, I'm having trouble understanding why the CFLH version is '5' here. Update: I _think_ this is just to have the CFLH return a different version of the class bytes before the RedefineClasses() call does its work. I don't understand why you want to do this... Perhaps ```// resets cached class bytes to nullptr,``` test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 26: > 24: #include > 25: #include > 26: #include Should be in alpha sort order? test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 48: > 46: } > 47: > 48: class ClassFileLoadHookHelper { A short comment describing the purpose of the `ClassFileLoadHookHelper` would be helpful to folks that only have a high level understanding of RedefineClasses() and RetransformClasses(). You did a very good job encapsulating support for a complicated sets of APIs into this helper. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 215: > 213: caps.can_redefine_classes = 1; > 214: caps.can_retransform_classes = 1; > 215: jvmti->AddCapabilities(&caps); Why no error check here? ------------- Changes requested by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/10032 From dcubed at openjdk.org Sun Sep 11 13:53:39 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sun, 11 Sep 2022 13:53:39 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" In-Reply-To: <23o7Tufx6pGFAMFDKi0WtKCGgXrwWSL15qF9NRALtGI=.a5685d6c-068e-49dd-abf2-7662faebf78d@github.com> References: <23o7Tufx6pGFAMFDKi0WtKCGgXrwWSL15qF9NRALtGI=.a5685d6c-068e-49dd-abf2-7662faebf78d@github.com> Message-ID: On Thu, 8 Sep 2022 21:41:09 GMT, Kevin Walls wrote: >> Test update to cope with heap size changing (shrinking) in the early life of the test app. >> >> A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. >> Recognising a shrinking heap and retrying resolves this. >> >> (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) > > Right, that outer loop is the original test, and it's not obvious if it is needed at all. > Testing without it is fine, for all the tests in that directory. > Possibly it was to make "really sure" we allocate enough memory to cause a GC. But after allocating whatever fraction of memory eden is, it does that again, and then calls System.gc(). No reason to do that 3 times... @kevinjwalls - If you do a comment with "/issue JDK-8293564", then you'll include the other bug ID that has a test affected by the same underlying issue with this PR. ------------- PR: https://git.openjdk.org/jdk/pull/10218 From kevinw at openjdk.org Mon Sep 12 08:30:43 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 12 Sep 2022 08:30:43 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread [v2] In-Reply-To: References: Message-ID: On Tue, 6 Sep 2022 08:42:13 GMT, Kevin Walls wrote: >> This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). >> >> A JVMTI operation could call threadObj() and clear the Windows GetLastError value. >> >> Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Comment update Thanks Chris, David and Dan. Dan, will update with those changes shortly, and now I know this one is going in I'll get that other stress test I had into a new JBS bug and link it. ------------- PR: https://git.openjdk.org/jdk/pull/10147 From kevinw at openjdk.org Mon Sep 12 09:41:27 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 12 Sep 2022 09:41:27 GMT Subject: RFR: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread [v3] In-Reply-To: References: Message-ID: > This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). > > A JVMTI operation could call threadObj() and clear the Windows GetLastError value. > > Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: nits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10147/files - new: https://git.openjdk.org/jdk/pull/10147/files/8de54561..30cf2b16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10147&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10147&range=01-02 Stats: 8 lines in 1 file changed: 4 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10147.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10147/head:pull/10147 PR: https://git.openjdk.org/jdk/pull/10147 From kevinw at openjdk.org Mon Sep 12 09:57:46 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 12 Sep 2022 09:57:46 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v3] In-Reply-To: References: Message-ID: <_SchQw1EgklzTeIK8Nbn_DC3H96687ktYjerYU8I-n0=.7545dd8d-8602-497a-85ac-d24144e264ad@github.com> On Fri, 9 Sep 2022 18:22:48 GMT, Chris Plummer wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> Clarify that loop is for checking heap not changing. Exception if continually changing. > > This code still isn't sitting right with me and I'm still not sure of it's original intent. The method is called `provokeGc`, but it seems to be quite a bit more complex than that. It (used to) loop 3 times, each time calculating the youngGen size as a % of the heap size (according to the MemoryPoolMXBean values). It then (on each iteration) allocates that much memory by applying the % to Runtime.maxMemory(), and does so twice. It could have just allocated the youngGen size twice, but instead used the round about way of determining how much to allocate. I'm not sure why. > > In any case, the end result should be triggering at least one youngGen GC per iteration, but more likely two unless it was empty at the start. Then it follows this up with a full GC (on each iteration). So what is the point of any of this? It it testing consistency of the MemoryPoolMXBean values? Is it testing the relation between the MemoryPoolMXBean heap size and Runtime.maxMemory()? > > You have changed it to only do the allocation part once rather than on every iteration, so now the loop is only checking if the heap is still shrinking, but just because heapSize == heapSize0 doesn't mean it's not shrinking. It can just mean no GC happened between the two Pools.getHeapCommittedSize() calls. I think maybe the original intend was to do the allocateHeap() part while the heap is shrinking, not just once after it has stabilized. > > BTW, make sure you test with ZGC. Thanks @plummercj Yes, the whole fraction/percentage calculation is odd. Maybe it could just allocate eden size in bytes, but I was not rushing to throw it out. I think it's clear that provokeGc wants to allocate and cause a GC. Tripling the pair of allocations appears to be an effort make extra sure it does that, but I think we're agreeing there is no clear point to that. The current provokeGc is from 2016: 8168396: Unexpected OOME in GcCauseTest02 and GcTest02 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1b7fd4c2f65e ...so there was a previous OOM problem, possibly because young gen was large and could not be promoted. That probably inspired the fraction calculation. I'm not sure it's the best way of doing things. Yes, my update is to retry if we see a shrink between fetching eden and heap size. It doesn't mean the heap has fully stabilized and has finished shrinking, it just means that we don't think a shrink occurred between fetching the two stats. That means our fraction calculation should be OK. No GC beteween the two stats being fetched is the common case of course, but now we are seeing enough GCs in between them to cause a frequent failures. ZGC: The tests in serviceability/tmtools/jstat do not run with ZGC or Shenandoah (requires vm.gc != "Z" & vm.gc != "Shenandoah"). They use e.g. "jstat -gcnew PID" which doesn't produce numbers with ZGC, so they would fail. ------------- PR: https://git.openjdk.org/jdk/pull/10218 From aturbanov at openjdk.org Mon Sep 12 12:58:35 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 12 Sep 2022 12:58:35 GMT Subject: RFR: 8293647: Avoid unnecessary boxing in jdk.hotspot.agent Message-ID: Usages of methods `Integer.valueOf`, `Boolean.valueOf`, `Long.valueOf` often can be simplified by using their pair methods `parseInt`/`parseBoolean`/`parseLong`. ------------- Commit messages: - 8293647: Avoid unnecessary boxing in jdk.hotspot.agent - [PATCH] Avoid unnecessary boxing in jdk.hotspot.agent Changes: https://git.openjdk.org/jdk/pull/10237/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10237&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293647 Stats: 16 lines in 3 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/10237.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10237/head:pull/10237 PR: https://git.openjdk.org/jdk/pull/10237 From duke at openjdk.org Mon Sep 12 13:12:52 2022 From: duke at openjdk.org (Bill Huang) Date: Mon, 12 Sep 2022 13:12:52 GMT Subject: Integrated: JDK-8293343 sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java failed with "Agent communication error: java.io.EOFException" In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 23:20:19 GMT, Bill Huang wrote: > This task provides a fix for java.io.EOFException on RmiSslNoKeyStoreTest and RmiBootstrapTest. > > The EOFException is only seen when tests are run in concurrent mode. It could be caused by a bug in prepareTestFiles() which creates a race condition that RmiBootstrapTest/RmiSslNoKeyStoreTest changes the file permissions while the other one reading the same files. > > In addition, tests are failing intermittently for SocketException with agentvm mode. This pull request has now been integrated. Changeset: 91c9091d Author: Bill Huang Committer: Kevin Walls URL: https://git.openjdk.org/jdk/commit/91c9091d7e64ba0bdb257521bd15ff183c6839fa Stats: 6 lines in 4 files changed: 0 ins; 2 del; 4 mod 8293343: sun/management/jmxremote/bootstrap/RmiSslNoKeyStoreTest.java failed with "Agent communication error: java.io.EOFException" 8293335: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1failed with "Agent communication error: java.io.EOFException" Reviewed-by: kevinw, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/10224 From duke at openjdk.org Mon Sep 12 16:35:55 2022 From: duke at openjdk.org (Daniel Skantz) Date: Mon, 12 Sep 2022 16:35:55 GMT Subject: Integrated: 8283627: Outdated comment in MachineDescriptionTwosComplement.isLP64 In-Reply-To: <3phI4L8RUaBPkDovtGNk94bAtx7R_9Inj1_i0bpEq6k=.3a91baf2-b59a-4857-aa03-e8f07d1d2a60@github.com> References: <3phI4L8RUaBPkDovtGNk94bAtx7R_9Inj1_i0bpEq6k=.3a91baf2-b59a-4857-aa03-e8f07d1d2a60@github.com> Message-ID: On Mon, 22 Aug 2022 15:06:31 GMT, Daniel Skantz wrote: > Update MachineDescriptionTwosComplement.java comment to indicate that LP64 machines are no longer uncommon. This pull request has now been integrated. Changeset: 524af949 Author: Daniel Skantz Committer: Kevin Walls URL: https://git.openjdk.org/jdk/commit/524af949370990df6f58a84ad2493eb1dcba2231 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod 8283627: Outdated comment in MachineDescriptionTwosComplement.isLP64 Reviewed-by: cjplummer, sspitsyn, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/9967 From cjplummer at openjdk.org Mon Sep 12 17:40:43 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Sep 2022 17:40:43 GMT Subject: RFR: 8293647: Avoid unnecessary boxing in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 12:35:30 GMT, Andrey Turbanov wrote: > Usages of methods `Integer.valueOf`, `Boolean.valueOf`, `Long.valueOf` often can be simplified by using their pair methods `parseInt`/`parseBoolean`/`parseLong`. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10237 From cjplummer at openjdk.org Mon Sep 12 17:52:43 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Sep 2022 17:52:43 GMT Subject: RFR: 8293339: vm/jvmti/StopThread/stop001/stop00103 crashes with SIGSEGV in Continuation::is_continuation_mounted In-Reply-To: References: Message-ID: On Sat, 10 Sep 2022 00:05:22 GMT, Serguei Spitsyn wrote: > I was not able to reproduce this issue in thousands of mach5 runs on multiple platforms. However, the root cause seems to be pretty simple. A JvmtiVTMSTransitionDisabler needs to be added to make the JVM TI StopThread function to be VTMS (Virtual Thread Mount state) transition safe. > > So the fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmtiEnv.cpp b/src/hotspot/share/prims/jvmtiEnv.cpp > index a9efe01c92e..f5e9176230a 100644 > --- a/src/hotspot/share/prims/jvmtiEnv.cpp > +++ b/src/hotspot/share/prims/jvmtiEnv.cpp > @@ -1182,6 +1182,8 @@ JvmtiEnv::ResumeAllVirtualThreads(jint except_count, const jthread* except_list) > jvmtiError > JvmtiEnv::StopThread(jthread thread, jobject exception) { > JavaThread* current_thread = JavaThread::current(); > + > + JvmtiVTMSTransitionDisabler disabler; > ThreadsListHandle tlh(current_thread); > JavaThread* java_thread = NULL; > oop thread_oop = NULL; Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10235 From cjplummer at openjdk.org Mon Sep 12 17:57:42 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Sep 2022 17:57:42 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v3] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 09:28:38 GMT, Kevin Walls wrote: >> Test update to cope with heap size changing (shrinking) in the early life of the test app. >> >> A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. >> Recognising a shrinking heap and retrying resolves this. >> >> (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Clarify that loop is for checking heap not changing. Exception if continually changing. Hmm: - public static GcProvoker createGcProvoker() { - return new GcProvokerImpl(); So what happened to GcProvokerImpl? It not longer exists, but was not deleted as part of this changeset. Must have been cleaned up later. As of this changeset it was still in place: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/1b7fd4c2f65e/test/serviceability/tmtools/jstat/utils/GcProvokerImpl.java And it's provokeGc() method was doing the same thing this "new" implementation is dong. ------------- PR: https://git.openjdk.org/jdk/pull/10218 From kevinw at openjdk.org Mon Sep 12 18:40:41 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 12 Sep 2022 18:40:41 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v3] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 09:28:38 GMT, Kevin Walls wrote: >> Test update to cope with heap size changing (shrinking) in the early life of the test app. >> >> A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. >> Recognising a shrinking heap and retrying resolves this. >> >> (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Clarify that loop is for checking heap not changing. Exception if continually changing. OK, yes that technique in GcProvokerImpl comes in with: date: Thu Jan 14 15:35:21 2016 +0300 summary: 8130063: Refactoring tmtools jstat and jstack tests to jtreg ..but IIRC tmtools is a testsuite being integrated into the JDK source, so the code is much older. Does this change anything? 8-) ------------- PR: https://git.openjdk.org/jdk/pull/10218 From cjplummer at openjdk.org Mon Sep 12 19:09:44 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Sep 2022 19:09:44 GMT Subject: RFR: 8293143: Workaround for JDK-8292217 when doing "step over" of bytecode with unresolved cp referernce In-Reply-To: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> References: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> Message-ID: On Wed, 31 Aug 2022 00:25:20 GMT, Chris Plummer wrote: > There is a workaround we can do for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) for the use case where a step over or step out is being done. This workaround can't be made to also work for the step into case. From [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) > > "There is a workaround that fixes this issue when doing a STEP_OVER or STEP_OUT. Rather than the debug agent checking if it has enabled JVMTI single stepping, instead it checks some fields in the ThreadNode that say if single stepping is pending, and it is for a STEP_INTO. If it is not STEP_INTO, then it can assume that no StepEvent will occur at the same location and therefor the MethodEntryEvent should not be deferred. So this limits the bug to only happening when doing a STEP_INTO. " Ping! ------------- PR: https://git.openjdk.org/jdk/pull/10091 From cjplummer at openjdk.org Mon Sep 12 19:09:43 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Sep 2022 19:09:43 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v3] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 09:28:38 GMT, Kevin Walls wrote: >> Test update to cope with heap size changing (shrinking) in the early life of the test app. >> >> A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. >> Recognising a shrinking heap and retrying resolves this. >> >> (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Clarify that loop is for checking heap not changing. Exception if continually changing. I think the point is that the loop has been there probably since the beginning. So I wouldn't take it out. However, I'm not sure I agree with how you have now moved some parts out of the loop so they are only done once. ------------- PR: https://git.openjdk.org/jdk/pull/10218 From amenkov at openjdk.org Mon Sep 12 20:12:05 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 12 Sep 2022 20:12:05 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v4] In-Reply-To: References: Message-ID: > The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) > > cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. > After successful RedefineClasses it should be reset. > The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Dan's feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10032/files - new: https://git.openjdk.org/jdk/pull/10032/files/9bc08346..fa7aca43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=02-03 Stats: 27 lines in 3 files changed: 12 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/10032.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10032/head:pull/10032 PR: https://git.openjdk.org/jdk/pull/10032 From amenkov at openjdk.org Mon Sep 12 20:17:55 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 12 Sep 2022 20:17:55 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v3] In-Reply-To: References: Message-ID: On Sat, 10 Sep 2022 15:11:33 GMT, Daniel D. Daugherty wrote: > I like the fact that the fix is small and I really like the new test. I only have minor comments and a couple of questions. Thank you for the review > Please run these changes thru Tier[456] since that's where JVM/TI tests run in different configs w/ different options. In progress > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4333: > >> 4331: >> 4332: if (scratch_class->get_cached_class_file() != the_class->get_cached_class_file()) { >> 4333: // 1. the_class doesn't have a cache yet, scratch_class does have. > > typo: s/does have./does have a cache./ Fixed > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4337: > >> 4335: // are multiple concurrent RetransformClasses calls on different threads. >> 4336: // the_class and scratch_class have the same cached bytes, but different buffers. >> 4337: // In such cases we need to deallocate one of the buffer. > > typo: s/the buffer/the buffers/ fixed > typo: s/has cached/have cached/ The comment is about processing RedefineClasses when the_class has cached bytes. So it should be "has" > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4340: > >> 4338: // 3. RedefineClasses and the_class has cached bytes from previous transformation. >> 4339: // In the case we need to use class bytes from scratch_class. >> 4340: if (the_class->get_cached_class_file() != 0) { > > s/!= 0/!= nullptr/ fixed. > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 174: > >> 172: throw new RuntimeException("Redefine error (ver = " + ver + ")"); >> 173: } >> 174: // verity ClassFileLoadHook get expected class bytes > > typos: s/verity/verify/ > s/get/gets the/ fixed > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 197: > >> 195: int testCase; >> 196: try { >> 197: testCase= Integer.valueOf(args[0]); > > nit: please add space before '=' fixed. > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 215: > >> 213: redefine(1); // cached class bytes are not set >> 214: retransform(2, 1); // sets cached class bytes to ver 1 >> 215: redefine(3); // resets cached class bytes > > Perhaps: > ```// resets cached class bytes to nullptr``` done > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 224: > >> 222: redefine(1); // cached class bytes are not set >> 223: retransform(2, 1); // sets cached class bytes to ver 1 >> 224: redefine(3); // resets cached class bytes > > Perhaps: > ```// resets cached class bytes to nullptr``` done > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 232: > >> 230: test("Retransform-Redefine-Retransform-Retransform", () -> { >> 231: retransform(1, 0); // sets cached class bytes to ver 0 (initially loaded) >> 232: redefine(2); // resets cached class bytes > > Perhaps: > ```// resets cached class bytes to nullptr``` done > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 26: > >> 24: #include >> 25: #include >> 26: #include > > Should be in alpha sort order? done > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 48: > >> 46: } >> 47: >> 48: class ClassFileLoadHookHelper { > > A short comment describing the purpose of the `ClassFileLoadHookHelper` would > be helpful to folks that only have a high level understanding of RedefineClasses() > and RetransformClasses(). > > You did a very good job encapsulating support for a complicated sets of APIs > into this helper. Added short description > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 215: > >> 213: caps.can_redefine_classes = 1; >> 214: caps.can_retransform_classes = 1; >> 215: jvmti->AddCapabilities(&caps); > > Why no error check here? Added ------------- PR: https://git.openjdk.org/jdk/pull/10032 From amenkov at openjdk.org Mon Sep 12 20:30:04 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 12 Sep 2022 20:30:04 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v5] In-Reply-To: References: Message-ID: > The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) > > cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. > After successful RedefineClasses it should be reset. > The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: s/verity/verify/ ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10032/files - new: https://git.openjdk.org/jdk/pull/10032/files/fa7aca43..13264736 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10032.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10032/head:pull/10032 PR: https://git.openjdk.org/jdk/pull/10032 From amenkov at openjdk.org Mon Sep 12 20:30:05 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 12 Sep 2022 20:30:05 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v3] In-Reply-To: References: Message-ID: <8quzXh-4dzhc3QOdxICE7br12AsKJbLMfSU_55X1mRQ=.fa398076-a388-4c70-906f-fdc1cfc301ba@github.com> On Sat, 10 Sep 2022 14:39:54 GMT, Daniel D. Daugherty wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> updated test. comments, code reorg > > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 240: > >> 238: case 5: >> 239: test("Redefine-Retransform-Redefine-Retransform with CFLH", () -> { >> 240: redefine(1, 5); // CFLH sets cached class bytes to ver 1 > > I'm having trouble understanding why the CFLH version is '5' here. > Update: I _think_ this is just to have the CFLH return a different version > of the class bytes before the RedefineClasses() call does its work. I > don't understand why you want to do this... Test cases 1-4 are from the bug description. I added test cases 5 & 6 to verify additional code paths - they are the same as 3 & 4, but in RedefineClasses we provide new class bytes in CFLH. I.e. in cases 3 and 4 after RedefineClasses classes have no cached bytes and class bytes are reconstituted in the subsequent Retransform; In case 5 and 6 cache_bytes buffer is created during RedefineClasses, RetransformClasses use existing cache. > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 242: > >> 240: redefine(1, 5); // CFLH sets cached class bytes to ver 1 >> 241: retransform(2, 1); // uses existing cache >> 242: redefine(3, 6); // resets cached class bytes, > > I'm having trouble understanding why the CFLH version is '6' here. > Update: I _think_ this is just to have the CFLH return a different version > of the class bytes before the RedefineClasses() call does its work. I > don't understand why you want to do this... > > Perhaps: > ```// resets cached class bytes to nullptr,``` Fixed the comment > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 251: > >> 249: test("Retransform-Redefine-Retransform-Retransform with CFLH", () -> { >> 250: retransform(1, 0); // sets cached class bytes to ver 0 (initially loaded) >> 251: redefine(2, 5); // resets cached class bytes, > > I'm having trouble understanding why the CFLH version is '5' here. > Update: I _think_ this is just to have the CFLH return a different version > of the class bytes before the RedefineClasses() call does its work. I > don't understand why you want to do this... > > Perhaps > ```// resets cached class bytes to nullptr,``` Fixed the comment ------------- PR: https://git.openjdk.org/jdk/pull/10032 From cjplummer at openjdk.org Mon Sep 12 21:20:13 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Sep 2022 21:20:13 GMT Subject: RFR: 8293669: SA: Remove unnecssary "InstanceStackChunkKlass: InstanceStackChunkKlass" output when scanning heap Message-ID: Get rid of the following "debugging" output that was introduced in the loom repo: ` InstanceStackChunkKlass: InstanceStackChunkKlass ` I'd like to push this as a trivial change. ------------- Commit messages: - Get rid of extra output Changes: https://git.openjdk.org/jdk/pull/10245/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10245&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293669 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10245.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10245/head:pull/10245 PR: https://git.openjdk.org/jdk/pull/10245 From sspitsyn at openjdk.org Mon Sep 12 21:32:02 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 12 Sep 2022 21:32:02 GMT Subject: RFR: 8293647: Avoid unnecessary boxing in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 12:35:30 GMT, Andrey Turbanov wrote: > Usages of methods `Integer.valueOf`, `Boolean.valueOf`, `Long.valueOf` often can be simplified by using their pair methods `parseInt`/`parseBoolean`/`parseLong`. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10237 From sspitsyn at openjdk.org Mon Sep 12 21:42:42 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 12 Sep 2022 21:42:42 GMT Subject: RFR: 8293669: SA: Remove unnecssary "InstanceStackChunkKlass: InstanceStackChunkKlass" output when scanning heap In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 21:11:37 GMT, Chris Plummer wrote: > Get rid of the following "debugging" output that was introduced in the loom repo: > > ` InstanceStackChunkKlass: InstanceStackChunkKlass ` > > I'd like to push this as a trivial change. I agree, this fix is trivial. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10245 From lmesnik at openjdk.org Mon Sep 12 21:50:39 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 12 Sep 2022 21:50:39 GMT Subject: RFR: 8293339: vm/jvmti/StopThread/stop001/stop00103 crashes with SIGSEGV in Continuation::is_continuation_mounted In-Reply-To: References: Message-ID: On Sat, 10 Sep 2022 00:05:22 GMT, Serguei Spitsyn wrote: > I was not able to reproduce this issue in thousands of mach5 runs on multiple platforms. However, the root cause seems to be pretty simple. A JvmtiVTMSTransitionDisabler needs to be added to make the JVM TI StopThread function to be VTMS (Virtual Thread Mount state) transition safe. > > So the fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmtiEnv.cpp b/src/hotspot/share/prims/jvmtiEnv.cpp > index a9efe01c92e..f5e9176230a 100644 > --- a/src/hotspot/share/prims/jvmtiEnv.cpp > +++ b/src/hotspot/share/prims/jvmtiEnv.cpp > @@ -1182,6 +1182,8 @@ JvmtiEnv::ResumeAllVirtualThreads(jint except_count, const jthread* except_list) > jvmtiError > JvmtiEnv::StopThread(jthread thread, jobject exception) { > JavaThread* current_thread = JavaThread::current(); > + > + JvmtiVTMSTransitionDisabler disabler; > ThreadsListHandle tlh(current_thread); > JavaThread* java_thread = NULL; > oop thread_oop = NULL; Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10235 From sspitsyn at openjdk.org Mon Sep 12 21:57:01 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 12 Sep 2022 21:57:01 GMT Subject: RFR: 8293339: vm/jvmti/StopThread/stop001/stop00103 crashes with SIGSEGV in Continuation::is_continuation_mounted In-Reply-To: References: Message-ID: On Sat, 10 Sep 2022 00:05:22 GMT, Serguei Spitsyn wrote: > I was not able to reproduce this issue in thousands of mach5 runs on multiple platforms. However, the root cause seems to be pretty simple. A JvmtiVTMSTransitionDisabler needs to be added to make the JVM TI StopThread function to be VTMS (Virtual Thread Mount state) transition safe. > > So the fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmtiEnv.cpp b/src/hotspot/share/prims/jvmtiEnv.cpp > index a9efe01c92e..f5e9176230a 100644 > --- a/src/hotspot/share/prims/jvmtiEnv.cpp > +++ b/src/hotspot/share/prims/jvmtiEnv.cpp > @@ -1182,6 +1182,8 @@ JvmtiEnv::ResumeAllVirtualThreads(jint except_count, const jthread* except_list) > jvmtiError > JvmtiEnv::StopThread(jthread thread, jobject exception) { > JavaThread* current_thread = JavaThread::current(); > + > + JvmtiVTMSTransitionDisabler disabler; > ThreadsListHandle tlh(current_thread); > JavaThread* java_thread = NULL; > oop thread_oop = NULL; Chris and Leonid, thank you for review! ------------- PR: https://git.openjdk.org/jdk/pull/10235 From sspitsyn at openjdk.org Mon Sep 12 21:59:31 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 12 Sep 2022 21:59:31 GMT Subject: Integrated: 8293339: vm/jvmti/StopThread/stop001/stop00103 crashes with SIGSEGV in Continuation::is_continuation_mounted In-Reply-To: References: Message-ID: On Sat, 10 Sep 2022 00:05:22 GMT, Serguei Spitsyn wrote: > I was not able to reproduce this issue in thousands of mach5 runs on multiple platforms. However, the root cause seems to be pretty simple. A JvmtiVTMSTransitionDisabler needs to be added to make the JVM TI StopThread function to be VTMS (Virtual Thread Mount state) transition safe. > > So the fix is a one-liner: > > diff --git a/src/hotspot/share/prims/jvmtiEnv.cpp b/src/hotspot/share/prims/jvmtiEnv.cpp > index a9efe01c92e..f5e9176230a 100644 > --- a/src/hotspot/share/prims/jvmtiEnv.cpp > +++ b/src/hotspot/share/prims/jvmtiEnv.cpp > @@ -1182,6 +1182,8 @@ JvmtiEnv::ResumeAllVirtualThreads(jint except_count, const jthread* except_list) > jvmtiError > JvmtiEnv::StopThread(jthread thread, jobject exception) { > JavaThread* current_thread = JavaThread::current(); > + > + JvmtiVTMSTransitionDisabler disabler; > ThreadsListHandle tlh(current_thread); > JavaThread* java_thread = NULL; > oop thread_oop = NULL; This pull request has now been integrated. Changeset: d3f7e3b4 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/d3f7e3b41779427a0765bdd40a3627cb0490cbce Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8293339: vm/jvmti/StopThread/stop001/stop00103 crashes with SIGSEGV in Continuation::is_continuation_mounted Reviewed-by: cjplummer, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/10235 From cjplummer at openjdk.org Mon Sep 12 23:57:38 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Sep 2022 23:57:38 GMT Subject: RFR: 8293669: SA: Remove unnecssary "InstanceStackChunkKlass: InstanceStackChunkKlass" output when scanning heap In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 21:11:37 GMT, Chris Plummer wrote: > Get rid of the following "debugging" output that was introduced in the loom repo: > > ` InstanceStackChunkKlass: InstanceStackChunkKlass ` > > I'd like to push this as a trivial change. Thanks, Serguei! ------------- PR: https://git.openjdk.org/jdk/pull/10245 From cjplummer at openjdk.org Tue Sep 13 00:00:45 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 13 Sep 2022 00:00:45 GMT Subject: Integrated: 8293669: SA: Remove unnecssary "InstanceStackChunkKlass: InstanceStackChunkKlass" output when scanning heap In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 21:11:37 GMT, Chris Plummer wrote: > Get rid of the following "debugging" output that was introduced in the loom repo: > > ` InstanceStackChunkKlass: InstanceStackChunkKlass ` > > I'd like to push this as a trivial change. This pull request has now been integrated. Changeset: 526eb54f Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/526eb54fc3d0a96e228a57e20facfccd83fb8081 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8293669: SA: Remove unnecssary "InstanceStackChunkKlass: InstanceStackChunkKlass" output when scanning heap Reviewed-by: sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/10245 From duke at openjdk.org Tue Sep 13 07:09:52 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 13 Sep 2022 07:09:52 GMT Subject: RFR: 8293647: Avoid unnecessary boxing in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Mon, 12 Sep 2022 12:35:30 GMT, Andrey Turbanov wrote: > Usages of methods `Integer.valueOf`, `Boolean.valueOf`, `Long.valueOf` often can be simplified by using their pair methods `parseInt`/`parseBoolean`/`parseLong`. Marked as reviewed by stsypanov at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/10237 From kevinw at openjdk.org Tue Sep 13 07:38:02 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 13 Sep 2022 07:38:02 GMT Subject: Integrated: 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 14:47:35 GMT, Kevin Walls wrote: > This is an MR which partially reverts JDK-8289091 such that JavaThread::threadObj() does not call Thread::current(). > > A JVMTI operation could call threadObj() and clear the Windows GetLastError value. > > Partial, because I haven't reverted changes in JavaThread::print_on_error(), they aren't connected to the problems seen. This pull request has now been integrated. Changeset: dfc16e04 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/dfc16e047f1f8adaa8510574d00bf9f958902c43 Stats: 105 lines in 3 files changed: 101 ins; 0 del; 4 mod 8292302: Windows GetLastError value overwritten by ThreadLocalStorage::thread Reviewed-by: cjplummer, dholmes, dcubed ------------- PR: https://git.openjdk.org/jdk/pull/10147 From sspitsyn at openjdk.org Tue Sep 13 09:54:29 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 13 Sep 2022 09:54:29 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v5] In-Reply-To: References: Message-ID: <14hiQId61qMjRFoYpdaAy-AXxiMW2vgsMcW0l92V-5I=.75648ba6-cd01-4301-a852-c3b3836895fd@github.com> On Mon, 12 Sep 2022 20:30:04 GMT, Alex Menkov wrote: >> The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) >> >> cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. >> After successful RedefineClasses it should be reset. >> The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > s/verity/verify/ I've posted one minor comment. Otherwise, it is good. Thanks, Serguei test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 222: > 220: caps.can_retransform_classes = 1; > 221: res = jvmti->AddCapabilities(&caps); > 222: if (res != JVMTI_ERROR_NONE) { The type of res is jint. It is better to use a variable of type jvmtiError. I've missed this initially. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10032 From alanb at openjdk.org Tue Sep 13 13:17:34 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Sep 2022 13:17:34 GMT Subject: RFR: 8289610: Degrade Thread.stop Message-ID: Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. ------------- Commit messages: - Deprecate for removal - Next iteration, update dates in headers - Merge - Initial commit Changes: https://git.openjdk.org/jdk/pull/10230/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289610 Stats: 311 lines in 23 files changed: 114 ins; 147 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/10230.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230 PR: https://git.openjdk.org/jdk/pull/10230 From duke at openjdk.org Tue Sep 13 13:17:35 2022 From: duke at openjdk.org (ExE Boss) Date: Tue, 13 Sep 2022 13:17:35 GMT Subject: RFR: 8289610: Degrade Thread.stop In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote: > Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. > > Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. > > To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. > > The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. src/java.base/share/classes/java/lang/ThreadDeath.java line 42: > 40: */ > 41: @Deprecated(since="20") > 42: public class ThreadDeath extends Error { Actually, `ThreadDeath` is?thrown?manually by?**JShell** instrumentation?code since?[JDK?8289613] ([GH?10166])[^1]. [JDK?8289613]: https://bugs.openjdk.org/browse/JDK-8289613 [GH?10166]: https://github.com/openjdk/jdk/pull/10166 [^1]: https://github.com/openjdk/jdk/blob/00befddd7ce97d324250807824469daaa9434eef/src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java#L104-L107 ------------- PR: https://git.openjdk.org/jdk/pull/10230 From rriggs at openjdk.org Tue Sep 13 14:12:48 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Sep 2022 14:12:48 GMT Subject: RFR: 8289610: Degrade Thread.stop In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote: > Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. > > Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. > > To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. > > The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. core-libs parts look fine. src/java.base/share/classes/java/lang/Thread.java line 1635: > 1633: * > 1634: * @throws UnsupportedOperationException > 1635: * always fold with previous line. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From cjplummer at openjdk.org Tue Sep 13 17:50:55 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 13 Sep 2022 17:50:55 GMT Subject: RFR: 8289610: Degrade Thread.stop In-Reply-To: References: Message-ID: <8ZLJ1_MCq61Of0Jb2zUNFDskX7BYN1LFwGQ3JGSPcUQ=.f971b32e-491d-400d-bced-c13aabc30a0f@github.com> On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote: > Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. > > Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. > > To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. > > The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. serviceability changes look good ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/10230 From aturbanov at openjdk.org Tue Sep 13 17:57:47 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 13 Sep 2022 17:57:47 GMT Subject: Integrated: 8293647: Avoid unnecessary boxing in jdk.hotspot.agent In-Reply-To: References: Message-ID: <5096SMP1taufb358gD6qPuFzor1L85FLm7OFblwoZA4=.e8ab3bb0-6600-4353-9404-f4133ebb1cb2@github.com> On Mon, 12 Sep 2022 12:35:30 GMT, Andrey Turbanov wrote: > Usages of methods `Integer.valueOf`, `Boolean.valueOf`, `Long.valueOf` often can be simplified by using their pair methods `parseInt`/`parseBoolean`/`parseLong`. This pull request has now been integrated. Changeset: 7e020398 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/7e0203980582c47e53f8851998138e13913bd28a Stats: 16 lines in 3 files changed: 0 ins; 0 del; 16 mod 8293647: Avoid unnecessary boxing in jdk.hotspot.agent Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/10237 From mullan at openjdk.org Tue Sep 13 19:01:51 2022 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 13 Sep 2022 19:01:51 GMT Subject: RFR: 8289610: Degrade Thread.stop In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote: > Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. > > Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. > > To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. > > The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. What about also removing and undocumenting `RuntimePermission("stopThread")` as part of this change? ------------- PR: https://git.openjdk.org/jdk/pull/10230 From eosterlund at openjdk.org Tue Sep 13 19:09:42 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 13 Sep 2022 19:09:42 GMT Subject: RFR: 8289610: Degrade Thread.stop In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote: > Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. > > Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. > > To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. > > The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. There is a bunch of VM code for this too. Should we clean that up separately? ------------- PR: https://git.openjdk.org/jdk/pull/10230 From alanb at openjdk.org Tue Sep 13 19:17:45 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Sep 2022 19:17:45 GMT Subject: RFR: 8289610: Degrade Thread.stop In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 19:06:14 GMT, Erik ?sterlund wrote: > There is a bunch of VM code for this too. Should we clean that up separately? Yes chatted with @dholmes-ora about this recently and he suggested separating out so there is a follow-on JBS issue created for that. Aside from JVM_StopThread, I suspect code that deals with pending exceptions before a thread start can go away as the JVM TI StopThread can't cause an async exception on an unstarted thread. I'm hoping Thread.stillborn can go away too. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From eosterlund at openjdk.org Tue Sep 13 19:17:46 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 13 Sep 2022 19:17:46 GMT Subject: RFR: 8289610: Degrade Thread.stop In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 19:12:26 GMT, Alan Bateman wrote: > > There is a bunch of VM code for this too. Should we clean that up separately? > > > > Yes chatted with @dholmes-ora about this recently and he suggested separating out so there is a follow-on JBS issue created for that. Aside from JVM_StopThread, I suspect code that deals with pending exceptions before a thread start can go away as the JVM TI StopThread can't cause an async exception on an unstarted thread. I'm hoping Thread.stillborn can go away too. Sounds good. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From alanb at openjdk.org Tue Sep 13 19:17:47 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Sep 2022 19:17:47 GMT Subject: RFR: 8289610: Degrade Thread.stop In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 18:57:34 GMT, Sean Mullan wrote: > What about also removing and undocumenting `RuntimePermission("stopThread")` as part of this change? Ah yes, the table RuntimePermission can be updated as part of this (and the corresponding constant in sun/security/util/SecurityConstants). ------------- PR: https://git.openjdk.org/jdk/pull/10230 From amenkov at openjdk.org Tue Sep 13 21:03:13 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 13 Sep 2022 21:03:13 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v6] In-Reply-To: References: Message-ID: > The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) > > cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. > After successful RedefineClasses it should be reset. > The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Use jvmtiError for JVMTI function results ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10032/files - new: https://git.openjdk.org/jdk/pull/10032/files/13264736..d853f23f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10032&range=04-05 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10032.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10032/head:pull/10032 PR: https://git.openjdk.org/jdk/pull/10032 From amenkov at openjdk.org Tue Sep 13 21:09:50 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 13 Sep 2022 21:09:50 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v5] In-Reply-To: <14hiQId61qMjRFoYpdaAy-AXxiMW2vgsMcW0l92V-5I=.75648ba6-cd01-4301-a852-c3b3836895fd@github.com> References: <14hiQId61qMjRFoYpdaAy-AXxiMW2vgsMcW0l92V-5I=.75648ba6-cd01-4301-a852-c3b3836895fd@github.com> Message-ID: On Tue, 13 Sep 2022 09:49:58 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> s/verity/verify/ > > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp line 222: > >> 220: caps.can_retransform_classes = 1; >> 221: res = jvmti->AddCapabilities(&caps); >> 222: if (res != JVMTI_ERROR_NONE) { > > The type of res is jint. It is better to use a variable of type jvmtiError. I've missed this initially. Fixed ------------- PR: https://git.openjdk.org/jdk/pull/10032 From lmesnik at openjdk.org Tue Sep 13 21:43:30 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 13 Sep 2022 21:43:30 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v3] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 09:28:38 GMT, Kevin Walls wrote: >> Test update to cope with heap size changing (shrinking) in the early life of the test app. >> >> A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. >> Recognising a shrinking heap and retrying resolves this. >> >> (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Clarify that loop is for checking heap not changing. Exception if continually changing. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10218 From lmesnik at openjdk.org Tue Sep 13 23:12:22 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 13 Sep 2022 23:12:22 GMT Subject: RFR: 8289608: Change com/sun/jdi tests to not use Thread.suspend/resume Message-ID: There are 2 tests that should be deleted. They test Thread.suspend/resume and don't have a sense if these functions don't work. ------------- Commit messages: - 8289608: Change com/sun/jdi tests to not use Thread.suspend/resume Changes: https://git.openjdk.org/jdk/pull/10255/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10255&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289608 Stats: 354 lines in 3 files changed: 0 ins; 354 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10255.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10255/head:pull/10255 PR: https://git.openjdk.org/jdk/pull/10255 From cjplummer at openjdk.org Tue Sep 13 23:27:44 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 13 Sep 2022 23:27:44 GMT Subject: RFR: 8289608: Change com/sun/jdi tests to not use Thread.suspend/resume In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 23:05:00 GMT, Leonid Mesnik wrote: > There are 2 tests that should be deleted. They test Thread.suspend/resume and don't have a sense if these functions don't work. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10255 From mchung at openjdk.org Tue Sep 13 23:54:31 2022 From: mchung at openjdk.org (Mandy Chung) Date: Tue, 13 Sep 2022 23:54:31 GMT Subject: RFR: 8289610: Degrade Thread.stop In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote: > Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. > > Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. > > To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. > > The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. The change looks good. There are other tests that reference `ThreadDeath` for example `test/lib/jdk/test/lib/process/ProcessTools.java`, `test/jdk/java/util/Timer/KillThread.java` , `test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/flow/support/NonFatal.java` etc. Is it expected to update them in a follow-on issue? ------------- PR: https://git.openjdk.org/jdk/pull/10230 From sspitsyn at openjdk.org Wed Sep 14 05:42:50 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Sep 2022 05:42:50 GMT Subject: RFR: 7124710: interleaved RedefineClasses() and RetransformClasses() calls may have a problem [v6] In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 21:03:13 GMT, Alex Menkov wrote: >> The problem is RedefineClasses does not update cached_class_bytes, so subsequent RetransformClasses gets obsolete class bytes (this are testcases 3-6 from the new test) >> >> cached_class_bytes are set when an agent instruments the class from ClassFileLoadHook. >> After successful RedefineClasses it should be reset. >> The fix updates ClassFileLoadHook caller to not use old cached_class_bytes with RedefineClasses (if some agent instruments the class, new cached_class_bytes are allocated for scratch_class) and updates cached_class_bytes after successful RedefineClasses or RetransformClasses. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Use jvmtiError for JVMTI function results Thank you for the update! It looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10032 From sspitsyn at openjdk.org Wed Sep 14 05:55:43 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Sep 2022 05:55:43 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v3] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 09:28:38 GMT, Kevin Walls wrote: >> Test update to cope with heap size changing (shrinking) in the early life of the test app. >> >> A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. >> Recognising a shrinking heap and retrying resolves this. >> >> (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Clarify that loop is for checking heap not changing. Exception if continually changing. I've posted one comment. Otherwise, the update looks good. Thanks, Serguei test/hotspot/jtreg/serviceability/tmtools/jstat/utils/GcProvoker.java line 76: > 74: System.gc(); > 75: continue; > 76: } else { In fact, the `else-statement` is not needed here because the `if-statement` is ended with `continue`. At least, this looks confusing to me. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10218 From sspitsyn at openjdk.org Wed Sep 14 05:57:46 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 Sep 2022 05:57:46 GMT Subject: RFR: 8289608: Change com/sun/jdi tests to not use Thread.suspend/resume In-Reply-To: References: Message-ID: <-7AtpUYENlKP1IwxafFwkssl4w-F5aVt9MhezRah6us=.bfff2cc9-49ae-4f88-9291-a8d201694589@github.com> On Tue, 13 Sep 2022 23:05:00 GMT, Leonid Mesnik wrote: > There are 2 tests that should be deleted. They test Thread.suspend/resume and don't have a sense if these functions don't work. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10255 From asotona at openjdk.org Wed Sep 14 11:10:15 2022 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 14 Sep 2022 11:10:15 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v16] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le - Merge branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - Merge branch 'openjdk:master' into JDK-8244681 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module - Added man-page line about lossy-conversion lint - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments re-enabled warnings for java.base, java.rmi and java.smartcardio - ... and 10 more: https://git.openjdk.org/jdk/compare/7f3250d7...4b78b1c5 ------------- Changes: https://git.openjdk.org/jdk/pull/8599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=15 Stats: 439 lines in 14 files changed: 437 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.org/jdk/pull/8599 From asotona at openjdk.org Wed Sep 14 11:25:38 2022 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 14 Sep 2022 11:25:38 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v16] In-Reply-To: References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: <7HAZTQI9U8tr8hrc3uRhkeAnZU4yjyjVDhTB2vXd00E=.69ffd410-c37e-45ec-b812-69bf4a2782ea@github.com> On Wed, 14 Sep 2022 11:10:15 GMT, Adam Sotona wrote: >> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. >> >> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. >> >> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. >> >> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. >> >> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. >> >> Thanks for your review, >> Adam > > Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'openjdk:master' into JDK-8244681 > - Merge branch 'openjdk:master' into JDK-8244681 > - re-enabled lossy conversions warnings for java.security.jgss, jdk.crypto.ec and jdk.internal.le > - Merge branch 'openjdk:master' into JDK-8244681 > - Merge branch 'openjdk:master' into JDK-8244681 > - Merge branch 'openjdk:master' into JDK-8244681 > - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module > - Added man-page line about lossy-conversion lint > - Merge branch 'openjdk:master' into JDK-8244681 > - 8244681: Add a warning for possibly lossy conversion in compound assignments > re-enabled warnings for java.base, java.rmi and java.smartcardio > - ... and 10 more: https://git.openjdk.org/jdk/compare/7f3250d7...4b78b1c5 Please review also linked Release Note issue. Thanks, Adam ------------- PR: https://git.openjdk.org/jdk/pull/8599 From asotona at openjdk.org Wed Sep 14 11:35:03 2022 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 14 Sep 2022 11:35:03 GMT Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v17] In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: re-enabled lossy-conversions warnings for jdk.hotspot.agent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8599/files - new: https://git.openjdk.org/jdk/pull/8599/files/4b78b1c5..0b93c284 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8599&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.org/jdk/pull/8599 From sgehwolf at openjdk.org Wed Sep 14 12:34:30 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 14 Sep 2022 12:34:30 GMT Subject: RFR: 8293540: [Metrics] Incorrectly detected ressource limits with additional cgroup fs mounts Message-ID: Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2: test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`. Testing: - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix) - [x] added tests fail before, pass after the product fix. - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. - [ ] GHA still running. Please review! Many thanks in advance. ------------- Depends on: https://git.openjdk.org/jdk/pull/10193 Commit messages: - 8293540: [Metrics] Potentially incorrectly detected ressource limits with additional cgroup fs mounts Changes: https://git.openjdk.org/jdk/pull/10248/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293540 Stats: 175 lines in 6 files changed: 137 ins; 23 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/10248.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248 PR: https://git.openjdk.org/jdk/pull/10248 From alanb at openjdk.org Wed Sep 14 13:45:44 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Sep 2022 13:45:44 GMT Subject: RFR: 8289608: Change com/sun/jdi tests to not use Thread.suspend/resume In-Reply-To: References: Message-ID: <1Zc-eTKAH97bvM_4ylyaWXRzZIEhCgENu1bn-KBlg3s=.7bc76640-c25a-4720-9643-1950eed31ede@github.com> On Tue, 13 Sep 2022 23:05:00 GMT, Leonid Mesnik wrote: > There are 2 tests that should be deleted. They test Thread.suspend/resume and don't have a sense if these functions don't work. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10255 From alanb at openjdk.org Wed Sep 14 14:09:52 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Sep 2022 14:09:52 GMT Subject: RFR: 8289610: Degrade Thread.stop [v2] In-Reply-To: References: Message-ID: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> > Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. > > Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. > > To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. > > The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. Alan Bateman 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 - Remove stopThread permission from RuntimePermission table, exclude jshell tests - Deprecate for removal - Next iteration, update dates in headers - Merge - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10230/files - new: https://git.openjdk.org/jdk/pull/10230/files/380e4043..86424b65 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=00-01 Stats: 2990 lines in 108 files changed: 2115 ins; 353 del; 522 mod Patch: https://git.openjdk.org/jdk/pull/10230.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230 PR: https://git.openjdk.org/jdk/pull/10230 From alanb at openjdk.org Wed Sep 14 14:09:53 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Sep 2022 14:09:53 GMT Subject: RFR: 8289610: Degrade Thread.stop In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 23:51:03 GMT, Mandy Chung wrote: > The change looks good. There are other tests that reference `ThreadDeath` for example `test/lib/jdk/test/lib/process/ProcessTools.java`, `test/jdk/java/util/Timer/KillThread.java` , `test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/flow/support/NonFatal.java` etc. Is it expected to update them in a follow-on issue? I've been trying to keep the test cleanup separate if possible, only because the changes become unwieldy. Aside from jshell, the tests that used Thread.stop have already been changed or removed in advance of this PR. The tests that have catch blocks for ThreadDeath will work as before as there is no Thread.stop. There are one or two tests that will need special attention - the reactivestreams-tck tests that you listed is 3rd party code and we might decide to do nothing there. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From alanb at openjdk.org Wed Sep 14 14:09:55 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Sep 2022 14:09:55 GMT Subject: RFR: 8289610: Degrade Thread.stop [v2] In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 14:03:52 GMT, Roger Riggs wrote: > fold with previous line. Done. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From jpai at openjdk.org Wed Sep 14 14:24:42 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 14 Sep 2022 14:24:42 GMT Subject: RFR: 8289610: Degrade Thread.stop [v2] In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> References: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> Message-ID: On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote: >> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. >> >> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. >> >> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. >> >> The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. > > Alan Bateman 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 > - Remove stopThread permission from RuntimePermission table, exclude jshell tests > - Deprecate for removal > - Next iteration, update dates in headers > - Merge > - Initial commit The changes to the `core-libs` look fine to me. There are some test security policy files (for example `IsKeepingAlive.policy`) and the `DynamicPolicy` which use the `stopThread` `RuntimePermission` which no longer exists. Should those policy files and artifacts be updated to remove reference to this permission too? ------------- PR: https://git.openjdk.org/jdk/pull/10230 From jpai at openjdk.org Wed Sep 14 14:29:11 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 14 Sep 2022 14:29:11 GMT Subject: RFR: 8289610: Degrade Thread.stop [v2] In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> References: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> Message-ID: On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote: >> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. >> >> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. >> >> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. >> >> The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. > > Alan Bateman 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 > - Remove stopThread permission from RuntimePermission table, exclude jshell tests > - Deprecate for removal > - Next iteration, update dates in headers > - Merge > - Initial commit src/java.logging/share/classes/java/util/logging/LogManager.java line 2670: > 2668: c.run(); > 2669: } catch (ThreadDeath death) { > 2670: throw death; In theory, before this change, some (odd/weird) application code which was registered as a `listener` could throw a `ThreadDeath` and we would then abort any other `listeners` from being run. With this change that would no longer be that case. However, I think that is fine, since the API doc of `LogManager.addConfigurationListener()` already states: * It is recommended that listeners do not throw errors or exceptions. * * If a listener terminates with an uncaught error or exception then * the first exception will be propagated to the caller of * {@link #readConfiguration()} (or {@link #readConfiguration(java.io.InputStream)}) * after all listeners have been invoked. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From alanb at openjdk.org Wed Sep 14 14:38:41 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Sep 2022 14:38:41 GMT Subject: RFR: 8289610: Degrade Thread.stop [v2] In-Reply-To: References: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> Message-ID: On Wed, 14 Sep 2022 14:21:09 GMT, Jaikiran Pai wrote: > The changes to the `core-libs` look fine to me. There are some test security policy files (for example `IsKeepingAlive.policy`) and the `DynamicPolicy` which use the `stopThread` `RuntimePermission` which no longer exists. Should those policy files and artifacts be updated to remove reference to this permission too? Mandy asked the test cleanup too. I'm hoping that we will do the test cleanup separately, only to avoid the changes being too unwieldly. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From jpai at openjdk.org Wed Sep 14 15:26:41 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 14 Sep 2022 15:26:41 GMT Subject: RFR: 8289610: Degrade Thread.stop [v2] In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> References: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> Message-ID: On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote: >> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. >> >> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. >> >> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. >> >> The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. > > Alan Bateman 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 > - Remove stopThread permission from RuntimePermission table, exclude jshell tests > - Deprecate for removal > - Next iteration, update dates in headers > - Merge > - Initial commit Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10230 From jpai at openjdk.org Wed Sep 14 15:26:42 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 14 Sep 2022 15:26:42 GMT Subject: RFR: 8289610: Degrade Thread.stop [v2] In-Reply-To: References: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> Message-ID: On Wed, 14 Sep 2022 14:35:05 GMT, Alan Bateman wrote: > > The changes to the `core-libs` look fine to me. There are some test security policy files (for example `IsKeepingAlive.policy`) and the `DynamicPolicy` which use the `stopThread` `RuntimePermission` which no longer exists. Should those policy files and artifacts be updated to remove reference to this permission too? > > Mandy asked the test cleanup too. I'm hoping that we will do the test cleanup separately, only to avoid the changes being too unwieldly. Sorry, I missed your previous response to that similar question. Doing those changes separately sounds fine to me. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From rriggs at openjdk.org Wed Sep 14 15:33:45 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 14 Sep 2022 15:33:45 GMT Subject: RFR: 8289610: Degrade Thread.stop [v2] In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> References: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> Message-ID: On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote: >> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. >> >> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. >> >> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. >> >> The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. > > Alan Bateman 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 > - Remove stopThread permission from RuntimePermission table, exclude jshell tests > - Deprecate for removal > - Next iteration, update dates in headers > - Merge > - Initial commit LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/10230 From mchung at openjdk.org Wed Sep 14 15:59:53 2022 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 14 Sep 2022 15:59:53 GMT Subject: RFR: 8289610: Degrade Thread.stop [v2] In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> References: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> Message-ID: On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote: >> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. >> >> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. >> >> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. >> >> The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. > > Alan Bateman 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 > - Remove stopThread permission from RuntimePermission table, exclude jshell tests > - Deprecate for removal > - Next iteration, update dates in headers > - Merge > - Initial commit Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10230 From prr at openjdk.org Wed Sep 14 17:53:55 2022 From: prr at openjdk.org (Phil Race) Date: Wed, 14 Sep 2022 17:53:55 GMT Subject: RFR: 8289610: Degrade Thread.stop [v2] In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> References: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> Message-ID: On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote: >> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. >> >> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. >> >> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. >> >> The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. > > Alan Bateman 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 > - Remove stopThread permission from RuntimePermission table, exclude jshell tests > - Deprecate for removal > - Next iteration, update dates in headers > - Merge > - Initial commit Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10230 From mullan at openjdk.org Wed Sep 14 20:32:47 2022 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 14 Sep 2022 20:32:47 GMT Subject: RFR: 8289610: Degrade Thread.stop [v2] In-Reply-To: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> References: <01cUinxLbVchDmT0-aFmDnUzbhbjhdk0H7oAMoiXyps=.1f219cd8-d684-4bee-9413-c5cbb9030f78@github.com> Message-ID: <7rR40Xh40dmqQRAmSYBOl-h7vbUwKpq204tERqKKn0Q=.c168ee8e-2cb8-4aaa-a6b4-c562367013fb@github.com> On Wed, 14 Sep 2022 14:09:52 GMT, Alan Bateman wrote: >> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. >> >> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. >> >> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. >> >> The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. > > Alan Bateman 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 > - Remove stopThread permission from RuntimePermission table, exclude jshell tests > - Deprecate for removal > - Next iteration, update dates in headers > - Merge > - Initial commit src/java.base/share/classes/java/lang/Thread.java line 1642: > 1640: * {@code ThreadDeath} exception propagating up the stack). If > 1641: * any of the objects previously protected by these monitors were in > 1642: * an inconsistent state, the damaged objects become visible to s/become/became/ (because you are writing in past tense now). ------------- PR: https://git.openjdk.org/jdk/pull/10230 From dcubed at openjdk.org Wed Sep 14 22:04:10 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 14 Sep 2022 22:04:10 GMT Subject: RFR: 8289608: Change com/sun/jdi tests to not use Thread.suspend/resume In-Reply-To: References: Message-ID: <5uKs5LahFQBzTvcUaydiNmUG5TX948uTbm4R7IDSs2I=.b1e4d8ef-211d-49a0-a285-70f624c1e8b2@github.com> On Tue, 13 Sep 2022 23:05:00 GMT, Leonid Mesnik wrote: > There are 2 tests that should be deleted. They test Thread.suspend/resume and don't have a sense if these functions don't work. Thumbs up. I agree that these tests are verifying interaction with j.l.Thread.{suspend,resume} and we don't need to do that anymore. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/10255 From dcubed at openjdk.org Wed Sep 14 22:46:43 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 14 Sep 2022 22:46:43 GMT Subject: RFR: 8293540: [Metrics] Incorrectly detected ressource limits with additional cgroup fs mounts In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 13:06:10 GMT, Severin Gehwolf wrote: > Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2: > > > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java > test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java > > > I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`. > > Testing: > - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix) > - [x] added tests fail before, pass after the product fix. > - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. > - [ ] GHA still running. > > Please review! Many thanks in advance. I fixed a typo in the bug's synopsis line so this PR's title needs to be update. Doing a "/issue JDK-8293540" will do the trick. ------------- PR: https://git.openjdk.org/jdk/pull/10248 From sgehwolf at openjdk.org Thu Sep 15 08:07:08 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 15 Sep 2022 08:07:08 GMT Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts In-Reply-To: References: Message-ID: <4fY8V3tuDctSf_kqS2pDNuIKKlJMVNPllkm753EwmTc=.5519d859-57b2-4493-9d5e-7e7311538d12@github.com> On Tue, 13 Sep 2022 13:06:10 GMT, Severin Gehwolf wrote: > Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2: > > > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java > test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java > > > I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`. > > Testing: > - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix) > - [x] added tests fail before, pass after the product fix. > - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. > - [ ] GHA still running. > > Please review! Many thanks in advance. Thanks! I've updated the PR title to match the bug synopsis. ------------- PR: https://git.openjdk.org/jdk/pull/10248 From sgehwolf at openjdk.org Thu Sep 15 08:51:55 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 15 Sep 2022 08:51:55 GMT Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts [v2] In-Reply-To: References: Message-ID: > Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2: > > > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java > test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java > > > I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`. > > Testing: > - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix) > - [x] added tests fail before, pass after the product fix. > - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. > - [ ] GHA still running. > > Please review! Many thanks in advance. 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. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10248/files - new: https://git.openjdk.org/jdk/pull/10248/files/9cc6c7cd..9cc6c7cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10248.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248 PR: https://git.openjdk.org/jdk/pull/10248 From sgehwolf at openjdk.org Thu Sep 15 08:55:41 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 15 Sep 2022 08:55:41 GMT Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts [v3] In-Reply-To: References: Message-ID: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com> > Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2: > > > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java > test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java > > > I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`. > > Testing: > - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix) > - [x] added tests fail before, pass after the product fix. > - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. > - [ ] GHA still running. > > Please review! Many thanks in advance. Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts ------------- Changes: https://git.openjdk.org/jdk/pull/10248/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=02 Stats: 175 lines in 6 files changed: 137 ins; 23 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/10248.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248 PR: https://git.openjdk.org/jdk/pull/10248 From asotona at openjdk.org Thu Sep 15 10:12:53 2022 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 15 Sep 2022 10:12:53 GMT Subject: Integrated: 8244681: Add a warning for possibly lossy conversion in compound assignments In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com> Message-ID: On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. > > The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. > > The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. > > Thanks for your review, > Adam This pull request has now been integrated. Changeset: aff5ff14 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/aff5ff14b208b3c2be93d7b4fab8b07c5be12f3e Stats: 438 lines in 13 files changed: 437 ins; 0 del; 1 mod 8244681: Add a warning for possibly lossy conversion in compound assignments 8293797: Release Note: Javac warns about type casts in compound assignments with possible lossy conversions Reviewed-by: erikj, prr ------------- PR: https://git.openjdk.org/jdk/pull/8599 From lmesnik at openjdk.org Thu Sep 15 17:29:27 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 15 Sep 2022 17:29:27 GMT Subject: Integrated: 8289608: Change com/sun/jdi tests to not use Thread.suspend/resume In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 23:05:00 GMT, Leonid Mesnik wrote: > There are 2 tests that should be deleted. They test Thread.suspend/resume and don't have a sense if these functions don't work. This pull request has now been integrated. Changeset: 2028ec74 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/2028ec7412fae3ee0a67f0c90bdc686c2edc1055 Stats: 354 lines in 3 files changed: 0 ins; 354 del; 0 mod 8289608: Change com/sun/jdi tests to not use Thread.suspend/resume Reviewed-by: cjplummer, sspitsyn, alanb, dcubed ------------- PR: https://git.openjdk.org/jdk/pull/10255 From dcubed at openjdk.org Thu Sep 15 19:38:02 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 15 Sep 2022 19:38:02 GMT Subject: RFR: 8293875: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 Message-ID: A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64. ------------- Commit messages: - 8293875: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 Changes: https://git.openjdk.org/jdk/pull/10293/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10293&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293875 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10293.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10293/head:pull/10293 PR: https://git.openjdk.org/jdk/pull/10293 From bpb at openjdk.org Thu Sep 15 19:38:02 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 15 Sep 2022 19:38:02 GMT Subject: RFR: 8293875: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 19:27:47 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10293 From dcubed at openjdk.org Thu Sep 15 19:42:10 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 15 Sep 2022 19:42:10 GMT Subject: RFR: 8293875: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 In-Reply-To: References: Message-ID: <1rdlpqwgRq-3sfdp-YeodVc5B2fZZy_VQz9iu8FImrs=.88cebebd-177b-4077-a290-e585070116f4@github.com> On Thu, 15 Sep 2022 19:32:14 GMT, Brian Burkhalter wrote: >> A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64. > > Marked as reviewed by bpb (Reviewer). @bplb - Thanks for the fast review. ------------- PR: https://git.openjdk.org/jdk/pull/10293 From dcubed at openjdk.org Thu Sep 15 19:42:10 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 15 Sep 2022 19:42:10 GMT Subject: Integrated: 8293875: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 19:27:47 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64. This pull request has now been integrated. Changeset: 6beeb847 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/6beeb8471ccf140e59864d7f983e1d9ad741309c Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8293875: ProblemList sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 on linux-x64 Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk/pull/10293 From aturbanov at openjdk.org Thu Sep 15 21:06:24 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 15 Sep 2022 21:06:24 GMT Subject: RFR: 8293879: Remove unnecessary castings in jdk.hotspot.agent Message-ID: Redundant castings make code harder to read. Found them by IntelliJ IDEA. I tried to choose only casts which are definitely safe to remove. Most generification was done in [JDK-8241618](https://bugs.openjdk.org/browse/JDK-8241618), but casts weren't removed. ------------- Commit messages: - [PATCH] Remove unnecessary castings in jdk.hotspot.agent Changes: https://git.openjdk.org/jdk/pull/10295/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10295&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293879 Stats: 261 lines in 75 files changed: 0 ins; 8 del; 253 mod Patch: https://git.openjdk.org/jdk/pull/10295.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10295/head:pull/10295 PR: https://git.openjdk.org/jdk/pull/10295 From lmesnik at openjdk.org Thu Sep 15 21:31:48 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 15 Sep 2022 21:31:48 GMT Subject: RFR: 8293879: Remove unnecessary castings in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 20:49:14 GMT, Andrey Turbanov wrote: > Redundant castings make code harder to read. > Found them by IntelliJ IDEA. > I tried to choose only casts which are definitely safe to remove. > Most generification was done in [JDK-8241618](https://bugs.openjdk.org/browse/JDK-8241618), but casts weren't removed. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10295 From cjplummer at openjdk.org Thu Sep 15 22:34:40 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 15 Sep 2022 22:34:40 GMT Subject: RFR: 8293879: Remove unnecessary castings in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 20:49:14 GMT, Andrey Turbanov wrote: > Redundant castings make code harder to read. > Found them by IntelliJ IDEA. > I tried to choose only casts which are definitely safe to remove. > Most generification was done in [JDK-8241618](https://bugs.openjdk.org/browse/JDK-8241618), but casts weren't removed. Looks good. Nice cleanup. It looks like a lot of these got introduced by [JDK-8241618](https://bugs.openjdk.org/browse/JDK-8241618), which says: > I started to address the unchecked warnings. Unfortunately, this was a much bigger task than I anticipated. I had to generify most of the module. So I guess with the new use of generics in place, the existing casts became unnecessary. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GenCollectedHeap.java line 134: > 132: } else { > 133: return VMObjectFactory.newObject(GenerationSpec.class, > 134: oldGenSpecField.getAddress()); Maybe make each of these one line instead of two. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/10295 From aturbanov at openjdk.org Fri Sep 16 09:13:51 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 16 Sep 2022 09:13:51 GMT Subject: RFR: 8293879: Remove unnecessary castings in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 22:27:25 GMT, Chris Plummer wrote: >> Redundant castings make code harder to read. >> Found them by IntelliJ IDEA. >> I tried to choose only casts which are definitely safe to remove. >> Most generification was done in [JDK-8241618](https://bugs.openjdk.org/browse/JDK-8241618), but casts weren't removed. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GenCollectedHeap.java line 134: > >> 132: } else { >> 133: return VMObjectFactory.newObject(GenerationSpec.class, >> 134: oldGenSpecField.getAddress()); > > Maybe make each of these one line instead of two. Other lines in this file don't exceed 80 chars. So, I think it's better to preserver line break here. ------------- PR: https://git.openjdk.org/jdk/pull/10295 From alanb at openjdk.org Fri Sep 16 09:45:14 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Sep 2022 09:45:14 GMT Subject: RFR: 8289610: Degrade Thread.stop [v3] In-Reply-To: References: Message-ID: > Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. > > Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. > > To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. > > The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Repalce "it" with "victim thread" - Merge - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop - become -> became in javadoc - Merge - Remove stopThread permission from RuntimePermission table, exclude jshell tests - Deprecate for removal - Next iteration, update dates in headers - Merge - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10230/files - new: https://git.openjdk.org/jdk/pull/10230/files/86424b65..a00f38a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=01-02 Stats: 2575 lines in 102 files changed: 1741 ins; 370 del; 464 mod Patch: https://git.openjdk.org/jdk/pull/10230.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230 PR: https://git.openjdk.org/jdk/pull/10230 From jpai at openjdk.org Fri Sep 16 10:03:51 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 Sep 2022 10:03:51 GMT Subject: RFR: 8289610: Degrade Thread.stop [v3] In-Reply-To: References: Message-ID: On Fri, 16 Sep 2022 09:45:14 GMT, Alan Bateman wrote: >> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. >> >> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. >> >> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. >> >> The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Repalce "it" with "victim thread" > - Merge > - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop > - become -> became in javadoc > - Merge > - Remove stopThread permission from RuntimePermission table, exclude jshell tests > - Deprecate for removal > - Next iteration, update dates in headers > - Merge > - Initial commit Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10230 From mullan at openjdk.org Fri Sep 16 13:16:53 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 16 Sep 2022 13:16:53 GMT Subject: RFR: 8289610: Degrade Thread.stop [v3] In-Reply-To: References: Message-ID: On Fri, 16 Sep 2022 09:45:14 GMT, Alan Bateman wrote: >> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. >> >> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. >> >> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. >> >> The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Repalce "it" with "victim thread" > - Merge > - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop > - become -> became in javadoc > - Merge > - Remove stopThread permission from RuntimePermission table, exclude jshell tests > - Deprecate for removal > - Next iteration, update dates in headers > - Merge > - Initial commit Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10230 From dcubed at openjdk.org Fri Sep 16 15:05:42 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Sep 2022 15:05:42 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v3] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 09:28:38 GMT, Kevin Walls wrote: >> Test update to cope with heap size changing (shrinking) in the early life of the test app. >> >> A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. >> Recognising a shrinking heap and retrying resolves this. >> >> (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Clarify that loop is for checking heap not changing. Exception if continually changing. Any chance this PR will integrate sometime today? We're still getting serviceability/tmtools/jstat/GcTest01.java failures in Tier7 and I don't want to ProblemList it if the fix is going in soon... ------------- PR: https://git.openjdk.org/jdk/pull/10218 From stuefe at openjdk.org Fri Sep 16 15:06:11 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 16 Sep 2022 15:06:11 GMT Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy Message-ID: Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd. The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader. Also, the tests were expanded to test the display of empty loaders and empty parent loaders. Thanks to @dholmes-ora for finding this bug. ------------- Commit messages: - JDK-8293156-Dcmd-VM.classloaders-fails-to-print-the-full-hierarchy Changes: https://git.openjdk.org/jdk/pull/10312/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10312&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293156 Stats: 145 lines in 2 files changed: 97 ins; 24 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/10312.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10312/head:pull/10312 PR: https://git.openjdk.org/jdk/pull/10312 From kevinw at openjdk.org Fri Sep 16 16:59:10 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 16 Sep 2022 16:59:10 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v4] In-Reply-To: References: Message-ID: > Test update to cope with heap size changing (shrinking) in the early life of the test app. > > A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. > Recognising a shrinking heap and retrying resolves this. > > (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Remove else. Add comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10218/files - new: https://git.openjdk.org/jdk/pull/10218/files/7a203f58..b4f08a07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10218&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10218&range=02-03 Stats: 15 lines in 1 file changed: 8 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10218.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10218/head:pull/10218 PR: https://git.openjdk.org/jdk/pull/10218 From kevinw at openjdk.org Fri Sep 16 16:59:11 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 16 Sep 2022 16:59:11 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v3] In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 05:50:32 GMT, Serguei Spitsyn wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> Clarify that loop is for checking heap not changing. Exception if continually changing. > > test/hotspot/jtreg/serviceability/tmtools/jstat/utils/GcProvoker.java line 76: > >> 74: System.gc(); >> 75: continue; >> 76: } else { > > In fact, the `else-statement` is not needed here because the `if-statement` is ended with `continue`. > At least, this looks confusing to me. OK sure, just updated to remove else, and add a comment which may help. ------------- PR: https://git.openjdk.org/jdk/pull/10218 From kevinw at openjdk.org Fri Sep 16 17:00:35 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 16 Sep 2022 17:00:35 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v3] In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 09:28:38 GMT, Kevin Walls wrote: >> Test update to cope with heap size changing (shrinking) in the early life of the test app. >> >> A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. >> Recognising a shrinking heap and retrying resolves this. >> >> (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Clarify that loop is for checking heap not changing. Exception if continually changing. OK, just updated to address the needless else. It should be clear that this loop is only to give it a couple of tries to fetch the eden as a fraction, retrying if the heap is shrinking. The previous allocations and System.gc calls being in the loop does not appear necessary. This currently always causes an allocation as far as I can see in testing, including with the params that have caused failures. This change does not address that the whole percentage of heap/memory is kind of strange and maybe unnecessary. If there are future problems, maybe we just allocate eden size in bytes instead, but for now I'd like to go ahead with the change here. ------------- PR: https://git.openjdk.org/jdk/pull/10218 From dcubed at openjdk.org Fri Sep 16 18:06:43 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Sep 2022 18:06:43 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v4] In-Reply-To: References: Message-ID: <-uir9p4SAsgNPyUdhv90qLyAJVjaJ5T7yclwwOO4Wyw=.16f0f02b-7274-46cc-a6c3-f1cbe1f95512@github.com> On Fri, 16 Sep 2022 16:59:10 GMT, Kevin Walls wrote: >> Test update to cope with heap size changing (shrinking) in the early life of the test app. >> >> A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. >> Recognising a shrinking heap and retrying resolves this. >> >> (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove else. Add comment. I'm good with the changes. Thanks for adding the retry when we observe the heap shrinking. It's not clear what kind of testing has already been done: - JDK-8293218 failures have been seen in Tier[78]. - JDK-8293564 failures have been seen in Tier7. - Both tests also run in Tier[13]. I recommend doing Tier1 testing and then use that build-ID for Tier3 and Tier7 testing. The tests also run in Tier[456] testing, but I think you can skip those. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/10218 From amenkov at openjdk.org Fri Sep 16 23:31:11 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 16 Sep 2022 23:31:11 GMT Subject: RFR: 8285383: vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java failed with "exit code: 96" Message-ID: The test does not work as described in the test summary. It supposed to redefine test class from ClassLoad/ClassFileLoadHook/ClassPrepare/ClassFileLoadHook callbacks and then suspend the thread and do PopFrame, but actually it does a single redefinition from ClassPrepare. Redefinition from ClassLoad never happens, redefinition from ClassFileLoadHook is commented out. Actually the scenario is not good at all. ClassLoad, ClassPrepare and ClassFileLoadHook events are wrong places to redefine classes. When we redefine a class and try to redefine it again from ClassLoad we actually cannot redefine it. 2nd (3rd, etc.) redefinition should complete before the 1st one, and 2nd version of the class becomes obsolete immediately. ClassFileLoadHook can be used to replace class bytes, but it should return new class bytes via parameters instead of calling redefineClasses. Testing for PopFrame does not add any value. With the scenario all redefinition happen before the test object is created, so this PopFrame has nothing to do with class redefinition. Class redefinition when some methods of the class are executed is covered by other tests from vmTestbase/nsk/jvmti/scenarios/hotswap ------------- Commit messages: - removed the test Changes: https://git.openjdk.org/jdk/pull/10318/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10318&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285383 Stats: 735 lines in 8 files changed: 0 ins; 735 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10318.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10318/head:pull/10318 PR: https://git.openjdk.org/jdk/pull/10318 From alanb at openjdk.org Sat Sep 17 08:41:19 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 17 Sep 2022 08:41:19 GMT Subject: RFR: 8289610: Degrade Thread.stop [v4] In-Reply-To: References: Message-ID: > Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. > > Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. > > To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. > > The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge - Updates to Java Thread Primitive Deprecation page - Repalce "it" with "victim thread" - Merge - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop - become -> became in javadoc - Merge - Remove stopThread permission from RuntimePermission table, exclude jshell tests - Deprecate for removal - Next iteration, update dates in headers - ... and 2 more: https://git.openjdk.org/jdk/compare/214db2f4...93806f99 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10230/files - new: https://git.openjdk.org/jdk/pull/10230/files/a00f38a2..93806f99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10230&range=02-03 Stats: 5663 lines in 389 files changed: 1218 ins; 1745 del; 2700 mod Patch: https://git.openjdk.org/jdk/pull/10230.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10230/head:pull/10230 PR: https://git.openjdk.org/jdk/pull/10230 From kevinw at openjdk.org Sat Sep 17 09:59:06 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Sat, 17 Sep 2022 09:59:06 GMT Subject: RFR: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" [v4] In-Reply-To: References: Message-ID: <38j8Q4RVC38tiXogEtfIQpXojpzAq_ypz-BXoAv7LlA=.17bfafb6-c944-4225-9430-1706bd29ac00@github.com> On Fri, 16 Sep 2022 16:59:10 GMT, Kevin Walls wrote: >> Test update to cope with heap size changing (shrinking) in the early life of the test app. >> >> A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. >> Recognising a shrinking heap and retrying resolves this. >> >> (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove else. Add comment. OK thanks for all the comments, this is looking like a reasonable robustness improvement, and I can't trigger a failure. Will integrate. ------------- PR: https://git.openjdk.org/jdk/pull/10218 From kevinw at openjdk.org Sat Sep 17 09:59:07 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Sat, 17 Sep 2022 09:59:07 GMT Subject: Integrated: 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" In-Reply-To: References: Message-ID: On Thu, 8 Sep 2022 09:56:05 GMT, Kevin Walls wrote: > Test update to cope with heap size changing (shrinking) in the early life of the test app. > > A change in GC timing affects this test which reads eden size and heap size. Both eden and heap are likely to shrink initially for this test. Failures were that heap size shrank after reading eden size, such that eden appeared to be >100% of heap. > Recognising a shrinking heap and retrying resolves this. > > (Re-ordering to read heap size then eden would be enough to make the check in provokeGc work. But it would allocate sometimes a very small fraction of the heap, which is not the intent.) This pull request has now been integrated. Changeset: cfd44bb2 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/cfd44bb2cd4f2fdbfc15a7a76757a92c0a557439 Stats: 27 lines in 2 files changed: 19 ins; 3 del; 5 mod 8293218: serviceability/tmtools/jstat/GcNewTest.java fails with "Error in the percent calculation" 8293564: serviceability/tmtools/jstat/GcTest01.java fails with "Error in the percent calculation" Reviewed-by: sspitsyn, lmesnik, dcubed ------------- PR: https://git.openjdk.org/jdk/pull/10218 From dcubed at openjdk.org Sat Sep 17 15:01:55 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 17 Sep 2022 15:01:55 GMT Subject: RFR: 8285383: vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java failed with "exit code: 96" In-Reply-To: References: Message-ID: On Fri, 16 Sep 2022 23:24:29 GMT, Alex Menkov wrote: > The test does not work as described in the test summary. > It supposed to redefine test class from ClassLoad/ClassFileLoadHook/ClassPrepare/ClassFileLoadHook callbacks and then suspend the thread and do PopFrame, but actually it does a single redefinition from ClassPrepare. Redefinition from ClassLoad never happens, redefinition from ClassFileLoadHook is commented out. > > Actually the scenario is not good at all. > ClassLoad, ClassPrepare and ClassFileLoadHook events are wrong places to redefine classes. > When we redefine a class and try to redefine it again from ClassLoad we actually cannot redefine it. 2nd (3rd, etc.) redefinition should complete before the 1st one, and 2nd version of the class becomes obsolete immediately. > ClassFileLoadHook can be used to replace class bytes, but it should return new class bytes via parameters instead of calling redefineClasses. > Testing for PopFrame does not add any value. With the scenario all redefinition happen before the test object is created, so this PopFrame has nothing to do with class redefinition. > Class redefinition when some methods of the class are executed is covered by other tests from vmTestbase/nsk/jvmti/scenarios/hotswap Probably should have made it clear in the main PR comment that you are deleting a bad test. Thumbs up. This is a trivial fix, but you should wait for a review from a Serviceability team member. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/10318 From lmesnik at openjdk.org Sat Sep 17 15:55:40 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 17 Sep 2022 15:55:40 GMT Subject: RFR: 8285383: vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java failed with "exit code: 96" In-Reply-To: References: Message-ID: <0jUPdRRqFKVCV2PP6htO9bZdQa-rO5MIsG4XZsH-Tqc=.c6839609-3e07-4cac-b2df-9061224f2c46@github.com> On Fri, 16 Sep 2022 23:24:29 GMT, Alex Menkov wrote: > The test does not work as described in the test summary. > It supposed to redefine test class from ClassLoad/ClassFileLoadHook/ClassPrepare/ClassFileLoadHook callbacks and then suspend the thread and do PopFrame, but actually it does a single redefinition from ClassPrepare. Redefinition from ClassLoad never happens, redefinition from ClassFileLoadHook is commented out. > > Actually the scenario is not good at all. > ClassLoad, ClassPrepare and ClassFileLoadHook events are wrong places to redefine classes. > When we redefine a class and try to redefine it again from ClassLoad we actually cannot redefine it. 2nd (3rd, etc.) redefinition should complete before the 1st one, and 2nd version of the class becomes obsolete immediately. > ClassFileLoadHook can be used to replace class bytes, but it should return new class bytes via parameters instead of calling redefineClasses. > Testing for PopFrame does not add any value. With the scenario all redefinition happen before the test object is created, so this PopFrame has nothing to do with class redefinition. > Class redefinition when some methods of the class are executed is covered by other tests from vmTestbase/nsk/jvmti/scenarios/hotswap Do we have a way to reproduce https://bugs.openjdk.org/browse/JDK-8228404 if the test is removed? ------------- PR: https://git.openjdk.org/jdk/pull/10318 From sspitsyn at openjdk.org Sun Sep 18 09:31:53 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sun, 18 Sep 2022 09:31:53 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions Message-ID: There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. There are a couple of details of this fix to highlight: - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. - Suspending threads in temporary transition is allowed. The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. ------------- Commit messages: - 8293613: need to properly handle and hide tmp VTMS transitions Changes: https://git.openjdk.org/jdk/pull/10321/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293613 Stats: 56 lines in 10 files changed: 49 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10321.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10321/head:pull/10321 PR: https://git.openjdk.org/jdk/pull/10321 From jpai at openjdk.org Sun Sep 18 12:05:10 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 18 Sep 2022 12:05:10 GMT Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port Message-ID: Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616? The test has been intermittently failing with `cannot find a free port after 10 tries`. The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`. Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address. The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free. The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does. Multiple test runs after this change hasn't yet run into the failure. ------------- Commit messages: - 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port Changes: https://git.openjdk.org/jdk/pull/10322/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10322&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8030616 Stats: 7 lines in 3 files changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10322.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10322/head:pull/10322 PR: https://git.openjdk.org/jdk/pull/10322 From jpai at openjdk.org Sun Sep 18 13:08:18 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 18 Sep 2022 13:08:18 GMT Subject: RFR: 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" Message-ID: Can I please get a review of this change which proposes to fix the intermittent failures noted in https://bugs.openjdk.org/browse/JDK-8293657? There are two parts to this fix. One is straightforward fix in the test configuration file where it uses an incompatible cipher suite with the enabled protocols. The details of that are noted in my comment in the JBS https://bugs.openjdk.org/browse/JDK-8293657?focusedCommentId=14524400&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14524400. The fix for that resides solely in `management_ssltest07_ok.properties.in` file. The more curious part was why this specific test configuration is ever passing instead of always failing. That turned out to be a bug in the `sun.management.jmxremote.HostAwareSslSocketFactory`. The (internal implementation detail) in `sun.rmi.transport.tcp.TCPEndpoint` holds a cache of `localEndpoints` which effectively are server and client socket factories that get used when creating the corresponding socket/server sockets. The cache uses a key, whose one component is the `HostAwareSslSocketFactory` instance. This class extends from `javax.rmi.ssl.SslRMIServerSocketFactory` which is where the `equals()` is implemented for the `HostAwareSslSocketFactory` instances. The bug resides in the fact that the current implementation of the `HostAwareSslSocketFactory` constructor doesn't pass to its `super` the `enabledCipherSuites`, `enabledProtocols` and `needClientAuth` values with which the `HostAwareSslSocketFactory` was constructed with. Instead it stores these values as private memb ers and thus the `SslRMIServerSocketFactory` has its own version of these members as `null`. The `SslRMIServerSocketFactory` uses these values in its `equals` implementation and thus ends up computing a wrong output from the `equals` call. This ultimately ends up with the (internal) `TCPEndpoint` returning an incorrect (server) socket factory that gets used during the client/server communication. What this means is that the restrictions imposed on enabled protocols and enabled cipher suites in `management_ssltest07_ok.properties.in` aren't taken into account and instead a different set of (lenient) configurations for these attributes gets used (because of the cached socket factory constructed for a previous run of a different test configuration). The commit in this PR fixes the `HostAwareSslSocketFactory` to correctly pass to its `super` the enabled protocols, enabled cipher suites and the client auth mode, instead of saving that state (only) in `HostAwareSslSocketFactory`. Additionally the commit removes this test from the problem listing. ------------- Commit messages: - 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" Changes: https://git.openjdk.org/jdk/pull/10323/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10323&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293657 Stats: 16 lines in 3 files changed: 1 ins; 7 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/10323.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10323/head:pull/10323 PR: https://git.openjdk.org/jdk/pull/10323 From msheppar at openjdk.org Sun Sep 18 22:03:38 2022 From: msheppar at openjdk.org (Mark Sheppard) Date: Sun, 18 Sep 2022 22:03:38 GMT Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai wrote: > Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616? > > The test has been intermittently failing with `cannot find a free port after 10 tries`. The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`. > > Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address. > > The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free. > > The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does. > > Multiple test runs after this change hasn't yet run into the failure. While the change is reasonable, I?m not sure about your rationale. The contributing factors to the intermittent failures are due to the flawed ephemeral port allocation strategy, that incurs a race condition to use the selected ephemeral port within the test before the OS uses it. So from the time that the port has been acquired, then released via the autoclose of the serversocket, and then reused in the test, it is possible that the OS may have also relocated that ephemeral port. This change doesn?t alter this race condition. The are a number of significant attributes to the port allocation strategy: The port allocation strategy acquires an ephemeral port from the OS while binding it to a ServerSocket. The significance of ServerSocket is it surreptitiously sets SO_REUSEADDR socket option on the server socket (Net.socket0() == Java_sun_nio_ch_Net_socket0). The fact that SO_REUSEADDR is set is important in this scenario. The objective with using SO_REUSEADDR on a serversocket is allow for efficient server restarts due to a shutdown for whatever reason. With SO_REUSEADDR set the restarting server, which typically uses a well known port, won?t get a BindException, while the port may still be associated with the ?terminating? server i.e. it may not have been fully released by the OS, for general reuse. Thus, this has a number of favourable consequences with your proposed change, as the address binding is the same as that used for acquiring the port, so it is essential a ?server restart scenario?, albeit with an Ephemeral port. As such, there still exists the possibility that the port will be reused by the OS, where conditions of heavy ephemeral port allocation is occurring. As such, the change may reduce the rate of intermittent failure, but it won?t solve the issue fully. There is a possibility that it may increase the rate of failure as many network tests now use Loopback address rather than the local host address i.e. the primary configured IP address. This will depend on the load on a test system, and the amount of concurrently executing network tests, with the corresponding high volume of ephemeral port allocation. Nonetheless, it is a reasonable change, provided there is no subtle change in test semantics. I think it will ameliorate the intermittent failures. ------------- PR: https://git.openjdk.org/jdk/pull/10322 From jpai at openjdk.org Mon Sep 19 00:44:40 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 Sep 2022 00:44:40 GMT Subject: RFR: 8030616: sun/management/jmxremote/bootstrap/RmiBootstrapTest fails intermittently with cannot find a free port In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai wrote: > Can I please get a review of this test only change which proposes to fix the recent intermittent failures in `RmiBootstrapTest` reported in https://bugs.openjdk.org/browse/JDK-8030616? > > The test has been intermittently failing with `cannot find a free port after 10 tries`. The tests uses the `jdk.test.lib.Utils.getFreePort()` utility method to get a free port to use in the tests. That port is then used to create and bind a JMX connector server. The issue resides in the fact that the `getFreePort` utility uses loopback address to identify a free port, whereas the JMX connector server uses that identified port to bind to a non-loopback address - there's logic in `sun.rmi.transport.tcp.TCPEndpoint` line 117 which calls `InetAddress.getLocalHost()` which can and does return a non-loopback address. This effectively means that the port that was identified as free (on loopback) may not really be free on (some other address) and a subsequent attempt to bind against it by the connector server will end up with a `BindException`. > > Data collected in failures on the CI system has shown that this is indeed the case and the port that was chosen (for loopback) as free was already used by another process on a different address. The test additionally has logic to attempt retries upto a maximum of 10 times to find a new free port on such `BindException`. Turns out the next free port (on loopback) returned by `jdk.test.lib.Utils.getFreePort()` is incremental and it so happens that the systems where this failed had a process listening on a range of 10 to 12 ports, so these too ended up with `BindException` when the JMX connector server used that port for a different address. > > The commit here makes sure that the JMX connector server in the test is now configured to loopback address as the address to bind to. That way the test uses the correct address (loopback) on which the port was free. > > The commit also has a change to the javadoc of the test utility `jdk.test.lib.Utils.getFreePort()` to clarify that it returns a free port on loopback address. This now matches what the implementation of that method does. > > Multiple test runs after this change hasn't yet run into the failure. Hello Mark, this specific change is merely meant to address the specific test case which is running into this problem. As you note the free port identification logic has and will continue to have the race condition. It will be applicable to all tests that use that utility. This change doesn't propose to do anything for such cases. However, in this specific case it wasn't the race condition which was causing the issue. Data that was collected from those failures shows that the issue was because of using the wrong address while trying to bind the free port that was identified. The data collected from these failed runs has been added to the linked JBS issue as a comment to show the port usage. ------------- PR: https://git.openjdk.org/jdk/pull/10322 From aturbanov at openjdk.org Mon Sep 19 10:59:50 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 19 Sep 2022 10:59:50 GMT Subject: RFR: 8293879: Remove unnecessary castings in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 20:49:14 GMT, Andrey Turbanov wrote: > Redundant castings make code harder to read. > Found them by IntelliJ IDEA. > I tried to choose only casts which are definitely safe to remove. > Most generification was done in [JDK-8241618](https://bugs.openjdk.org/browse/JDK-8241618), but casts weren't removed. Thank you for review! ------------- PR: https://git.openjdk.org/jdk/pull/10295 From aturbanov at openjdk.org Mon Sep 19 11:02:51 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 19 Sep 2022 11:02:51 GMT Subject: Integrated: 8293879: Remove unnecessary castings in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 20:49:14 GMT, Andrey Turbanov wrote: > Redundant castings make code harder to read. > Found them by IntelliJ IDEA. > I tried to choose only casts which are definitely safe to remove. > Most generification was done in [JDK-8241618](https://bugs.openjdk.org/browse/JDK-8241618), but casts weren't removed. This pull request has now been integrated. Changeset: 5725a93c Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/5725a93c078dac9775ccef04f3624647a8d38e83 Stats: 261 lines in 75 files changed: 0 ins; 8 del; 253 mod 8293879: Remove unnecessary castings in jdk.hotspot.agent Reviewed-by: lmesnik, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/10295 From sspitsyn at openjdk.org Mon Sep 19 17:57:58 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 19 Sep 2022 17:57:58 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v2] In-Reply-To: References: Message-ID: > There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. > > There are a couple of details of this fix to highlight: > - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. > - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. > - Suspending threads in temporary transition is allowed. > > The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: some refactoring/renaming from Alan ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10321/files - new: https://git.openjdk.org/jdk/pull/10321/files/af80743a..7ff72d7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=00-01 Stats: 53 lines in 5 files changed: 27 ins; 12 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/10321.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10321/head:pull/10321 PR: https://git.openjdk.org/jdk/pull/10321 From cjplummer at openjdk.org Mon Sep 19 19:01:50 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 19 Sep 2022 19:01:50 GMT Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy In-Reply-To: References: Message-ID: On Fri, 16 Sep 2022 14:55:42 GMT, Thomas Stuefe wrote: > Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd. > > The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader. > > Also, the tests were expanded to test the display of empty loaders and empty parent loaders. > > Thanks to @dholmes-ora for finding this bug. src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp line 187: > 185: } > 186: > 187: void print_with_childs(outputStream* st, BranchTracker& branchtracker, I know this isn't part of your changes, but the plural of child is children, not childs. However, I think child_nodes would probably be best here. src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp line 320: > 318: return (loader_klass() != NULL) && (loader_klass() == target_node->loader_klass()) && > 319: ((loader_name_oop() == NULL && target_node->loader_name_oop() == NULL) || > 320: (::strcmp(loader_name(), target_node->loader_name()) == 0)); This is hard to parse. I think using if/else statements would be cleaner. test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderHierarchyTest.java line 124: > 122: output.shouldContain(" +-- \"Kevin\", ClassLoaderHierarchyTest$TestClassLoader"); > 123: output.shouldContain(" +-- ClassLoaderHierarchyTest$TestClassLoader"); > 124: output.shouldContain(" | +-- \"Bill\", ClassLoaderHierarchyTest$TestClassLoader"); Can you test using one long string, and do the same for each section below? I think embedding \\R as the newline character should work on all platforms. If you run into unforeseen issues, then don't worry about. ------------- PR: https://git.openjdk.org/jdk/pull/10312 From sspitsyn at openjdk.org Mon Sep 19 19:18:57 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 19 Sep 2022 19:18:57 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: > There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. > > There are a couple of details of this fix to highlight: > - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. > - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. > - Suspending threads in temporary transition is allowed. > > The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fixed typo in VirtualThread.c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10321/files - new: https://git.openjdk.org/jdk/pull/10321/files/7ff72d7f..551d8d32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10321.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10321/head:pull/10321 PR: https://git.openjdk.org/jdk/pull/10321 From amenkov at openjdk.org Mon Sep 19 20:14:57 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 19 Sep 2022 20:14:57 GMT Subject: RFR: 8285383: vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java failed with "exit code: 96" In-Reply-To: <0jUPdRRqFKVCV2PP6htO9bZdQa-rO5MIsG4XZsH-Tqc=.c6839609-3e07-4cac-b2df-9061224f2c46@github.com> References: <0jUPdRRqFKVCV2PP6htO9bZdQa-rO5MIsG4XZsH-Tqc=.c6839609-3e07-4cac-b2df-9061224f2c46@github.com> Message-ID: On Sat, 17 Sep 2022 15:53:27 GMT, Leonid Mesnik wrote: > Do we have a way to reproduce https://bugs.openjdk.org/browse/JDK-8228404 if the test is removed? It's hard to consider this test as a reproducer for JDK-8228404 There were 3 "bad oop found" failures - July 2019 (jdk 14), Feb 2020 (jdk 15) and Apr 2022 (jdk 19) And 1 Kitchensink24HStress.java failure (Jan 2020 (jdk 14)) ------------- PR: https://git.openjdk.org/jdk/pull/10318 From cjplummer at openjdk.org Mon Sep 19 20:46:10 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 19 Sep 2022 20:46:10 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 19:18:57 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fixed typo in VirtualThread.c src/hotspot/share/prims/jvmtiEnvBase.cpp line 713: > 711: if (!jt->is_in_tmp_VTMS_transition()) { > 712: jvf = check_and_skip_hidden_frames(jt, jvf); > 713: } I think this comment needs some help. It's hard to match it up with what the code is doing. I think you are saying you want to avoid skipping hidden frames when in transition, although if that's the case, it's not clear to me why not skipping is ok. Also is skipping (or not skipping) ok regardless of the JvmtiEnvBase::is_cthread_with_continuation() result? src/hotspot/share/prims/jvmtiExport.cpp line 1055: > 1053: if (JavaThread::current()->is_in_tmp_VTMS_transition()) { > 1054: return false; > 1055: } You mentioned this in the PR description. However, it's not clear to me why this is ok. Also, it should be commented. Same thing for changes in JvmtiExport::post_class_load() and JvmtiExport::post_class_prepare(). src/hotspot/share/runtime/javaThread.cpp line 1174: > 1172: #if INCLUDE_JVMTI > 1173: // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks. > 1174: assert(!is_in_non_tmp_VTMS_transition(), "no suspend allowed in VTMS transition"); IMHO, a non tmp VTMS transition should be considered a type of VTMS transition, so the assert check here does not really match the assert text. Also see my related comments below on naming and use of these flags and APIs. src/hotspot/share/runtime/javaThread.hpp line 650: > 648: void set_is_in_VTMS_transition(bool val); > 649: bool is_in_tmp_VTMS_transition() const { return _is_in_tmp_VTMS_transition; } > 650: void toggle_is_in_tmp_VTMS_transition() { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; }; The naming of the flags does not match up with the naming of the APIs, which is confusing. An API named is_in_VTMS_transition() should return _is_in_VTMS_transition. I think part of problem is that _is_in_VTMS_transition is not a superset of _is_in_tmp_VTMS_transition. The flags are never both set true, although both can be false. Maybe this should be changed to make it an invariant that if _is_in_tmp_VTMS_transit is true, then _is_in_tmp_VTMS_transition is true. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From lmesnik at openjdk.org Mon Sep 19 22:07:42 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 19 Sep 2022 22:07:42 GMT Subject: RFR: 8285383: vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java failed with "exit code: 96" In-Reply-To: References: Message-ID: <2ldtpXn_nDCVIsE6CE80cdOT9eJN4SMcxWwxfX4w9qs=.84e47c26-a42d-4f01-8d9b-5c096ebc71b0@github.com> On Fri, 16 Sep 2022 23:24:29 GMT, Alex Menkov wrote: > The fix deletes bad test. > > Background: > The test does not work as described in the test summary. > It supposed to redefine test class from ClassLoad/ClassFileLoadHook/ClassPrepare/ClassFileLoadHook callbacks and then suspend the thread and do PopFrame, but actually it does a single redefinition from ClassPrepare. Redefinition from ClassLoad never happens, redefinition from ClassFileLoadHook is commented out. > > Actually the scenario is not good at all. > ClassLoad, ClassPrepare and ClassFileLoadHook events are wrong places to redefine classes. > When we redefine a class and try to redefine it again from ClassLoad we actually cannot redefine it. 2nd (3rd, etc.) redefinition should complete before the 1st one, and 2nd version of the class becomes obsolete immediately. > ClassFileLoadHook can be used to replace class bytes, but it should return new class bytes via parameters instead of calling redefineClasses. > Testing for PopFrame does not add any value. With the scenario all redefinition happen before the test object is created, so this PopFrame has nothing to do with class redefinition. > Class redefinition when some methods of the class are executed is covered by other tests from vmTestbase/nsk/jvmti/scenarios/hotswap Looks good ------------- Marked as reviewed by lmesnik (Reviewer). PR: https://git.openjdk.org/jdk/pull/10318 From lmesnik at openjdk.org Tue Sep 20 00:28:16 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 20 Sep 2022 00:28:16 GMT Subject: RFR: 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume Message-ID: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume ------------- Commit messages: - 8289608: Change com/sun/jdi tests to not use Thread.suspend/resume Changes: https://git.openjdk.org/jdk/pull/10351/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10351&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289607 Stats: 319 lines in 16 files changed: 90 ins; 166 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/10351.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10351/head:pull/10351 PR: https://git.openjdk.org/jdk/pull/10351 From lmesnik at openjdk.org Tue Sep 20 00:36:38 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 20 Sep 2022 00:36:38 GMT Subject: RFR: 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume [v2] In-Reply-To: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: > The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. > Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. > > Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: revert changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10351/files - new: https://git.openjdk.org/jdk/pull/10351/files/8f660693..356ee078 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10351&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10351&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10351.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10351/head:pull/10351 PR: https://git.openjdk.org/jdk/pull/10351 From stuefe at openjdk.org Tue Sep 20 05:37:44 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 20 Sep 2022 05:37:44 GMT Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy [v2] In-Reply-To: References: Message-ID: > Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd. > > The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader. > > Also, the tests were expanded to test the display of empty loaders and empty parent loaders. > > Thanks to @dholmes-ora for finding this bug. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: cjplummer feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10312/files - new: https://git.openjdk.org/jdk/pull/10312/files/0f5de199..224df5fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10312&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10312&range=00-01 Stats: 20 lines in 1 file changed: 10 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/10312.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10312/head:pull/10312 PR: https://git.openjdk.org/jdk/pull/10312 From stuefe at openjdk.org Tue Sep 20 05:37:45 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 20 Sep 2022 05:37:45 GMT Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy In-Reply-To: References: Message-ID: On Fri, 16 Sep 2022 14:55:42 GMT, Thomas Stuefe wrote: > Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd. > > The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader. > > Also, the tests were expanded to test the display of empty loaders and empty parent loaders. > > Thanks to @dholmes-ora for finding this bug. Hi @plummercj , thanks for your Review. I worked most of your your feedback. .. Thomas ------------- PR: https://git.openjdk.org/jdk/pull/10312 From stuefe at openjdk.org Tue Sep 20 05:37:48 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 20 Sep 2022 05:37:48 GMT Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy [v2] In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 18:45:35 GMT, Chris Plummer wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> cjplummer feedback > > src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp line 187: > >> 185: } >> 186: >> 187: void print_with_childs(outputStream* st, BranchTracker& branchtracker, > > I know this isn't part of your changes, but the plural of child is children, not childs. However, I think child_nodes would probably be best here. Fixed > src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp line 320: > >> 318: return (loader_klass() != NULL) && (loader_klass() == target_node->loader_klass()) && >> 319: ((loader_name_oop() == NULL && target_node->loader_name_oop() == NULL) || >> 320: (::strcmp(loader_name(), target_node->loader_name()) == 0)); > > This is hard to parse. I think using if/else statements would be cleaner. Fixed > test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderHierarchyTest.java line 124: > >> 122: output.shouldContain(" +-- \"Kevin\", ClassLoaderHierarchyTest$TestClassLoader"); >> 123: output.shouldContain(" +-- ClassLoaderHierarchyTest$TestClassLoader"); >> 124: output.shouldContain(" | +-- \"Bill\", ClassLoaderHierarchyTest$TestClassLoader"); > > Can you test using one long string, and do the same for each section below? I think embedding \\R as the newline character should work on all platforms. If you run into unforeseen issues, then don't worry about. I'd prefer to leave it this way. I tried what you suggested before, but the output can contain trailing spaces in the branchwork of the tree - that is a byproduct of the indentation writer (the class writing the branches) and not easy to fix. I wanted the test to be somewhat tolerant against minor future changes in how the tree is printed. ------------- PR: https://git.openjdk.org/jdk/pull/10312 From dholmes at openjdk.org Tue Sep 20 05:42:57 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Sep 2022 05:42:57 GMT Subject: RFR: 8289610: Degrade Thread.stop [v4] In-Reply-To: References: Message-ID: On Sat, 17 Sep 2022 08:41:19 GMT, Alan Bateman wrote: >> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. >> >> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. >> >> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. >> >> The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge > - Updates to Java Thread Primitive Deprecation page > - Repalce "it" with "victim thread" > - Merge > - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop > - become -> became in javadoc > - Merge > - Remove stopThread permission from RuntimePermission table, exclude jshell tests > - Deprecate for removal > - Next iteration, update dates in headers > - ... and 2 more: https://git.openjdk.org/jdk/compare/4a31f682...93806f99 Hi Alan, Good to see this finally become non-functional but as long as the debugger/JVMTI can trigger throwing an async ThreadDeath then I have to question the potential change in behaviour introduced by removing all the `catch (ThreadDeath td)` logic in various places. src/java.base/share/classes/java/io/FilterOutputStream.java line 195: > 193: // evaluate possible precedence of flushException over closeException > 194: if ((flushException instanceof ThreadDeath) && > 195: !(closeException instanceof ThreadDeath)) { If the ThreadDeath originates from the debugger then this is now a change in behaviour. src/java.base/share/classes/java/lang/Shutdown.java line 132: > 130: if (hook != null) hook.run(); > 131: } catch (Throwable t) { > 132: // ignore Again change of behaviour if TD originates from debugger. src/java.base/share/classes/java/lang/ThreadDeath.java line 30: > 28: /** > 29: * An instance of {@code ThreadDeath} was originally specified to be thrown > 30: * by a victim thread when "stopped" with {@link Thread#stop()}. Should this have always mentioned the possibility of TD coming from a debugger as well? src/java.base/share/classes/java/lang/ThreadGroup.java line 700: > 698: ueh.uncaughtException(t, e); > 699: } else { > 700: System.err.print("Exception in thread \"" + t.getName() + "\" "); Again change in behaviour. src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 37: > 35: stop a thread removed? > 36:

Because it was inherently unsafe. Stopping a thread caused it to > 37: unlock all the monitors that it had locked. (The monitors were Just an aside but this rationale was always a significant under-statement as async-exceptions are inherently unsafe even if no concurrency or monitors are involved. src/java.desktop/macosx/classes/sun/lwawt/LWToolkit.java line 170: > 168: } > 169: } > 170: } catch (ThreadDeath td) { Again change in behaviour src/java.desktop/share/classes/java/awt/EventDispatchThread.java line 205: > 203: eq.dispatchEvent(event); > 204: } > 205: catch (ThreadDeath death) { Again change in behaviour. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From alanb at openjdk.org Tue Sep 20 06:05:14 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 Sep 2022 06:05:14 GMT Subject: RFR: 8289610: Degrade Thread.stop [v4] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 04:21:39 GMT, David Holmes wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: >> >> - Merge >> - Updates to Java Thread Primitive Deprecation page >> - Repalce "it" with "victim thread" >> - Merge >> - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop >> - become -> became in javadoc >> - Merge >> - Remove stopThread permission from RuntimePermission table, exclude jshell tests >> - Deprecate for removal >> - Next iteration, update dates in headers >> - ... and 2 more: https://git.openjdk.org/jdk/compare/26f404b2...93806f99 > > src/java.base/share/classes/java/io/FilterOutputStream.java line 195: > >> 193: // evaluate possible precedence of flushException over closeException >> 194: if ((flushException instanceof ThreadDeath) && >> 195: !(closeException instanceof ThreadDeath)) { > > If the ThreadDeath originates from the debugger then this is now a change in behaviour. > Good to see this finally become non-functional but as long as the debugger/JVMTI can trigger throwing an async ThreadDeath then I have to question the potential change in behaviour introduced by removing all the `catch (ThreadDeath td)` logic in various places. I've gone through a few times too and concluded it would be better to remove these untestable code paths. The debugger scenario is more like what used to be Thread.stop(Throwable). It can be used to throw any exception or error, e.g. ask the debugger to throw IllegalArgumentException or SQLException when I'm at this breakpoint so I can see how the code behaves. Yes, the user could ask the debugger to throw java.lang.ThreadDeath when prompted but it's not really interesting now because code won't get this error outside of a debugger. We could leave the special handing but we have no way to test is and we'll need to the remove the special handling when TD is removed. As a general point, the special casing of TD is a bit inconsistent and more likely to be seen in older code rather newer code. A static analysis of 24M classes found very few usages in 3rd libraries. > Should this have always mentioned the possibility of TD coming from a debugger as well? The debugger can cause any error or exception to be thrown so I don't think we should put anything in the TD spec about this. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From sspitsyn at openjdk.org Tue Sep 20 11:59:58 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Sep 2022 11:59:58 GMT Subject: RFR: 8285383: vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java failed with "exit code: 96" In-Reply-To: References: Message-ID: On Fri, 16 Sep 2022 23:24:29 GMT, Alex Menkov wrote: > The fix deletes bad test. > > Background: > The test does not work as described in the test summary. > It supposed to redefine test class from ClassLoad/ClassFileLoadHook/ClassPrepare/ClassFileLoadHook callbacks and then suspend the thread and do PopFrame, but actually it does a single redefinition from ClassPrepare. Redefinition from ClassLoad never happens, redefinition from ClassFileLoadHook is commented out. > > Actually the scenario is not good at all. > ClassLoad, ClassPrepare and ClassFileLoadHook events are wrong places to redefine classes. > When we redefine a class and try to redefine it again from ClassLoad we actually cannot redefine it. 2nd (3rd, etc.) redefinition should complete before the 1st one, and 2nd version of the class becomes obsolete immediately. > ClassFileLoadHook can be used to replace class bytes, but it should return new class bytes via parameters instead of calling redefineClasses. > Testing for PopFrame does not add any value. With the scenario all redefinition happen before the test object is created, so this PopFrame has nothing to do with class redefinition. > Class redefinition when some methods of the class are executed is covered by other tests from vmTestbase/nsk/jvmti/scenarios/hotswap LGTM Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10318 From smarks at openjdk.org Tue Sep 20 16:32:54 2022 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 20 Sep 2022 16:32:54 GMT Subject: RFR: 8289610: Degrade Thread.stop [v4] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 06:00:14 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/io/FilterOutputStream.java line 195: >> >>> 193: // evaluate possible precedence of flushException over closeException >>> 194: if ((flushException instanceof ThreadDeath) && >>> 195: !(closeException instanceof ThreadDeath)) { >> >> If the ThreadDeath originates from the debugger then this is now a change in behaviour. > >> Good to see this finally become non-functional but as long as the debugger/JVMTI can trigger throwing an async ThreadDeath then I have to question the potential change in behaviour introduced by removing all the `catch (ThreadDeath td)` logic in various places. > > I've gone through this a few times too and concluded it would be better to remove these untestable code paths. The debugger scenario is more like what used to be Thread.stop(Throwable). It can be used to throw any exception or error, e.g. ask the debugger to throw IllegalArgumentException or SQLException when I'm at this breakpoint so I can see how the code behaves. Yes, the user could ask the debugger to throw java.lang.ThreadDeath when prompted but it's not really interesting now because code won't get this error outside of a debugger. We could leave the special handing but we have no way to test is and we'll need to the remove the special handling when TD is removed. As a general point, the special casing of TD is a bit inconsistent and more likely to be seen in older code rather newer code. A static analysis of 24M classes found very few usages in 3rd party libraries. I agree with Alan on this. First, use and handling of `ThreadDeath` is quite rare; see my [analysis](https://bugs.openjdk.org/browse/JDK-8289610?focusedCommentId=14523723&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14523723) of the corpus search results in the bug report. Second, while this does change the behavior in the debugger case, I'm hard-pressed to see how anybody is _relying_ on such behavior. And maybe somebody somewhere is indeed relying on this behavior, but it doesn't seem to me this behavior is guaranteed by any specifications. A more likely way that programs could observe changes in `ThreadDeath` handling occurs when programs throw `ThreadDeath` explicitly, that is, not using `Thread.stop`. This does seem to occur infrequently "in the wild" (we'll fix the jshell case). The point of throwing `ThreadDeath` explicitly is to take advantage of special-case handling of `ThreadDeath` that might occur higher in the call stack. Such special-casing was at one time an accepted exception handing idiom, but it's essentially disused. I don't think the JDK needs to continue to support this old idiom. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From cjplummer at openjdk.org Tue Sep 20 18:06:58 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Sep 2022 18:06:58 GMT Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy [v2] In-Reply-To: References: Message-ID: <7xGhj4G6VBdSVEF1omY1zgAZa3DqSRmeK6QTly9xrTU=.a4a60db6-3c1d-4b1e-9bb5-e591c6d1a5c2@github.com> On Tue, 20 Sep 2022 05:29:12 GMT, Thomas Stuefe wrote: >> src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp line 187: >> >>> 185: } >>> 186: >>> 187: void print_with_childs(outputStream* st, BranchTracker& branchtracker, >> >> I know this isn't part of your changes, but the plural of child is children, not childs. However, I think child_nodes would probably be best here. > > Fixed It looks like there are a couple more references to "childs" still present. ------------- PR: https://git.openjdk.org/jdk/pull/10312 From cjplummer at openjdk.org Tue Sep 20 18:10:54 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Sep 2022 18:10:54 GMT Subject: RFR: 8293143: Workaround for JDK-8292217 when doing "step over" of bytecode with unresolved cp referernce In-Reply-To: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> References: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> Message-ID: On Wed, 31 Aug 2022 00:25:20 GMT, Chris Plummer wrote: > There is a workaround we can do for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) for the use case where a step over or step out is being done. This workaround can't be made to also work for the step into case. From [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) > > "There is a workaround that fixes this issue when doing a STEP_OVER or STEP_OUT. Rather than the debug agent checking if it has enabled JVMTI single stepping, instead it checks some fields in the ThreadNode that say if single stepping is pending, and it is for a STEP_INTO. If it is not STEP_INTO, then it can assume that no StepEvent will occur at the same location and therefor the MethodEntryEvent should not be deferred. So this limits the bug to only happening when doing a STEP_INTO. " Ping! ------------- PR: https://git.openjdk.org/jdk/pull/10091 From amenkov at openjdk.org Tue Sep 20 18:21:09 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 20 Sep 2022 18:21:09 GMT Subject: Integrated: 8285383: vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java failed with "exit code: 96" In-Reply-To: References: Message-ID: On Fri, 16 Sep 2022 23:24:29 GMT, Alex Menkov wrote: > The fix deletes bad test. > > Background: > The test does not work as described in the test summary. > It supposed to redefine test class from ClassLoad/ClassFileLoadHook/ClassPrepare/ClassFileLoadHook callbacks and then suspend the thread and do PopFrame, but actually it does a single redefinition from ClassPrepare. Redefinition from ClassLoad never happens, redefinition from ClassFileLoadHook is commented out. > > Actually the scenario is not good at all. > ClassLoad, ClassPrepare and ClassFileLoadHook events are wrong places to redefine classes. > When we redefine a class and try to redefine it again from ClassLoad we actually cannot redefine it. 2nd (3rd, etc.) redefinition should complete before the 1st one, and 2nd version of the class becomes obsolete immediately. > ClassFileLoadHook can be used to replace class bytes, but it should return new class bytes via parameters instead of calling redefineClasses. > Testing for PopFrame does not add any value. With the scenario all redefinition happen before the test object is created, so this PopFrame has nothing to do with class redefinition. > Class redefinition when some methods of the class are executed is covered by other tests from vmTestbase/nsk/jvmti/scenarios/hotswap This pull request has now been integrated. Changeset: 21008cad Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/21008cad46d53a34715037d1ec1ca53a43a549db Stats: 735 lines in 8 files changed: 0 ins; 735 del; 0 mod 8285383: vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java failed with "exit code: 96" Reviewed-by: dcubed, lmesnik, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/10318 From sspitsyn at openjdk.org Tue Sep 20 21:09:41 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Sep 2022 21:09:41 GMT Subject: RFR: 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume [v2] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Tue, 20 Sep 2022 00:36:38 GMT, Leonid Mesnik wrote: >> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. >> Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. >> >> Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > revert changes src/hotspot/share/prims/jvmtiEnvBase.cpp line 1669: > 1667: if (java_thread->is_suspended()) { > 1668: if (!JvmtiSuspendControl::resume(java_thread)) { > 1669: return JVMTI_ERROR_THREAD_NOT_SUSPENDED; This is right. ------------- PR: https://git.openjdk.org/jdk/pull/10351 From sspitsyn at openjdk.org Tue Sep 20 21:15:07 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Sep 2022 21:15:07 GMT Subject: RFR: 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume [v2] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Tue, 20 Sep 2022 00:36:38 GMT, Leonid Mesnik wrote: >> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. >> Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. >> >> Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > revert changes test/hotspot/jtreg/testlibrary/jvmti/libJvmtiUtils.cpp line 84: > 82: } > 83: check_jvmti_status(jni, err, "Error during ResumeThread"); > 84: } Would it better to return the jvmtiError status as an int, so it can be checked at the java level? In fact, it is not good that the `JVMTI_ERROR_THREAD_NOT_ALIVE`, `JVMTI_ERROR_THREAD_SUSPENDED` and `JVMTI_ERROR_THREAD_NOT_SUSPENDED` are always ignored. test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java line 136: > 134: static final String EQUALS_NOT_INTERRUPTED = "Statuses of threads are equal: not interrupted"; > 135: > 136: static final int MAX_CASE = 1; This constant is not used anymore. Should it be deleted? ------------- PR: https://git.openjdk.org/jdk/pull/10351 From sspitsyn at openjdk.org Tue Sep 20 21:26:47 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Sep 2022 21:26:47 GMT Subject: RFR: 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume [v2] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Tue, 20 Sep 2022 00:36:38 GMT, Leonid Mesnik wrote: >> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. >> Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. >> >> Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > revert changes Hi Leonid, This looks good in general. I've added a couple of comments though. The PR title does not match the bug title: com/sun/jdi vs hotspot/jtreg. Thanks, Serguei ------------- PR: https://git.openjdk.org/jdk/pull/10351 From sspitsyn at openjdk.org Tue Sep 20 21:40:50 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Sep 2022 21:40:50 GMT Subject: RFR: 8293143: Workaround for JDK-8292217 when doing "step over" of bytecode with unresolved cp referernce In-Reply-To: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> References: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> Message-ID: <-tgP6vvrJeKxrzCRpGUKFG_EciFuucG5gzKyX0Knttw=.1f190453-f09f-4693-8b7f-3fecc013f2c6@github.com> On Wed, 31 Aug 2022 00:25:20 GMT, Chris Plummer wrote: > There is a workaround we can do for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) for the use case where a step over or step out is being done. This workaround can't be made to also work for the step into case. From [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) > > "There is a workaround that fixes this issue when doing a STEP_OVER or STEP_OUT. Rather than the debug agent checking if it has enabled JVMTI single stepping, instead it checks some fields in the ThreadNode that say if single stepping is pending, and it is for a STEP_INTO. If it is not STEP_INTO, then it can assume that no StepEvent will occur at the same location and therefor the MethodEntryEvent should not be deferred. So this limits the bug to only happening when doing a STEP_INTO. " test/jdk/com/sun/jdi/CLETest.java line 226: > 224: System.out.println("TESTCASE #" + testcase + " FAILED" + > 225: (testcase == 2 ? "(ignoring)" : "") + > 226: ": too many events in EventSet: " + set.size()); The comment says there is a workaround in place allowing the 1st test case to pass. However, the 1st test case is marked as failed at the line 222 and the produced message says it is ignoring the 2nd test case. I'm confused. Do I miss anything? ------------- PR: https://git.openjdk.org/jdk/pull/10091 From cjplummer at openjdk.org Tue Sep 20 21:43:34 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Sep 2022 21:43:34 GMT Subject: RFR: 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume [v2] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Tue, 20 Sep 2022 00:36:38 GMT, Leonid Mesnik wrote: >> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. >> Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. >> >> Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > revert changes > Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. As far as I know, this is the only test we have for ThreadReference.interrupt(). Also see [JDK-8282384](https://bugs.openjdk.org/browse/JDK-8282384), which points out that we have no test for ThreadReference.interrupt() of a virtual thread, and suggests modifying this test to support virtual threads. I actually attempted to do this, but ran into an issue with ThreadReference.resume() support for virtual threads, although I'm not sure what that issue was, and it may be fixed now. ------------- PR: https://git.openjdk.org/jdk/pull/10351 From cjplummer at openjdk.org Tue Sep 20 22:05:50 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Sep 2022 22:05:50 GMT Subject: RFR: 8289607: Change com/sun/jdi tests to not use Thread.suspend/resume [v2] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Tue, 20 Sep 2022 21:11:30 GMT, Serguei Spitsyn wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> revert changes > > test/hotspot/jtreg/testlibrary/jvmti/libJvmtiUtils.cpp line 84: > >> 82: } >> 83: check_jvmti_status(jni, err, "Error during ResumeThread"); >> 84: } > > Would it better to return the jvmtiError status as an int, so it can be checked at the java level? > In fact, it is not good that the `JVMTI_ERROR_THREAD_NOT_ALIVE`, `JVMTI_ERROR_THREAD_SUSPENDED` and `JVMTI_ERROR_THREAD_NOT_SUSPENDED` are always ignored. I was going to ask something similar. Should the tests ever see these errors? If not, probably an exception should be thrown here. If they are ok in some situations, then the tests should be checking for them. ------------- PR: https://git.openjdk.org/jdk/pull/10351 From sspitsyn at openjdk.org Tue Sep 20 22:19:55 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Sep 2022 22:19:55 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 20:19:10 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed typo in VirtualThread.c > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 713: > >> 711: if (!jt->is_in_tmp_VTMS_transition()) { >> 712: jvf = check_and_skip_hidden_frames(jt, jvf); >> 713: } > > I think this comment needs some help. It's hard to match it up with what the code is doing. I think you are saying you want to avoid skipping hidden frames when in transition, although if that's the case, it's not clear to me why not skipping is ok. > > Also is skipping (or not skipping) ok regardless of the JvmtiEnvBase::is_cthread_with_continuation() result? Thank you for reviewing and the comment, Chris. I agree, this part and related comment is kind of obscure. I'll think how to make the comment better. In fact, all temporary VTMS transitions do temporary switch the `JavaThread` identity from virtual thread to carrier. There is no need to skip frames because there are no real carrier thread frames at the top. Moreover, any attempt to skip frames which are in transition works incorrectly and gives an empty stack. The check `JvmtiEnvBase::is_cthread_with_continuation()` is needed to make sure we have a deal with a continuation. There is no need to skip frames otherwise. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From cjplummer at openjdk.org Tue Sep 20 22:20:06 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Sep 2022 22:20:06 GMT Subject: RFR: 8293143: Workaround for JDK-8292217 when doing "step over" of bytecode with unresolved cp referernce In-Reply-To: <-tgP6vvrJeKxrzCRpGUKFG_EciFuucG5gzKyX0Knttw=.1f190453-f09f-4693-8b7f-3fecc013f2c6@github.com> References: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> <-tgP6vvrJeKxrzCRpGUKFG_EciFuucG5gzKyX0Knttw=.1f190453-f09f-4693-8b7f-3fecc013f2c6@github.com> Message-ID: On Mon, 12 Sep 2022 21:52:31 GMT, Serguei Spitsyn wrote: >> There is a workaround we can do for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) for the use case where a step over or step out is being done. This workaround can't be made to also work for the step into case. From [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) >> >> "There is a workaround that fixes this issue when doing a STEP_OVER or STEP_OUT. Rather than the debug agent checking if it has enabled JVMTI single stepping, instead it checks some fields in the ThreadNode that say if single stepping is pending, and it is for a STEP_INTO. If it is not STEP_INTO, then it can assume that no StepEvent will occur at the same location and therefor the MethodEntryEvent should not be deferred. So this limits the bug to only happening when doing a STEP_INTO. " > > test/jdk/com/sun/jdi/CLETest.java line 226: > >> 224: System.out.println("TESTCASE #" + testcase + " FAILED" + >> 225: (testcase == 2 ? "(ignoring)" : "") + >> 226: ": too many events in EventSet: " + set.size()); > > The comment says there is a workaround in place allowing the 1st test case to pass. > However, the 1st test case is marked as failed at the line 222 and the produced message says it is ignoring the 2nd test case. I'm confused. Do I miss anything? testcase #2 is expected to fail, so that is why we do not set "testFailed = true" at line 222. However, if testcase #1 fails, we do want the overall test to fail, so in that case we set "testFailed = true" at line 222. ------------- PR: https://git.openjdk.org/jdk/pull/10091 From sspitsyn at openjdk.org Tue Sep 20 22:38:47 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Sep 2022 22:38:47 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 20:22:54 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed typo in VirtualThread.c > > src/hotspot/share/prims/jvmtiExport.cpp line 1055: > >> 1053: if (JavaThread::current()->is_in_tmp_VTMS_transition()) { >> 1054: return false; >> 1055: } > > You mentioned this in the PR description. However, it's not clear to me why this is ok. Also, it should be commented. > > Same thing for changes in JvmtiExport::post_class_load() and JvmtiExport::post_class_prepare(). I initially wanted to consult on this with Alan. It feels like it'd be better if I did it before posting this PR. We have just two possible approaches here. The best approach is to move any class loading out of the temporary transition code path. Then we already have the relevant asserts in place. However, this is not that easy to solve. Alan already suggested a couple of patches which I've tested but new places with class loads were discovered. Another approach is to skip all ClassLoad, ClassPrepare and CFLH events in context of temporary transitions. It is hard to estimate how acceptable it is. At least, I've not found any failing tests because of it which means it most likely does not impact the debugger. My current suggestion is to file a bug and try to address it later as Alan may need more time for analysis. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Tue Sep 20 22:45:04 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Sep 2022 22:45:04 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Mon, 19 Sep 2022 20:41:50 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed typo in VirtualThread.c > > src/hotspot/share/runtime/javaThread.cpp line 1174: > >> 1172: #if INCLUDE_JVMTI >> 1173: // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks. >> 1174: assert(!is_in_non_tmp_VTMS_transition(), "no suspend allowed in VTMS transition"); > > IMHO, a non tmp VTMS transition should be considered a type of VTMS transition, so the assert check here does not really match the assert text. Also see my related comments below on naming and use of these flags and APIs. Thanks. Accepted. > src/hotspot/share/runtime/javaThread.hpp line 650: > >> 648: void set_is_in_VTMS_transition(bool val); >> 649: bool is_in_tmp_VTMS_transition() const { return _is_in_tmp_VTMS_transition; } >> 650: void toggle_is_in_tmp_VTMS_transition() { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; }; > > The naming of the flags does not match up with the naming of the APIs, which is confusing. An API named is_in_VTMS_transition() should return _is_in_VTMS_transition. I think part of problem is that _is_in_VTMS_transition is not a superset of _is_in_tmp_VTMS_transition. The flags are never both set true, although both can be false. Maybe this should be changed to make it an invariant that if _is_in_tmp_VTMS_transit is true, then _is_in_tmp_VTMS_transition is true. I agree, this naming is not good. However, I was reluctant to do required renaming because it can potentially impact many spots and make review harder. Let me think a little bit more on this. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From dholmes at openjdk.org Wed Sep 21 02:35:44 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Sep 2022 02:35:44 GMT Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy [v2] In-Reply-To: References: Message-ID: <0goVLP540GYUPvShbPPV7bm2Jgg_5s_kU8b2hTOD7RA=.bedcc542-225a-45e3-bce3-522fc358da3e@github.com> On Tue, 20 Sep 2022 05:37:44 GMT, Thomas Stuefe wrote: >> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd. >> >> The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader. >> >> Also, the tests were expanded to test the display of empty loaders and empty parent loaders. >> >> Thanks to @dholmes-ora for finding this bug. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > cjplummer feedback Hi Thomas, Generally this seems fine - but one issue below. Thanks. src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp line 209: > 207: st->print(" \"%s\",", the_loader_name); > 208: } > 209: st->print(" %s", the_loader_class_name); `the_loader_class_name` could be NULL here. You need to change `loader_class_name()` t return "??" like the original code uses. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10312 From stuefe at openjdk.org Wed Sep 21 06:41:50 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 06:41:50 GMT Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy [v2] In-Reply-To: <0goVLP540GYUPvShbPPV7bm2Jgg_5s_kU8b2hTOD7RA=.bedcc542-225a-45e3-bce3-522fc358da3e@github.com> References: <0goVLP540GYUPvShbPPV7bm2Jgg_5s_kU8b2hTOD7RA=.bedcc542-225a-45e3-bce3-522fc358da3e@github.com> Message-ID: On Wed, 21 Sep 2022 02:26:02 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> cjplummer feedback > > src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp line 209: > >> 207: st->print(" \"%s\",", the_loader_name); >> 208: } >> 209: st->print(" %s", the_loader_class_name); > > `the_loader_class_name` could be NULL here. You need to change `loader_class_name()` t return "??" like the original code uses. Good catch. We never encounter this because Klass can only be null for the bootstrap loader, which is handled in a different branch. I'll fix it. ------------- PR: https://git.openjdk.org/jdk/pull/10312 From dholmes at openjdk.org Wed Sep 21 06:47:58 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Sep 2022 06:47:58 GMT Subject: RFR: 8289610: Degrade Thread.stop [v4] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 16:29:08 GMT, Stuart Marks wrote: >>> Good to see this finally become non-functional but as long as the debugger/JVMTI can trigger throwing an async ThreadDeath then I have to question the potential change in behaviour introduced by removing all the `catch (ThreadDeath td)` logic in various places. >> >> I've gone through this a few times too and concluded it would be better to remove these untestable code paths. The debugger scenario is more like what used to be Thread.stop(Throwable). It can be used to throw any exception or error, e.g. ask the debugger to throw IllegalArgumentException or SQLException when I'm at this breakpoint so I can see how the code behaves. Yes, the user could ask the debugger to throw java.lang.ThreadDeath when prompted but it's not really interesting now because code won't get this error outside of a debugger. We could leave the special handing but we have no way to test is and we'll need to the remove the special handling when TD is removed. As a general point, the special casing of TD is a bit inconsistent and more likely to be seen in older code rather newer code. A static analysis of 24M classes found very few usages in 3rd party libraries. > > I agree with Alan on this. First, use and handling of `ThreadDeath` is quite rare; see my [analysis](https://bugs.openjdk.org/browse/JDK-8289610?focusedCommentId=14523723&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14523723) of the corpus search results in the bug report. Second, while this does change the behavior in the debugger case, I'm hard-pressed to see how anybody is _relying_ on such behavior. And maybe somebody somewhere is indeed relying on this behavior, but it doesn't seem to me this behavior is guaranteed by any specifications. > > A more likely way that programs could observe changes in `ThreadDeath` handling occurs when programs throw `ThreadDeath` explicitly, that is, not using `Thread.stop`. This does seem to occur infrequently "in the wild" (we'll fix the jshell case). The point of throwing `ThreadDeath` explicitly is to take advantage of special-case handling of `ThreadDeath` that might occur higher in the call stack. Such special-casing was at one time an accepted exception handing idiom, but it's essentially disused. I don't think the JDK needs to continue to support this old idiom. Okay I will defer to your views here. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From stuefe at openjdk.org Wed Sep 21 06:51:56 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 06:51:56 GMT Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy [v3] In-Reply-To: References: Message-ID: > Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd. > > The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader. > > Also, the tests were expanded to test the display of empty loaders and empty parent loaders. > > Thanks to @dholmes-ora for finding this bug. Thomas Stuefe has updated the pull request incrementally with three additional commits since the last revision: - Fix test error in GHAs - feedback dholmes - childs->children ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10312/files - new: https://git.openjdk.org/jdk/pull/10312/files/224df5fc..3510ddcb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10312&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10312&range=01-02 Stats: 5 lines in 2 files changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10312.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10312/head:pull/10312 PR: https://git.openjdk.org/jdk/pull/10312 From stuefe at openjdk.org Wed Sep 21 06:51:57 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 06:51:57 GMT Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 05:33:10 GMT, Thomas Stuefe wrote: > Hi @plummercj , thanks for your Review. I worked most of your your feedback. > > .. Thomas ------------- PR: https://git.openjdk.org/jdk/pull/10312 From stuefe at openjdk.org Wed Sep 21 06:51:57 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 06:51:57 GMT Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy [v2] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 05:37:44 GMT, Thomas Stuefe wrote: >> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd. >> >> The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader. >> >> Also, the tests were expanded to test the display of empty loaders and empty parent loaders. >> >> Thanks to @dholmes-ora for finding this bug. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > cjplummer feedback - Fixed all remaining occurrences of "childs" - Fixed possible segfault when printing class name for bootstrap loader - Fixed GHAs (apparently we don't have a MainWrapper class when executing jtreg in GHAs, so I cannot parse for it) ------------- PR: https://git.openjdk.org/jdk/pull/10312 From sspitsyn at openjdk.org Wed Sep 21 07:40:01 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Sep 2022 07:40:01 GMT Subject: RFR: 8293143: Workaround for JDK-8292217 when doing "step over" of bytecode with unresolved cp referernce In-Reply-To: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> References: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> Message-ID: On Wed, 31 Aug 2022 00:25:20 GMT, Chris Plummer wrote: > There is a workaround we can do for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) for the use case where a step over or step out is being done. This workaround can't be made to also work for the step into case. From [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) > > "There is a workaround that fixes this issue when doing a STEP_OVER or STEP_OUT. Rather than the debug agent checking if it has enabled JVMTI single stepping, instead it checks some fields in the ThreadNode that say if single stepping is pending, and it is for a STEP_INTO. If it is not STEP_INTO, then it can assume that no StepEvent will occur at the same location and therefor the MethodEntryEvent should not be deferred. So this limits the bug to only happening when doing a STEP_INTO. " The workaround looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10091 From dholmes at openjdk.org Wed Sep 21 07:47:54 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Sep 2022 07:47:54 GMT Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy [v3] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 06:51:56 GMT, Thomas Stuefe wrote: >> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd. >> >> The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader. >> >> Also, the tests were expanded to test the display of empty loaders and empty parent loaders. >> >> Thanks to @dholmes-ora for finding this bug. > > Thomas Stuefe has updated the pull request incrementally with three additional commits since the last revision: > > - Fix test error in GHAs > - feedback dholmes > - childs->children Nothing further from me. Thanks! ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10312 From alanb at openjdk.org Wed Sep 21 07:52:03 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Sep 2022 07:52:03 GMT Subject: RFR: 8289610: Degrade Thread.stop [v4] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 06:43:50 GMT, David Holmes wrote: > Okay I will defer to your views here. Thanks. Thank you, I'll get the CSR moving again and we'll try to get this done. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From sgehwolf at openjdk.org Wed Sep 21 09:39:47 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 21 Sep 2022 09:39:47 GMT Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts [v3] In-Reply-To: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com> References: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com> Message-ID: On Thu, 15 Sep 2022 08:55:41 GMT, Severin Gehwolf wrote: >> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2: >> >> >> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java >> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java >> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java >> >> >> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`. >> >> Testing: >> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix) >> - [x] added tests fail before, pass after the product fix. >> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. >> - [x] GHA all pass. >> >> Please review! Many thanks in advance. > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts Anyone willing to review this? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10248 From kevinw at openjdk.org Wed Sep 21 11:12:45 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 21 Sep 2022 11:12:45 GMT Subject: RFR: 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 12:57:28 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the intermittent failures noted in https://bugs.openjdk.org/browse/JDK-8293657? > > There are two parts to this fix. One is straightforward fix in the test configuration file where it uses an incompatible cipher suite with the enabled protocols. The details of that are noted in my comment in the JBS https://bugs.openjdk.org/browse/JDK-8293657?focusedCommentId=14524400&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14524400. The fix for that resides solely in `management_ssltest07_ok.properties.in` file. > > The more curious part was why this specific test configuration is ever passing instead of always failing. That turned out to be a bug in the `sun.management.jmxremote.HostAwareSslSocketFactory`. The (internal implementation detail) in `sun.rmi.transport.tcp.TCPEndpoint` holds a cache of `localEndpoints` which effectively are server and client socket factories that get used when creating the corresponding socket/server sockets. The cache uses a key, whose one component is the `HostAwareSslSocketFactory` instance. This class extends from `javax.rmi.ssl.SslRMIServerSocketFactory` which is where the `equals()` is implemented for the `HostAwareSslSocketFactory` instances. The bug resides in the fact that the current implementation of the `HostAwareSslSocketFactory` constructor doesn't pass to its `super` the `enabledCipherSuites`, `enabledProtocols` and `needClientAuth` values with which the `HostAwareSslSocketFactory` was constructed with. Instead it stores these values as private me mbers and thus the `SslRMIServerSocketFactory` has its own version of these members as `null`. The `SslRMIServerSocketFactory` uses these values in its `equals` implementation and thus ends up computing a wrong output from the `equals` call. This ultimately ends up with the (internal) `TCPEndpoint` returning an incorrect (server) socket factory that gets used during the client/server communication. What this means is that the restrictions imposed on enabled protocols and enabled cipher suites in `management_ssltest07_ok.properties.in` aren't taken into account and instead a different set of (lenient) configurations for these attributes gets used (because of the cached socket factory constructed for a previous run of a different test configuration). > > The commit in this PR fixes the `HostAwareSslSocketFactory` to correctly pass to its `super` the enabled protocols, enabled cipher suites and the client auth mode, instead of saving that state (only) in `HostAwareSslSocketFactory`. > > Additionally the commit removes this test from the problem listing. Marked as reviewed by kevinw (Committer). Great investigation, of what must be a long-standing issue. Looks good. ------------- PR: https://git.openjdk.org/jdk/pull/10323 From alanb at openjdk.org Wed Sep 21 13:47:47 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Sep 2022 13:47:47 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume Message-ID: Degrade Thread.suspend/resume to throw UOE unconditionally. Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). ------------- Commit messages: - Fix typo in test comment - Keep link to threadPrimitiveDeprecation.html - Merge - Tests - Initial commit Changes: https://git.openjdk.org/jdk/pull/10324/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10324&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8249627 Stats: 347 lines in 15 files changed: 148 ins; 139 del; 60 mod Patch: https://git.openjdk.org/jdk/pull/10324.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10324/head:pull/10324 PR: https://git.openjdk.org/jdk/pull/10324 From smarks at openjdk.org Wed Sep 21 13:47:48 2022 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 21 Sep 2022 13:47:48 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman wrote: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). Code changes look fine, though I didn't look too closely at the JDWP and JVMTI stuff. Nice use of JUnit. Not a big deal, but I could see leaving the links from `Thread::suspend` et. al. to the "Why deprecated?" doc, and then updating that doc to make it clear that the mechanisms have in fact been removed, but leaving the rationale that's there mostly in place. Might also be useful in the CSR to re-emphasize that this does not affect the ability to suspend and resume threads through the debugging interfaces. Of course the specs in those areas need to be updated so they no longer deal with the case of a thread that's been suspended through the API, but the debugging mechanisms' functions themselves are unchanged. ------------- PR: https://git.openjdk.org/jdk/pull/10324 From cjplummer at openjdk.org Wed Sep 21 16:36:29 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 21 Sep 2022 16:36:29 GMT Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy [v3] In-Reply-To: References: Message-ID: <0l9zlblzDGyK8ov4IFf2X5vrvNLD6kfeoyQ846nw7vg=.0dcd0e6b-dd7b-44d2-b71f-516462260154@github.com> On Wed, 21 Sep 2022 06:51:56 GMT, Thomas Stuefe wrote: >> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd. >> >> The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader. >> >> Also, the tests were expanded to test the display of empty loaders and empty parent loaders. >> >> Thanks to @dholmes-ora for finding this bug. > > Thomas Stuefe has updated the pull request incrementally with three additional commits since the last revision: > > - Fix test error in GHAs > - feedback dholmes > - childs->children Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10312 From stuefe at openjdk.org Wed Sep 21 17:09:16 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 17:09:16 GMT Subject: RFR: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy [v3] In-Reply-To: <0l9zlblzDGyK8ov4IFf2X5vrvNLD6kfeoyQ846nw7vg=.0dcd0e6b-dd7b-44d2-b71f-516462260154@github.com> References: <0l9zlblzDGyK8ov4IFf2X5vrvNLD6kfeoyQ846nw7vg=.0dcd0e6b-dd7b-44d2-b71f-516462260154@github.com> Message-ID: On Wed, 21 Sep 2022 16:32:30 GMT, Chris Plummer wrote: >> Thomas Stuefe has updated the pull request incrementally with three additional commits since the last revision: >> >> - Fix test error in GHAs >> - feedback dholmes >> - childs->children > > Marked as reviewed by cjplummer (Reviewer). Thanks @plummercj and @dholmes-ora . ------------- PR: https://git.openjdk.org/jdk/pull/10312 From stuefe at openjdk.org Wed Sep 21 17:10:43 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 21 Sep 2022 17:10:43 GMT Subject: Integrated: JDK-8293156: Dcmd VM.classloaders fails to print the full hierarchy In-Reply-To: References: Message-ID: On Fri, 16 Sep 2022 14:55:42 GMT, Thomas Stuefe wrote: > Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be omitted from the output if a parent class loader never loaded any class and therefore had no associated DCmd. > > The fix changes the command to not rely on the existence of a CLD structure for the loader; instead, all information (loader class name, loader name, etc) is pulled via the loader oop, which has to be always there unless its the bootstrap loader. > > Also, the tests were expanded to test the display of empty loaders and empty parent loaders. > > Thanks to @dholmes-ora for finding this bug. This pull request has now been integrated. Changeset: c6be2cd3 Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/c6be2cd347fc07dcc0da56acf40fc7a005119f09 Stats: 157 lines in 2 files changed: 103 ins; 21 del; 33 mod 8293156: Dcmd VM.classloaders fails to print the full hierarchy Reviewed-by: dholmes, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/10312 From cjplummer at openjdk.org Wed Sep 21 17:15:19 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 21 Sep 2022 17:15:19 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: <_bEledEsS53FuI7oLyVxlCrmpLwJFQitD0uB320-tR8=.7c04ba0b-963b-4bdd-8972-14c0950751dd@github.com> On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman wrote: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). Changes look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/10324 From cjplummer at openjdk.org Wed Sep 21 17:29:23 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 21 Sep 2022 17:29:23 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 22:15:49 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 713: >> >>> 711: if (!jt->is_in_tmp_VTMS_transition()) { >>> 712: jvf = check_and_skip_hidden_frames(jt, jvf); >>> 713: } >> >> I think this comment needs some help. It's hard to match it up with what the code is doing. I think you are saying you want to avoid skipping hidden frames when in transition, although if that's the case, it's not clear to me why not skipping is ok. >> >> Also is skipping (or not skipping) ok regardless of the JvmtiEnvBase::is_cthread_with_continuation() result? > > Thank you for reviewing and the comment, Chris. > I agree, this part and related comment is kind of obscure. > I'll think how to make the comment better. > In fact, all temporary VTMS transitions do temporary switch the `JavaThread` identity from virtual thread to carrier. There is no need to skip frames because there are no real carrier thread frames at the top. Moreover, any attempt to skip frames which are in transition works incorrectly and gives an empty stack. The check `JvmtiEnvBase::is_cthread_with_continuation()` is needed to make sure we have a deal with a continuation. There is no need to skip frames otherwise. It's still not clear to me if the result of `JvmtiEnvBase::is_cthread_with_continuation()` impacts if you have to possibly skip hidden frames. In other words, do you always have to do the `if` block that follows, no matter what `JvmtiEnvBase::is_cthread_with_continuation()` returns? If you don't, then maybe instead of a "? :" expression, an if/else would be better. I'm not sure if the following is correct, but something like: javaVFrame *jvf; if (JvmtiEnvBase::is_cthread_with_continuation(jt)) { jvf = jt->carrier_last_java_vframe(reg_map_p); } else { jvf - jt->last_java_vframe(reg_map_p); // Skipping hidden frames when jt->is_in_tmp_VTMS_transition()==true results // in returning jvf==NULL, and so, empty stack traces for carrier threads. if (!jt->is_in_tmp_VTMS_transition()) { jvf = check_and_skip_hidden_frames(jt, jvf); } } ------------- PR: https://git.openjdk.org/jdk/pull/10321 From cjplummer at openjdk.org Wed Sep 21 17:32:17 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 21 Sep 2022 17:32:17 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 22:41:50 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/runtime/javaThread.cpp line 1174: >> >>> 1172: #if INCLUDE_JVMTI >>> 1173: // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks. >>> 1174: assert(!is_in_non_tmp_VTMS_transition(), "no suspend allowed in VTMS transition"); >> >> IMHO, a non tmp VTMS transition should be considered a type of VTMS transition, so the assert check here does not really match the assert text. Also see my related comments below on naming and use of these flags and APIs. > > Thanks. Accepted. I thought I was pointing out a naming issue, but your change indicates that it was actually a bug, and it is ok to be in a tmp transition here. Is that correct? ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Wed Sep 21 22:18:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Sep 2022 22:18:22 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman wrote: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10324 From lmesnik at openjdk.org Thu Sep 22 03:04:26 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 22 Sep 2022 03:04:26 GMT Subject: RFR: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume [v3] In-Reply-To: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: > The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. > Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. > > Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10351/files - new: https://git.openjdk.org/jdk/pull/10351/files/356ee078..c892fca0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10351&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10351&range=01-02 Stats: 112 lines in 5 files changed: 81 ins; 16 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/10351.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10351/head:pull/10351 PR: https://git.openjdk.org/jdk/pull/10351 From lmesnik at openjdk.org Thu Sep 22 03:06:17 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 22 Sep 2022 03:06:17 GMT Subject: RFR: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume [v2] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Tue, 20 Sep 2022 21:41:31 GMT, Chris Plummer wrote: > > Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. > > As far as I know, this is the only test we have for ThreadReference.interrupt(). Also see [JDK-8282384](https://bugs.openjdk.org/browse/JDK-8282384), which points out that we have no test for ThreadReference.interrupt() of a virtual thread, and suggests modifying this test to support virtual threads. I actually attempted to do this, but ran into an issue because Thread.resume() is not supported for virtual threads, but seems your changes get rid of resume() so it shouldn't be an issue anymore. > > I think losing this test case means we no longer test interrupt when suspended. Maybe we need to have the debugger side initiate the suspending. Let me file another bug for this. Just don't block Alan's fix https://github.com/openjdk/jdk/pull/10324 ------------- PR: https://git.openjdk.org/jdk/pull/10351 From darcy at openjdk.org Thu Sep 22 04:38:30 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 22 Sep 2022 04:38:30 GMT Subject: RFR: 8289610: Degrade Thread.stop [v4] In-Reply-To: References: Message-ID: On Sat, 17 Sep 2022 08:41:19 GMT, Alan Bateman wrote: >> Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. >> >> Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. >> >> To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. >> >> The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge > - Updates to Java Thread Primitive Deprecation page > - Repalce "it" with "victim thread" > - Merge > - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop > - become -> became in javadoc > - Merge > - Remove stopThread permission from RuntimePermission table, exclude jshell tests > - Deprecate for removal > - Next iteration, update dates in headers > - ... and 2 more: https://git.openjdk.org/jdk/compare/c06e7ac5...93806f99 src/java.base/share/classes/java/lang/Thread.java line 1632: > 1630: > 1631: /** > 1632: * Throws {@code UnsupportedOperationException}. Consider using an implSpec tag here. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From cjplummer at openjdk.org Thu Sep 22 05:18:10 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 22 Sep 2022 05:18:10 GMT Subject: RFR: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume [v3] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Thu, 22 Sep 2022 03:04:26 GMT, Leonid Mesnik wrote: >> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. >> Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. >> >> Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fix serviceability changes look good ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/10351 From jpai at openjdk.org Thu Sep 22 07:12:17 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 Sep 2022 07:12:17 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman wrote: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). Hello Alan, this PR deletes the `CountStackFrames.java` test case. Is that intentional? Looking at that test case it doesn't have any `suspend`/`resume` related testing and instead is just verifying that `Thread.countStackFrames()` throws the expected `UnsupportedOperationException`. Edit: Please ignore what I said - I now see that these tests have been moved to a new test file. ------------- PR: https://git.openjdk.org/jdk/pull/10324 From alanb at openjdk.org Thu Sep 22 07:12:29 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 Sep 2022 07:12:29 GMT Subject: RFR: 8289610: Degrade Thread.stop [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 04:36:08 GMT, Joe Darcy wrote: > Consider using an implSpec tag here. implSpec is usually for default methods or overrideable methods. In this case, Thread.stop is final so code that extends Thread can't override and change the behavior. So it's not clear to me that implSpec would be useful as it would duplicate the description in the generated javadoc. ------------- PR: https://git.openjdk.org/jdk/pull/10230 From dholmes at openjdk.org Thu Sep 22 08:06:30 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Sep 2022 08:06:30 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman wrote: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). One minor nit but otherwise looks good! Thanks. src/java.base/share/classes/java/lang/SecurityManager.java line 497: > 495: *

> 496: * This method is invoked for the current security manager by the > 497: * {@code stop}, {@code suspend}, {@code resume}, Why is stop being removed in this PR? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10324 From alanb at openjdk.org Thu Sep 22 08:25:22 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 Sep 2022 08:25:22 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 07:57:38 GMT, David Holmes wrote: > Why is stop being removed in this PR? It's just the sequencing of the two PRs and avoid merge conflicts. The Thread.stop should really edit this sentence, then this PR will edit it again. It was simpler to just do the SM edits in one PR. ------------- PR: https://git.openjdk.org/jdk/pull/10324 From jpai at openjdk.org Thu Sep 22 08:33:21 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 Sep 2022 08:33:21 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman wrote: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). The `java.base` changes look fine to me. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/10324 From sspitsyn at openjdk.org Thu Sep 22 09:13:19 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Sep 2022 09:13:19 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Wed, 21 Sep 2022 17:25:42 GMT, Chris Plummer wrote: >> Thank you for reviewing and the comment, Chris. >> I agree, this part and related comment is kind of obscure. >> I'll think how to make the comment better. >> In fact, all temporary VTMS transitions do temporary switch the `JavaThread` identity from virtual thread to carrier. There is no need to skip frames because there are no real carrier thread frames at the top. Moreover, any attempt to skip frames which are in transition works incorrectly and gives an empty stack. The check `JvmtiEnvBase::is_cthread_with_continuation()` is needed to make sure we have a deal with a continuation. There is no need to skip frames otherwise. > > It's still not clear to me if the result of `JvmtiEnvBase::is_cthread_with_continuation()` impacts if you have to possibly skip hidden frames. In other words, do you always have to do the `if` block that follows, no matter what `JvmtiEnvBase::is_cthread_with_continuation()` returns? If you don't, then maybe instead of a "? :" expression, an if/else would be better. I'm not sure if the following is correct, but something like: > > javaVFrame *jvf; > if (JvmtiEnvBase::is_cthread_with_continuation(jt)) { > jvf = jt->carrier_last_java_vframe(reg_map_p); > } else { > jvf - jt->last_java_vframe(reg_map_p); > // Skipping hidden frames when jt->is_in_tmp_VTMS_transition()==true results > // in returning jvf==NULL, and so, empty stack traces for carrier threads. > if (!jt->is_in_tmp_VTMS_transition()) { > jvf = check_and_skip_hidden_frames(jt, jvf); > } > } I understand you question about `is_cthread_with_continuation(jt)` check. And I've incorrectly answered you initial question about it. It is much simpler to check if `jt->is_in_VTMS_transition()` but not tmp transition. I've already updated this part with renaming. Could you, please, look at it and check if it is more clear this way? I'll push my fix shortly. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Thu Sep 22 09:16:28 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Sep 2022 09:16:28 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: > There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. > > There are a couple of details of this fix to highlight: > - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. > - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. > - Suspending threads in temporary transition is allowed. > > The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: 1. addressed review comments from Chris; added VirtualThread.java update from Alan ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10321/files - new: https://git.openjdk.org/jdk/pull/10321/files/551d8d32..48f827fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10321&range=02-03 Stats: 99 lines in 8 files changed: 19 ins; 5 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/10321.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10321/head:pull/10321 PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Thu Sep 22 09:23:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Sep 2022 09:23:22 GMT Subject: RFR: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume [v3] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Thu, 22 Sep 2022 03:04:26 GMT, Leonid Mesnik wrote: >> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. >> Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. >> >> Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fix Leonid, I've posted a couple of comments but am not sure you see them. Do you see my comments? If so, are you going to address them? ------------- PR: https://git.openjdk.org/jdk/pull/10351 From jpai at openjdk.org Thu Sep 22 09:43:15 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 Sep 2022 09:43:15 GMT Subject: RFR: 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 12:57:28 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the intermittent failures noted in https://bugs.openjdk.org/browse/JDK-8293657? > > There are two parts to this fix. One is straightforward fix in the test configuration file where it uses an incompatible cipher suite with the enabled protocols. The details of that are noted in my comment in the JBS https://bugs.openjdk.org/browse/JDK-8293657?focusedCommentId=14524400&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14524400. The fix for that resides solely in `management_ssltest07_ok.properties.in` file. > > The more curious part was why this specific test configuration is ever passing instead of always failing. That turned out to be a bug in the `sun.management.jmxremote.HostAwareSslSocketFactory`. The (internal implementation detail) in `sun.rmi.transport.tcp.TCPEndpoint` holds a cache of `localEndpoints` which effectively are server and client socket factories that get used when creating the corresponding socket/server sockets. The cache uses a key, whose one component is the `HostAwareSslSocketFactory` instance. This class extends from `javax.rmi.ssl.SslRMIServerSocketFactory` which is where the `equals()` is implemented for the `HostAwareSslSocketFactory` instances. The bug resides in the fact that the current implementation of the `HostAwareSslSocketFactory` constructor doesn't pass to its `super` the `enabledCipherSuites`, `enabledProtocols` and `needClientAuth` values with which the `HostAwareSslSocketFactory` was constructed with. Instead it stores these values as private me mbers and thus the `SslRMIServerSocketFactory` has its own version of these members as `null`. The `SslRMIServerSocketFactory` uses these values in its `equals` implementation and thus ends up computing a wrong output from the `equals` call. This ultimately ends up with the (internal) `TCPEndpoint` returning an incorrect (server) socket factory that gets used during the client/server communication. What this means is that the restrictions imposed on enabled protocols and enabled cipher suites in `management_ssltest07_ok.properties.in` aren't taken into account and instead a different set of (lenient) configurations for these attributes gets used (because of the cached socket factory constructed for a previous run of a different test configuration). > > The commit in this PR fixes the `HostAwareSslSocketFactory` to correctly pass to its `super` the enabled protocols, enabled cipher suites and the client auth mode, instead of saving that state (only) in `HostAwareSslSocketFactory`. > > Additionally the commit removes this test from the problem listing. Thank you Kevin for the review. ------------- PR: https://git.openjdk.org/jdk/pull/10323 From sspitsyn at openjdk.org Thu Sep 22 09:43:18 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Sep 2022 09:43:18 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: <8lGsnac-zbc4jYW4ebQZxCVvYtEBYBcZNeQLBx4Hueg=.6cc8ec9c-0010-49ad-abc7-cd8bbec6a1a7@github.com> On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. addressed review comments from Chris; added VirtualThread.java update from Alan Alan is currently investigating and testing his approach to get rid of temporary transitions. If it comes to be successful then I'll close this PR. Getting rid of temporary transitions is preferable as it will simplify the code a lot. However, I've pushed an update to complete my current chunk of work for safety. It includes two items: - an update from Alan, to get rid of some lambda form classes loading in context of temporary VTMS transition - update which address comments from Chris: - renaming of Thread class functions - changes in the function: `JvmtiEnvBase::get_cthread_last_java_vframe()` ------------- PR: https://git.openjdk.org/jdk/pull/10321 From dfuchs at openjdk.org Thu Sep 22 11:05:18 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 22 Sep 2022 11:05:18 GMT Subject: RFR: 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 12:57:28 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the intermittent failures noted in https://bugs.openjdk.org/browse/JDK-8293657? > > There are two parts to this fix. One is straightforward fix in the test configuration file where it uses an incompatible cipher suite with the enabled protocols. The details of that are noted in my comment in the JBS https://bugs.openjdk.org/browse/JDK-8293657?focusedCommentId=14524400&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14524400. The fix for that resides solely in `management_ssltest07_ok.properties.in` file. > > The more curious part was why this specific test configuration is ever passing instead of always failing. That turned out to be a bug in the `sun.management.jmxremote.HostAwareSslSocketFactory`. The (internal implementation detail) in `sun.rmi.transport.tcp.TCPEndpoint` holds a cache of `localEndpoints` which effectively are server and client socket factories that get used when creating the corresponding socket/server sockets. The cache uses a key, whose one component is the `HostAwareSslSocketFactory` instance. This class extends from `javax.rmi.ssl.SslRMIServerSocketFactory` which is where the `equals()` is implemented for the `HostAwareSslSocketFactory` instances. The bug resides in the fact that the current implementation of the `HostAwareSslSocketFactory` constructor doesn't pass to its `super` the `enabledCipherSuites`, `enabledProtocols` and `needClientAuth` values with which the `HostAwareSslSocketFactory` was constructed with. Instead it stores these values as private me mbers and thus the `SslRMIServerSocketFactory` has its own version of these members as `null`. The `SslRMIServerSocketFactory` uses these values in its `equals` implementation and thus ends up computing a wrong output from the `equals` call. This ultimately ends up with the (internal) `TCPEndpoint` returning an incorrect (server) socket factory that gets used during the client/server communication. What this means is that the restrictions imposed on enabled protocols and enabled cipher suites in `management_ssltest07_ok.properties.in` aren't taken into account and instead a different set of (lenient) configurations for these attributes gets used (because of the cached socket factory constructed for a previous run of a different test configuration). > > The commit in this PR fixes the `HostAwareSslSocketFactory` to correctly pass to its `super` the enabled protocols, enabled cipher suites and the client auth mode, instead of saving that state (only) in `HostAwareSslSocketFactory`. > > Additionally the commit removes this test from the problem listing. I had a look at the RMIServerSocketFactory hierarchy and the proposed changes look reasonable. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/10323 From lmesnik at openjdk.org Thu Sep 22 15:05:37 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 22 Sep 2022 15:05:37 GMT Subject: RFR: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume [v4] In-Reply-To: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: <8JLdprikc0ub2-fJpBfZdvPetHalkAwMnWuTEDWUJWo=.288de2f6-24de-4f2b-bcf6-94dfd56e5f00@github.com> > The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. > Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. > > Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10351/files - new: https://git.openjdk.org/jdk/pull/10351/files/c892fca0..5ad84a91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10351&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10351&range=02-03 Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10351.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10351/head:pull/10351 PR: https://git.openjdk.org/jdk/pull/10351 From lmesnik at openjdk.org Thu Sep 22 15:05:37 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 22 Sep 2022 15:05:37 GMT Subject: RFR: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume [v3] In-Reply-To: References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Thu, 22 Sep 2022 09:21:00 GMT, Serguei Spitsyn wrote: > Leonid, I've posted a couple of comments but am not sure you see them. Do you see my comments? If so, are you going to address them? Yes, I updated JvmtiUtils and removed unused variable. The PR title is correct now. ------------- PR: https://git.openjdk.org/jdk/pull/10351 From cjplummer at openjdk.org Thu Sep 22 20:15:29 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 22 Sep 2022 20:15:29 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. addressed review comments from Chris; added VirtualThread.java update from Alan src/hotspot/share/runtime/javaThread.hpp line 652: > 650: void set_is_in_VTMS_transition(bool val); > 651: void toggle_is_in_tmp_VTMS_transition() { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; }; > 652: My suggestion was to have the term "in VTMS transition" be inclusive of temp transitions. So based on your current names I would suggest: - is_in_VTMS_transition -> is_in_non_tmp_VTMS_transition - is_in_any_VTMS_transition -> is_in_VTMS_transition But that becomes a problem for `set_is_in_VTMS_transition`, which would need to be renamed `set_is_in_non_tmp_VTMS_transition`, which I'm guessing you don't want to do. So let's instead just hope this all goes away before thinking about it any more. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From jpai at openjdk.org Fri Sep 23 04:54:17 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 23 Sep 2022 04:54:17 GMT Subject: RFR: 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 12:57:28 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the intermittent failures noted in https://bugs.openjdk.org/browse/JDK-8293657? > > There are two parts to this fix. One is straightforward fix in the test configuration file where it uses an incompatible cipher suite with the enabled protocols. The details of that are noted in my comment in the JBS https://bugs.openjdk.org/browse/JDK-8293657?focusedCommentId=14524400&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14524400. The fix for that resides solely in `management_ssltest07_ok.properties.in` file. > > The more curious part was why this specific test configuration is ever passing instead of always failing. That turned out to be a bug in the `sun.management.jmxremote.HostAwareSslSocketFactory`. The (internal implementation detail) in `sun.rmi.transport.tcp.TCPEndpoint` holds a cache of `localEndpoints` which effectively are server and client socket factories that get used when creating the corresponding socket/server sockets. The cache uses a key, whose one component is the `HostAwareSslSocketFactory` instance. This class extends from `javax.rmi.ssl.SslRMIServerSocketFactory` which is where the `equals()` is implemented for the `HostAwareSslSocketFactory` instances. The bug resides in the fact that the current implementation of the `HostAwareSslSocketFactory` constructor doesn't pass to its `super` the `enabledCipherSuites`, `enabledProtocols` and `needClientAuth` values with which the `HostAwareSslSocketFactory` was constructed with. Instead it stores these values as private me mbers and thus the `SslRMIServerSocketFactory` has its own version of these members as `null`. The `SslRMIServerSocketFactory` uses these values in its `equals` implementation and thus ends up computing a wrong output from the `equals` call. This ultimately ends up with the (internal) `TCPEndpoint` returning an incorrect (server) socket factory that gets used during the client/server communication. What this means is that the restrictions imposed on enabled protocols and enabled cipher suites in `management_ssltest07_ok.properties.in` aren't taken into account and instead a different set of (lenient) configurations for these attributes gets used (because of the cached socket factory constructed for a previous run of a different test configuration). > > The commit in this PR fixes the `HostAwareSslSocketFactory` to correctly pass to its `super` the enabled protocols, enabled cipher suites and the client auth mode, instead of saving that state (only) in `HostAwareSslSocketFactory`. > > Additionally the commit removes this test from the problem listing. Thank you Daniel for your review. My tier1,tier2,tier3 testing which change went fine without any issues. ------------- PR: https://git.openjdk.org/jdk/pull/10323 From jpai at openjdk.org Fri Sep 23 04:57:36 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 23 Sep 2022 04:57:36 GMT Subject: Integrated: 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 12:57:28 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the intermittent failures noted in https://bugs.openjdk.org/browse/JDK-8293657? > > There are two parts to this fix. One is straightforward fix in the test configuration file where it uses an incompatible cipher suite with the enabled protocols. The details of that are noted in my comment in the JBS https://bugs.openjdk.org/browse/JDK-8293657?focusedCommentId=14524400&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14524400. The fix for that resides solely in `management_ssltest07_ok.properties.in` file. > > The more curious part was why this specific test configuration is ever passing instead of always failing. That turned out to be a bug in the `sun.management.jmxremote.HostAwareSslSocketFactory`. The (internal implementation detail) in `sun.rmi.transport.tcp.TCPEndpoint` holds a cache of `localEndpoints` which effectively are server and client socket factories that get used when creating the corresponding socket/server sockets. The cache uses a key, whose one component is the `HostAwareSslSocketFactory` instance. This class extends from `javax.rmi.ssl.SslRMIServerSocketFactory` which is where the `equals()` is implemented for the `HostAwareSslSocketFactory` instances. The bug resides in the fact that the current implementation of the `HostAwareSslSocketFactory` constructor doesn't pass to its `super` the `enabledCipherSuites`, `enabledProtocols` and `needClientAuth` values with which the `HostAwareSslSocketFactory` was constructed with. Instead it stores these values as private me mbers and thus the `SslRMIServerSocketFactory` has its own version of these members as `null`. The `SslRMIServerSocketFactory` uses these values in its `equals` implementation and thus ends up computing a wrong output from the `equals` call. This ultimately ends up with the (internal) `TCPEndpoint` returning an incorrect (server) socket factory that gets used during the client/server communication. What this means is that the restrictions imposed on enabled protocols and enabled cipher suites in `management_ssltest07_ok.properties.in` aren't taken into account and instead a different set of (lenient) configurations for these attributes gets used (because of the cached socket factory constructed for a previous run of a different test configuration). > > The commit in this PR fixes the `HostAwareSslSocketFactory` to correctly pass to its `super` the enabled protocols, enabled cipher suites and the client auth mode, instead of saving that state (only) in `HostAwareSslSocketFactory`. > > Additionally the commit removes this test from the problem listing. This pull request has now been integrated. Changeset: f6d78cda Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/f6d78cda853ce6ec6fdda845f1799253461fc618 Stats: 16 lines in 3 files changed: 1 ins; 7 del; 8 mod 8293657: sun/management/jmxremote/bootstrap/RmiBootstrapTest.java#id1 failed with "SSLHandshakeException: Remote host terminated the handshake" Reviewed-by: kevinw, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/10323 From alanb at openjdk.org Fri Sep 23 07:59:16 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 23 Sep 2022 07:59:16 GMT Subject: Integrated: 8289610: Degrade Thread.stop In-Reply-To: References: Message-ID: On Fri, 9 Sep 2022 12:44:31 GMT, Alan Bateman wrote: > Degrade Thread.stop to throw UOE unconditionally, deprecate ThreadDeath for removal, and remove the remaining special handling of ThreadDeath from the JDK. > > Thread.stop is inherently unsafe and has been deprecated since JDK 1.2 (1998) with a link to a supplementary page that explains the rationale. Some of the API surface has already been degraded or removed: Thread.stop(Throwable) was degraded to throw UOE in Java 8 and removed in Java 11, and ThreadGroup.stop was degraded to throw UOE in Java 19. As of Java 19, the no-arg Thread.stop continues to work as before for platform threads but throws UOE for virtual threads. The next step in the glacial pace removal is the degrading of the no-arg Thread.stop method to throw UOE for all threads. > > To keep things manageable, the change proposed here leaves JVM_StopThread in place. A separate issue will remove it and do other cleanup/removal in the VM. We have another JBS issue for the updates to the JLS and JVMS where asynchronous exceptions are defined. There is also some remaining work on a test class used by 6 jshell tests - if they aren't done in time then we will temporarily exclude them. > > The change here has no impact on the debugger APIs (JVM TI StopThread, JDWP ThreadReference/Stop, and JDI ThreadReference.stop). Debuggers can continue to cause threads to throw an asynchronous exception, as might be done when simulating code throwing an exception at some point in the code. This pull request has now been integrated. Changeset: acd5bcfc Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/acd5bcfc8897908d82e9008ee2def9476f046a4d Stats: 341 lines in 26 files changed: 115 ins; 162 del; 64 mod 8289610: Degrade Thread.stop Reviewed-by: rriggs, cjplummer, jpai, mchung, prr, mullan ------------- PR: https://git.openjdk.org/jdk/pull/10230 From dholmes at openjdk.org Fri Sep 23 08:58:42 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Sep 2022 08:58:42 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup Message-ID: Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). Testing: tiers 1-3 ------------- Commit messages: - Removal all special handling of ThreadDeath. - Remove all references to the stillborn field - Initial commit: remove JVM_StopThread - Merge - Updates to Java Thread Primitive Deprecation page - Repalce "it" with "victim thread" - Merge - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop - become -> became in javadoc - Merge - ... and 5 more: https://git.openjdk.org/jdk/compare/01e7b881...58bfb313 Changes: https://git.openjdk.org/jdk/pull/10400/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10400&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293592 Stats: 549 lines in 43 files changed: 134 ins; 308 del; 107 mod Patch: https://git.openjdk.org/jdk/pull/10400.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10400/head:pull/10400 PR: https://git.openjdk.org/jdk/pull/10400 From sspitsyn at openjdk.org Fri Sep 23 09:13:15 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Sep 2022 09:13:15 GMT Subject: RFR: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume [v4] In-Reply-To: <8JLdprikc0ub2-fJpBfZdvPetHalkAwMnWuTEDWUJWo=.288de2f6-24de-4f2b-bcf6-94dfd56e5f00@github.com> References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> <8JLdprikc0ub2-fJpBfZdvPetHalkAwMnWuTEDWUJWo=.288de2f6-24de-4f2b-bcf6-94dfd56e5f00@github.com> Message-ID: On Thu, 22 Sep 2022 15:05:37 GMT, Leonid Mesnik wrote: >> The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. >> Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. >> >> Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fix Looks good. Thank you for the update. Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10351 From sspitsyn at openjdk.org Fri Sep 23 09:37:18 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Sep 2022 09:37:18 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 22:41:50 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/runtime/javaThread.cpp line 1174: >> >>> 1172: #if INCLUDE_JVMTI >>> 1173: // Suspending a JavaThread in VTMS transition or disabling VTMS transitions can cause deadlocks. >>> 1174: assert(!is_in_non_tmp_VTMS_transition(), "no suspend allowed in VTMS transition"); >> >> IMHO, a non tmp VTMS transition should be considered a type of VTMS transition, so the assert check here does not really match the assert text. Also see my related comments below on naming and use of these flags and APIs. > > Thanks. Accepted. Chris, I believe, this comment is resolved. Please, let me know if you disagree. >> src/hotspot/share/runtime/javaThread.hpp line 650: >> >>> 648: void set_is_in_VTMS_transition(bool val); >>> 649: bool is_in_tmp_VTMS_transition() const { return _is_in_tmp_VTMS_transition; } >>> 650: void toggle_is_in_tmp_VTMS_transition() { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; }; >> >> The naming of the flags does not match up with the naming of the APIs, which is confusing. An API named is_in_VTMS_transition() should return _is_in_VTMS_transition. I think part of problem is that _is_in_VTMS_transition is not a superset of _is_in_tmp_VTMS_transition. The flags are never both set true, although both can be false. Maybe this should be changed to make it an invariant that if _is_in_tmp_VTMS_transit is true, then _is_in_tmp_VTMS_transition is true. > > I agree, this naming is not good. However, I was reluctant to do required renaming because it can potentially impact many spots and make review harder. Let me think a little bit more on this. I've simplified this naming but, probably, not in a way your were expecting. Please, see my comment below. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Fri Sep 23 09:37:21 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Sep 2022 09:37:21 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 20:09:21 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. addressed review comments from Chris; added VirtualThread.java update from Alan > > src/hotspot/share/runtime/javaThread.hpp line 652: > >> 650: void set_is_in_VTMS_transition(bool val); >> 651: void toggle_is_in_tmp_VTMS_transition() { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; }; >> 652: > > My suggestion was to have the term "in VTMS transition" be inclusive of temp transitions. So based on your current names I would suggest: > > - is_in_VTMS_transition -> is_in_non_tmp_VTMS_transition > - is_in_any_VTMS_transition -> is_in_VTMS_transition > > But that becomes a problem for `set_is_in_VTMS_transition`, which would need to be renamed `set_is_in_non_tmp_VTMS_transition`, which I'm guessing you don't want to do. So let's instead just hope this all goes away before thinking about it any more. Thank you for sharing your suggestion. To be honest, I'm inclined to keep the two as simple as possible, independent end mutually exclusive. Temporary transitions have big difference comparing to normal transitions. They are allowed to be suspended and do not clash with VTMS disablers. Please, let me know if are okay with this. Unfortunately, it seems, Alan got some difficulties in getting rid of temporary transitions. I'll double check on it just to be sure I understand it correctly. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Fri Sep 23 09:42:15 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Sep 2022 09:42:15 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v3] In-Reply-To: References: Message-ID: On Tue, 20 Sep 2022 22:34:59 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiExport.cpp line 1055: >> >>> 1053: if (JavaThread::current()->is_in_tmp_VTMS_transition()) { >>> 1054: return false; >>> 1055: } >> >> You mentioned this in the PR description. However, it's not clear to me why this is ok. Also, it should be commented. >> >> Same thing for changes in JvmtiExport::post_class_load() and JvmtiExport::post_class_prepare(). > > I initially wanted to consult on this with Alan. It feels like it'd be better if I did it before posting this PR. > We have just two possible approaches here. The best approach is to move any class loading out of the temporary transition code path. Then we already have the relevant asserts in place. However, this is not that easy to solve. Alan already suggested a couple of patches which I've tested but new places with class loads were discovered. Another approach is to skip all ClassLoad, ClassPrepare and CFLH events in context of temporary transitions. It is hard to estimate how acceptable it is. At least, I've not found any failing tests because of it which means it most likely does not impact the debugger. My current suggestion is to file a bug and try to address it later as Alan may need more time for analysis. We touched this issue with Alan and made a couple of updates. However, it occurred much harder to get rid of all class loading in context of temporary transitions. My current suggestion is still on the table. It is to file a separate bug and attempt to fix it later. NO test failures were discovered because of the skipped ClassLoad, ClassPrepare and CFLH events. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From alanb at openjdk.org Fri Sep 23 11:12:24 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 23 Sep 2022 11:12:24 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes wrote: > Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). > > Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. > > Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). > > Testing: tiers 1-3 (JDK-8289610 is integrated now so once you sync up it should remove the changes from the dependent PR once the list of changed files. You should be able to trim down the labels too.) I did a pass over the src/hotspot change and didn't spot any issues. It's good that stillborn can go away. The removal of the special-casing of ThreadDeath is consistent with the libs side of the change, including the change to ExceptionDescribe. ------------- PR: https://git.openjdk.org/jdk/pull/10400 From alanb at openjdk.org Fri Sep 23 13:57:56 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 23 Sep 2022 13:57:56 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v2] In-Reply-To: References: Message-ID: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Update DegradedMethodsThrowUOE to test Thread.stop - Merge - Update modifyThread and modifyThreadGroup targets - Merge - Fix typo in test comment - Keep link to threadPrimitiveDeprecation.html - Merge - Tests - Initial commit ------------- Changes: https://git.openjdk.org/jdk/pull/10324/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10324&range=01 Stats: 466 lines in 17 files changed: 148 ins; 255 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/10324.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10324/head:pull/10324 PR: https://git.openjdk.org/jdk/pull/10324 From jsjolen at openjdk.org Fri Sep 23 17:25:44 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 23 Sep 2022 17:25:44 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj Message-ID: Here's a suggested solution for the ticket mentioned and a use case for outputStream. I'm not attached to the name. This saves space for all allocated outputStreams, which is nice. It also makes the purpose of ResourceObj more clear ("please handle the life cycle for me"), reducing the need for it. Thank you for considering it. ------------- Commit messages: - DynCHeapObj Changes: https://git.openjdk.org/jdk/pull/10412/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10412&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294308 Stats: 64 lines in 13 files changed: 44 ins; 0 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/10412.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10412/head:pull/10412 PR: https://git.openjdk.org/jdk/pull/10412 From lmesnik at openjdk.org Fri Sep 23 17:48:42 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 23 Sep 2022 17:48:42 GMT Subject: Integrated: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume In-Reply-To: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> References: <1JY3RYxx4CgdpkKNyx4CiS0YXIVfVUud8iPkEk_d-Fw=.bd2e296c-17ec-42af-9986-d4e3e2ed4068@github.com> Message-ID: On Mon, 19 Sep 2022 23:02:42 GMT, Leonid Mesnik wrote: > The Thread.suspend/resume is replaced by JVM TI SuspendThread/ResumeThread whether it is possible. > Testcase from test test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java was removed because only one environment can suspend threads so debugger is not compatible with JVM TI agent suspending test. > > Test test/hotspot/jtreg/runtime/handshake/HandshakeSuspendExitTest.java starts failing because it got JVMTI_ERROR_INTERNAL. The problem is that JvmtiSuspendControl::resume() returned false. However, it might happen only if the thread is not suspended, which means that it should be JVMTI_ERROR_THREAD_NOT_SUSPENDED. This pull request has now been integrated. Changeset: 543851db Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/543851db926469df57a8f4a2bd3458349012145f Stats: 393 lines in 16 files changed: 163 ins; 168 del; 62 mod 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/10351 From cjplummer at openjdk.org Fri Sep 23 18:31:23 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Sep 2022 18:31:23 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes wrote: > Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). > > Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. > > Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). > > Testing: tiers 1-3 src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 102: > 100: try { > 101: connector = connectors.next(); > 102: } catch (Exception | Error x) { Maybe this should just catch `Throwable`, although it is unclear to me why we would want to catch any exception here. src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126: > 124: try { > 125: transportService = transportServices.next(); > 126: } catch (Exception | Error x) { Another that could be just catch `Throwable` ------------- PR: https://git.openjdk.org/jdk/pull/10400 From cjplummer at openjdk.org Fri Sep 23 18:39:19 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Sep 2022 18:39:19 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. addressed review comments from Chris; added VirtualThread.java update from Alan src/hotspot/share/prims/jvmtiThreadState.cpp line 273: > 271: > 272: assert(!thread->is_in_tmp_VTMS_transition(), "sanity check"); > 273: assert(!thread->is_in_VTMS_transition(), "VTMS_transition sanity check"); Why not cover both of these with `!thread->is_in_any_VTMS_transition()`? ------------- PR: https://git.openjdk.org/jdk/pull/10321 From cjplummer at openjdk.org Fri Sep 23 18:39:22 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Sep 2022 18:39:22 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 09:30:32 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/runtime/javaThread.hpp line 652: >> >>> 650: void set_is_in_VTMS_transition(bool val); >>> 651: void toggle_is_in_tmp_VTMS_transition() { _is_in_tmp_VTMS_transition = !_is_in_tmp_VTMS_transition; }; >>> 652: >> >> My suggestion was to have the term "in VTMS transition" be inclusive of temp transitions. So based on your current names I would suggest: >> >> - is_in_VTMS_transition -> is_in_non_tmp_VTMS_transition >> - is_in_any_VTMS_transition -> is_in_VTMS_transition >> >> But that becomes a problem for `set_is_in_VTMS_transition`, which would need to be renamed `set_is_in_non_tmp_VTMS_transition`, which I'm guessing you don't want to do. So let's instead just hope this all goes away before thinking about it any more. > > Thank you for sharing your suggestion. > To be honest, I'm inclined to keep the two as simple as possible, independent end mutually exclusive. > Temporary transitions have big difference comparing to normal transitions. > They are allowed to be suspended and do not clash with VTMS disablers. > Please, let me know if are okay with this. > > Unfortunately, it seems, Alan got some difficulties in getting rid of temporary transitions. > I'll double check on it just to be sure I understand it correctly. ok ------------- PR: https://git.openjdk.org/jdk/pull/10321 From coleenp at openjdk.org Fri Sep 23 19:58:22 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 23 Sep 2022 19:58:22 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 17:08:46 GMT, Johan Sj?len wrote: > Here's a suggested solution for the ticket mentioned and a use case for outputStream. I'm not attached to the name. > > This saves space for all allocated outputStreams, which is nice. It also makes the purpose of ResourceObj more clear ("please handle the life cycle for me"), reducing the need for it. > > Thank you for considering it. src/hotspot/share/memory/allocation.hpp line 219: > 217: }; > 218: > 219: class DynCHeapObj { I tried this and it seems to work: If you make CHeapObj new operators take MEMFLAGS f = F, where F is the default value, you could not have this class and make outputStream inherit from CHeapObj and the new calls will override mtInternal. I guess the risk is that you get mtInternal if you forget the parameter to new. src/hotspot/share/opto/compile.cpp line 4413: > 4411: // print_inlining_init is actually called several times. > 4412: print_inlining_stream_free(); > 4413: _print_inlining_stream = new (mtCompiler) stringStream(); These now need a delete (which is good because it doesn't need an explicit destructor call). ------------- PR: https://git.openjdk.org/jdk/pull/10412 From sspitsyn at openjdk.org Fri Sep 23 20:42:03 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Sep 2022 20:42:03 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: <8XO95Zy9ZwaIiWxspJhRLwP9JdLM8sVpTyIoF3JKYOY=.a0320f59-6e1e-4c9d-ad2c-5b2b8b792529@github.com> On Fri, 23 Sep 2022 18:32:57 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. addressed review comments from Chris; added VirtualThread.java update from Alan > > src/hotspot/share/prims/jvmtiThreadState.cpp line 273: > >> 271: >> 272: assert(!thread->is_in_tmp_VTMS_transition(), "sanity check"); >> 273: assert(!thread->is_in_VTMS_transition(), "VTMS_transition sanity check"); > > Why not cover both of these with `!thread->is_in_any_VTMS_transition()`? It is to be clear what condition caused the assert as they are different beasts. ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Fri Sep 23 20:48:02 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Sep 2022 20:48:02 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 13:57:56 GMT, Alan Bateman wrote: >> Degrade Thread.suspend/resume to throw UOE unconditionally. >> >> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. >> >> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. >> >> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Update DegradedMethodsThrowUOE to test Thread.stop > - Merge > - Update modifyThread and modifyThreadGroup targets > - Merge > - Fix typo in test comment > - Keep link to threadPrimitiveDeprecation.html > - Merge > - Tests > - Initial commit Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10324 From cjplummer at openjdk.org Fri Sep 23 21:00:47 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Sep 2022 21:00:47 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. addressed review comments from Chris; added VirtualThread.java update from Alan Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10321 From cjplummer at openjdk.org Fri Sep 23 21:00:47 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 23 Sep 2022 21:00:47 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: <8XO95Zy9ZwaIiWxspJhRLwP9JdLM8sVpTyIoF3JKYOY=.a0320f59-6e1e-4c9d-ad2c-5b2b8b792529@github.com> References: <8XO95Zy9ZwaIiWxspJhRLwP9JdLM8sVpTyIoF3JKYOY=.a0320f59-6e1e-4c9d-ad2c-5b2b8b792529@github.com> Message-ID: On Fri, 23 Sep 2022 20:38:17 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiThreadState.cpp line 273: >> >>> 271: >>> 272: assert(!thread->is_in_tmp_VTMS_transition(), "sanity check"); >>> 273: assert(!thread->is_in_VTMS_transition(), "VTMS_transition sanity check"); >> >> Why not cover both of these with `!thread->is_in_any_VTMS_transition()`? > > It is to be clear what condition caused the assert as they are different beasts. ok ------------- PR: https://git.openjdk.org/jdk/pull/10321 From dholmes at openjdk.org Fri Sep 23 21:47:06 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Sep 2022 21:47:06 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: > Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). > > Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. > > Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). > > Testing: tiers 1-3 David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' into 8293592-JVM_StopThread - Removal all special handling of ThreadDeath. - Remove all references to the stillborn field - Initial commit: remove JVM_StopThread - Merge - Updates to Java Thread Primitive Deprecation page - Repalce "it" with "victim thread" - Merge - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop - become -> became in javadoc - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 ------------- Changes: https://git.openjdk.org/jdk/pull/10400/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10400&range=01 Stats: 208 lines in 18 files changed: 19 ins; 146 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/10400.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10400/head:pull/10400 PR: https://git.openjdk.org/jdk/pull/10400 From dholmes at openjdk.org Fri Sep 23 21:47:08 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Sep 2022 21:47:08 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes wrote: > Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). > > Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. > > Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). > > Testing: tiers 1-3 This PR is now back to its proper form after merging the upstream changes. I can't say I like the "dependent PR" feature. ------------- PR: https://git.openjdk.org/jdk/pull/10400 From dholmes at openjdk.org Fri Sep 23 21:47:10 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Sep 2022 21:47:10 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 18:21:30 GMT, Chris Plummer wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into 8293592-JVM_StopThread >> - Removal all special handling of ThreadDeath. >> - Remove all references to the stillborn field >> - Initial commit: remove JVM_StopThread >> - Merge >> - Updates to Java Thread Primitive Deprecation page >> - Repalce "it" with "victim thread" >> - Merge >> - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop >> - become -> became in javadoc >> - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 > > src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 102: > >> 100: try { >> 101: connector = connectors.next(); >> 102: } catch (Exception | Error x) { > > Maybe this should just catch `Throwable`, although it is unclear to me why we would want to catch any exception here. @plummercj these changes are not actually part of this PR but came from the upstream PR this was dependent on. > src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126: > >> 124: try { >> 125: transportService = transportServices.next(); >> 126: } catch (Exception | Error x) { > > Another that could be just catch `Throwable` @plummercj these changes are not actually part of this PR but came from the upstream PR this was dependent on. ------------- PR: https://git.openjdk.org/jdk/pull/10400 From alanb at openjdk.org Sat Sep 24 06:43:17 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 Sep 2022 06:43:17 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 21:47:06 GMT, David Holmes wrote: >> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). >> >> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. >> >> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). >> >> Testing: tiers 1-3 > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into 8293592-JVM_StopThread > - Removal all special handling of ThreadDeath. > - Remove all references to the stillborn field > - Initial commit: remove JVM_StopThread > - Merge > - Updates to Java Thread Primitive Deprecation page > - Repalce "it" with "victim thread" > - Merge > - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop > - become -> became in javadoc > - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10400 From alanb at openjdk.org Sat Sep 24 06:43:18 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 Sep 2022 06:43:18 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: <-8imvtLKzzu_1t6YJsZYkxNbQ5JD1PaXXzK2O0nWc-s=.7c3843ad-c959-4a14-86c8-7b9722c3eb05@github.com> On Fri, 23 Sep 2022 21:42:08 GMT, David Holmes wrote: >> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 126: >> >>> 124: try { >>> 125: transportService = transportServices.next(); >>> 126: } catch (Exception | Error x) { >> >> Another that could be just catch `Throwable` > > @plummercj these changes are not actually part of this PR but came from the upstream PR this was dependent on. I think this dates from JDK 5 when pluggable JDI connectors and transports were aded. VirtualMachineManager does specify that it tolerates configuration and deployment issues with: "At start-up time the VirtualMachineManager attempts to load and instantiate (using the no-arg constructor) each class listed in the provider configuration file. Exceptions thrown when loading or creating the Connector are caught and ignored. In other words, the start-up process continues despite of errors." Looking at it now, I think it should be catching ServiceConfigurationError as that is what the SL's iterator hasNext/next will throw if locating, loading or instantiating a Connector fails. This seems something for an another issue of course, just strange that the Skara bots included it. ------------- PR: https://git.openjdk.org/jdk/pull/10400 From alanb at openjdk.org Sat Sep 24 06:50:45 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 Sep 2022 06:50:45 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v3] In-Reply-To: References: Message-ID: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Remove tests from exclude list - Merge - Update DegradedMethodsThrowUOE to test Thread.stop - Merge - Update modifyThread and modifyThreadGroup targets - Merge - Fix typo in test comment - Keep link to threadPrimitiveDeprecation.html - Merge - Tests - ... and 1 more: https://git.openjdk.org/jdk/compare/543851db...6aa38889 ------------- Changes: https://git.openjdk.org/jdk/pull/10324/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10324&range=02 Stats: 454 lines in 16 files changed: 136 ins; 255 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/10324.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10324/head:pull/10324 PR: https://git.openjdk.org/jdk/pull/10324 From alanb at openjdk.org Sat Sep 24 06:50:46 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 Sep 2022 06:50:46 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 13:57:56 GMT, Alan Bateman wrote: >> Degrade Thread.suspend/resume to throw UOE unconditionally. >> >> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. >> >> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. >> >> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Update DegradedMethodsThrowUOE to test Thread.stop > - Merge > - Update modifyThread and modifyThreadGroup targets > - Merge > - Fix typo in test comment > - Keep link to threadPrimitiveDeprecation.html > - Merge > - Tests > - Initial commit Leonid has integrated JDK-8289607 to remove the last usages of Thread.suspend/resume from the hotspot tests so I've refreshed this PR to drop the temporary excluding of these tests. ------------- PR: https://git.openjdk.org/jdk/pull/10324 From sspitsyn at openjdk.org Sat Sep 24 08:45:17 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 24 Sep 2022 08:45:17 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. addressed review comments from Chris; added VirtualThread.java update from Alan Thank you for review, Chris! ------------- PR: https://git.openjdk.org/jdk/pull/10321 From jsjolen at openjdk.org Sat Sep 24 09:53:23 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sat, 24 Sep 2022 09:53:23 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v2] In-Reply-To: References: Message-ID: <7EOFhJV-QAk2dB7FM5LHurR5R0lypcWPvdO_nSSMRgk=.8752a923-0b25-4ad3-832e-511037267449@github.com> > Here's a suggested solution for the ticket mentioned and a use case for outputStream. I'm not attached to the name. > > This saves space for all allocated outputStreams, which is nice. It also makes the purpose of ResourceObj more clear ("please handle the life cycle for me"), reducing the need for it. > > Thank you for considering it. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Try out Coleen's suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10412/files - new: https://git.openjdk.org/jdk/pull/10412/files/eb0174f6..11e88122 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10412&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10412&range=00-01 Stats: 61 lines in 2 files changed: 1 ins; 42 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/10412.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10412/head:pull/10412 PR: https://git.openjdk.org/jdk/pull/10412 From jsjolen at openjdk.org Sat Sep 24 09:53:25 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sat, 24 Sep 2022 09:53:25 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 19:53:56 GMT, Coleen Phillimore wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Try out Coleen's suggestion > > src/hotspot/share/memory/allocation.hpp line 219: > >> 217: }; >> 218: >> 219: class DynCHeapObj { > > I tried this and it seems to work: If you make CHeapObj new operators take MEMFLAGS f = F, where F is the default value, you could not have this class and make outputStream inherit from CHeapObj and the new calls will override mtInternal. I guess the risk is that you get mtInternal if you forget the parameter to new. Good idea! I implemented this instead. > src/hotspot/share/opto/compile.cpp line 4413: > >> 4411: // print_inlining_init is actually called several times. >> 4412: print_inlining_stream_free(); >> 4413: _print_inlining_stream = new (mtCompiler) stringStream(); > > These now need a delete (which is good because it doesn't need an explicit destructor call). We'll wait and see how https://github.com/openjdk/jdk/pull/10396 turns out before merging this :-). ------------- PR: https://git.openjdk.org/jdk/pull/10412 From mernst at openjdk.org Sun Sep 25 17:04:38 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Message-ID: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni ------------- Commit messages: - Remove file that was removed upstream - Fix inconsistency in capitalization - Undo change in zlip - Fix typos Changes: https://git.openjdk.org/jdk/pull/10029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294321 Stats: 317 lines in 108 files changed: 0 ins; 195 del; 122 mod Patch: https://git.openjdk.org/jdk/pull/10029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029 PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:38 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue. Done: https://bugs.openjdk.org/browse/SKARA-1566 ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jpai at openjdk.org Sun Sep 25 17:04:38 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> References: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> Message-ID: On Thu, 25 Aug 2022 19:55:47 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > >> If you already are an OpenJDK [Author](https://openjdk.java.net/bylaws#author), [Committer](https://openjdk.java.net/bylaws#committer) or [Reviewer](https://openjdk.java.net/bylaws#reviewer), please click [here](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1) to open a new issue so that we can record that fact. Please use "Add GitHub user mernst" as summary for the issue. > > Done: https://bugs.openjdk.org/browse/SKARA-1566 Hello Michael @mernst, these changes are mostly fine. However, they are spread across files which reside in different areas of the JDK. For changes like these, we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs. Would you be willing to split this PR into separate ones. I would recommend starting with one PR which includes changes that are part of `test/jdk/java`, `test/jdk/jdk` and `test/jdk/jni`. If you can come up with that PR, then I'll go ahead and create a JBS issue for it and you can then link the PR against that issue. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:38 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:38 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> Message-ID: On Mon, 5 Sep 2022 06:32:44 GMT, Jaikiran Pai wrote: > these changes are mostly fine. Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? It doesn't seem useful to make a pull request with known deficiencies. > we usually split up the changes into different PRs to help reviewers of specific areas focus on the individual PRs. Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Sun Sep 25 17:04:39 2022 From: duke at openjdk.org (SWinxy) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: <_zVJ429VO5Y3YZu0eDp_RD4BZRgEOBdDIIBuGf9vH6I=.b17025c7-1e0b-4a1b-a756-3a971b76bd03@github.com> Message-ID: On Mon, 5 Sep 2022 14:54:50 GMT, Michael Ernst wrote: > Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? These changes are fine. I don't see an instance where the duplicated words would mean a change in the specification. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jpai at openjdk.org Sun Sep 25 17:04:39 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Hello Michael, > > these changes are mostly fine. > > Can you be specific about the exact problems that you noticed that prevented you from saying "these changes are fine"? It doesn't seem useful to make a pull request with known deficiencies. I wasn't implying this PR had deficiencies. What I meant was, to be able to have this reviewed, in addition to code changes this will also need a issue to be created and linked to this PR (and the PR title changed to the form `: `). I have now created https://bugs.openjdk.org/browse/JDK-8294321. Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:39 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Sat, 24 Sep 2022 10:41:05 GMT, Jaikiran Pai wrote: > Splitting these changes into smaller PRs instead of one big one that touches several different areas of the JDK and 108 files, will help reviewers. OK. I'll repeat my comment from before: > Feel free to split up the pull request, if you feel that specific expertise in specific parts of the JDK is necessary to review these changes. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Sun Sep 25 17:04:39 2022 From: duke at openjdk.org (SWinxy) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Oh no what happened ![image](https://user-images.githubusercontent.com/8303399/192155378-4bb439fa-d27a-417d-8a3c-cf7f7329458f.png) src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053: > 1051: * fetch will take place at index 1. > 1052: * > 1053: * @return The current position index. Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:39 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Sun, 25 Sep 2022 16:51:27 GMT, SWinxy wrote: > Oh no what happened Oops! Thanks for pointing out the goof. It seems to be fixed now. It has now been a month since I opened the pull request, and I have responded to each substantive comment promptly. It would be great to merge this pull request to avoid the need for more merges. > src/java.xml/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java line 1053: > >> 1051: * fetch will take place at index 1. >> 1052: * >> 1053: * @return The current position index. > > Note that there is an inconsistent change here, albeit insignificant. In `NodeSet`, the capital 'The' is removed after the `@return`, while the lowercase 'the' is removed here. Thanks for pointing out the inconsistency. I have fixed it. (I noticed many violations of the official Javadoc style, but this is not the right pull request to fix them.) ------------- PR: https://git.openjdk.org/jdk/pull/10029 From alanb at openjdk.org Sun Sep 25 17:04:40 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 25 Sep 2022 17:04:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni src/java.base/share/native/libzip/zlib/zlib.h line 756: > 754: If this is done, the old level and strategy will be applied to the data > 755: compressed before deflateParams(), and the new level and strategy will be > 756: applied to the data compressed after deflateParams(). This is an issue for the upstream zlib project, we probably don't want to change it here. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From lancea at openjdk.org Sun Sep 25 17:04:40 2022 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 25 Sep 2022 17:04:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 09:31:07 GMT, Alan Bateman wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > src/java.base/share/native/libzip/zlib/zlib.h line 756: > >> 754: If this is done, the old level and strategy will be applied to the data >> 755: compressed before deflateParams(), and the new level and strategy will be >> 756: applied to the data compressed after deflateParams(). > > This is an issue for the upstream zlib project, we probably don't want to change it here. Agree. See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Sun Sep 25 17:04:40 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 25 Sep 2022 17:04:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 09:55:18 GMT, Lance Andersen wrote: >> src/java.base/share/native/libzip/zlib/zlib.h line 756: >> >>> 754: If this is done, the old level and strategy will be applied to the data >>> 755: compressed before deflateParams(), and the new level and strategy will be >>> 756: applied to the data compressed after deflateParams(). >> >> This is an issue for the upstream zlib project, we probably don't want to change it here. > > Agree. See https://github.com/madler/zlib/commit/5752b171fd4cc96b8d1f9526ec1940199c6e9740 which is in the zlib development branch and addresses a wide range of typos. OK. I backed out the change to zlib. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Sun Sep 25 17:23:28 2022 From: duke at openjdk.org (SWinxy) Date: Sun, 25 Sep 2022 17:23:28 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni I'm not a committer (yet) so I can't [sponsor](https://openjdk.org/sponsor/) this PR, even though I would. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From dholmes at openjdk.org Mon Sep 26 07:21:37 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Sep 2022 07:21:37 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 11:10:19 GMT, Alan Bateman wrote: >> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). >> >> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. >> >> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). >> >> Testing: tiers 1-3 > > (JDK-8289610 is integrated now so once you sync up it should remove the changes from the dependent PR and reduce the list of changed files. You should be able to trim down the labels too.) > > I did a pass over the src/hotspot change and didn't spot any issues. It's good that stillborn can go away. The removal of the special-casing of ThreadDeath is consistent with the libs side of the change, including the change to ExceptionDescribe. Thanks @AlanBateman ! ------------- PR: https://git.openjdk.org/jdk/pull/10400 From kbarrett at openjdk.org Mon Sep 26 10:15:23 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 26 Sep 2022 10:15:23 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v2] In-Reply-To: References: Message-ID: On Sat, 24 Sep 2022 09:47:38 GMT, Johan Sj?len wrote: >> src/hotspot/share/memory/allocation.hpp line 219: >> >>> 217: }; >>> 218: >>> 219: class DynCHeapObj { >> >> I tried this and it seems to work: If you make CHeapObj new operators take MEMFLAGS f = F, where F is the default value, you could not have this class and make outputStream inherit from CHeapObj and the new calls will override mtInternal. I guess the risk is that you get mtInternal if you forget the parameter to new. > > Good idea! I implemented this instead. We can eliminate this problem: "I guess the risk is that you get mtInternal if you forget the parameter to new." We can instead have CHeapObj that *only* allocates with mtFoo, and CHeapObj<> that *requires* specifying the flag when allocating the memory. (I did something like this for the CHeapAllocator in my prototype for Standard Library usage.) As part of that, we can also have the MEMFLAGS argument (when needed) always be the first argument in the placement list. Very(!) lightly tested: https://github.com/kimbarrett/openjdk-jdk/tree/dynamic-memflags ------------- PR: https://git.openjdk.org/jdk/pull/10412 From dholmes at openjdk.org Mon Sep 26 10:32:40 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 26 Sep 2022 10:32:40 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v3] In-Reply-To: References: Message-ID: <5FVc4-m-MyON0EHxtzwvuBFlwypdnhukQPk8lzYaA9Y=.85232874-19eb-4c1b-be85-9c6f37f7a20e@github.com> On Sat, 24 Sep 2022 06:50:45 GMT, Alan Bateman wrote: >> Degrade Thread.suspend/resume to throw UOE unconditionally. >> >> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. >> >> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. >> >> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Remove tests from exclude list > - Merge > - Update DegradedMethodsThrowUOE to test Thread.stop > - Merge > - Update modifyThread and modifyThreadGroup targets > - Merge > - Fix typo in test comment > - Keep link to threadPrimitiveDeprecation.html > - Merge > - Tests > - ... and 1 more: https://git.openjdk.org/jdk/compare/543851db...6aa38889 Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10324 From coleenp at openjdk.org Mon Sep 26 15:38:20 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 26 Sep 2022 15:38:20 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 10:13:18 GMT, Kim Barrett wrote: >> Good idea! I implemented this instead. > > We can eliminate this problem: > "I guess the risk is that you get mtInternal if you forget the parameter to new." > > We can instead have CHeapObj that *only* allocates with mtFoo, and > CHeapObj<> that *requires* specifying the flag when allocating the memory. (I > did something like this for the CHeapAllocator in my prototype for Standard > Library usage.) As part of that, we can also have the MEMFLAGS argument (when > needed) always be the first argument in the placement list. > > Very(!) lightly tested: > https://github.com/kimbarrett/openjdk-jdk/tree/dynamic-memflags Or you could have the class that requires dynamic mtFlag be declared with mtNone and assert in one place in AllocateHeap that mt != mtNone. Actually that assert might already be there. Can't really puzzle out what Kim's change does. ------------- PR: https://git.openjdk.org/jdk/pull/10412 From pchilanomate at openjdk.org Mon Sep 26 15:40:56 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 26 Sep 2022 15:40:56 GMT Subject: RFR: 8294370: Fix allocation bug in java_lang_Thread::async_get_stack_trace() Message-ID: Please review this small fix in async_get_stack_trace(). The GrowableArrays created to store the bci and Method* of each frame found while traversing the stack are allocated in the resource area of the thread that calls async_get_stack_trace(). But if the handshake is executed by the target and if the number of frames in the stack exceeds the initial size of the GrowableArrays then we will hit an assertion when trying to grow the size of the arrays (see bug description). Currently we don't see any issues because the initial size of the GrowableArrays is 512 and our tests don't test beyond that (the maximum value of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be easily reproduced by either decreasing the initial size of the GrowableArrays or by increasing the value of DEPTH in those strace tests. To fix it I allocated the arrays in the C heap instead. Also I lowered the initial size of the arrays since 512 seemed too much to start with. Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/10424/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10424&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294370 Stats: 11 lines in 1 file changed: 6 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10424.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10424/head:pull/10424 PR: https://git.openjdk.org/jdk/pull/10424 From joehw at openjdk.org Mon Sep 26 16:16:34 2022 From: joehw at openjdk.org (Joe Wang) Date: Mon, 26 Sep 2022 16:16:34 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni We have discussed several times in the past that we don't touch upstream (in this case, Apache) code unless the change is essential. In general, if you fix a bug in a class, it's fine to fix other non-essential things within the class, such as code styles, javadocs, typos as in this case, etc. Otherwise, I would suggest you contribute such changes to the upstream projects. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Mon Sep 26 16:51:36 2022 From: mernst at openjdk.org (Michael Ernst) Date: Mon, 26 Sep 2022 16:51:36 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Reinstate typos in Apache code that is copied into the JDK - Merge ../jdk-openjdk into typos-typos - Remove file that was removed upstream - Fix inconsistency in capitalization - Undo change in zlip - Fix typos ------------- Changes: https://git.openjdk.org/jdk/pull/10029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=01 Stats: 85 lines in 76 files changed: 0 ins; 0 del; 85 mod Patch: https://git.openjdk.org/jdk/pull/10029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029 PR: https://git.openjdk.org/jdk/pull/10029 From joehw at openjdk.org Mon Sep 26 17:04:25 2022 From: joehw at openjdk.org (Joe Wang) Date: Mon, 26 Sep 2022 17:04:25 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Thanks for the update! ------------- PR: https://git.openjdk.org/jdk/pull/10029 From sgehwolf at openjdk.org Mon Sep 26 18:36:22 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 26 Sep 2022 18:36:22 GMT Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts [v3] In-Reply-To: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com> References: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com> Message-ID: On Thu, 15 Sep 2022 08:55:41 GMT, Severin Gehwolf wrote: >> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2: >> >> >> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java >> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java >> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java >> >> >> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`. >> >> Testing: >> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix) >> - [x] added tests fail before, pass after the product fix. >> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. >> - [x] GHA all pass. >> >> Please review! Many thanks in advance. > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts @iklam Could you help me getting this reviewed, please? ------------- PR: https://git.openjdk.org/jdk/pull/10248 From lancea at openjdk.org Mon Sep 26 19:38:20 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 26 Sep 2022 19:38:20 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Thank you for your efforts on the cleaning up these typos I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review. I realize the changes are fairly trivial but this will most likely expedite getting your changes back ------------- PR: https://git.openjdk.org/jdk/pull/10029 From sspitsyn at openjdk.org Tue Sep 27 00:18:26 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 27 Sep 2022 00:18:26 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 21:47:06 GMT, David Holmes wrote: >> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). >> >> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. >> >> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). >> >> Testing: tiers 1-3 > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into 8293592-JVM_StopThread > - Removal all special handling of ThreadDeath. > - Remove all references to the stillborn field > - Initial commit: remove JVM_StopThread > - Merge > - Updates to Java Thread Primitive Deprecation page > - Repalce "it" with "victim thread" > - Merge > - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop > - become -> became in javadoc > - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 This looks good to me. I do not see any issues. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10400 From dholmes at openjdk.org Tue Sep 27 05:00:24 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Sep 2022 05:00:24 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 00:15:17 GMT, Serguei Spitsyn wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into 8293592-JVM_StopThread >> - Removal all special handling of ThreadDeath. >> - Remove all references to the stillborn field >> - Initial commit: remove JVM_StopThread >> - Merge >> - Updates to Java Thread Primitive Deprecation page >> - Repalce "it" with "victim thread" >> - Merge >> - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop >> - become -> became in javadoc >> - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 > > This looks good to me. > I do not see any issues. > Thanks, > Serguei Thanks @sspitsyn ! ------------- PR: https://git.openjdk.org/jdk/pull/10400 From cjplummer at openjdk.org Tue Sep 27 05:24:51 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 27 Sep 2022 05:24:51 GMT Subject: RFR: 8294411: SA should provide more useful info when it fails to start up due to "failed to workaround classshareing" Message-ID: Sometimes SA fails to startup with the following error message: ERROR: failed to workaround classshareing Unable to open core file The code in question is init_classsharing_workaround() in ps_core_common.c. There a number of reasons why the class sharing work around can fail, and the reason is usually pretty well described with a print_debug() statement. However, since this is an error, these should really just be print_error() statements so the user doesn't need to figure out how to get more info by setting LIBSAPROC_DEBUG (which may also produce a ton of output unrelated to the error). ------------- Commit messages: - Fix indentation. - Changed many cases of debug output to error output. Changes: https://git.openjdk.org/jdk/pull/10438/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10438&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294411 Stats: 15 lines in 1 file changed: 2 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/10438.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10438/head:pull/10438 PR: https://git.openjdk.org/jdk/pull/10438 From dholmes at openjdk.org Tue Sep 27 06:52:13 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Sep 2022 06:52:13 GMT Subject: RFR: 8294370: Fix allocation bug in java_lang_Thread::async_get_stack_trace() In-Reply-To: References: Message-ID: <9RyCg2SrkZi10QFNOSfh0JZoFB8WFvEb203n65RVCTE=.55d59e80-7083-43f4-a6ad-5d4ca55bcd0f@github.com> On Mon, 26 Sep 2022 14:23:38 GMT, Patricio Chilano Mateo wrote: > Please review this small fix in async_get_stack_trace(). The GrowableArrays created to store the bci and Method* of each frame found while traversing the stack are allocated in the resource area of the thread that calls async_get_stack_trace(). But if the handshake is executed by the target and if the number of frames in the stack exceeds the initial size of the GrowableArrays then we will hit an assertion when trying to grow the size of the arrays (see bug description). > Currently we don't see any issues because the initial size of the GrowableArrays is 512 and our tests don't test beyond that (the maximum value of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be easily reproduced by either decreasing the initial size of the GrowableArrays or by increasing the value of DEPTH in those strace tests. > To fix it I allocated the arrays in the C heap instead. Also I lowered the initial size of the arrays since 512 seemed too much to start with. > Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory. > > Thanks, > Patricio Good find! Looks good! A couple of queries at this stage. Thanks. src/hotspot/share/classfile/javaClasses.cpp line 2004: > 2002: const bool skip_hidden = !ShowHiddenFrames; > 2003: > 2004: // Pick some initial length The comment should at least hint at there being some reasonable reason for choosing the value that follows. :) src/hotspot/share/classfile/javaClasses.cpp line 2008: > 2006: _methods = new (ResourceObj::C_HEAP, mtInternal) GrowableArray(init_length, mtInternal); > 2007: _bcis = new (ResourceObj::C_HEAP, mtInternal) GrowableArray(init_length, mtInternal); > 2008: Couldn't you just do this in the constructor? I'm not clear if there is a subtle reason for needing lazy-init as well as moving to the C_Heap. ------------- PR: https://git.openjdk.org/jdk/pull/10424 From rehn at openjdk.org Tue Sep 27 08:05:19 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 27 Sep 2022 08:05:19 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: <-5Dm6rla6Uq1BWSlvsaVKXwLsbd0c2tgewPhpygfqZ0=.283a80a5-5025-4460-8ede-68a37e668764@github.com> On Fri, 23 Sep 2022 21:47:06 GMT, David Holmes wrote: >> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). >> >> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. >> >> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). >> >> Testing: tiers 1-3 > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into 8293592-JVM_StopThread > - Removal all special handling of ThreadDeath. > - Remove all references to the stillborn field > - Initial commit: remove JVM_StopThread > - Merge > - Updates to Java Thread Primitive Deprecation page > - Repalce "it" with "victim thread" > - Merge > - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop > - become -> became in javadoc > - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 Looks good, thank for fixing. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10400 From kevinw at openjdk.org Tue Sep 27 08:20:26 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 27 Sep 2022 08:20:26 GMT Subject: RFR: 8294411: SA should provide more useful info when it fails to start up due to "failed to workaround classshareing" In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 05:16:35 GMT, Chris Plummer wrote: > Sometimes SA fails to startup with the following error message: > > ERROR: failed to workaround classshareing > Unable to open core file > > The code in question is init_classsharing_workaround() in ps_core_common.c. There a number of reasons why the class sharing work around can fail, and the reason is usually pretty well described with a print_debug() statement. However, since this is an error, these should really just be print_error() statements so the user doesn't need to figure out how to get more info by setting LIBSAPROC_DEBUG (which may also produce a ton of output unrelated to the error). Very useful! ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.org/jdk/pull/10438 From alanb at openjdk.org Tue Sep 27 11:40:30 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 Sep 2022 11:40:30 GMT Subject: RFR: 8249627: Degrade Thread.suspend and Thread.resume [v3] In-Reply-To: References: Message-ID: On Sat, 24 Sep 2022 06:50:45 GMT, Alan Bateman wrote: >> Degrade Thread.suspend/resume to throw UOE unconditionally. >> >> Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. >> >> The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. >> >> Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Remove tests from exclude list > - Merge > - Update DegradedMethodsThrowUOE to test Thread.stop > - Merge > - Update modifyThread and modifyThreadGroup targets > - Merge > - Fix typo in test comment > - Keep link to threadPrimitiveDeprecation.html > - Merge > - Tests > - ... and 1 more: https://git.openjdk.org/jdk/compare/543851db...6aa38889 Wakeup bot ------------- PR: https://git.openjdk.org/jdk/pull/10324 From alanb at openjdk.org Tue Sep 27 11:47:20 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 Sep 2022 11:47:20 GMT Subject: Integrated: 8249627: Degrade Thread.suspend and Thread.resume In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 16:32:31 GMT, Alan Bateman wrote: > Degrade Thread.suspend/resume to throw UOE unconditionally. > > Another step in the removal of this deadlock prone mis-feature from the user-facing API. Thread.suspend/resume have been deprecated since JDK 1.2 (1998) and terminally deprecated since Java 14. ThreadGroup.suspend/resume were degraded to throw UOE in Java 19. As of Java 19, Thread.suspend/resume continues to work for platform threads but throws UOE for virtual threads. The next step is to degrade both methods to throw UOE for all threads. A corpus search of 19M classes in 113k JAR files found only 22 classes using these methods so this change is unlikely to be disruptive. > > The change requires some minor adjustments to the JVM TI and JDWP specifications, and a minor update to the JDI docs. > > Leonid Mesnik is working on [PR10351](https://github.com/openjdk/jdk/pull/10351) to remove/replace the last few usages of Thread.suspend/resume from the hotspot tests (most of these can use JVMTI SuspendThread/ResumeThread). This pull request has now been integrated. Changeset: 1abf971b Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/1abf971b93222f422c0026cee944a6db214f955a Stats: 454 lines in 16 files changed: 136 ins; 255 del; 63 mod 8249627: Degrade Thread.suspend and Thread.resume Reviewed-by: cjplummer, sspitsyn, dholmes, jpai ------------- PR: https://git.openjdk.org/jdk/pull/10324 From coleenp at openjdk.org Tue Sep 27 12:40:26 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 27 Sep 2022 12:40:26 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 21:47:06 GMT, David Holmes wrote: >> Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). >> >> Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. >> >> Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). >> >> Testing: tiers 1-3 > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into 8293592-JVM_StopThread > - Removal all special handling of ThreadDeath. > - Remove all references to the stillborn field > - Initial commit: remove JVM_StopThread > - Merge > - Updates to Java Thread Primitive Deprecation page > - Repalce "it" with "victim thread" > - Merge > - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop > - become -> became in javadoc > - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10400 From pchilanomate at openjdk.org Tue Sep 27 16:11:24 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 27 Sep 2022 16:11:24 GMT Subject: RFR: 8294370: Fix allocation bug in java_lang_Thread::async_get_stack_trace() In-Reply-To: <9RyCg2SrkZi10QFNOSfh0JZoFB8WFvEb203n65RVCTE=.55d59e80-7083-43f4-a6ad-5d4ca55bcd0f@github.com> References: <9RyCg2SrkZi10QFNOSfh0JZoFB8WFvEb203n65RVCTE=.55d59e80-7083-43f4-a6ad-5d4ca55bcd0f@github.com> Message-ID: On Tue, 27 Sep 2022 06:48:50 GMT, David Holmes wrote: > Good find! Looks good! A couple of queries at this stage. > > Thanks. > Thanks for looking at this David. > src/hotspot/share/classfile/javaClasses.cpp line 2004: > >> 2002: const bool skip_hidden = !ShowHiddenFrames; >> 2003: >> 2004: // Pick some initial length > > The comment should at least hint at there being some reasonable reason for choosing the value that follows. :) How about: "Pick minimum length that will cover most cases"? > src/hotspot/share/classfile/javaClasses.cpp line 2008: > >> 2006: _methods = new (ResourceObj::C_HEAP, mtInternal) GrowableArray(init_length, mtInternal); >> 2007: _bcis = new (ResourceObj::C_HEAP, mtInternal) GrowableArray(init_length, mtInternal); >> 2008: > > Couldn't you just do this in the constructor? I'm not clear if there is a subtle reason for needing lazy-init as well as moving to the C_Heap. Yes, this could have been done in the constructor too. But since there are additional checks in the closure that could fail I move the allocation here to avoid unnecessary allocation/deallocation. The allocation still needs to be done in the C_Heap in case the target executes the handshake. Otherwise if the target allocates the arrays in its resource area they could be deallocated by the time the requester tries to access them after the handshake. ------------- PR: https://git.openjdk.org/jdk/pull/10424 From cjplummer at openjdk.org Tue Sep 27 19:43:28 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 27 Sep 2022 19:43:28 GMT Subject: RFR: 8293143: Workaround for JDK-8292217 when doing "step over" of bytecode with unresolved cp referernce In-Reply-To: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> References: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> Message-ID: On Wed, 31 Aug 2022 00:25:20 GMT, Chris Plummer wrote: > There is a workaround we can do for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) for the use case where a step over or step out is being done. This workaround can't be made to also work for the step into case. From [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) > > "There is a workaround that fixes this issue when doing a STEP_OVER or STEP_OUT. Rather than the debug agent checking if it has enabled JVMTI single stepping, instead it checks some fields in the ThreadNode that say if single stepping is pending, and it is for a STEP_INTO. If it is not STEP_INTO, then it can assume that no StepEvent will occur at the same location and therefor the MethodEntryEvent should not be deferred. So this limits the bug to only happening when doing a STEP_INTO. " I could still use one more review for this PR. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10091 From amenkov at openjdk.org Tue Sep 27 20:31:21 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 27 Sep 2022 20:31:21 GMT Subject: RFR: 8293143: Workaround for JDK-8292217 when doing "step over" of bytecode with unresolved cp referernce In-Reply-To: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> References: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> Message-ID: On Wed, 31 Aug 2022 00:25:20 GMT, Chris Plummer wrote: > There is a workaround we can do for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) for the use case where a step over or step out is being done. This workaround can't be made to also work for the step into case. From [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) > > "There is a workaround that fixes this issue when doing a STEP_OVER or STEP_OUT. Rather than the debug agent checking if it has enabled JVMTI single stepping, instead it checks some fields in the ThreadNode that say if single stepping is pending, and it is for a STEP_INTO. If it is not STEP_INTO, then it can assume that no StepEvent will occur at the same location and therefor the MethodEntryEvent should not be deferred. So this limits the bug to only happening when doing a STEP_INTO. " Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10091 From cjplummer at openjdk.org Tue Sep 27 20:59:46 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 27 Sep 2022 20:59:46 GMT Subject: RFR: 8293143: Workaround for JDK-8292217 when doing "step over" of bytecode with unresolved cp referernce In-Reply-To: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> References: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> Message-ID: On Wed, 31 Aug 2022 00:25:20 GMT, Chris Plummer wrote: > There is a workaround we can do for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) for the use case where a step over or step out is being done. This workaround can't be made to also work for the step into case. From [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) > > "There is a workaround that fixes this issue when doing a STEP_OVER or STEP_OUT. Rather than the debug agent checking if it has enabled JVMTI single stepping, instead it checks some fields in the ThreadNode that say if single stepping is pending, and it is for a STEP_INTO. If it is not STEP_INTO, then it can assume that no StepEvent will occur at the same location and therefor the MethodEntryEvent should not be deferred. So this limits the bug to only happening when doing a STEP_INTO. " Thanks Alex and Serguei! ------------- PR: https://git.openjdk.org/jdk/pull/10091 From dholmes at openjdk.org Tue Sep 27 21:04:21 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Sep 2022 21:04:21 GMT Subject: RFR: 8293592: Remove JVM_StopThread, stillborn, and related cleanup [v2] In-Reply-To: <-5Dm6rla6Uq1BWSlvsaVKXwLsbd0c2tgewPhpygfqZ0=.283a80a5-5025-4460-8ede-68a37e668764@github.com> References: <-5Dm6rla6Uq1BWSlvsaVKXwLsbd0c2tgewPhpygfqZ0=.283a80a5-5025-4460-8ede-68a37e668764@github.com> Message-ID: On Tue, 27 Sep 2022 08:01:48 GMT, Robbin Ehn wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into 8293592-JVM_StopThread >> - Removal all special handling of ThreadDeath. >> - Remove all references to the stillborn field >> - Initial commit: remove JVM_StopThread >> - Merge >> - Updates to Java Thread Primitive Deprecation page >> - Repalce "it" with "victim thread" >> - Merge >> - Revert test/langtools/ProblemList.txt as jshell tests no longer rely on Thread.stop >> - become -> became in javadoc >> - ... and 6 more: https://git.openjdk.org/jdk/compare/3675f4c2...4eb07903 > > Looks good, thank for fixing. Thanks @robehn and @coleenp ! ------------- PR: https://git.openjdk.org/jdk/pull/10400 From dholmes at openjdk.org Tue Sep 27 21:07:30 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Sep 2022 21:07:30 GMT Subject: Integrated: 8293592: Remove JVM_StopThread, stillborn, and related cleanup In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 06:17:34 GMT, David Holmes wrote: > Now that Thread.stop has been degraded to throw `UnsupportedOperationException` (JDK-8299610) the only direct source of async exceptions is from JVMTI `StopThread`. We can remove the `JVM_StopThread` code, remove the `stillborn` field from `java.lang.Thread` and its associated accesses from the VM, and we can stop special-casing `ThreadDeath` handling (as was done for the JDK code as part of JDK-8299610). > > Note that JVMTI `StopThread` can only act on a thread that is alive, so it is no longer possible to stop a thread before it has been started. > > Also note that there is a change in behaviour for JNI `ExceptionDescribe` as it no longer ignores `ThreadDeath` exceptions (not that it was ever specified to ignore them, it simply mirrored the behaviour of the default `UncaughtExceptionHandler` in `java.lang.ThreadGroup` - which also no longer ignores them so the mirroring behaviour remains the same). > > Testing: tiers 1-3 This pull request has now been integrated. Changeset: 763d4bf0 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/763d4bf0749e54f74821e5155f672ed24d6f2fcd Stats: 208 lines in 18 files changed: 19 ins; 146 del; 43 mod 8293592: Remove JVM_StopThread, stillborn, and related cleanup Reviewed-by: alanb, sspitsyn, rehn, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/10400 From cjplummer at openjdk.org Tue Sep 27 21:23:47 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 27 Sep 2022 21:23:47 GMT Subject: Integrated: 8293143: Workaround for JDK-8292217 when doing "step over" of bytecode with unresolved cp reference In-Reply-To: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> References: <8dj-7f1jlj-brGsQHfJQxc44r6ER7Is9ZEsfsVUqwM0=.79ad5f3c-9f04-4e9a-b377-895fe69fbe55@github.com> Message-ID: <8cDAQQMwA6DYiPam8ueVUukS_eUUYKL3VXXdbp6SHy8=.9bb5492f-972e-4f0b-b0e2-1da02f45f2b6@github.com> On Wed, 31 Aug 2022 00:25:20 GMT, Chris Plummer wrote: > There is a workaround we can do for [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) for the use case where a step over or step out is being done. This workaround can't be made to also work for the step into case. From [JDK-8292217](https://bugs.openjdk.org/browse/JDK-8292217) > > "There is a workaround that fixes this issue when doing a STEP_OVER or STEP_OUT. Rather than the debug agent checking if it has enabled JVMTI single stepping, instead it checks some fields in the ThreadNode that say if single stepping is pending, and it is for a STEP_INTO. If it is not STEP_INTO, then it can assume that no StepEvent will occur at the same location and therefor the MethodEntryEvent should not be deferred. So this limits the bug to only happening when doing a STEP_INTO. " This pull request has now been integrated. Changeset: 6ad151d0 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/6ad151d09623217699d3d21c36d4e01f3bfd7d7b Stats: 17 lines in 2 files changed: 10 ins; 0 del; 7 mod 8293143: Workaround for JDK-8292217 when doing "step over" of bytecode with unresolved cp reference Reviewed-by: sspitsyn, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/10091 From lmesnik at openjdk.org Tue Sep 27 21:30:26 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 27 Sep 2022 21:30:26 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. addressed review comments from Chris; added VirtualThread.java update from Alan Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10321 From lmesnik at openjdk.org Tue Sep 27 21:43:08 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 27 Sep 2022 21:43:08 GMT Subject: RFR: 8294483: Remove vmTestbase/nsk/jvmti/GetThreadState tests. Message-ID: <_Ly0VOxB3rQUksG6V-anyYLKdbTaOHBgsPBKNfteIjU=.c6adfd1f-4c4c-4fe1-a661-ed786cbdb883@github.com> Tests in the vmTestbase/nsk/jvmti/GetThreadState were ported to serviceability/jvmti/thread/GetThreadState and should be removed. ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/10457/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10457&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294483 Stats: 2417 lines in 21 files changed: 0 ins; 2417 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10457.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10457/head:pull/10457 PR: https://git.openjdk.org/jdk/pull/10457 From cjplummer at openjdk.org Tue Sep 27 21:46:22 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 27 Sep 2022 21:46:22 GMT Subject: RFR: 8293563: [macos-aarch64] SA core file tests failing with sun.jvm.hotspot.oops.UnknownOopException Message-ID: JDK-8293563 is due to a macOS bug (or maybe a feature) that is resulting in the java heap not always being present in the core file. Running with `-XX:+AlwaysPreTouch` seems to work around this problem. This issue is only on macosx-aarch64, not x64. ------------- Commit messages: - Pretouch heap memory so it appears in the core dump. Changes: https://git.openjdk.org/jdk/pull/10458/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10458&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293563 Stats: 28 lines in 7 files changed: 13 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/10458.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10458/head:pull/10458 PR: https://git.openjdk.org/jdk/pull/10458 From kvn at openjdk.org Tue Sep 27 21:49:26 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 27 Sep 2022 21:49:26 GMT Subject: RFR: 8294483: Remove vmTestbase/nsk/jvmti/GetThreadState tests. In-Reply-To: <_Ly0VOxB3rQUksG6V-anyYLKdbTaOHBgsPBKNfteIjU=.c6adfd1f-4c4c-4fe1-a661-ed786cbdb883@github.com> References: <_Ly0VOxB3rQUksG6V-anyYLKdbTaOHBgsPBKNfteIjU=.c6adfd1f-4c4c-4fe1-a661-ed786cbdb883@github.com> Message-ID: On Tue, 27 Sep 2022 21:36:32 GMT, Leonid Mesnik wrote: > Tests in the vmTestbase/nsk/jvmti/GetThreadState were ported to serviceability/jvmti/thread/GetThreadState and should be removed. Good ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10457 From dholmes at openjdk.org Tue Sep 27 21:55:18 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 Sep 2022 21:55:18 GMT Subject: RFR: 8294483: Remove vmTestbase/nsk/jvmti/GetThreadState tests. In-Reply-To: <_Ly0VOxB3rQUksG6V-anyYLKdbTaOHBgsPBKNfteIjU=.c6adfd1f-4c4c-4fe1-a661-ed786cbdb883@github.com> References: <_Ly0VOxB3rQUksG6V-anyYLKdbTaOHBgsPBKNfteIjU=.c6adfd1f-4c4c-4fe1-a661-ed786cbdb883@github.com> Message-ID: On Tue, 27 Sep 2022 21:36:32 GMT, Leonid Mesnik wrote: > Tests in the vmTestbase/nsk/jvmti/GetThreadState were ported to serviceability/jvmti/thread/GetThreadState and should be removed. Seems fine. I was very surprised to discover that these tests copied way back in 2018! Thanks for fixing. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10457 From lmesnik at openjdk.org Tue Sep 27 22:51:27 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 27 Sep 2022 22:51:27 GMT Subject: Integrated: 8294483: Remove vmTestbase/nsk/jvmti/GetThreadState tests. In-Reply-To: <_Ly0VOxB3rQUksG6V-anyYLKdbTaOHBgsPBKNfteIjU=.c6adfd1f-4c4c-4fe1-a661-ed786cbdb883@github.com> References: <_Ly0VOxB3rQUksG6V-anyYLKdbTaOHBgsPBKNfteIjU=.c6adfd1f-4c4c-4fe1-a661-ed786cbdb883@github.com> Message-ID: On Tue, 27 Sep 2022 21:36:32 GMT, Leonid Mesnik wrote: > Tests in the vmTestbase/nsk/jvmti/GetThreadState were ported to serviceability/jvmti/thread/GetThreadState and should be removed. This pull request has now been integrated. Changeset: f8d9fa88 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/f8d9fa88735d8451108a0664990b8fc7409338e9 Stats: 2417 lines in 21 files changed: 0 ins; 2417 del; 0 mod 8294483: Remove vmTestbase/nsk/jvmti/GetThreadState tests. Reviewed-by: kvn, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/10457 From mernst at openjdk.org Tue Sep 27 23:16:16 2022 From: mernst at openjdk.org (Michael Ernst) Date: Tue, 27 Sep 2022 23:16:16 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> References: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> Message-ID: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com> On Mon, 26 Sep 2022 19:36:02 GMT, Lance Andersen wrote: > Thank you for your efforts on the cleaning up these typos > > I would suggest breaking these changes into separate PRs by team as there seems to be changes to hotspot, core-libs, and client to make it easier to review. > > I realize the changes are fairly trivial but this will most likely expedite getting your changes back Feel free to break up the pull request if that is what is needed to free it from red tape. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From dholmes at openjdk.org Wed Sep 28 01:59:18 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Sep 2022 01:59:18 GMT Subject: RFR: 8294370: Fix allocation bug in java_lang_Thread::async_get_stack_trace() In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 14:23:38 GMT, Patricio Chilano Mateo wrote: > Please review this small fix in async_get_stack_trace(). The GrowableArrays created to store the bci and Method* of each frame found while traversing the stack are allocated in the resource area of the thread that calls async_get_stack_trace(). But if the handshake is executed by the target and if the number of frames in the stack exceeds the initial size of the GrowableArrays then we will hit an assertion when trying to grow the size of the arrays (see bug description). > Currently we don't see any issues because the initial size of the GrowableArrays is 512 and our tests don't test beyond that (the maximum value of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be easily reproduced by either decreasing the initial size of the GrowableArrays or by increasing the value of DEPTH in those strace tests. > To fix it I allocated the arrays in the C heap instead. Also I lowered the initial size of the arrays since 512 seemed too much to start with. > Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory. > > Thanks, > Patricio Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10424 From dholmes at openjdk.org Wed Sep 28 01:59:21 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 28 Sep 2022 01:59:21 GMT Subject: RFR: 8294370: Fix allocation bug in java_lang_Thread::async_get_stack_trace() In-Reply-To: References: <9RyCg2SrkZi10QFNOSfh0JZoFB8WFvEb203n65RVCTE=.55d59e80-7083-43f4-a6ad-5d4ca55bcd0f@github.com> Message-ID: On Tue, 27 Sep 2022 16:09:07 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 2004: >> >>> 2002: const bool skip_hidden = !ShowHiddenFrames; >>> 2003: >>> 2004: // Pick some initial length >> >> The comment should at least hint at there being some reasonable reason for choosing the value that follows. :) > > How about: "Pick minimum length that will cover most cases"? Sounds good. >> src/hotspot/share/classfile/javaClasses.cpp line 2008: >> >>> 2006: _methods = new (ResourceObj::C_HEAP, mtInternal) GrowableArray(init_length, mtInternal); >>> 2007: _bcis = new (ResourceObj::C_HEAP, mtInternal) GrowableArray(init_length, mtInternal); >>> 2008: >> >> Couldn't you just do this in the constructor? I'm not clear if there is a subtle reason for needing lazy-init as well as moving to the C_Heap. > > Yes, this could have been done in the constructor too. But since there are additional checks in the closure that could fail I move the allocation here to avoid unnecessary allocation/deallocation. The allocation still needs to be done in the C_Heap in case the target executes the handshake. Otherwise if the target allocates the arrays in its resource area they could be deallocated by the time the requester tries to access them after the handshake. Good point - only allocate when known to be needed. ------------- PR: https://git.openjdk.org/jdk/pull/10424 From sspitsyn at openjdk.org Wed Sep 28 04:26:36 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Sep 2022 04:26:36 GMT Subject: RFR: 8294411: SA should provide more useful info when it fails to start up due to "failed to workaround classshareing" In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 05:16:35 GMT, Chris Plummer wrote: > Sometimes SA fails to startup with the following error message: > > ERROR: failed to workaround classshareing > Unable to open core file > > The code in question is init_classsharing_workaround() in ps_core_common.c. There a number of reasons why the class sharing work around can fail, and the reason is usually pretty well described with a print_debug() statement. However, since this is an error, these should really just be print_error() statements so the user doesn't need to figure out how to get more info by setting LIBSAPROC_DEBUG (which may also produce a ton of output unrelated to the error). Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10438 From sspitsyn at openjdk.org Wed Sep 28 04:45:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Sep 2022 04:45:22 GMT Subject: RFR: 8293613: need to properly handle and hide tmp VTMS transitions [v4] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 09:16:28 GMT, Serguei Spitsyn wrote: >> There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. >> >> There are a couple of details of this fix to highlight: >> - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. >> - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. >> - Suspending threads in temporary transition is allowed. >> >> The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > 1. addressed review comments from Chris; added VirtualThread.java update from Alan Thank you for review, Leonid! ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Wed Sep 28 04:45:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Sep 2022 04:45:22 GMT Subject: RFR: 8294370: Fix allocation bug in java_lang_Thread::async_get_stack_trace() In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 14:23:38 GMT, Patricio Chilano Mateo wrote: > Please review this small fix in async_get_stack_trace(). The GrowableArrays created to store the bci and Method* of each frame found while traversing the stack are allocated in the resource area of the thread that calls async_get_stack_trace(). But if the handshake is executed by the target and if the number of frames in the stack exceeds the initial size of the GrowableArrays then we will hit an assertion when trying to grow the size of the arrays (see bug description). > Currently we don't see any issues because the initial size of the GrowableArrays is 512 and our tests don't test beyond that (the maximum value of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be easily reproduced by either decreasing the initial size of the GrowableArrays or by increasing the value of DEPTH in those strace tests. > To fix it I allocated the arrays in the C heap instead. Also I lowered the initial size of the arrays since 512 seemed too much to start with. > Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory. > > Thanks, > Patricio Yes, it is good find! The fix looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10424 From sspitsyn at openjdk.org Wed Sep 28 04:48:14 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Sep 2022 04:48:14 GMT Subject: Integrated: 8293613: need to properly handle and hide tmp VTMS transitions In-Reply-To: References: Message-ID: On Sun, 18 Sep 2022 09:13:11 GMT, Serguei Spitsyn wrote: > There are several places in VirtualThread class implementation where virtual threads are being mounted or unmounted, so there is a transition of the JavaThread identity from carrier thread to virtual thread and back. The execution state in such transitions is inconsistent, and so, has to be invisible to JVM TI agents. Such transitions are named as VTMS (virtual thread mount state) transitions, and there is a JVM TI mechanism which supports them. Besides normal VTMS transitions there are also a couple of performance-critical contexts (in `VirtualThread` methods: `scheduleUnpark()`, `cancel()` and `unpark()`) which can be named as temporary VTMS transitions. Execution state of such temporary VTMS transitions has to be also invisible to the JVM TI agent which is implemented in the current update. > > There are a couple of details of this fix to highlight: > - A JavaThread which is in temporary VTMS transition is marked with a special bit `_is_in_tmp_VTMS_transition`. It is done with the native notification method `toggleJvmtiTmpVTMSTrans()`. > - A couple of lambda form classes can be created in context of temporary VTMS transitions, so their `ClassLoad`, `ClassPrepare` and `CFLH` events are ignored. > - Suspending threads in temporary transition is allowed. > > The fix was tested in Loom repository by using `JTREG_MAIN_WRAPPER=Virtual` mode of execution which forces all main threads to be run as virtual. All `JVM TI` and `JDI` tests were run on all platforms. It includes `Kitchensink` and `JCK` tests. Additionally, the fix was tested in the jdk 20 repository. It includes `JVM TI` and `JDI` tests and tiers 1-6. This pull request has now been integrated. Changeset: 79ccc791 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/79ccc791f275be7cfea95ff0ce8cf7361c7f08ad Stats: 148 lines in 10 files changed: 80 ins; 3 del; 65 mod 8293613: need to properly handle and hide tmp VTMS transitions Reviewed-by: cjplummer, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/10321 From sspitsyn at openjdk.org Wed Sep 28 05:11:46 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 Sep 2022 05:11:46 GMT Subject: RFR: 8293563: [macos-aarch64] SA core file tests failing with sun.jvm.hotspot.oops.UnknownOopException In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 21:38:43 GMT, Chris Plummer wrote: > JDK-8293563 is due to a macOS bug (or maybe a feature) that is resulting in the java heap not always being present in the core file. Running with `-XX:+AlwaysPreTouch` seems to work around this problem. This issue is only on macosx-aarch64, not x64. Looks good. Thanks, Serguei test/hotspot/jtreg/ProblemList.txt line 123: > 121: serviceability/sa/TestJmapCore.java 8267433 macosx-x64 > 122: serviceability/sa/TestJmapCoreMetaspace.java 8267433 macosx-x64 > 123: I see, 8269982 removed in problem list is a dup of 8293563. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10458 From iklam at openjdk.org Wed Sep 28 05:47:46 2022 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 28 Sep 2022 05:47:46 GMT Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts [v3] In-Reply-To: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com> References: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com> Message-ID: On Thu, 15 Sep 2022 08:55:41 GMT, Severin Gehwolf wrote: >> Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2: >> >> >> test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java >> test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java >> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java >> >> >> I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`. >> >> Testing: >> - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix) >> - [x] added tests fail before, pass after the product fix. >> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. >> - [x] GHA all pass. >> >> Please review! Many thanks in advance. > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts The JDK change looks good to me. Some nits for the test cases. test/jdk/jdk/internal/platform/docker/TestDockerBasic.java line 26: > 24: /* > 25: * @test > 26: * @summary Verify that -XshowSettings:system works Add `@bug 8293540` test/jdk/jdk/internal/platform/docker/TestDockerBasic.java line 64: > 62: opts.addDockerOpts("--memory", "300m"); > 63: if (addCgroupMounts) { > 64: opts.addDockerOpts("--volume", "/sys/fs/cgroup:/cgroup-in:ro"); Add comments that the extra mount should be ignored by the cgroup set-up code. (Same for other test cases). ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.org/jdk/pull/10248 From kevinw at openjdk.org Wed Sep 28 12:38:25 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 28 Sep 2022 12:38:25 GMT Subject: RFR: 8293563: [macos-aarch64] SA core file tests failing with sun.jvm.hotspot.oops.UnknownOopException In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 21:38:43 GMT, Chris Plummer wrote: > JDK-8293563 is due to a macOS bug (or maybe a feature) that is resulting in the java heap not always being present in the core file. Running with `-XX:+AlwaysPreTouch` seems to work around this problem. This issue is only on macosx-aarch64, not x64. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/10458 From dfuchs at openjdk.org Wed Sep 28 13:24:26 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 28 Sep 2022 13:24:26 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com> References: <3PJ-Gv4AW5nTD3gcQ1mwZH5C0jFo09zD6879B3jlkY4=.05beeb4b-498d-40fb-8514-244ac0ef0772@github.com> <1UZcv-X4dxQHlgj8b5B2sGJ9NpxWrOp1EwbWeazjj2I=.1cf2b14f-7064-47b6-8d25-887732020bb0@github.com> Message-ID: On Tue, 27 Sep 2022 23:12:43 GMT, Michael Ernst wrote: > Feel free to break up the pull request if that is what is needed to free it from red tape. Only you can do that @mernst ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jsjolen at openjdk.org Wed Sep 28 13:45:53 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 28 Sep 2022 13:45:53 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3] In-Reply-To: References: Message-ID: > Here's a suggested solution for the ticket mentioned and a use case for outputStream. I'm not attached to the name. > > This saves space for all allocated outputStreams, which is nice. It also makes the purpose of ResourceObj more clear ("please handle the life cycle for me"), reducing the need for it. > > Thank you for considering it. Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Introduce new, invalid, memory flag - delete _print_inlining_stream - Merge remote-tracking branch 'origin/master' into dyn-cheapobj - Avoid leaking predString - Try out Coleen's suggestion - DynCHeapObj ------------- Changes: https://git.openjdk.org/jdk/pull/10412/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10412&range=02 Stats: 47 lines in 15 files changed: 9 ins; 0 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/10412.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10412/head:pull/10412 PR: https://git.openjdk.org/jdk/pull/10412 From jsjolen at openjdk.org Wed Sep 28 13:45:54 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 28 Sep 2022 13:45:54 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3] In-Reply-To: References: Message-ID: <8HwXXsQs7ymwwOCwOYVeyISo6akG2_XBOVf2ILTjFuQ=.5b323620-ca06-4200-9301-2f64bbc85374@github.com> On Mon, 26 Sep 2022 15:34:29 GMT, Coleen Phillimore wrote: >> We can eliminate this problem: >> "I guess the risk is that you get mtInternal if you forget the parameter to new." >> >> We can instead have CHeapObj that *only* allocates with mtFoo, and >> CHeapObj<> that *requires* specifying the flag when allocating the memory. (I >> did something like this for the CHeapAllocator in my prototype for Standard >> Library usage.) As part of that, we can also have the MEMFLAGS argument (when >> needed) always be the first argument in the placement list. >> >> Very(!) lightly tested: >> https://github.com/kimbarrett/openjdk-jdk/tree/dynamic-memflags > > Or you could have the class that requires dynamic mtFlag be declared with mtNone and assert in one place in AllocateHeap that mt != mtNone. Actually that assert might already be there. Can't really puzzle out what Kim's change does. I added a mtInvalid flag and did the assert. mtNone seems to be dealt with in some code, I'm not sure if it's appropriate to use it as an invalid value. Regardless, mtInvalid is a better name (for this purpose), so maybe we can change mtNone to mtInvalid in the future? ------------- PR: https://git.openjdk.org/jdk/pull/10412 From pchilanomate at openjdk.org Wed Sep 28 14:43:43 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 28 Sep 2022 14:43:43 GMT Subject: RFR: 8294370: Fix allocation bug in java_lang_Thread::async_get_stack_trace() [v2] In-Reply-To: References: Message-ID: <0WKocsH7YOhswIyiLidi6eyr-xqrGwLCIBo32VN7HO4=.24a710c3-f767-4474-a0c9-ac6ff79fea36@github.com> > Please review this small fix in async_get_stack_trace(). The GrowableArrays created to store the bci and Method* of each frame found while traversing the stack are allocated in the resource area of the thread that calls async_get_stack_trace(). But if the handshake is executed by the target and if the number of frames in the stack exceeds the initial size of the GrowableArrays then we will hit an assertion when trying to grow the size of the arrays (see bug description). > Currently we don't see any issues because the initial size of the GrowableArrays is 512 and our tests don't test beyond that (the maximum value of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be easily reproduced by either decreasing the initial size of the GrowableArrays or by increasing the value of DEPTH in those strace tests. > To fix it I allocated the arrays in the C heap instead. Also I lowered the initial size of the arrays since 512 seemed too much to start with. > Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Improve comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10424/files - new: https://git.openjdk.org/jdk/pull/10424/files/5e375a83..68486d1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10424&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10424&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10424.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10424/head:pull/10424 PR: https://git.openjdk.org/jdk/pull/10424 From pchilanomate at openjdk.org Wed Sep 28 14:46:33 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 28 Sep 2022 14:46:33 GMT Subject: RFR: 8294370: Fix allocation bug in java_lang_Thread::async_get_stack_trace() [v2] In-Reply-To: <0WKocsH7YOhswIyiLidi6eyr-xqrGwLCIBo32VN7HO4=.24a710c3-f767-4474-a0c9-ac6ff79fea36@github.com> References: <0WKocsH7YOhswIyiLidi6eyr-xqrGwLCIBo32VN7HO4=.24a710c3-f767-4474-a0c9-ac6ff79fea36@github.com> Message-ID: On Wed, 28 Sep 2022 14:43:43 GMT, Patricio Chilano Mateo wrote: >> Please review this small fix in async_get_stack_trace(). The GrowableArrays created to store the bci and Method* of each frame found while traversing the stack are allocated in the resource area of the thread that calls async_get_stack_trace(). But if the handshake is executed by the target and if the number of frames in the stack exceeds the initial size of the GrowableArrays then we will hit an assertion when trying to grow the size of the arrays (see bug description). >> Currently we don't see any issues because the initial size of the GrowableArrays is 512 and our tests don't test beyond that (the maximum value of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be easily reproduced by either decreasing the initial size of the GrowableArrays or by increasing the value of DEPTH in those strace tests. >> To fix it I allocated the arrays in the C heap instead. Also I lowered the initial size of the arrays since 512 seemed too much to start with. >> Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Improve comment Thanks for the reviews David and Serguei! ------------- PR: https://git.openjdk.org/jdk/pull/10424 From mernst at openjdk.org Wed Sep 28 14:49:20 2022 From: mernst at openjdk.org (Michael Ernst) Date: Wed, 28 Sep 2022 14:49:20 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Regarding breaking up the pull request: * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape. * I have spent a nontrivial amount of time on these fixes. There have been long delays, which forced me to resolve merge conflicts. I was told that the changes are "mostly fine" without any indication of what is wrong. I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted. * No one has explained what to do. "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is. I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to corrections. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From dfuchs at openjdk.org Wed Sep 28 15:13:39 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 28 Sep 2022 15:13:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 14:45:54 GMT, Michael Ernst wrote: >> Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Reinstate typos in Apache code that is copied into the JDK >> - Merge ../jdk-openjdk into typos-typos >> - Remove file that was removed upstream >> - Fix inconsistency in capitalization >> - Undo change in zlip >> - Fix typos > > Regarding breaking up the pull request: > * No one has stated that this is actually necessary or given a guarantee that it will result in a merged pull request, only that it *might* finally free this pull request of red tape. > * Despite my repeated requests, no one has justified that *this particular pull request* needs the expertise of different teams. The only reasons stated have been custom and bureaucracy. > * I have spent a nontrivial amount of time on these fixes. There have been long delays, which forced me to resolve merge conflicts. I was told that the changes are "mostly fine" without any indication of what is wrong. I am reluctant to spend yet more time, only to later (maybe weeks later, as has already happened) find out that I still have to do something else or that all my effort was wasted. > * I was condescendingly told "We have discussed several times in the past ..." even though I was not privy to those discussions. No pointer to documentation in the JDK itself, about pull requests, was given. > * No one has explained what to do. "separate PRs by team" doesn't tell me what to do, since I don't see an org chart anywhere in the documentation that tells me what a "team" is. > > I'm sorry to state it so bluntly, but this is not a good look for the JDK team being welcoming to contributions. Hi @mernst, sorry if this is how it appears. Pull requests that involve changes spanning a large set of files are notoriously harder to review since they require a reviewer from each different area to chime in. Basically you will need one reviewer from each of these areas: - client - compiler - core-libs - hotspot - i18n - javadoc - jmx - net - nio - security - serviceability Jaikiran suggested to reduce the scope of this PR in his first comment: https://github.com/openjdk/jdk/pull/10029#issuecomment-1236588632 as did several other reviewers. Sorry if the meaning (or reason) was not clear. best regards, ------------- PR: https://git.openjdk.org/jdk/pull/10029 From aivanov at openjdk.org Wed Sep 28 15:28:24 2022 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 28 Sep 2022 15:28:24 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Wed Sep 28 15:35:40 2022 From: mernst at openjdk.org (Michael Ernst) Date: Wed, 28 Sep 2022 15:35:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 15:26:13 GMT, Alexey Ivanov wrote: > The title says under `test/jdk/*`, yet there are lots of files changed in `src/*`. The title was edited by someone other than me, as you can see from the PR history. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From cjplummer at openjdk.org Wed Sep 28 17:20:34 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 28 Sep 2022 17:20:34 GMT Subject: RFR: 8294411: SA should provide more useful info when it fails to start up due to "failed to workaround classshareing" In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 05:16:35 GMT, Chris Plummer wrote: > Sometimes SA fails to startup with the following error message: > > ERROR: failed to workaround classshareing > Unable to open core file > > The code in question is init_classsharing_workaround() in ps_core_common.c. There a number of reasons why the class sharing work around can fail, and the reason is usually pretty well described with a print_debug() statement. However, since this is an error, these should really just be print_error() statements so the user doesn't need to figure out how to get more info by setting LIBSAPROC_DEBUG (which may also produce a ton of output unrelated to the error). Thanks, Kevin and Serguei! ------------- PR: https://git.openjdk.org/jdk/pull/10438 From cjplummer at openjdk.org Wed Sep 28 17:20:34 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 28 Sep 2022 17:20:34 GMT Subject: Integrated: 8294411: SA should provide more useful info when it fails to start up due to "failed to workaround classshareing" In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 05:16:35 GMT, Chris Plummer wrote: > Sometimes SA fails to startup with the following error message: > > ERROR: failed to workaround classshareing > Unable to open core file > > The code in question is init_classsharing_workaround() in ps_core_common.c. There a number of reasons why the class sharing work around can fail, and the reason is usually pretty well described with a print_debug() statement. However, since this is an error, these should really just be print_error() statements so the user doesn't need to figure out how to get more info by setting LIBSAPROC_DEBUG (which may also produce a ton of output unrelated to the error). This pull request has now been integrated. Changeset: 3b7fc80b Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/3b7fc80b1887db957a0134592eb0711c225ba64c Stats: 15 lines in 1 file changed: 2 ins; 0 del; 13 mod 8294411: SA should provide more useful info when it fails to start up due to "failed to workaround classshareing" Reviewed-by: kevinw, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/10438 From coleenp at openjdk.org Wed Sep 28 18:23:34 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 28 Sep 2022 18:23:34 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 13:45:53 GMT, Johan Sj?len wrote: >> Here's a suggested solution for the ticket mentioned and a use case for outputStream. I'm not attached to the name. >> >> This saves space for all allocated outputStreams, which is nice. It also makes the purpose of ResourceObj more clear ("please handle the life cycle for me"), reducing the need for it. >> >> Thank you for considering it. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Introduce new, invalid, memory flag > - delete _print_inlining_stream > - Merge remote-tracking branch 'origin/master' into dyn-cheapobj > - Avoid leaking predString > - Try out Coleen's suggestion > - DynCHeapObj Changes requested by coleenp (Reviewer). src/hotspot/share/opto/compile.hpp line 1064: > 1062: delete _print_inlining_stream; > 1063: }; > 1064: compile.cpp has print_inlining_stream_free() calls which will leak the stringStream now if called. I think this function needs to be removed and it should call the reset function to reinitialize the stream. There should be compiler tests that will fail if print_inlining_stream_free() is called with a null _print_inlining_stream pointer (I think the delete should fail (?) with null) src/hotspot/share/utilities/ostream.hpp line 45: > 43: // This allows for redirection via -XX:+DisplayVMOutputToStdout and > 44: // -XX:+DisplayVMOutputToStderr > 45: class outputStream : public CHeapObj { Were you going to change this to mtInvalid to require all components to pass the appropriate mtComponent flag? People might bikeshed on the name mtInvalid - it could also be mtOverride or mtDynamic. In any case, this is a nice improvement. ------------- PR: https://git.openjdk.org/jdk/pull/10412 From cjplummer at openjdk.org Wed Sep 28 20:35:20 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 28 Sep 2022 20:35:20 GMT Subject: RFR: 8293563: [macos-aarch64] SA core file tests failing with sun.jvm.hotspot.oops.UnknownOopException In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 21:38:43 GMT, Chris Plummer wrote: > JDK-8293563 is due to a macOS bug (or maybe a feature) that is resulting in the java heap not always being present in the core file. Running with `-XX:+AlwaysPreTouch` seems to work around this problem. This issue is only on macosx-aarch64, not x64. Thanks, Serguei and Kevin! ------------- PR: https://git.openjdk.org/jdk/pull/10458 From cjplummer at openjdk.org Wed Sep 28 20:38:50 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 28 Sep 2022 20:38:50 GMT Subject: Integrated: 8293563: [macos-aarch64] SA core file tests failing with sun.jvm.hotspot.oops.UnknownOopException In-Reply-To: References: Message-ID: On Tue, 27 Sep 2022 21:38:43 GMT, Chris Plummer wrote: > JDK-8293563 is due to a macOS bug (or maybe a feature) that is resulting in the java heap not always being present in the core file. Running with `-XX:+AlwaysPreTouch` seems to work around this problem. This issue is only on macosx-aarch64, not x64. This pull request has now been integrated. Changeset: 76f18651 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/76f1865124025ee6f788a50e1377b82fd577548f Stats: 28 lines in 7 files changed: 13 ins; 0 del; 15 mod 8293563: [macos-aarch64] SA core file tests failing with sun.jvm.hotspot.oops.UnknownOopException Reviewed-by: sspitsyn, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/10458 From cjplummer at openjdk.org Wed Sep 28 22:45:13 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 28 Sep 2022 22:45:13 GMT Subject: RFR: 8294547: HotSpotAgent.setupVM() should include "cause" exception when throwing DebuggerException Message-ID: In `HotSpotAgent.setupVM()`, if there is an underlying exception in the vm setup, the exception is consumed and a `DebuggerException` is thrown, hiding the root cause. When throwing the `DebuggerException`, the "cause" exception should be included. This provides a more detailed exception stack trace, such as the following: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:428) at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:338) at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:158) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:210) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:69) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) Caused by: sun.jvm.hotspot.debugger.NoSuchSymbolException: Could not find symbol "gHotSpotVMTypes" in any of the known library names (jvm.dll) at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.lookupInProcess(HotSpotTypeDataBase.java:622) at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.readVMTypes(HotSpotTypeDataBase.java:154) at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.(HotSpotTypeDataBase.java:89) at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:407) ... 7 more I'd like to push this as a trivial change. ------------- Commit messages: - Include cause exception Changes: https://git.openjdk.org/jdk/pull/10474/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10474&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294547 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10474.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10474/head:pull/10474 PR: https://git.openjdk.org/jdk/pull/10474 From cjplummer at openjdk.org Wed Sep 28 23:53:52 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 28 Sep 2022 23:53:52 GMT Subject: RFR: 8294548: Problem list SA core file tests on macosx-x64 due to JDK-8294316 Message-ID: The SA core file tests are already problem listed on macosx-x64 due to [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433), but they should also be due to [JDK-8294316](https://bugs.openjdk.org/browse/JDK-8294316), which is actually the much more serious of the two issues. I'd like to push this as a trivial change. ------------- Commit messages: - problemlist sa core file tests Changes: https://git.openjdk.org/jdk/pull/10476/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10476&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294548 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10476.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10476/head:pull/10476 PR: https://git.openjdk.org/jdk/pull/10476 From sspitsyn at openjdk.org Thu Sep 29 00:57:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Sep 2022 00:57:22 GMT Subject: RFR: 8294548: Problem list SA core file tests on macosx-x64 due to JDK-8294316 In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 23:32:24 GMT, Chris Plummer wrote: > The SA core file tests are already problem listed on macosx-x64 due to [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433), but they should also be due to [JDK-8294316](https://bugs.openjdk.org/browse/JDK-8294316), which is actually the much more serious of the two issues. > > I'd like to push this as a trivial change. Looks good and trivial. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10476 From sspitsyn at openjdk.org Thu Sep 29 01:01:24 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Sep 2022 01:01:24 GMT Subject: RFR: 8294547: HotSpotAgent.setupVM() should include "cause" exception when throwing DebuggerException In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 22:38:44 GMT, Chris Plummer wrote: > In `HotSpotAgent.setupVM()`, if there is an underlying exception in the vm setup, the exception is consumed and a `DebuggerException` is thrown, hiding the root cause. When throwing the `DebuggerException`, the "cause" exception should be included. This provides a more detailed exception stack trace, such as the following: > > > Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in > remote process) > sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:428) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:338) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:158) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:210) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:69) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) > Caused by: sun.jvm.hotspot.debugger.NoSuchSymbolException: Could not find symbol "gHotSpotVMTypes" in any of the known library names (jvm.dll) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.lookupInProcess(HotSpotTypeDataBase.java:622) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.readVMTypes(HotSpotTypeDataBase.java:154) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.(HotSpotTypeDataBase.java:89) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:407) > ... 7 more > > > I'd like to push this as a trivial change. Looks good and trivial. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10474 From sspitsyn at openjdk.org Thu Sep 29 07:28:49 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 29 Sep 2022 07:28:49 GMT Subject: RFR: 8288907: serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java fails with -XX:TieredStopAtLevel=2,3 Message-ID: The test SuspendResume fails on linux-aarch64 with timeouts. However, it never fails when test timeout is set to a bigger value: diff --git a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java index cd5b8251fce..562f2eae921 100644 --- a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java +++ b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java @@ -29,7 +29,7 @@ * @library /test/lib * @compile --enable-preview -source ${jdk.version} SuspendResume1.java * @run driver jdk.test.lib.FileInstaller . . - * @run main/othervm/native + * @run main/othervm/native/timeout=600 * --enable-preview * -Djava.util.concurrent.ForkJoinPool.common.parallelism=1 * -agentlib:SuspendResume1 I'd like to push this as a trivial fix. Testing: Submitted mach5 test runs on multiple platforms. ------------- Commit messages: - 8288907: serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java fails with -XX:TieredStopAtLevel=2,3 Changes: https://git.openjdk.org/jdk/pull/10480/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10480&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288907 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10480.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10480/head:pull/10480 PR: https://git.openjdk.org/jdk/pull/10480 From dholmes at openjdk.org Thu Sep 29 07:53:07 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Sep 2022 07:53:07 GMT Subject: RFR: 8288907: serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java fails with -XX:TieredStopAtLevel=2,3 In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 07:21:46 GMT, Serguei Spitsyn wrote: > The test SuspendResume fails on linux-aarch64 with timeouts. > However, it never fails when test timeout is set to a bigger value: > > diff --git a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java > index cd5b8251fce..562f2eae921 100644 > --- a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java > +++ b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java > @@ -29,7 +29,7 @@ > * @library /test/lib > * @compile --enable-preview -source ${jdk.version} SuspendResume1.java > * @run driver jdk.test.lib.FileInstaller . . > - * @run main/othervm/native > + * @run main/othervm/native/timeout=600 > * --enable-preview > * -Djava.util.concurrent.ForkJoinPool.common.parallelism=1 > * -agentlib:SuspendResume1 > > > I'd like to push this as a trivial fix. > > Testing: Submitted mach5 test runs on multiple platforms. Seems fine and trivial to me. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10480 From jsjolen at openjdk.org Thu Sep 29 08:52:16 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 29 Sep 2022 08:52:16 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 18:21:09 GMT, Coleen Phillimore wrote: >> Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Introduce new, invalid, memory flag >> - delete _print_inlining_stream >> - Merge remote-tracking branch 'origin/master' into dyn-cheapobj >> - Avoid leaking predString >> - Try out Coleen's suggestion >> - DynCHeapObj > > src/hotspot/share/opto/compile.hpp line 1064: > >> 1062: delete _print_inlining_stream; >> 1063: }; >> 1064: > > compile.cpp has print_inlining_stream_free() calls which will leak the stringStream now if called. I think this function needs to be removed and it should call the reset function to reinitialize the stream. > There should be compiler tests that will fail if print_inlining_stream_free() is called with a null _print_inlining_stream pointer (I think the delete should fail (?) with null) This is removed as part of https://github.com/openjdk/jdk/pull/10396 . The function used to be here but I merged with upstream when that went in. delete on null is OK, just like with free. ------------- PR: https://git.openjdk.org/jdk/pull/10412 From sgehwolf at openjdk.org Thu Sep 29 09:35:39 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 29 Sep 2022 09:35:39 GMT Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts [v4] In-Reply-To: References: Message-ID: > Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2: > > > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java > test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java > > > I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`. > > Testing: > - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix) > - [x] added tests fail before, pass after the product fix. > - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. > - [x] GHA all pass. > > Please review! Many thanks in advance. Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Add comments/@bug in tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10248/files - new: https://git.openjdk.org/jdk/pull/10248/files/8059dd81..6061a475 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=02-03 Stats: 6 lines in 4 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10248.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248 PR: https://git.openjdk.org/jdk/pull/10248 From sgehwolf at openjdk.org Thu Sep 29 09:35:39 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 29 Sep 2022 09:35:39 GMT Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts [v3] In-Reply-To: References: <-GC6RSB-rnXjie1pCd0k7bzPNbGlmyRbR6xyNNJNWzU=.c428b704-c7e6-450f-8107-63ce417e6408@github.com> Message-ID: <85W4uWEoa4BGsXK82_8x1y16cg3pPpDf5QO-2l5tp6Q=.023d9525-e803-434a-b831-a4d3b5bb7617@github.com> On Wed, 28 Sep 2022 05:45:14 GMT, Ioi Lam wrote: >> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> 8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts > > The JDK change looks good to me. Some nits for the test cases. Thanks for the review @iklam! > test/jdk/jdk/internal/platform/docker/TestDockerBasic.java line 26: > >> 24: /* >> 25: * @test >> 26: * @summary Verify that -XshowSettings:system works > > Add `@bug 8293540` Thanks, added. > test/jdk/jdk/internal/platform/docker/TestDockerBasic.java line 64: > >> 62: opts.addDockerOpts("--memory", "300m"); >> 63: if (addCgroupMounts) { >> 64: opts.addDockerOpts("--volume", "/sys/fs/cgroup:/cgroup-in:ro"); > > Add comments that the extra mount should be ignored by the cgroup set-up code. (Same for other test cases). OK. Added in the updated version. ------------- PR: https://git.openjdk.org/jdk/pull/10248 From jsjolen at openjdk.org Thu Sep 29 09:56:24 2022 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 29 Sep 2022 09:56:24 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3] In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 13:45:53 GMT, Johan Sj?len wrote: >> Here's a suggested solution for the ticket mentioned and a use case for outputStream. I'm not attached to the name. >> >> This saves space for all allocated outputStreams, which is nice. It also makes the purpose of ResourceObj more clear ("please handle the life cycle for me"), reducing the need for it. >> >> Thank you for considering it. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Introduce new, invalid, memory flag > - delete _print_inlining_stream > - Merge remote-tracking branch 'origin/master' into dyn-cheapobj > - Avoid leaking predString > - Try out Coleen's suggestion > - DynCHeapObj I still have to go through all of this and check for memory leaks, just FYI. ------------- PR: https://git.openjdk.org/jdk/pull/10412 From kbarrett at openjdk.org Thu Sep 29 11:10:10 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 29 Sep 2022 11:10:10 GMT Subject: RFR: 8294308: Allow dynamically choosing the MEMFLAGS of a type without ResourceObj [v3] In-Reply-To: <8HwXXsQs7ymwwOCwOYVeyISo6akG2_XBOVf2ILTjFuQ=.5b323620-ca06-4200-9301-2f64bbc85374@github.com> References: <8HwXXsQs7ymwwOCwOYVeyISo6akG2_XBOVf2ILTjFuQ=.5b323620-ca06-4200-9301-2f64bbc85374@github.com> Message-ID: On Wed, 28 Sep 2022 13:41:06 GMT, Johan Sj?len wrote: >> Or you could have the class that requires dynamic mtFlag be declared with mtNone and assert in one place in AllocateHeap that mt != mtNone. Actually that assert might already be there. Can't really puzzle out what Kim's change does. > > I added a mtInvalid flag and did the assert. mtNone seems to be dealt with in some code, I'm not sure if it's appropriate to use it as an invalid value. Regardless, mtInvalid is a better name (for this purpose), so maybe we can change mtNone to mtInvalid in the future? A much simpler (in the sense of avoiding the use of advanced template features) alternative to the one I posted earlier. (Thanks to @stefank for the suggestion.) https://github.com/openjdk/jdk/compare/master...kimbarrett:openjdk-jdk:dynamic-memflags-specialize I dislike the current proposed approach of adding an optional MEMFLAGS argument to all the CHeapObj allocation functions. ------------- PR: https://git.openjdk.org/jdk/pull/10412 From sgehwolf at openjdk.org Thu Sep 29 12:11:25 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 29 Sep 2022 12:11:25 GMT Subject: RFR: 8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts [v5] In-Reply-To: References: Message-ID: > Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2: > > > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java > test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java > > > I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`. > > Testing: > - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix) > - [x] added tests fail before, pass after the product fix. > - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. > - [x] GHA all pass. > > Please review! Many thanks in advance. 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 three additional commits since the last revision: - Merge branch 'master' into JDK-8293540-metrics-cgroups-mounts - Add comments/@bug in tests - 8293540: [Metrics] Potentially incorrectly detected resource limits with additional cgroup fs mounts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10248/files - new: https://git.openjdk.org/jdk/pull/10248/files/6061a475..3ecb3b9d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10248&range=03-04 Stats: 30991 lines in 1069 files changed: 14803 ins; 10731 del; 5457 mod Patch: https://git.openjdk.org/jdk/pull/10248.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10248/head:pull/10248 PR: https://git.openjdk.org/jdk/pull/10248 From pchilanomate at openjdk.org Thu Sep 29 15:38:49 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 29 Sep 2022 15:38:49 GMT Subject: Integrated: 8294370: Fix allocation bug in java_lang_Thread::async_get_stack_trace() In-Reply-To: References: Message-ID: <8SL4dWPsOCNogjLSsa0QFR9mh-n3n5TVbriMfmtXU1E=.616f0158-50f5-427d-927d-4577ef9a8251@github.com> On Mon, 26 Sep 2022 14:23:38 GMT, Patricio Chilano Mateo wrote: > Please review this small fix in async_get_stack_trace(). The GrowableArrays created to store the bci and Method* of each frame found while traversing the stack are allocated in the resource area of the thread that calls async_get_stack_trace(). But if the handshake is executed by the target and if the number of frames in the stack exceeds the initial size of the GrowableArrays then we will hit an assertion when trying to grow the size of the arrays (see bug description). > Currently we don't see any issues because the initial size of the GrowableArrays is 512 and our tests don't test beyond that (the maximum value of DEPTH in the vmTestbase/nsk/stress/strace/ tests is 500). The issue can be easily reproduced by either decreasing the initial size of the GrowableArrays or by increasing the value of DEPTH in those strace tests. > To fix it I allocated the arrays in the C heap instead. Also I lowered the initial size of the arrays since 512 seemed too much to start with. > Tested it by running all tests in the vmTestbase/nsk/stress/strace/ directory. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 5d48da45 Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/5d48da4574f6aacb0db445dd5750566330aa383d Stats: 11 lines in 1 file changed: 6 ins; 0 del; 5 mod 8294370: Fix allocation bug in java_lang_Thread::async_get_stack_trace() Reviewed-by: dholmes, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/10424 From cjplummer at openjdk.org Thu Sep 29 16:11:30 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 29 Sep 2022 16:11:30 GMT Subject: RFR: 8288907: serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java fails with -XX:TieredStopAtLevel=2,3 In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 07:21:46 GMT, Serguei Spitsyn wrote: > The test SuspendResume fails on linux-aarch64 with timeouts. > However, it never fails when test timeout is set to a bigger value: > > diff --git a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java > index cd5b8251fce..562f2eae921 100644 > --- a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java > +++ b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java > @@ -29,7 +29,7 @@ > * @library /test/lib > * @compile --enable-preview -source ${jdk.version} SuspendResume1.java > * @run driver jdk.test.lib.FileInstaller . . > - * @run main/othervm/native > + * @run main/othervm/native/timeout=600 > * --enable-preview > * -Djava.util.concurrent.ForkJoinPool.common.parallelism=1 > * -agentlib:SuspendResume1 > > > I'd like to push this as a trivial fix. > > Testing: Submitted mach5 test runs on multiple platforms. I'm not so sure increasing the timeout is the right thing to do. Here are the results of running 5 times on each of our 5 platforms with `-XX:TieredStopAtLevel=2"` macosx-aarch64-debug 22s windows-x64-debug 23s windows-x64-debug 23s macosx-aarch64-debug 23s macosx-aarch64-debug 24s macosx-aarch64-debug 24s windows-x64-debug 24s macosx-x64-debug 24s macosx-aarch64-debug 25s macosx-x64-debug 26s macosx-x64-debug 26s macosx-x64-debug 26s macosx-x64-debug 26s windows-x64-debug 28s windows-x64-debug 33s linux-x64-debug 43s linux-x64-debug 45s linux-aarch64-debug 2m 17s linux-x64-debug 2m 20s linux-x64-debug 2m 42s linux-x64-debug 2m 59s linux-aarch64-debug 3m 22s linux-aarch64-debug 4m 31s linux-aarch64-debug 6m 30s linux-aarch64-debug 9m 22s The last one was a timeout. So it seems that linux-aarch64 is consistently slow. linux-x64 is also a bit slow in some cases. It seems it would be worth understanding these performance differences. ------------- PR: https://git.openjdk.org/jdk/pull/10480 From cjplummer at openjdk.org Thu Sep 29 16:23:39 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 29 Sep 2022 16:23:39 GMT Subject: RFR: 8288907: serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java fails with -XX:TieredStopAtLevel=2,3 In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 07:21:46 GMT, Serguei Spitsyn wrote: > The test SuspendResume fails on linux-aarch64 with timeouts. > However, it never fails when test timeout is set to a bigger value: > > diff --git a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java > index cd5b8251fce..562f2eae921 100644 > --- a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java > +++ b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java > @@ -29,7 +29,7 @@ > * @library /test/lib > * @compile --enable-preview -source ${jdk.version} SuspendResume1.java > * @run driver jdk.test.lib.FileInstaller . . > - * @run main/othervm/native > + * @run main/othervm/native/timeout=600 > * --enable-preview > * -Djava.util.concurrent.ForkJoinPool.common.parallelism=1 > * -agentlib:SuspendResume1 > > > I'd like to push this as a trivial fix. > > Testing: Submitted mach5 test runs on multiple platforms. I also tried the same with product builds. linux-aarch64 got worse, with 4 out of 5 timing out. linux-x64 improved with only one run over 1m. ------------- PR: https://git.openjdk.org/jdk/pull/10480 From coleenp at openjdk.org Thu Sep 29 17:48:37 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 29 Sep 2022 17:48:37 GMT Subject: RFR: 8294547: HotSpotAgent.setupVM() should include "cause" exception when throwing DebuggerException In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 22:38:44 GMT, Chris Plummer wrote: > In `HotSpotAgent.setupVM()`, if there is an underlying exception in the vm setup, the exception is consumed and a `DebuggerException` is thrown, hiding the root cause. When throwing the `DebuggerException`, the "cause" exception should be included. This provides a more detailed exception stack trace, such as the following: > > > Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in > remote process) > sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:428) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:338) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:158) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:210) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:69) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) > Caused by: sun.jvm.hotspot.debugger.NoSuchSymbolException: Could not find symbol "gHotSpotVMTypes" in any of the known library names (jvm.dll) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.lookupInProcess(HotSpotTypeDataBase.java:622) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.readVMTypes(HotSpotTypeDataBase.java:154) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.(HotSpotTypeDataBase.java:89) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:407) > ... 7 more > > > I'd like to push this as a trivial change. Thank you! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/10474 From cjplummer at openjdk.org Thu Sep 29 18:34:14 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 29 Sep 2022 18:34:14 GMT Subject: Integrated: 8294548: Problem list SA core file tests on macosx-x64 due to JDK-8294316 In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 23:32:24 GMT, Chris Plummer wrote: > The SA core file tests are already problem listed on macosx-x64 due to [JDK-8267433](https://bugs.openjdk.org/browse/JDK-8267433), but they should also be due to [JDK-8294316](https://bugs.openjdk.org/browse/JDK-8294316), which is actually the much more serious of the two issues. > > I'd like to push this as a trivial change. This pull request has now been integrated. Changeset: 545ded1a Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/545ded1a82baf62ef551b2be2a08ee29ab5d9311 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod 8294548: Problem list SA core file tests on macosx-x64 due to JDK-8294316 Reviewed-by: sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/10476 From cjplummer at openjdk.org Thu Sep 29 18:35:32 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 29 Sep 2022 18:35:32 GMT Subject: Integrated: 8294547: HotSpotAgent.setupVM() should include "cause" exception when throwing DebuggerException In-Reply-To: References: Message-ID: <9IahbWLjFT3U7XQ2xxV99thL46k9cQrcPUOGg03FoZg=.6d80d011-9c76-456a-95aa-63be1471ed32@github.com> On Wed, 28 Sep 2022 22:38:44 GMT, Chris Plummer wrote: > In `HotSpotAgent.setupVM()`, if there is an underlying exception in the vm setup, the exception is consumed and a `DebuggerException` is thrown, hiding the root cause. When throwing the `DebuggerException`, the "cause" exception should be included. This provides a more detailed exception stack trace, such as the following: > > > Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in > remote process) > sun.jvm.hotspot.debugger.DebuggerException: Doesn't appear to be a HotSpot VM (could not find symbol "gHotSpotVMTypes" in remote process) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:428) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:338) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:158) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.attachDebugger(CLHSDB.java:210) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:69) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500) > Caused by: sun.jvm.hotspot.debugger.NoSuchSymbolException: Could not find symbol "gHotSpotVMTypes" in any of the known library names (jvm.dll) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.lookupInProcess(HotSpotTypeDataBase.java:622) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.readVMTypes(HotSpotTypeDataBase.java:154) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.(HotSpotTypeDataBase.java:89) > at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:407) > ... 7 more > > > I'd like to push this as a trivial change. This pull request has now been integrated. Changeset: 5f6ad926 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/5f6ad926d7ea763bf61aa98c7be7087a7aa6089c Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8294547: HotSpotAgent.setupVM() should include "cause" exception when throwing DebuggerException Reviewed-by: sspitsyn, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/10474 From aturbanov at openjdk.org Thu Sep 29 21:18:36 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 29 Sep 2022 21:18:36 GMT Subject: RFR: 8289711: Add container configuration data to mbeans [v10] In-Reply-To: References: Message-ID: On Wed, 10 Aug 2022 02:10:25 GMT, xpbob wrote: >> Container configuration information is useful for troubleshooting problems,Exposing information in MBeans is ideal for monitoring, jConsole, and other scenarios. >> Results the following >> ![??](https://user-images.githubusercontent.com/7837910/177248834-50beefe9-4db6-470c-8f15-df5a93892804.png) > > xpbob has updated the pull request incrementally with one additional commit since the last revision: > > add bean to list src/jdk.management/share/classes/com/sun/management/ContainerInfoMXBean.java line 31: > 29: * This is a special bean , only available on Linux systems > 30: */ > 31: public interface ContainerInfoMXBean extends PlatformManagedObject { let's remove one redundant space before `extends` ------------- PR: https://git.openjdk.org/jdk/pull/9372 From darcy at openjdk.org Fri Sep 30 00:40:24 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 00:40:24 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org Message-ID: With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. Updates were made using a shell script. I"ll run a copyright updater before any push. ------------- Commit messages: - JDK-8294618: Update openjdk.java.net => openjdk.org Changes: https://git.openjdk.org/jdk/pull/10501/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294618 Stats: 79 lines in 39 files changed: 0 ins; 0 del; 79 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 00:54:05 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 00:54:05 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2] In-Reply-To: References: Message-ID: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com> > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: - Update copyright. - Revert unintended update to binary file. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/b12d774f..2f257762 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=00-01 Stats: 10 lines in 11 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From mikael at openjdk.org Fri Sep 30 00:54:06 2022 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 30 Sep 2022 00:54:06 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v2] In-Reply-To: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com> References: <0BcqbC6x_sIhKNxYSL9KNDSyLc1UhJEs-DiWe9uTmRg=.4a85ed60-f7cf-4e92-8315-777ab768f8c3@github.com> Message-ID: On Fri, 30 Sep 2022 00:50:13 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright. > - Revert unintended update to binary file. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10501 From mikael at openjdk.org Fri Sep 30 00:54:08 2022 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 30 Sep 2022 00:54:08 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 00:33:57 GMT, Joe Darcy wrote: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Switch to https where needed/applicable while at it? ------------- PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 01:01:29 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 01:01:29 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v3] In-Reply-To: References: Message-ID: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Undo manpage update. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/2f257762..04dfc3ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 01:11:45 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 01:11:45 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: http -> https ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/04dfc3ef..cee96d0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=02-03 Stats: 22 lines in 6 files changed: 0 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 01:11:45 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 01:11:45 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 00:48:02 GMT, Mikael Vidstedt wrote: > Switch to https where needed/applicable while at it? Good idea; might as well do the update in a single changeset. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From iris at openjdk.org Fri Sep 30 04:11:19 2022 From: iris at openjdk.org (Iris Clark) Date: Fri, 30 Sep 2022 04:11:19 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > http -> https Marked as reviewed by iris (Reviewer). src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: > 32: * the following link: > 33: * > 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c The domain for hg wasn't changed to openjdk.org. The original URL is correct. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From dholmes at openjdk.org Fri Sep 30 04:40:24 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Sep 2022 04:40:24 GMT Subject: RFR: 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 01:32:44 GMT, Leonid Mesnik wrote: > 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE Why is `JVMTI_ERROR_WRONG_PHASE` a valid result here? ------------- PR: https://git.openjdk.org/jdk/pull/10502 From sspitsyn at openjdk.org Fri Sep 30 06:26:26 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 30 Sep 2022 06:26:26 GMT Subject: RFR: 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 04:37:58 GMT, David Holmes wrote: > Why is `JVMTI_ERROR_WRONG_PHASE` a valid result here? I think, it is because the testing `suspendResumeThread` tread is a daemon thread. I'm not sure why it was set to be a daemon thread though. ------------- PR: https://git.openjdk.org/jdk/pull/10502 From sspitsyn at openjdk.org Fri Sep 30 06:41:20 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 30 Sep 2022 06:41:20 GMT Subject: RFR: 8288907: serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java fails with -XX:TieredStopAtLevel=2,3 In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 07:21:46 GMT, Serguei Spitsyn wrote: > The test SuspendResume fails on linux-aarch64 with timeouts. > However, it never fails when test timeout is set to a bigger value: > > diff --git a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java > index cd5b8251fce..562f2eae921 100644 > --- a/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java > +++ b/test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java > @@ -29,7 +29,7 @@ > * @library /test/lib > * @compile --enable-preview -source ${jdk.version} SuspendResume1.java > * @run driver jdk.test.lib.FileInstaller . . > - * @run main/othervm/native > + * @run main/othervm/native/timeout=600 > * --enable-preview > * -Djava.util.concurrent.ForkJoinPool.common.parallelism=1 > * -agentlib:SuspendResume1 > > > I'd like to push this as a trivial fix. > > Testing: Submitted mach5 test runs on multiple platforms. Thank you for the comment, Chris. I agree, this test is executed on linux-aarch64 much slower than on other platforms. Now, I can move this bug to the Compiler team plate or push my fix and open a Compiler bug separately. It feels like you prefer the former. ------------- PR: https://git.openjdk.org/jdk/pull/10480 From sgehwolf at openjdk.org Fri Sep 30 08:48:35 2022 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 30 Sep 2022 08:48:35 GMT Subject: Integrated: 8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 13:06:10 GMT, Severin Gehwolf wrote: > Similar issue to the hotspot change discussed in https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation may get the resource limits wrong if there are additional cgroup fs mounts. Apparently that's more common than one might think. I've reproduced this with these existing tests on cg v2: > > > test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java > test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java > > > I've also added `test/jdk/jdk/internal/platform/docker/TestDockerBasic.java` and amended `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` which unconditionally fails (irrespective of cgroup version in use). The fix is fairly straight forward and is an extension which we already do for the `cpuset` controller: Allow duplicates, and if there are any prefer those mounted at `/sys/fs/cgroup`. > > Testing: > - [x] fastdebug build on cgroups v2 and cgroups v1 (before and after the product fix) > - [x] added tests fail before, pass after the product fix. > - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still pass. > - [x] GHA all pass. > > Please review! Many thanks in advance. This pull request has now been integrated. Changeset: 6d83482a Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/6d83482a6b5f1898514fd450d8143dbfef57e362 Stats: 181 lines in 6 files changed: 143 ins; 23 del; 15 mod 8293540: [Metrics] Incorrectly detected resource limits with additional cgroup fs mounts Reviewed-by: iklam ------------- PR: https://git.openjdk.org/jdk/pull/10248 From kevinw at openjdk.org Fri Sep 30 12:55:43 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 30 Sep 2022 12:55:43 GMT Subject: RFR: 8283093: JMX connections should default to using an ObjectInputFilter Message-ID: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com> Set the management.properties "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized. Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication. The sun/management tests run OK with this change. The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive. ------------- Commit messages: - 8283093: JMX connections should default to using an ObjectInputFilter Changes: https://git.openjdk.org/jdk/pull/10507/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10507&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8283093 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10507.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10507/head:pull/10507 PR: https://git.openjdk.org/jdk/pull/10507 From rehn at openjdk.org Fri Sep 30 13:09:30 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 30 Sep 2022 13:09:30 GMT Subject: RFR: 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 01:32:44 GMT, Leonid Mesnik wrote: > 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE The reason for it to be a daemon is that this thread should try to suspend/resume when we are terminating, thus trying to hit those rare exit parts where we do thread exits with a pending suspend. ------------- PR: https://git.openjdk.org/jdk/pull/10502 From ihse at openjdk.org Fri Sep 30 14:01:18 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 30 Sep 2022 14:01:18 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > http -> https $ grep -rl doc make -e openjdk.java.net doc/hotspot-unit-tests.html doc/hotspot-style.html doc/building.html doc/hotspot-unit-tests.md doc/hotspot-style.md doc/building.md make/Doctor.gmk make/jdk/src/classes/build/tools/taglet/Incubating.java make/autoconf/configure.ac make/conf/branding.conf Think you can fix those as well? Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..? ------------- PR: https://git.openjdk.org/jdk/pull/10501 From weijun at openjdk.org Fri Sep 30 14:18:28 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 30 Sep 2022 14:18:28 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 04:05:51 GMT, Iris Clark wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> http -> https > > src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: > >> 32: * the following link: >> 33: * >> 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c > > The domain for hg wasn't changed to openjdk.org. The original URL is correct. Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`? ------------- PR: https://git.openjdk.org/jdk/pull/10501 From dfuchs at openjdk.org Fri Sep 30 15:15:21 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 30 Sep 2022 15:15:21 GMT Subject: RFR: 8283093: JMX connections should default to using an ObjectInputFilter In-Reply-To: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com> References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com> Message-ID: On Fri, 30 Sep 2022 11:00:28 GMT, Kevin Walls wrote: > Set the management.properties "com.sun.management.jmxremote.serial.filter.pattern" value by default, to restrict types that can be deserialized. > > Use the example value from the Core Libraries guide (see section 2. Serialization Filtering / Built-in Filters / Filters for JMX), plus Subject which is needed when using authentication. > > The sun/management tests run OK with this change. The existing test sun/management/jmxremote/startstop/JMXStartStopTest.java will fail if the filter specified is made too restrictive. Hi Kevin - have you tried connecting with jconsole to a java program (you can e.g. connect jconsole to itself) and verified that all looked OK and that there wasn't any exception logged while clicking through the various MBeans it exposes? ------------- PR: https://git.openjdk.org/jdk/pull/10507 From kevinw at openjdk.org Fri Sep 30 16:44:23 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 30 Sep 2022 16:44:23 GMT Subject: RFR: 8283093: JMX connections should default to using an ObjectInputFilter In-Reply-To: References: <8L9FZBqnLLsGXIZHIluwciYNsRj0C2z_o30mygplUTM=.d26739c4-5586-44b1-ab1c-b6e62d217f8c@github.com> Message-ID: On Fri, 30 Sep 2022 15:11:26 GMT, Daniel Fuchs wrote: > Hi Kevin - have you tried connecting with jconsole to a java program (you can e.g. connect jconsole to itself) and verified that all looked OK and that there wasn't any exception logged while clicking through the various MBeans it exposes? Yes, all looks good in a manual test with jconsole. (I did use jconsole to experiment with a too-restrictive filter, to see what errors it causes.) ------------- PR: https://git.openjdk.org/jdk/pull/10507 From prr at openjdk.org Fri Sep 30 17:42:29 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 30 Sep 2022 17:42:29 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 14:16:24 GMT, Weijun Wang wrote: >> src/jdk.accessibility/windows/native/include/bridge/AccessBridgeCalls.h line 34: >> >>> 32: * the following link: >>> 33: * >>> 34: * http://hg.openjdk.org/jdk9/jdk9/jdk/raw-file/tip/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c >> >> The domain for hg wasn't changed to openjdk.org. The original URL is correct. > > Why do we need to link to a URL? Why not `../../bridge/AccessBridgeCalls.c`? This is correct. AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../" ------------- PR: https://git.openjdk.org/jdk/pull/10501 From joehw at openjdk.org Fri Sep 30 18:12:25 2022 From: joehw at openjdk.org (Joe Wang) Date: Fri, 30 Sep 2022 18:12:25 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 01:11:45 GMT, Joe Darcy wrote: >> With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. >> >> Updates were made using a shell script. I"ll run a copyright updater before any push. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > http -> https The ones in java.xml look good to me. ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.org/jdk/pull/10501 From sspitsyn at openjdk.org Fri Sep 30 20:27:52 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 30 Sep 2022 20:27:52 GMT Subject: RFR: 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE In-Reply-To: References: Message-ID: <4ZvQD6hkKP6tdNx_7xYJYgZhTwJJmVCHlpOc6_IhRUc=.65052a1f-565b-48f2-8208-ce0a4bba4f09@github.com> On Fri, 30 Sep 2022 01:32:44 GMT, Leonid Mesnik wrote: > 8294406: Test runtime/handshake/HandshakeDirectTest.java failed: JVMTI_ERROR_WRONG_PHASE The fix looks good. Thanks, Serguei Thanks, Robbin. I see the point. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10502 From darcy at openjdk.org Fri Sep 30 20:29:20 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 20:29:20 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v5] In-Reply-To: References: Message-ID: > With the domain change from openjdk.java.net to openjdk.org, references to URLs in the sources should be updated. > > Updates were made using a shell script. I"ll run a copyright updater before any push. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Update hg URLs to git. - Merge branch 'master' into JDK-8294618 - http -> https - Undo manpage update. - Update copyright. - Revert unintended update to binary file. - JDK-8294618: Update openjdk.java.net => openjdk.org ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10501/files - new: https://git.openjdk.org/jdk/pull/10501/files/cee96d0a..fbaf3d4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10501&range=03-04 Stats: 2670 lines in 133 files changed: 1729 ins; 406 del; 535 mod Patch: https://git.openjdk.org/jdk/pull/10501.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10501/head:pull/10501 PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 20:29:21 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 20:29:21 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 13:59:12 GMT, Magnus Ihse Bursie wrote: > Also, FWIW, there are 100+ hits in `test` as well. But that is so many it might warrant a separate PR..? Yes; I think it is sufficient to update src and doc with this PR. ------------- PR: https://git.openjdk.org/jdk/pull/10501 From darcy at openjdk.org Fri Sep 30 20:29:22 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Sep 2022 20:29:22 GMT Subject: RFR: JDK-8294618: Update openjdk.java.net => openjdk.org [v4] In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 17:38:54 GMT, Phil Race wrote: > This is correct. AccessBridge.h is published with the include/header files of the JDK and anyone reading it there can't exactly make use of "../" Update to persistent git links. ------------- PR: https://git.openjdk.org/jdk/pull/10501